Дмитрий

В похожей известной мне ситуации заказчик, заказав оценку стоимости у десятка различных исполнителей, получил разброс стоимости проекта от 400 тысяч до 32 млн рублей. (Заказчик в итоге отказался от проекта вообще).

Не знаю, есть ли в такой ситуации вообще какое-то единственно правильное решение, но помочь вам могут методы оценки стоимости проекта, тот же самый PERT. В двух словах:
Декомпозируйте задачи настолько, насколько это необходимо для того, чтобы их оценить хотя бы предварительно.
Выполните, исходя из имеющегося опыта, оценку сроков получившихся задач по трём точкам: оптимистическую, наиболее вероятную, пессимистическую. В этих оценках постарайтесь учесть возможные риски.
Вычислите ожидаемое время проекта на основании получившихся оценок, накиньте пару стандартных отклонений в плюс и минус: получите достаточно широкую вилку суммарного времени работы над проектом, но с высокой вероятностью включающей в себя то время, которое может получиться по факту.
Умножьте получившиеся оценки на стоимость работы вашей команды (в час/день -- какую единицу при оценке сроков использовали), таким образом получите оценку стоимости проекта сверху и снизу. Презентуйте получившуюся вилку и скоуп проекта, который лёг в её основу, заказчику. Сужайте вилку на свой страх и риск.

Если нет опыта, на основании которого можно было бы оценить масштаб работы -- лучше откажитесь от проекта.
Если не готовы выполнить такую оценку бесплатно -- лучше откажитесь от проекта.
Если скоуп проекта даже в таких приблизительных рамках очертить не получается -- лучше откажитесь от проекта.
Избегайте заключения контракта с фиксированной стоимостью, не подлежащей пересмотру, основанной на такой поверхностной оценке.

Высокая неопределённость на начальных этапах проекта -- явление нормальное, но брать на себя какие-то обязательства в таких условиях -- ваш риск. Оцените, готовы ли вы пойти на него.

location ^~ /images {
    root /var/www;
}

Добавить атрибут к форме или полям autocomplete="off"

Вам не переносить надо, а сделать с нуля по образу и подобию.

TDD Кента Бека - помогает понять, откуда взялась популярная архитектура фреймворков тестирования (ссылка) - читала, мне частично помогла.
xUnit test patterns - не читала, но все советуют - тоже объясняет принципы написания тестов без четкой привязки к технологии (ссылка).
По разнице в подходах тестирования - существует пирамида тестирования, но на практике мне не всегда понятно, где границы - приемочные и UI тесты ориентированы на use cases - т.е. на путь - в какой последовательности юзер проходит фичу и какой результат ожидает на каждом шаге (заходит на страницу, заполняет данные, ждет ответа; программа-клиент получает токен, шлет запрос, ждет респонс), а модульные тесты ориентированы на проверку кода как изолированных элементов - т.е. тестирование происходит отдельно от общего процесса, в котором этот код используется, чтобы можно было локализовать проблему с максимальной точностью.
PHPUnit я изучала только по документации, просто прошлась по всем примерам, считаю приемлемым вариантом изучения. Лучше сначала хорошо понять PHPUnit, а потом учить Codeception. Учиться, как мокать и стабать, можно уже на конкретных задачах, по мере надобности.

$row = $conn->query("SELECT group_concat(age), sum(age) FROM table")->fetch_row();
echo $row[0];
echo "<br>";
echo $row[1];

const sum = str.match(/\d+/g).reduce((acc, n) => acc + +n, 0);

// или

let sum = 0;
for (const n of str.split(/\D+/)) {
  sum += Number(n);
}

preg_match_all('/\d+/', $str, $matches);
$sum = array_sum($matches[0]);

// или

$sum = 0;
foreach (preg_split('/\D+/', $str) as $n) {
  $sum += intval($n);
}

Js на начальном этапе не нужен, музчина из соседнего ответа не в теме.
Ну точнее он живёт видимо в прошлом веке и подключен к интернету через модем по телефонной линии. Учителя же подключены по 4g, и "ждать" перезагрузки будут миллисекунд 50.

По срокам же вынужден огорчить. Полгода упорных занятий дадут тебе первую кривую версию которую ещё года два допиливать и ужасаться своим решениям принятым на начальном этапе.