Дефрагментация мозга

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

ORM на софтостроительной площадке

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

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

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

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

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

Вы резонно спросите: «А где рефакторинг?» Системе на тот момент исполнилось уже 2 года. Рефакторинг проводился раньше, но, в связи с тем, что его стоимость, прежде всего по требуемым срокам поставки, возрастала, количество реструктурируемого кода линейно уменьшалось. Это создало положительную обратную связь: реструктуризация становилась всё дороже.

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

Приведу пример подсистемы, для которой рефакторинг уже стал дороже полной переделки. Имелся модуль экспорта документов в форматы, пригодные для импорта системами клиентов уровня их внутренних АСУП[60]. Коллективная ответственность привела к выбору написания императивного кода в размере 20 тысяч строк вместо разработки нескольких шаблонов XSLT[61] из нескольких сотен строк. Почему? Во-первых, опасались потери производительности, а во-вторых, не имели достаточной компетенции в XSL. Цикломатическая сложность[62] кода в отдельных методах превышала запредельное число 50 при рекомендованном пороге в 10–20. Глубина вложенности вызовов также была больше 10, при цикличности их части: this с верхнего уровня передаётся в качестве параметра, и где-то глубоко внизу дёргают этот this за какой-то метод. Объектно-ориентированная тарелка со спагетти.

О производительности следует сказать отдельно. Загрузка достаточно сложного документа перед его экспортом занимала порядка 30 секунд. Потому что было принято идеологическое решение «ни строчки SQL», несмотря на необходимость поддержи только одной РСУБД. Вся система работала через слой доступа[63] под управлением NHibernate. Это был именно DAL, а не домен, так как парни не использовали всю мощь NHibernate, ограничиваясь отображением, и накручивали сверху слои бизнес-логики. При загрузке сложного документа с проверками подсистемы безопасности было насчитано порядка 20 тысяч (!) коротких SQL-запросов.