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

Как происходит зацикливание даже в простых случаях? Программисты классифицируют коров и столы по признаку наличия четырёх ножек, после чего всю энергию тратят на то, чтобы написать интерсепторы, аспекты, применяют мощные инструменты рефакторинга кода для того, чтобы ad hoc [119] разрешить некоторые возникающие противоречия в созданной модели.

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

Борьба с зацикливанием с обеих сторон нередко принимает причудливые формы.

Совсем недавно мне выдалось консультировать по сугубо техническим вопросам одну скрам [120] -команду. Проект был заказан крупным автопроизводителем и касался разработки бортовой системы мониторинга и управления периферийным оборудованием. Функциональные спецификации составили вместе толстую пачку листов формата А4, напечатанных с двух сторон, думаю, в общей сложности не менее 2 тысяч страниц. Понятно, что никто из программистов в здравом уме не стал читать документацию целиком, а взяли несколько функций, под которые и начали строить реализацию. После четырёх месяцев работы выяснилось, что архитектура эволюционным путём не выстраивается, хотя заказчик регулярно видел разные красивые экраны с заглушками и симуляцией приходящих от устройств прерываний. Разумеется, и я не стал читать все эти тысячи страниц, ограничившись весьма интересным документом, содержащим иерархию функций, то есть фактически глоссарий функциональной декомпозиции системы. Из документа следовало, что архитектура, состоящая из набора служб, доступных на общей шине (здравствуй, CORBA), охватывала несколько верхних уровней иерархии. Однако такая перестановка означала переделку большей части системы, тогда как регламент не разрешал увеличить время очередной итерации до минимально необходимых 2–3 месяцев, а бюджет и ресурсы не позволяли начать параллельную стройку. В итоге команда осталась в прежней архитектуре, осознавая на собственной шкуре, что затраты на добавление новых функций растут.

Совсем свежий пример: настоящее время, крупная корпорация – строится внутренняя система управления предприятием. Официально написаны 3,5 тысячи страниц функциональных спецификаций, полтора десятка программистов в том же «скраме» уже приступили к реализации отдельных частей. Через год-полтора будет ясно, получилось ли что-нибудь в итоге.

Эти два примера вполне соответствуют тенденциям взаимного перекладывания ответственности на сложных проектах. Заказчик осознаёт, что реализовать спецификации своими силами невозможно, прежде всего потому, что при таком объёме они тем не менее неполные и неизбежно содержат противоречия. Подрядчику же в принципе наплевать на спецификации, он будет крутить итерации, честно реализуя заявленный функционал и отрабатывая бюджет. Получился коровник на подпорках с покосившимися заборами и дырявой крышей вместо современного агрокомплекса? Извините, всё по спецификации, каждые две-три недели вы видели расцвеченные фотографии разных участков возводимого сооружения.

Синтез «водопада» сложной системы, итоги проектирования которого подаются на вход «гибкой» производственной машины кодирования и стабилизации – что может быть бессмысленнее и беспощаднее?Кроме частных примеров относительно крупных заказов, современная тенденция – огромное число некритичных проектов, программ и систем-пристроек к основной КИС. Масштаб проектов небольшой (сотни тысяч строк кода), заказчик точно не знает, что хочет получить в итоге, а подрядчик не имеет опыта в данной предметной области, если вообще имеет хоть в какой-то, и поэтому не может ему объяснить, что кактусы за полярным кругом не растут. Для такой ситуации привлечение команд с имеющими требуемый опыт квалифицированными специалистами и технологиями предметно-ориентированных языков или разработки по моделям маловероятна, поэтому пусть уж лучше итеративная методология «наживульки», чем никакая, как оно зачастую бывало в эпоху штатных отделов АСУ.

Тесты и практика продуктового софтостроения

Привожу комментарий Максима Крамаренко, руководителя компании Trackstudio, выпускающей одноимённый продукт для управления задачами в софтостроении.

...

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

1. При изменении спецификаций затраты времени на приведение в актуальное состояния тестов могут быть куда больше, чем на собственно код. Скажем, если пользователи захотят поменять синтаксис SQL в СУБД и писать SEARCH вместо SELECT, то это одно изменение продукта в одном месте приведёт к переписыванию почти всех тестов. Если для СУБД такие пожелания пользователей – редкость, то для менее стандартных программ – обычное дело.

2. Сбои, которые могут выловить тесты (повторяемый сбой в модуле, ранее уже исправлявшийся), – довольно редкое дело. Гораздо чаще сбои возникают в интеграции разных технологий, которые сложно автоматически протестировать. Например, при работе под таким-то браузером при таких-то настройках вот этот JavaScript работает неправильно.

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

4. Если не напрягаться с выпуском раз в 2 недели, то возможность быстро что-то протестировать не так уж и важна. Мы себя совершенно нормально чувствуем с испытанием бета-версии в течение 2–3 месяцев, зачем чаще?

5. Одни из наших конкурентов широко используют agile-методы и TDD [121] , но что-то оно им не очень помогает писать безошибочный код. Мы сравнивали количество найденных проблем в течение месяца-двух после major release, у нас показатели лучше в разы, если не на порядок. Частый выпуск версий просто не позволяет им довести код до ума и провоцирует исправление старых и серьёзных проблем методом написания «залепени». (Прим. автора: исправление ошибок, добавляющее новые проблемы.)

6. Я совсем не уверен, что пользователи хотят получать новую версию раз в 2 недели. TrackStudio 3.5 вышла примерно через полгода, после TrackStudio 3.2, и мы получили много негативных откликов, что такие частые релизы заставляют их обновлять локальную документацию и задерживают их собственные процессы на несколько месяцев. Многие пользователи совершенно спокойно живут без обновлений несколько лет. Если они купили продукт – значит, он делает то, что они хотят. Если чего-то не делает – они все равно уже нашли workaround (обходное решение), им всё равно.

7. Для корпоративного софта пользователи хотят длительного периода поддержки, пара лет, минимум. Если мы выпускаем продукт раз в 2 недели и находится серьёзная ошибка в версии годичной давности, то нам её нужно будет исправить примерно в 40 ветках. Конечно, править 40 веток кода никто не будет, пользователям сообщат, что ошибка будет исправлена в следующей версии, многие пользователи перейти на неё не смогут (см. п.6) к большой радости конкурентов с предложениями типа competitive upgrade offer.