Предел 100k строк

Предел 100k строк

11 марта 2023 г.

100k строк в кодовой базе – это эмпирически полученное значение, которое отделяет стартап от взрослой компании. До этого предела можно себе позволить сконцентрироваться исключительно на новой функциональности и не уделять внимания документации, архитектуре и тестам. А вот после…

💡

Git позволяет легко откатиться назад на любое количество коммитов, поэтому проследить изменение объема кодовой базы обычно не составляет труда. Заклинание для подсчета строк кода (в данном случае я считаю swift-файлы для iOS-проекта) выглядит так:

find . -name '*.swift' | xargs wc -l | sort

После превышения порога обязательно грядёт кризис. Разработка встанет наглухо, команду разработки поменяют (если она не разбежится до этого сама), но результата все равно не будет, пока не будут вложены значительные ресурсы в рефакторинг. Я наблюдал «проклятие 100k строк» в большинстве проектов, где доводилось принимать участие. Все просто – это классический техдолг и его последствия. Вопрос в том, почему именно такое значение порога?

В ходе экспериментов также было замечено, что объем кодовой базы одного и того же клиентского приложения на различных платформах после порога в 100k примерно одинаковый, различия не превышают нескольких процентов. Это значит, что после превышения магического порога выбор инструментария (языка программирования и библиотек) уже мало влияет на объем кодовой базы. А что влияет? Бизнес-логика! Объем «взрослой» кодовой базы теперь определяется сложностью бизнес-логики, а не сложностью технологий, доступных «из коробки» выбранного фреймворка. Получается, что наш магический порог определяется мощностью используемых фреймворков, т.е. количеством уже написанного и переиспользуемого по умолчанию кода. Для современных решений эта мощность составляет те самые 100k строк. Занятно, что эта же цифра применительно к современным реалиям упоминается в относительно свежей (мой экземпляр 2019-го года издания) книге Роберта Мартина «Чистая архитектура. Искусство разработки программного обеспечения»:

А как влиял рост вычислительной мощности на программы, которые мне приходилось писать? Определенно они стали больше. Раньше я думал, что 2000 строк – это большая программа. В конце концов, такая программа занимала полную коробку перфокарт и весила 4,5 килограмма. Однако теперь программа считается по-настоящему большой, только если объем кода превысит 100 000 строк.

Итак, с превышением порога фреймворк уже не может нивелировать сложность, и команда разработки сталкивается с этой сложностью 1 на 1. Разумеется, дальнейшее развитие проекта зависит от конкретных людей, но hardware у всех людей примерно одинаковый. Вычислительная емкость мозга у разных людей вряд ли различается больше, чем на порядок. Успешную команду от неуспешной отличает лишь то, насколько эффективно команда умеет в параллелизацию вычислений. Это подразумевает в первую очередь эффективную коммуникацию. Если коммуникация настроена, то можно использовать горизонтальное масштабирование и в итоге вывозить проекты гораздо большего масштаба, чем 100k строк. Разумеется, у параллелизации всегда есть накладные расходы, и в проектах менее 100k строк эти расходы могут оказаться неоправданными. Если же проект больше, то придется учиться размазывать сложность — тонким слоем, по всей команде, чтобы всем поровну и никого не обидеть =)