Ваша проблема очень распространена.И реальная проблема тоже, потому что нет хорошего решения.
Мы находимся в такой же ситуации, я бы сказал, что хуже, с 13 миллионами строк кода, оборотом и более 800 разработчиками, работающими надкод.Мы часто обсуждаем ту же проблему, которую вы описываете.
Первая идея, которую ваши разработчики уже использовали, - это рефакторинг общего кода в некоторых служебных классах.Наша проблема с этим решением, даже с парным программированием, наставничеством и обсуждением, состоит в том, что нас просто слишком много, чтобы это было эффективно.Фактически мы растем в подгруппах, где люди делятся знаниями в подгруппах, но знания не переходят между подгруппами.Возможно, мы ошибаемся, но я думаю, что даже парное программирование и разговоры не могут помочь в этом случае.
У нас также есть команда архитекторов.Эта команда отвечает за решение проблем проектирования и архитектуры, а также за создание общих утилит, которые могут нам понадобиться.Эта команда фактически производит то, что мы могли бы назвать корпоративной структурой.Да, это основа, и иногда она работает хорошо.Эта группа также несет ответственность за распространение передового опыта и повышение осведомленности о том, что следует делать или нет, что доступно или что нет.
Хорошая основная разработка Java API является одной из причин успеха Java.Хорошие сторонние библиотеки с открытым исходным кодом тоже очень важны.Даже небольшой хорошо разработанный API позволяет предложить действительно полезную абстракцию и может помочь значительно уменьшить размер кода.Но вы знаете, что создание фреймворка и публичного API - это совсем не то же самое, что просто кодирование служебного класса за 2 часа.Это действительно высокая стоимость.Служебный класс стоит 2 часа для начального кодирования, возможно, 2 дня с отладкой и юнит-тестами.Когда вы начинаете делиться общим кодом в больших проектах / командах, вы действительно создаете API.Вы должны обеспечить отличную документацию, действительно читаемый и поддерживаемый код.Когда вы выпускаете новую версию этого кода, вы должны поддерживать обратную совместимость.Вы должны продвигать его в масштабах компании (или, по крайней мере, в команде).От 2 дней для вашего небольшого служебного класса вы увеличиваете до 10 дней, 20 дней или даже 50 дней для полноценного API.
И ваш дизайн API может быть не таким уж хорошим.Что ж, дело не в том, что ваши инженеры не умны - на самом деле они есть.Но готовы ли вы позволить им поработать 50 дней над небольшим служебным классом, который просто помогает последовательно анализировать число для пользовательского интерфейса?Готовы ли вы позволить им полностью изменить дизайн, когда вы начнете использовать мобильный интерфейс с совершенно другими потребностями?Также вы заметили, как самые яркие инженеры в мире создают API, которые никогда не будут популярны или будут постепенно исчезать?Видите ли, первый веб-проект, который мы сделали, использовал только внутренние фреймворки или вообще не использовал фреймворк.Затем мы добавили PHP / JSP / ASP.Затем в Java мы добавили Struts.Теперь JSF является стандартом.И мы думаем об использовании Spring Web Flow, Vaadin или Lift ...
Все, что я хочу сказать, - это то, что не существует хорошего решения, накладные расходы растут экспоненциально с размером кода и размером команды.Совместное использование большой базы кода ограничивает вашу ловкость и отзывчивость.Любое изменение должно быть сделано осторожно, вы должны думать обо всех потенциальных проблемах интеграции, и каждый должен быть обучен новым особенностям и особенностям.
Но главная задача производительности компании-разработчика программного обеспечения - не набирать 10 или даже 50 строк кода при разборе XML.Общий код для этого в любом случае вырастет до тысячи строк кода и воссоздает сложный API, который будет распределен по служебным классам.Когда парень создает вспомогательный класс для разбора XML, это хорошая абстракция.Он дает имя одной дюжине или даже ста строкам специализированного кода.Этот код полезен, потому что он специализирован.Общий API позволяет работать с потоками, URL, строками, чем угодно.У него есть фабрика, поэтому вы можете выбрать реализацию парсера.Полезный класс хорош тем, что работает только с этим парсером и со строками.И потому, что вам нужна одна строка кода для его вызова.Но, конечно, этот служебный код имеет ограниченное использование.Это хорошо работает для этого мобильного приложения или для загрузки конфигурации XML.И именно поэтому разработчик в первую очередь добавил для него служебный класс.
В заключение, вместо того, чтобы пытаться консолидировать код для всей базы кода, я хотел бы разделить ответственность за код по мере роста команд:
- превратить вашу большую команду, работающую над одним большим проектом, в маленькие команды, работающие над несколькими подпроектами;
- гарантирует, что взаимодействие хорошо для минимизации проблем интеграции, но пусть команда имеет свой собственный код;
- внутри этих команд и соответствующих баз кода, убедитесь, что у вас есть лучшие практики.Нет дубликата кода, хорошие абстракции.Используйте существующие проверенные API от сообщества.Используйте парное программирование, надежную документацию API, вики ... Но вы действительно должны позволить различным командам делать свой выбор, создавать свой собственный код, даже если это означает дублирование кода между командами или различные дизайнерские решения.Вы знаете, если проектные решения отличаются, это может быть потому, что потребности разные.
То, что вы действительно управляете, - это сложность.В конце концов, если вы сделаете одну монолитную кодовую базу, очень общую и продвинутую, вы увеличите время для новичков, вы увеличите риск того, что разработчики вообще не будут использовать ваш общий код, и вы замедляете всех, потому что любое изменениеимеет гораздо больше шансов сломать существующую функциональность.