Мне не нравятся монолитные репозитории. Они объединяют несколько проектов, часто написанных на разных языках разными командами. К сожалению, Google, Facebook, и Яндекс предпочитают их. По их мнению, монорепозитории сокращают интеграционные накладные расходы. Они это делают, но за счет качества. В меньших репозиториях мы можем разрабатывать более качественный код.
Когда репозиторий меньше, вы можете достичь более высокого качества по ряду причин:
Вы можете писать более глубокие тесты. Интеграционные (или глубокие) тесты неизбежно медленные. В небольшом репозитории хорошее покрытие интеграционными тестами не означает медленную сборку. В большом репозитории - это так. Медленная сборка - это то, чего команда старается избежать, тем самым подвергая опасности покрытие.
Вы можете провести более подробный обзор. В большом репозитории может быть сложно запомнить все аспекты дизайна. Pull request, который затрагивает различные, казалось бы, несвязанные части кода, может быть вызовом для обзора. Даже если вы архитектор.
Вы можете написать README. Может быть, вы уже заметили: у больших проектов с открытым исходным кодом короткие и схематичные файлы README. Их нельзя делать слишком длинными, иначе они станут такими же объемными, как книга. Все, что они могут сделать, это направить читателя на веб-сайт документации. Невозможность объяснить весь объем в одном файле приводит к расширению объема работы. Участники проекта сталкиваются с трудностями в понимании границ проекта. Это, среди прочих негативных моментов, приводит к дублированию кода.
Вы можете выпускать релизы часто. В крупном репозитории частая повторная интеграция может быть дорогой, как в плане времени, так и денег. В небольшом репозитории сборка за несколько секунд - это не мечта программистов, а их реальность. Не только недорогая непрерывная интеграция, но и непрерывное развертывание. После каждого небольшого изменения вы можете опубликовать новый релиз с его собственной версией. В монорепозитории мы обычно ждем, пока накопится определенное количество изменений.
Вы можете эффективно использовать искусственный интеллект. Не секрет, что у современных LLM ограниченные окна контекста. Даже миллион строк кода не поместится в самое большое из них. Даже десять тысяч строк, не говоря уже о миллионе, слишком много для усвоения LLM. Сохраняя репозиторий небольшим, мы делаем большую услугу нашим маленьким друзьям: искусственным интеллектом.
Вы можете быстрее начать работу. Более крупные кодовые базы обычно старые и более хаотичные, полные устаревшего кода. Для начала делать значимый вклад в такой репозиторий требуется больше времени. Монорепо привлекают долгосрочных сотрудников, которым важна рабочая стабильность больше, чем качество кода.
Вы можете ожидать ответственности. В крупных кодовых базах очень трудно поддерживать идею владения кодом. Программисты едва ли могут чувствовать ответственность за код, написанный и изменённый другими. В меньших репозиториях, напротив, люди эмоционально привязываются к коду.
Вы можете перейти к открытому исходному коду. Независимо от того, насколько ваш начальник любит открытый исходный код, вы не можете выложить весь монорепозиторий вашего предприятия на GitHub. Однако, если вы извлечете небольшую часть из него, то сможете. Код, который открыт, видим и критикуется многими людьми, предположительно обладает более высоким качеством.
В итоге, вам следует искать возможность извлечь кусок кода в виде отдельного пакета. Затем настаивать на том, чтобы он был открытым исходным кодом. Затем продвигать его в сообществе. Затем бросить свою офисную работу и присоединиться к Zerocracy.
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-11-16 at 03:39
