Задать вопрос
  • Как реогранизовать процесс разработки в IT-продукте?

    1. Git. Без него сейчас ну просто никак.
    2. Gitlab CI или GitHub actions для деплоя.
    3. Пишете скрипт, который при запуске на локалке создаёт новую базу и заполняет её фейковыми данными для тестов. Так новые разработчики не будут иметь доступ к данным.
    3. Новые разработчики будут иметь доступ к коду, смогут создавать свои ветки в Git, пушить эти свои ветки в ваш удаленный репозиторий Git и даже создавать merge request на слияние их ветки с основной веткой разработки. А вы уже сможете сделать ревью их кода и подтвердить слияние, либо отказать. Все права отлично настраиваются как в Gitlab, так и в GitHub.
    4. Если же вы вообще не хотите показывать даже код сторонним разработчикам, то тут без модулей либо даже микросервисов не обойдешься. Я бы начал пробовать с модулей.

    P. S. Если в голову придёт мысль переписать проект полностью, то десять тысяч раз подумайте перед этим. В моей практике нет ни одного успешного переписывания сложного проекта... Всегда нужны новые срочные фичи, и придется параллельно внедрять эти фичи в старую кодовую базу, одновременно с этим пытаться их внедрить в сырую переписываемую кодовую базу. Это может закончиться ещё более запутанным проектом, чем был оригинал.
    Ответ написан
    Комментировать
  • Как реогранизовать процесс разработки в IT-продукте?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Первый вариант - если есть прибыль, нанять людей, чтобы написать все с нуля, но уже масштабирование сразу предусмотреть в архитектуре. Зависит от сложности проекта, конечно.

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

    Разделить разработку и поддержку.

    Разработка - на тестовом енвайрнменте с тестовыми данными
    Поддержка - ограниченным кругом доверенных специалистов.
    Ответ написан
    Комментировать
  • Как реогранизовать процесс разработки в IT-продукте?

    beevasya
    @beevasya
    программист C++/C#
    Этап 1. Ну в первую очередь вам необходимо всю вашу систему поставить на рельсы CI/CD, т.е. естественно система контроля версий, автотесты, автоматизировать процесс публикации/развертывания, всё это нужно чтобы внесение каких-либо изменений/доработок не втягивало вас в рутину, а выполнялось нажатием двух кнопок. Отдельно хочу обратить внимание на автотесты!!! Возьмите себе за правило, что каждая доработка или новая функциональность внедряется только вместе с тестами, а выпуск нового релиза только после успешной прогонки всех тестов. Да поначалу это будет создавать много сложностей, но в последствии вы получите повышенный контроль качества при внесении каких-либо изменений.
    Этап 2. Посидеть и подумать над новой архитектурой, возможно посмотреть в сторону микросервисов. Цель - сегментировать вашу систему. Сегментация вам нужна для того чтобы вы постепенно смогли заменять отдельные элементы вашей системы. Другой вариант - использовать соответствующие паттерны: декораторы, прокси, адаптеры, медиаторы и пр., т.е. вы заново переписываете элемент системы, но таким образом чтобы сохранялся интерфейс взаимодействия со старыми элементами. Например (естественно надуманный), был у вас класс Data для доступа к БД, в нем вы просто реализовывали методы для получения данных на основе SQL-запросов, но сейчас решили перейти на ORM. В этом случае, создаете нужные модели, настраиваете связи, т.е. все как будто вы делаете с нуля. После того как ваша ORM заработала правильно, вы при новых доработках начинаете использовать ORM и параллельно превращаете ваш класс Data в некоторый прокси, который будет делать обращения к данным через новый ORM. Далее постепенно начинаете менять все обращения к Data на прямую через ORM. И со временем наступит момент, когда не будет ни одного обращения к Data, тогда вы смело сможете его убрать.
    Этап 3. Формирование плана перехода на новую архитектуру. После того как вы создали новую архитектуру и предусмотрели в ней переходные механизмы, необходимо выработать порядок действий, определить более приоритетные работы, возможно что-то отдать на оутсорс, что-то заменить готовыми сторонними решениями и т.д. В конечном итоге должен появиться некоторый план-график, на основе которого вы увидите примерный путь вашей миграции. Нужно это для того чтобы видеть границы вашего переезда и не превратить его в вечный процесс. Условно говоря, вы определяете что через два года у нас будет новая система и всё.
    Этап 4. Естественно это реализация вашего плана :) Тут уже руководите процессом (точнее даже проектом): распределяйте ресурсы, набирайте нужных людей под конкретные этапы плана, создавайте вехи плана (проекта). Тут вам в помощь различные системы управления проектами, коих полным полно.
    И самое главное, теперь вы должны измениться сами! Вместо программиста вы должны стать руководителем, ваша задача не кодить, а налаживать рабочие процессы. Вы должны перейти от проектной работы к процессной. Познайте разницу между проектом и процессом и у вас наступит счастье :)
    Ответ написан
    Комментировать