Я в своей жизни ещё ни разу не встречал проекта, где бы всё было сделано по правилам проектирования архитектуры, с хорошей документацией и чётким пониманием того, куда движется проект. Как правило — это ужасный легаси код, отсутствие не только документации, а даже каких-либо комментариев в самом коде, полное отсутствие логики построения приложения и полное попустительство со стороны заказчика. Что же делать и как с этим жить?
Для начала нужно проанализировать ситуацию, почему так вообще происходит. Причин для этого много:
- нежелание заказчика контролировать команду разработчиков
- отсутствие на проекте архитектора и тимлида
- отсутствие код-ревью
- отсутствие в команде понимания, что такое командная работа
- банальная лень и непрофессионализм
- очень сжатые сроки для разработки
Причин на самом деле может быть много, но это одни из основных. Самое первое заблуждение, которое делает заказчик/начальство, это то, что они считают, что программист — это тот человек, который может самоорганизоваться, умеет строить архитектуру, обладает аналитическим складом ума, и только и мечтает, как создать программный шедевр.
Это очень частые и роковые заблуждения. Для наглядности, можно сравнить команду разработчиков со строительной бригадой. Если в строительной бригаде не будет прораба, то все знают, к чему это приведет. И это не смотря на то, что все строители профессионалы своего дела. А все вместе, без четкой организации и контроля — это сборище выпивох и бракоделов.
В команде программистов дело обстоит точно также. Без четко выработанной системы подходов в планировании и организации рабочего процесса, без постоянного контроля, вся работа превращается в какой-то хаос. Каждый программист начинает писать не то что нужно, а так как ему проще, или как ему хочется. Очень часто при этом отключая мозги вообще.
Те же, кто за таким программистом начинают обслуживать проект, и видя этот ужасный легаси код, при тех же самых условиях труда, не рефакторят его, а ставят свои костыли, и так же не пишут комментарии и документацию. И все это продолжается до тех пор, пока проект жив. Но финал известен всем.
Но большая часть вины, конечно же, лежит на руководстве, которое пытается здесь и сейчас выжимать прибыль из проекта, совершено не думая, а что же будет завтра. А завтра могут произойти следующие вещи:
- один из главных разработчиков, который знает, как этот говнокод работает, может уволится — и бизнес закончился
- огромное количество костылей на проекте может создать трудно выявляемые баги, которые завалят продакшн — и бизнес закончился
- нагрузка из-за ужасного легаси кода может возрасти на столько, что мощности даже самого крутого сервера станет недостаточно — и бизнес закончился
- накладные расходы на постоянное обслуживание проекта могут вырасти на столько, что превысят прибыль от проекта — и бизнес закончился
И еще много похожих пунктов, которые не просто подкосят бизнес, а наверняка его убьют! Согласитесь, перспектива малоприятная. И если сегодня ещё всё хорошо, то завтра уже может быть всё плохо.
Что же нужно делать в подобной ситуации, чтобы не угробить весь проект? Для начала необходимо провести полный анализ всего проекта. Создать, как минимум, концептуальную документацию, как работает ресурс. Нарисовать диаграммы проекта, чтобы по ним было проще понять, какой функционал можно безболезненно отрезать от монолитного проекта. Из отрезанного функционала можно строить абстрактные мини-решения, которые уже не будут жестко завязаны в один тугой узел со всем проектом. Например, можно это создать на базе микросервисов.
В проект обязательно нужно ввести толкового тимлида или архитектора, который очень четко сможет организовать команду под проект, с системным подходом к решению текущих проблем, с жестким контролем того, что делают программисты.
Должна начать создаваться подробная документация по всему проекту. Чтобы новый на проекте программист мог легко войти в курс дела, и понять, как работает тот или иной функционал. Нужно начать использовать современные подходы и паттерны проектирования, так как нужно уверено смотреть в будущее, а не в прошлое. Нужно повышать уровень квалификации своей команды, чтобы все понимали необходимость и эффективность командной работы, и зачем всё это нужно.
Без решительных шагов по избавлению от легаси кода, вы не сможете контролировать ваш проект и ваше детище в итоге вас сожрёт. И даже не смотря на то, что вам понадобится вложить существенные ресурсы для создания грамотного решения, это всё-равно нужно делать, так как ту прибыль, которую вы раньше выжимали с проекта, вы получали авансом. И теперь настало время платить по счетам. И если вы этого не сделаете, то все как обычно — вы просто потеряете свой бизнес.