Несеребряные пули или кратко про методы софтостроения

Давайте пробежимся по способам софтостроения, придуманным примерно за 70 лет его существования. Их не так много, как может показаться. Но достаточно много, чтобы завести в тупик.

Присказка

Человек по природе адаптивен. Заходишь, к примеру, на кухню, где на гриле вертится курица. Аромат бьет в нос, а если проголодался, так и вовсе слюнки потекут. Минут через пять перестаешь ощущать запах. О еде напоминает лишь крутящийся за стеклом духовки кусок мяса с растопыренными крыльями. Запах-то никуда не делся, его можно померить, но информация с рецепторов заблокирована мозгом ^[1].

Такое происходит повсеместно, и софтостроение не исключение. Начинаем с «открытий чудных», что нам «готовит просвещенья дух», плавно переходим к текучке, стыд-и-скрам, спринты-шминты, инкапсуляция-полиморфизм-народность, и, опаньки — крутится себе кусок мяса в печке, грозя подгореть до срока, несмотря на регулярную материальную стимуляцию выше средней по больнице.

В 1960-х годах один любознательный мужик по фамилии Досс (Richard B. Doss ^[2]) установил, что в пропитанной протестантским трудоголизмом Америке 70-80 % людей трудятся сильно ниже своих возможностей. Причем, в отличие от робота-манипулятора, белковый работник способен это быстро просечь. Исследования повторяли в «нулевые» и «десятые» с тем же результатом. На здоровье такая ситуация влияет, мягко говоря, неважно.

Цель текста не разубеждать вас в недостаточной продуктивности или давать какие-то советы. Мы только кратко пробежимся по способам софтостроения, придуманным примерно за 70 лет его существования.

Три способа

Не буду тянуть резину, начну с главного. Способов разработки программного обеспечения всего три. Да, три — хорошее число, красивое. Итак:

Нисходящий способ. Это когда сначала глобально думают «что делать», потом «как делать», а потом уже делают, если время осталось.

Восходящий способ. Это когда сначала делают, понемножку, мелкими частями. Думают «что, да как» только над этой частью, не заморачиваясь на глобальное и непреходящее.

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

Нисходящая разработка

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

Сошествие способа в массы приходится на 1960-е годы, органично дополняя требования структурного программирования мыть руки перед едой и пользоваться столовыми приборами и салфетками. Глобальная задача делилась на более мелкие подзадачи, те, в свою очередь, на еще более детальные и так далее до уровня структурного блока, который можно непосредственно реализовать на языке программирования. Кстати, тесты к этим блокам пишутся параллельно, привет TDD-шникам из 1960-х.

Русская пословица «Семь раз отмерь — один раз отрежь» как раз про нисходящий метод.

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

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

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

В дальнейшем способ неоднократно улучшался, например V-метод ^[3], где стадиям разработки по левому спуску буквы «V» соответствуют стадии тестов и приемок подъема справа. По горизонтальному уровню сразу видно, какой проектный документ подрядчика служит основанием для приемочного документа заказчика.

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

Восходящая разработка

На самом деле, восходящий способ еще древнее нисходящего. В 1950-х уже существовали и Фортран, и Кобол, но не было ясных представлений, как строить софт. Поэтому поступали самым естественным образом: сегодня сделаем одно, завтра другое, потом когда-нибудь склеим в третье. Если нужно реализовать несколько задач, то выбираем наиболее важные.

Иногда способ также называют инкрементальным, видимо, по аналогии с i++. Добавили функцию — инкремент. При желании натянуть глобус на меркаторову проекцию инкрементальным можно обозвать и спиральный метод, но об этом позже. Способ также любят изображать в виде цикла, хотя для i++ не определены конечные значения, поэтому «копать» придется «отсюда и до обеда». Продолжая тему русских пословиц, есть у нас поговорка «крутится, как белка в колесе» — вот это как раз про восходящий способ.

Методика была и остается наиболее характерной для домашних (in-house) разработок. Свои программисты должны делать то, что нужно для бизнеса еще вчера. Чтобы думать о более глобальном, в 1960-х появились «софтверхаузы» ^[4] — крупные проектные конторы по разработке заказных систем, включая таких монстров, как IBM ^[5].

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

В 1990-х годах пошел мощный тренд замены «домашних» программистов на внешних консультантов. Одна из причин — усложнение технологий и специализация, труднодостижимая внутри фирмы для которой софтостроение — непрофильная деятельность. Домашний софт теперь разрабатывается временными командами шабашников контрактников. Изменились отношения, а заказчик — не спец во всех этих методологиях, анализах, архитектурах. Заказчик в лучшем случае знает, в чем отдельные проблемы и может расставить над ними приоритеты. Команда контрактников в свою очередь, не знает о бизнесе заказчика достаточно, чтобы cпланировать всю реализацию.

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

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

Что улучшилось:

• планирование по-прежнему короткое, но охватывает не одну функцию, а их группу при этом срок этапа жестко ограничен;
• ведется протокол сделанного;
• теоретически, должно выделяться время на упрощение и чистку кода (рефакторинг);
• теоретически, риски регрессии должны парироваться всеобъемлющими тестами.

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

Дублирование кода, ненужные усложнения, отложенные «на потом» неэффективные реализации — если вовремя не разгребать сделанное ранее, то растет технический долг. Чем позже долг возвращается, тем больше в итоге приходится платить: временем, человеко-днями, ошибками, сбоями, медленной работой и т.п.

Спустя каких-то 10-15 лет авторы «Манифеста аджайла» начали бить в набат ^[6]: «Ребята, что вы делаете, мы имели в виду другое». Они в чем-то правы, восходящая разработка так проста и тем притягательна, что все эти дополнительные процедуры кажутся необязательными.

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

Проблемы, как и в случае с «водопадами», принципиальные. Проще управлять процессом, но практически невозможно — конечным результатом, так как он нигде четко не фиксируется. Риски перекладываются на заказчика: пускай владелец продукта думает, у него башка большая. Если с технической архитектурой при наличии опыта, тестов и рефакторинга команда справляется (до определенного порога сложности), то с архитектурой функциональной дело плохо. Упрощение постановки задачи, тот самый «рефакторинг», теперь уже модели предметной области, помог бы избавиться от навороченного и дорогого в сопровождении кода, но сделать его некому. Да и модели-то нет, если честно, вся семантика в головах и в коде.

Но нет повода расстраиваться, вспомните про самый провальный спринт в мировой истории: 5 дней сотворения и полтора миллиарда лет непрерывного рефакторинга.

Спиральная разработка

Упомянутые «водопадные» ограничения стали ясны еще в 1970-х, после массовых внедрений соответствующих методологий типа SADT/IDEF ^[7]. Параллельно работали и по восходящим методикам на «домашних» проектах с другими заморочками, что создавало ощущение некоторого тупика. Поэтому озадаченные проблемой исследователи (прежде всего Barry Boehm ^[8]), почесав репу, выдали к середине 1980-х годов обновленное видение процесса софтостроения в виде спирали ^[9].

Логика рассуждений «спиральщика» примерно такова. Да, с ростом сложности задач мы тратим все больше времени на анализ и проектирование, риск ошибок на этой стадии растет. Но реализуя отдельные функции без общего плана мы рискуем ошибиться не меньше, получив в итоге неэффективно работающие или просто несовместимые части. Поэтому оставим в покое «святую корову» — проектирование, но а) ограничим ему сроки и б) будем жестко проверять принятые решения, выкатывая полный прототип.

Пункт «б» очень важен. При восходящей разработке вы тоже постоянно что-то выдаете, багфиксы там, новые фичи. Но это сработает, если система уже в эксплуатации и на сопровождении. А если нет? Представьте, заказчик хочет систему управления движением поездов, а вы ему через пару-тройку недель показываете экраны ввода информации о подвижном составе и симулятор расписания. Несерьезно.

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

Из сказанного понятно, что относить спираль к инкрементным способам так же нелепо, как китов к рыбам, хотя у тех и других есть хвост.

Что в спирали хорошего? Мы резко снижаем риски выкатить заказчику вместо продукта откровенную лажу, но при этом не приносим в жертву проектирование. То есть, глобальное видение ситуации сохраняется, конечным результатом можно управлять, рассчитывая бюджет и прибыль. Всем, клиенту и подрядчику, виден свет в конце тоннеля. Заказчик, если он серьезен в намерениях, тоже не будет бухтеть: «Что вы мне то хвост, то хобот подсовываете, покажите мне всего слона!» На каждом витке слон виден целиком.

Однако, по сравнению с восходящим софтостроением, обойтись взводом программистов-техников без аналитиков и проектировщиков не получается, и вам придется объяснять этот щекотливый момент заказчику в обосновании более высокой цены. После стадии проектирования первого витка спецы не простаивают, а продолжают вгрызаться в задачу, ожидая фидбэк, но на финальном витке они, скорее всего, вообще не понадобятся. Длина витка может составлять до нескольких месяцев, но обычно обходится двумя-тремя. На еженедельный спринтовый экстрим не похоже, но и на годовое ожидание продукта тоже. Нелегким остается и выбор, когда на данном витке «уже хватит проектировать» и пора начинать класть кирпичи.

Наиболее известная и успешная реализация спиральной методики — MSF ^[10] (Microsoft Solution Framework). У Микрософта позднее появилась и обстриженная версия, заточенная под восходящие методы, и продаваемая как MSF for Agile для относительно небольших проектов и команд.

Вместо эпилога

Дедушка Брукс в своем бестселлере ^[11] выделил четыре типа софта, который люди строят.

На картинке видно, что в некоторый момент вы можете перестать «просто писать программу» и «за втридорога» захотеть сделать из нее то ли продукт (то, что поставляется множеству разных клиентов), то ли комплекс (то, что состоит из многих программ и бесшовно интегрируется в среду заказчика, включая оборудование). И если «писать программу», по большому счету, можно любым из софтостроительных способов, то ваши прекрасные планы по дальнейшему развитию могут быть нарушены недостатками нисходящих и восходящих методов.

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

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

Оригинал текста ^[12] на сайте «Механика софтостроения»

Автор: Сергей Тарасов

Источник ^[13]