Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

В 2008 году крупный разработчик ERP-системы для розничной торговли оказался в числе наших клиентов. Что же хотела компания с 25-летней историей, двумя сотнями сотрудников и множеством клиентов в Европе и Северной Америке, среди которых такие бренды, как Naf Naf, Vieux Campers, Tally Weijl, Guess, от небольшой программистской фирмы, вчерашнего «стартапа»?

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

Проведённый Марком, нашим консультантом, уже самый первый аудит во время командировки в Монпелье принёс очень интересную информацию к размышлению. Предыдущая версия была реализована в классической клиент-серверной технологии в среде Microsoft. То есть SQL Server, «толстый клиент» или веб-клиент под ASP.Net с разделяемой на уровне сборок логикой. Все работало прекрасно до некоторого времени. А время, поскольку клиенты крупные, подошло быстро, за несколько лет. База данных разрослась, время отклика как интерактивной работы, так и пакетов увеличилось, производительность продолжала понемногу деградировать. Например, обработка консолидациирезультатов торговли за сутки стала превышать эти самые сутки.

Программисты даром времени не теряли и упомянутую консолидацию переписывали три раза. Сначала на SQL, но с курсорами, получив ещё худший результат. Потом попытались избавиться от курсоров, но всё равно не смогли достигнуть требуемой производительности. Потом в команде каким-то образом появились специалисты, сказавшие: «Это не объектный подход!» Они переписали всю обработку на C#, окончательно похоронив производительность модуля.

База данных у клиентов – порядка одного терабайта, с примерно 500 миллионами строк в самой большой таблице, соответствующей истории за несколько лет. В версии-«бабушке» использовались технологии «старой школы» вроде архивации, благодаря чему она как-то справлялась с объёмами, хотя бы и за счёт вывода данных из оперативного контура. Но смена СУБД на более мощную из «большой тройки» и более производительное «железо», видимо, произвела на разработчиков обманчивое впечатление, что всё решится как-нибудь само.

Физическая архитектура хранения, секционирование таблиц, оптимизация индексов и запросов по выборочной статистике – эти вопросы всерьёз не рассматривались, база данных тихо кряхтела одним файлом, правда, на мощном 16-ядерном сервере с 32 гигабайтами памяти и быстрым дисковым массивом.

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

Однажды я наблюдал, правда, уже в другом продукте, как обрабатывали таким образом матрицу прав доступа. Две сотни пользователей, десять миллионов объектов и voila – списки размером порядка 100 миллионов элементов сидят в памяти сервера приложения, где со скрипом тормозов обрабатываются запросами LINQ. Выдавать из СУБД информацию, уже прошедшую необходимые фильтры доступа, почему-то оказалось сложнее.

Вот под это развитие и было решено использовать программную фабрику, чтобы генерировать рутинный код отображения таблиц на объекты, объектов, на их посредников ( proxy ) для доступа через канал WCF и части интерфейса на WPF.

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

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