Последствия плохой программной архитектуры
Большинство современных компаний, ведущих разработку собственных программных продуктов, неизбежно сталкиваются с последствиями плохой архитектуры.
Какие это проблемы? Кратко перечислим их:
- Постоянно растущий штат разработчиков.
- Системное снижение продуктивности, нивелирующее увеличение штата.
- Экспоненциальный рост сложности программной системы во времени.
Постоянный рост издержек при снижающейся отдаче рано или поздно приведет компанию к краху. Но это не единственный риск. Сложность создаваемых программных систем быстро выходит за рамки человеческих возможностей восприятия. Сопровождать и развивать такую систему становится непосильной задачей, особенно для вновь привлеченных программистов. В попытках остановить растущий беспорядок, создаются тонны документации с требованиями и гигансткие баг-трекеры. Внедрение нового функционала разработчиками все больше начинает походить на подвиг, сопровождаемый постоянными переработками и выгораниями. Все это кажется чем-то неизбежным. Безусловной платой за успех.
Цель и мера хорошей архитектуры
Прежде чем перейти к описанию последствий плохой архитектуры программного обеспечения, стоит ответить на два вопроса:
- В чем заключается цель хорошей хорошей архитектуры?
- Какова мера качества хорошей архитектуры?
Ответом на первый вопрос может служить цитата Роберта Мартина:
Мерой качества архитектуры может служить простая мера трудозатрат, необходимых для удовлетворения потребностей заказчика. Если трудозатраты невелики и остаются небольшими в течение эксплуатации системы, система имеет хорошую архитектуру. Если трудозатраты увеличиваются с выходом каждой новой версии, система имеет плохой дизайн. Вот так все просто.
Показательный пример
Рассмотрим конкретный пример. У нас есть статистика по компании, развивающей собственный программный продукт. Для начала рассмотрим рост численности штата разработчиков.
Когда компания выпустила первую версию своего продукта, ей потребовалось всего 20 сотрудников. К выпуску восьмой версии, над продуктом трудилось уже более 1200 человек. Можно предположить, что дела у компании идут прекрасно и она быстро растет. Но давайте взглянем на график продуктивности за тот же период, измеряемый в количестве строк кода.
Очевидно, что здесь что-то не так. Выпуск каждой новой версии поддерживается все большим количеством разработчиков, но при этом количество строк кода приближается к своему пределу.
А теперь взгляните на по-настоящему удручающий график роста стоимости строки кода с течением времени.
Эта тенденция говорит о нежизнеспособности. Какой бы рентабельной ни была компания в настоящее время, растущие накладные расходы поглотят прибыль и приведут компанию к застою, если не к краху.
Чем обусловлено такое значительное изменение продуктивности? Почему строка кода в 8 версии стоит в 40 раз дороже, чем в версии 1?
Причины неприятностей
Когда системы создаются второпях, когда увеличение штата разработчиков - единственный способ продолжать выпускать новые версии, когда чистоте кода или архитектуре уделяется минимум внимания, можно даже не сомневаться, что такая тенденция рано или поздно приведет к краху.
Рассмотрим тенденцию продуктивности разработчиков, выраженную в процентах.
Сначала разработчики показывают продуктивность, близкую к 100%, но с выходом каждой новой версии она падает. Начиная с четвертой версии, как можно заметить, их продуктивность начинает приближаться к нижнему пределу - нулю.
С точки зрения разработчиков, такая ситуация выглядит удручающе. Поэтому все они продолжают трудиться с полной отдачей сил. Но, несмотря на сверхурочный труд и самоотверженность, они просто не могут произвести больше. Все их усилия направлены не на реализацию новых функций, а на борьбу с беспорядком. Большую часть времени они заняты тем, что переносят беспорядок из одного места в другое, чтобы получить возможность добавить еще одну мелочь.
Точка зрения собственников компании
Если вы думаете, что ситуация скверная, взгляните на нее с точки зрения собственников компании. На графике ниже приведена динамика роста фонда оплаты труда.
Когда была выпущена версия 1, месячный фонд оплаты труда составлял сто тысяч долларов. К выпуску восьмой версии фонд оплаты труда составил пять миллионов долларов в месяц. Рост в 50 раз!
Этот график выглядит не просто скверно, он пугает! Очевидно, что происходит что-то ужасное. Одна надежда, что рост доходов опережает рост расходов. А значит, оправдывает расходы. Но с любой точки зрения, данная кривая вызывает беспокойство.
Что именно не так?
Примерно 2600 лет назад Эзоп сочинил притчу о зайце и черепахе.
Притча подчеркивает глупость самонадеянности. Заяц был настолько уверен в своей скорости, что не отнесся всерьез к состязанию. Остановился незадолго до финиша и решил вздремнуть. В итоге, он проспал, когда черепаха пересекла финишную черту.
Современные разработчики также участвуют в похожей гонке и проявляют похожую самонадеянность. Разумеется, они не спят. Многие из них работают как проклятые. Но часть их мозга действительно спит - та часть, которая знает, что хороший, чистый, хорошо проработанный код играет немаловажную роль.
Эти разработчики верят в известную ложь: "Нам бы только выйти на рынок, а порядок мы наведем после". В результате, порядок так и не наводится, потому что давление конкуренции на рынке никогда не ослабевает. Выход на рынок означает, что теперь у нас на хвосте висят конкуренты.
Поэтому разработчики никогда не переключают режим работы. Они не могут вернуться и навести порядок, потому что должны реализовывать следующую новую функцию, а потом еще одну, и еще, и еще. В результате, беспорядок нарастает, а продуктивность стремится к своему пределу около нуля.
Ползучий беспорядок в коде, иссушающий их продуктивность, никогда не спит и никогда не бездействует. Если впустить его, он уменьшит производительность до нуля за считанные месяцы. Важно понимать, что создание беспорядка всегда оказывается медленнее, чем неуклонное соблюдение чистоты. Независимо от выбранного масштаба времени.
Эксперимент
Джейсон Горман провел показательный эксперимент. В течение шести дней он писал от начала до конца простую программу преобразования целых числе из десятичной системы счисления в римскую. Работа считалась законченной, когда программа успешно проходила предопределенный комплект приемочных тестов. Каждый день на решение поставленной задачи затрачивалось чуть меньше 30 минут. В первый, второй и третий дни Джейсон использовал известную методику разработки через тестирование (TDD, Test Driven Development). В остальные дни он писал код, не ограничивая себя рамками этой методики.
Каждый раз на решение задачи затрачивалось все меньше времени. Отметьте также, что в дни, когда применялась методика TDD, упражнение выполнялось примерно на 10% быстрее, чем в дни без применения TDD. Но самое важное, что даже самый худший результат, полученный с TDD оказался лучше самого лучшего результата, полученного без TDD.
Разработчики, не практикующие TDD на постоянной основе, могут посчитать этот результат удивительным. Но те, кто используют TDD, согласятся с простой истиной разработки программного обеспечения - поспешай не торопясь.
Разработчики могут подумать, что проблему можно решить, только начав все с самого начала и перепроектировав всю систему целиком. Но это та же самонадеянность, которая привела их к текущему беспорядку.
Заключение
Любой компании, занимающейся разработкой, лучше всего избегать самонадеянных решений, и с самого начала со всей серьезностью отнестить к качеству архитектуры ее продукта.
Серьезное отношение к архитектуре программного обеспечения подразумевает знание о том, что такое хорошая архитектура. Чтобы создать систему, дизайн и архитектура которой способствуют уменьшению трудозатрат и увеличению продуктивности, нужно знать, какие элементы архитектуры ведут к этому.
О том, как выглядит добротная, чистая архитектура, позволяющая разработчикам создавать системы, способные приносить прибыль компаниям долгое время, я рассказываю в своем телеграм-канале solonkov.team. Там же вы сможете задать интересующие вас вопросы и заказать консультацию.
- скопипастил введение к Чистой Архитектуре дядюшки Боба, причём текст и графики абсолютно идентичны
- не указал источник
- оставил ссылку на свой ТГ канал
Какие конкретные проблемы могут возникнуть в результате плохой программной архитектуры? Какие рекомендации вы можете дать для предотвращения таких последствий?
Проблемы подчеркнуты в статье. Основные - рост издержек и снижение продуктивности. Быстрых и простых решений здесь нет. Я буду приводить рекомендации в последующих статьях цикла про архитектуру.
Если при выпуске восьмой версии фонд оплаты труда составляет 5 млн. и Компания-разработчик может себе это позволить, то честь ей и хвала. Значит входящих поступлений для этого хватает
если столько разрабов выросло, а производительность та же, то при падении выручки (кризис) наступит плохая пора для ИТ-системы
Мне кажется, сперва прогноз по выручке, а потом количество разработчиков и ФОТ.
то есть прогноз по выручке плохой, а система раздулась, то жертвовать функциональностью и терять еще больше выручки?
тогда все равно придем к тому, как переделать систему так, чтобы меньшими силами обслуживать — то, о чем в статье, а ваш комментарий говорит "ну зачем, если выручка есть", то есть полагание на "потом отреагируем, как монстра почистить, если выручка будет падать", но ведь реактивная модель чревата большими рисками не сделать так, как "потом придумаем"
Предположим, плохая архитектура уже есть, кто-то ее создал. Обдумывали набор управленческих и технологических механик для исправления подобной ситуации?
Решение комплексное и зависит от тяжести ситуации. Мало у каких компаний все идеально. Рекомендации по исправлению ситуации я буду приводить постепенно в своих дальнейших статьях.
Это обычно куда сложнее, и требует настоящей экспертизы. А не фантазий "будем вкладываться в архитектуру на стадии МВП в ущерб тайм-ту-маркет, и на маркет не попадем вообще"
Как-то всё намешано, вроде и правильно, но не особо полезно.
Не обязательно использовать именно TDD, главное писать тесты и иметь контроль качества. Но тесты не проверяют хорошая ли архитектура. А хорошие тесты тоже надо ещё суметь написать. Не на всё можно написать тесты. Некоторые вещи очень сложно протестировать, как в плане организации, корректности, как и в плане вычислительных затрат. Всегда будет что-то, что тестами не учитывается. Классический пример: пользователь из другой страны с другими локальными настройками: язык, часовой пояс, раскладка клавиатуры, точка или запятая как разделитель дробной части и т. д. (особенно американцы об этом не задумываются).
Метрика в виде количества строк кода? Индусы одобряют! Сразу вижу оптимизацию - зааутсорсить все в Индию. Там ребята опытные, и умеют хорошо давать рост строк кода!
З.Ы. Продумывать архитектуру и работать с тех долгом - дело правильное и нужное. Когда не мешают ТТМ. Но все эти скачки со строками кода тут совершенно лишние.