BonBonSlick
@BonBonSlick
Junior Web Developer Trainee

Как избежать дублей кода и функционала в крупном проекте?

Что если в проекте работает более 15+ людей из разных компаний, естественно общения между ними нет, только код при merge branch, это все что их связывает. И иногда не ясно готово ли уже что-то, для решения той или иной задачи. Сидишь делаешь, а потом находишь уже глубоко в проекте что-то, что решает уже задачу, надо было это лишь использовать.

Как тогда организовать работу?
Как узнать сделали ли, есть ли уже в сервисе подобный функционал?
Сделан ли он правильно?
Как его найти?
Как избежать дублей кода и функционала?
  • Вопрос задан
  • 1084 просмотра
Решения вопроса 5
rockon404
@rockon404
Frontend Developer
По меркам крупных проектов, 15 человек это маленький проект.
1. Во-первых, надо использовать одну из методологий разработки. Scrum отлично подходит для распределенных команд и рефакторинга. Все разработчики будут в курсе всего.
2. Используйте issue tracker. Jira - отличный вариант.
3. workflow. Должны быть регламентированны все шаги от постановки задачи и создания ее PM до закрытия ее QA после тестирования. Это исключит параллельное выполнение одной и той же задачи. Так же надо зарегламентировать правила именования веток и коммитов в Git и их слияния.
4. Общайтесь. Slack - отличный мессенджер для распределенных команд. Google Meet - для созвонов.
5. Правильная, прозрачная архитектура и использование фреймворков. Никаких велосипедов в серьезных проектах. Иначе поддерживать проект будет крайне тяжело. С грамотной архитектурой разработчик будет знать, где проверить наличие компонента, утилиты и всего прочего, перед тем как добавить нужный функционал самому. Это в совокупности с пунктами 1, 2 и 4 должно полностью исключить дубли.
6. Документация. Используйте Apiary для документирования API. Плюсы Apiary - быстро, эффективно, стандартизировано и понятно.
Напишите документацию по настройке окружения, установке проекта и рабочем процессе для новых разработчиков.
Фичи, компоненты и модули приложения, при использовании популярных фреймворков, документировать нет особого смысла, иначе можете получить тонну неактуальной и неграмотно написанной документации, на которую разработчики еще и потратят кучу времени.
Если же нужны справочные материалы для пользователей, серьезная мультиязычная документация для заказчика, или описание продукта для инвесторов, нанимайте технического писателя.
7. Code review - фронты проверяют код по фронтовой части, беки по бекенду, мобильные разработчики по мобилкам и тд. PR мержить только после достаточного количества аппрувов (например 3). Так разработчики будут не только в курсе всего, что происходит с проектом по их части, но и будут учиться друг у друга и использовать одни и те же подходы для решения похожих задач.
8. Инструментарий: прекоммиты, линтеры, автотесты и прочее.
9. Опционально, деление на команды.
Ответ написан
Minifets
@Minifets
Hello world!!!
Что это за крупный проект на 15+ человек только с гитом? :)

Или если это просто вопрос про то, что используется в крупных проектах, то вот примерный список:
1) Тесты. (Есть даже подход TDD, когда сначала пишут тесты, а потом уже код, который их проходит)
2) Документация API. Как правило разработка идет модульно, и у каждого модуля должна быть своя документация.
3) Issue tracker. Описание задачи, тут же можно и вести общение с другими разработчиками и увидедть, что уже сделано.
4) Bug tracker. (см. П.3, почти одно и тоже)
5) Continuous Integration. Автоматизация процесса слияния веток и постоянного прогона тестов.

Может что-то еще забыл. Но этого должно быть достаточно для решения многих проблем.
Ответ написан
Maksclub
@Maksclub Куратор тега Веб-разработка
maksfedorov.ru
для этого и ведут документацию, например с помощью Confluence

желательно делать релизы какие-то , где все программситы бы делали краткое описание своих фич...
тогда с каждым релизом вы знаете, что добавилось в целом в проекте

вот например в Yii2 ведется CHANGELOG:
https://github.com/yiisoft/yii2/blob/2.0.13.1/fram...

...

Это однозначно решается не вами, но вы можете очень сильно сигнализировать и давать доводы вашему техдиру/руководителю об этом.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
1. Руководитель проекта следит за тем, чтобы вся проектная документация была актуальна (планы, спеки, схемы и т.д.).
2. Руководитель проекта также следит за своевременным выполнением плана (вех проекта) и за своевременной готовностью функциональных блоков внутри них.
3. Каждый разработчик (группа) получает на кодирование свой функциональный блок со своим набором функций, исходя из требований бизнес-логики.
4. Межблочное взаимодействие описывается с помощью единого интеграционного API, документация по которому пишется заранее и доступна всем.
5. Каждый законченный функциональный блок проходит тестирование перед тем, как он будет помещён в общую систему.

Для контроля версий кода - используется git.
Для переговоров разработчиков и отслеживания статуса и сроков по проекту - redmine
Ответ написан
Комментировать
Вообще, могут быть ситуации, когда руководитель проекта сменился, разработчики поменялись и т.п.
ИМХО система должна быть разбита на понятные модули и быть самодокументированной.
Например пришел новый разработчик и ему дали задание сделать отправку письма на email. Очевидно, что он вначале глянет, нет ли модуля работы с письмами.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Ни как.
Культура разработчиков и отсутствие гонки позволит облегчить проблемы с этим.
Ответ написан
Комментировать
TheRonCronix
@TheRonCronix
Чтобы добиться консистентности системы, необходим архитектор - человек, который имеет системное видение системы.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы