Как реогранизовать процесс разработки в IT-продукте?
Есть продукт, который за несколько лет вырос из пет-проекта в достаточно крупный продукт, разработку вёл долгое время в одиночку и фактически учился прямо во время разработки, состоит из почти сотни тысяч строк python кода и порядка 200 HTML страниц. Весь код написан разными способами (часть проекта с использованием классов, часть без классов, часть на микросервисах, часть на монолите), на фронтенде тоже неразбериха.
В итоге фактически получилась солянка из всего что вообще есть в IT, очень много легаси кода. Сейчас после добавления некоторых новых проектов (в рамках этого продукта) доход достаточно сильно вырос, но и выросла нагрузка со стороны пользователей. Теперь есть возможность нанять новых людей, но как именно организовать процессы нет опыта, т.к сам разработку вёл без GIT и без особого контроля доступа (у базы данных есть только один пользователь с root правами, загрузка кода на сервера происходит через ssh). Кроме того, для некоторых клиентов делали индивидуальный функционал конкретно под их нужды, соответственно код изобилует костылями :(
Сейчас над проектом вместе со мной работает хороший друг, который имеет root права ко всем серверам и базам данных, но вдвоём уже не вывозим, нужны новые разработчики, а просто случайных людей брать в команду не получится - есть много личных данных пользователей, которые достаточно легко можно использоваться для своей выгоды. Конечно можно описать условия работы в договоре и, в случае слива данных, начать судиться, но понятное дело, что потраченное время и деньги на это всё того не стоят.
Нужно организовать работу так, чтобы разработчики имели ограниченные права доступа и при этом могли полноценно вести разработку.
Сейчас на ум приходит:
1) Разделение проекта на микросервисы, подключение гита и создание дубликата базы данных с деперсонализацией данных (чтобы у разработчика не было доступа к реальным данным, а только к тестовым). Но тут уйдёт много времени на чистку кода от возможных сливов доступа (т.к в разных частях кода используется подключение к базам данных и могут быть какие-то слабые места, поэтому код, перед тем, как отдавать другому разработчику, придётся проверять и чистить, на что может уйти уйма времени и не факт, что получится почистить всё полностью).
2) Создание что-то вроде модульной системы, когда разработчики (хоть даже фрилансеры, которые могут меняться ежедневно) пишут "расширения" ("модули"), которые изменяют/добавляют функционал с последующей проверкой кода доверенным разрабом, чтобы не было никаких бэкдоров и подобного. Примерно так устроен движок XenForo, что позволяет сообществу некоторых форумах делать свои обновления. Но не совсем ясно как этот функционал внедрить в уже существующий код.
Опыта работы в уже существующей IT компании, к сожалению, нет, поэтому достаточно мало понимания как работа идёт в командах.
Понимаю, что в любом случае придётся очень много времени потратить на реорганизацию всего этого хаоса, но сделать надо))
Пожалуйста, расскажите в каком направлении рыть, где можно набраться опыта организации работы в IT команде, какие технологии использовать.
Первый вариант - если есть прибыль, нанять людей, чтобы написать все с нуля, но уже масштабирование сразу предусмотреть в архитектуре. Зависит от сложности проекта, конечно.
Второй вариант - смотреть первый вариант, только своими силами и переписывать часть функционала, вынося его в микросервисы. В первую очередь вынести то, что под нагрузкой, потом потихоньку остальной функционал. С планами заменить все что нельзя масштабировать, без остановки сервиса.
Под словом микросервисы я вообще не рекомендую ставить микросервисы как самоцель. Можно и микросервисы и макросервисы, важно чтобы было легко затем поддерживать и масштабировать.
Разделить разработку и поддержку.
Разработка - на тестовом енвайрнменте с тестовыми данными
Поддержка - ограниченным кругом доверенных специалистов.
1. Git. Без него сейчас ну просто никак.
2. Gitlab CI или GitHub actions для деплоя.
3. Пишете скрипт, который при запуске на локалке создаёт новую базу и заполняет её фейковыми данными для тестов. Так новые разработчики не будут иметь доступ к данным.
3. Новые разработчики будут иметь доступ к коду, смогут создавать свои ветки в Git, пушить эти свои ветки в ваш удаленный репозиторий Git и даже создавать merge request на слияние их ветки с основной веткой разработки. А вы уже сможете сделать ревью их кода и подтвердить слияние, либо отказать. Все права отлично настраиваются как в Gitlab, так и в GitHub.
4. Если же вы вообще не хотите показывать даже код сторонним разработчикам, то тут без модулей либо даже микросервисов не обойдешься. Я бы начал пробовать с модулей.
P. S. Если в голову придёт мысль переписать проект полностью, то десять тысяч раз подумайте перед этим. В моей практике нет ни одного успешного переписывания сложного проекта... Всегда нужны новые срочные фичи, и придется параллельно внедрять эти фичи в старую кодовую базу, одновременно с этим пытаться их внедрить в сырую переписываемую кодовую базу. Это может закончиться ещё более запутанным проектом, чем был оригинал.
Этап 1. Ну в первую очередь вам необходимо всю вашу систему поставить на рельсы CI/CD, т.е. естественно система контроля версий, автотесты, автоматизировать процесс публикации/развертывания, всё это нужно чтобы внесение каких-либо изменений/доработок не втягивало вас в рутину, а выполнялось нажатием двух кнопок. Отдельно хочу обратить внимание на автотесты!!! Возьмите себе за правило, что каждая доработка или новая функциональность внедряется только вместе с тестами, а выпуск нового релиза только после успешной прогонки всех тестов. Да поначалу это будет создавать много сложностей, но в последствии вы получите повышенный контроль качества при внесении каких-либо изменений.
Этап 2. Посидеть и подумать над новой архитектурой, возможно посмотреть в сторону микросервисов. Цель - сегментировать вашу систему. Сегментация вам нужна для того чтобы вы постепенно смогли заменять отдельные элементы вашей системы. Другой вариант - использовать соответствующие паттерны: декораторы, прокси, адаптеры, медиаторы и пр., т.е. вы заново переписываете элемент системы, но таким образом чтобы сохранялся интерфейс взаимодействия со старыми элементами. Например (естественно надуманный), был у вас класс Data для доступа к БД, в нем вы просто реализовывали методы для получения данных на основе SQL-запросов, но сейчас решили перейти на ORM. В этом случае, создаете нужные модели, настраиваете связи, т.е. все как будто вы делаете с нуля. После того как ваша ORM заработала правильно, вы при новых доработках начинаете использовать ORM и параллельно превращаете ваш класс Data в некоторый прокси, который будет делать обращения к данным через новый ORM. Далее постепенно начинаете менять все обращения к Data на прямую через ORM. И со временем наступит момент, когда не будет ни одного обращения к Data, тогда вы смело сможете его убрать.
Этап 3. Формирование плана перехода на новую архитектуру. После того как вы создали новую архитектуру и предусмотрели в ней переходные механизмы, необходимо выработать порядок действий, определить более приоритетные работы, возможно что-то отдать на оутсорс, что-то заменить готовыми сторонними решениями и т.д. В конечном итоге должен появиться некоторый план-график, на основе которого вы увидите примерный путь вашей миграции. Нужно это для того чтобы видеть границы вашего переезда и не превратить его в вечный процесс. Условно говоря, вы определяете что через два года у нас будет новая система и всё.
Этап 4. Естественно это реализация вашего плана :) Тут уже руководите процессом (точнее даже проектом): распределяйте ресурсы, набирайте нужных людей под конкретные этапы плана, создавайте вехи плана (проекта). Тут вам в помощь различные системы управления проектами, коих полным полно. И самое главное, теперь вы должны измениться сами! Вместо программиста вы должны стать руководителем, ваша задача не кодить, а налаживать рабочие процессы. Вы должны перейти от проектной работы к процессной. Познайте разницу между проектом и процессом и у вас наступит счастье :)
Средний
