Гигиенический минимум нефункциональных требований современного проекта

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

С чем чаще будут сталкиваться проекты, которые закрывают глаза на всякие “технические штуки”?

• много ошибок находится уже в процессе эксплуатации пользователями, а не на стадии разработки и тестирования;
• на оценку возможности, сроков и трудоёмкости изменений в проект тратится много времени, порой больше, чем сами правки;
• при параллельной разработке нескольких функций требуется значительное количество дополнительного времени, чтобы объединить их вместе. Либо, разработка вообще не ведётся параллельно;
• взлом сайта, утечки данных;
• после публикации на продуктив функционал не работает или работает не так же как на площадке для разработки и на выяснение причин тратится много времени;
• подключение нового разработчика на проект занимает дни, а его полноценная адаптация для начала выполнения базовых задач — недели;
• невозможно использовать готовые решения из-за старого ПО;
• проблемы с производительностью;
• невозможность восстановить данные после их потери за счёт ошибок или сбоев в ПО или железе;
• невозможность воспроизвести проблемы и длительный срок диагностики для выявления их причин;
• внезапно “упавший” сайт, даже если его давно никто не дорабатывал (прим.: кончилось место на диске).

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

Какие требования разработчики должны соблюдать, чтобы таких проблем было сильно меньше?

• настроить системы регулярного резервного копирования (прим. BorgBackup);
• следовать одному стилю оформления кода (прим. PSR-12) и настроить статический анализ кода на автоматическую проверку следования (прим. PHP CS Fixer);
• фиксировать изменения в коде через систему контроля версий (прим. Git);
• использовать пакетные менеджеры зависимостей (прим. npm, Composer);
• использовать стабильные и актуальные версии ПО, если нет веских причин этого не делать;
• настроить статический анализ качества кода и статически типизировать код (прим. Psalm, PHPMD);
• проверять код через процедуру ревью (например, через GitLab);
• вносить изменения в структуру таблиц СУБД используя миграции (прим. doctrine-migrations);
• критичные части кода и бизнес-сценариев покрыть автоматическими тестами (например с использованием PHPUnit, CodeceptJS);
• настроить систему контроля метрик: доступности, ресурсов, производительности (прим. Zabbix);

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

Мы считаем вышеперечисленные требования критичными для большинства проектов, однако, в зависимости от специфики конкретного проекта на первый план могут выходить и другие важные требования. Перечислим их вкратце:

• описывать и запускать окружения автоматизированным и воспроизводимым образом (прим. Docker, Nix);
• централизовано собирать логи разных частей приложения (прим. ELK);
• регулярно замерять производительность критичных участков кода (тесты производительности, прим. PHPBench) и приложения в целом (нагрузочное тестирование, прим. Apache JMeter);
• использовать CI/CD для стандартизации и автоматизации релизов (прим. GitLab CI/CD);
• вести документацию архитектурных решений (ADR);
• использовать фоновую обработку подходящих задач (прим. RabbitMQ).

Выделите время на качественный фундамент вашего проекта и оно окупится почти сразу. Удачных проектов!