Архитектура проекта

Самый простой в реализации пример архитектуры - это двухуровневая конфигурация веб сервера. Однако она применима только к несложным и ненагруженным (по нынешним меркам) проектам.

Для сложных и высоконагруженных проектов одной двухуровневой схемой не обойтись, нужен отдельный этап в разработке проекта: проектирование архитектуры.

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

Если чёткого проектирования нет, а программисты слабо знакомы с предметной областью (а чаще вообще не знакомы), то часто выясняется, что сделано не совсем то или совсем не то. Требуется переделка, которая требует времени и может рождать дополнительные баги. Такой цикл может повторяться несколько раз, пока не подойдёт срок сдачи проекта. Как правило именно в этот момент до всех разработчиков доходит что нужно было на самом деле сделать, но времени уже нет.

Исполнитель пытается сдать то, что сделано, что непонятно как работает. Иногда это удаётся. Но если и удалось, то при попытке что-то поменять всё "рассыпается".

  Что необходимо учитывать при архитектурном проектировании

• TDD не применимо в разработке сайтов. Слишком сложно и слишком трудоёмко. Вёрстка, например, вообще не поддаётся автоматическому тестированию. Но этот метод может принести немалую пользу при разработке кастомных модулей и библиотек для сайта.
• ООП - требует подготовленных специалистов. Есть мнение, что ООП-программист - это вообще программист особого типа, им надо родиться. Если нет соответствующего опыта, то создавать проект с активным использованием ООП не рекомендуется, так как будет создан сильносвязанный и слабоуправляемый объектный "зоопарк".
• Использование фреймворков и библиотек, хотя и является оптимальным вариантом для большинства проектов, тоже представляет собой определённый риск при недостаточной подготовке команды и при отсутствии технического контроля со стороны ведущего разработчика.

  Бесплатные фреймворки не гарантируют преемственности своих разработок. Разработчики могут просто начать вести новую ветку, приостановив поддержку старой, а для клиента это означает либо возрастание риска уязвимости (если оставаться на старой ветке), либо большие вложения (если переводить работу проекта на новую ветку фреймворка).

  Материалы по теме

Доклады на конференции FailOver Conference Украина
• Разработка сложного высоконагруженного проекта без SQL
• Контейнерная виртуализация для растущих проектов