Последствия плохой программной архитектуры

Большинство современных компаний, ведущих разработку собственных программных продуктов, неизбежно сталкиваются с последствиями плохой архитектуры.

Какие это проблемы? Кратко перечислим их:

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

Прежде чем перейти к описанию последствий плохой архитектуры программного обеспечения, стоит ответить на два вопроса:

Ответом на первый вопрос может служить цитата Роберта Мартина:

Мерой качества архитектуры может служить простая мера трудозатрат, необходимых для удовлетворения потребностей заказчика. Если трудозатраты невелики и остаются небольшими в течение эксплуатации системы, система имеет хорошую архитектуру. Если трудозатраты увеличиваются с выходом каждой новой версии, система имеет плохой дизайн. Вот так все просто.

Рассмотрим конкретный пример. У нас есть статистика по компании, развивающей собственный программный продукт. Для начала рассмотрим рост численности штата разработчиков.

Когда компания выпустила первую версию своего продукта, ей потребовалось всего 20 сотрудников. К выпуску восьмой версии, над продуктом трудилось уже более 1200 человек. Можно предположить, что дела у компании идут прекрасно и она быстро растет. Но давайте взглянем на график продуктивности за тот же период, измеряемый в количестве строк кода.

Очевидно, что здесь что-то не так. Выпуск каждой новой версии поддерживается все большим количеством разработчиков, но при этом количество строк кода приближается к своему пределу.

А теперь взгляните на по-настоящему удручающий график роста стоимости строки кода с течением времени.

Эта тенденция говорит о нежизнеспособности. Какой бы рентабельной ни была компания в настоящее время, растущие накладные расходы поглотят прибыль и приведут компанию к застою, если не к краху.

Чем обусловлено такое значительное изменение продуктивности? Почему строка кода в 8 версии стоит в 40 раз дороже, чем в версии 1?

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

Рассмотрим тенденцию продуктивности разработчиков, выраженную в процентах.

Сначала разработчики показывают продуктивность, близкую к 100%, но с выходом каждой новой версии она падает. Начиная с четвертой версии, как можно заметить, их продуктивность начинает приближаться к нижнему пределу - нулю.

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

Если вы думаете, что ситуация скверная, взгляните на нее с точки зрения собственников компании. На графике ниже приведена динамика роста фонда оплаты труда.

Когда была выпущена версия 1, месячный фонд оплаты труда составлял сто тысяч долларов. К выпуску восьмой версии фонд оплаты труда составил пять миллионов долларов в месяц. Рост в 50 раз!

Этот график выглядит не просто скверно, он пугает! Очевидно, что происходит что-то ужасное. Одна надежда, что рост доходов опережает рост расходов. А значит, оправдывает расходы. Но с любой точки зрения, данная кривая вызывает беспокойство.

Примерно 2600 лет назад Эзоп сочинил притчу о зайце и черепахе.

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

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

Эти разработчики верят в известную ложь: "Нам бы только выйти на рынок, а порядок мы наведем после". В результате, порядок так и не наводится, потому что давление конкуренции на рынке никогда не ослабевает. Выход на рынок означает, что теперь у нас на хвосте висят конкуренты.

Поэтому разработчики никогда не переключают режим работы. Они не могут вернуться и навести порядок, потому что должны реализовывать следующую новую функцию, а потом еще одну, и еще, и еще. В результате, беспорядок нарастает, а продуктивность стремится к своему пределу около нуля.

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

Джейсон Горман провел показательный эксперимент. В течение шести дней он писал от начала до конца простую программу преобразования целых числе из десятичной системы счисления в римскую. Работа считалась законченной, когда программа успешно проходила предопределенный комплект приемочных тестов. Каждый день на решение поставленной задачи затрачивалось чуть меньше 30 минут. В первый, второй и третий дни Джейсон использовал известную методику разработки через тестирование (TDD, Test Driven Development). В остальные дни он писал код, не ограничивая себя рамками этой методики.

Каждый раз на решение задачи затрачивалось все меньше времени. Отметьте также, что в дни, когда применялась методика TDD, упражнение выполнялось примерно на 10% быстрее, чем в дни без применения TDD. Но самое важное, что даже самый худший результат, полученный с TDD оказался лучше самого лучшего результата, полученного без TDD.

Разработчики, не практикующие TDD на постоянной основе, могут посчитать этот результат удивительным. Но те, кто используют TDD, согласятся с простой истиной разработки программного обеспечения - поспешай не торопясь.

Разработчики могут подумать, что проблему можно решить, только начав все с самого начала и перепроектировав всю систему целиком. Но это та же самонадеянность, которая привела их к текущему беспорядку.

Любой компании, занимающейся разработкой, лучше всего избегать самонадеянных решений, и с самого начала со всей серьезностью отнестить к качеству архитектуры ее продукта.

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

О том, как выглядит добротная, чистая архитектура, позволяющая разработчикам создавать системы, способные приносить прибыль компаниям долгое время, я рассказываю в своем телеграм-канале solonkov.team. Там же вы сможете задать интересующие вас вопросы и заказать консультацию.