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

Тонкий клиент отображал в динамике результаты обработки события сервером. Большинство экранных форм, таким образом, формировалось автоматически, программист только объявлял в процедуре соответствующие поля ввода и сетки. Для специфичных случаев расположения элементов управления было необходимо визуально проектировать форму либо во встроенном в приложение редакторе, либо в среде Visual Basic, загрузив затем описание формы на сервер.

В общем случае, для создания программистом новых классов в системе было необходимо:

• декларировать классы;

• создать соответствующие таблицы;

• описать возможные ограничения на уровне метаданных (например, папку для создания по умолчанию или максимальное число ссылок);

• написать обработчики стандартных событий;

• добавить привилегии, видимые администратору;

• если необходимо, инициализировать данные, например, создать служебные объекты или документы-классификаторы.

Всё перечисленное программист мог сделать на макрорасширении над языком Transact SQL, не выходя за рамки разработки соответствующих скриптов. Приведу примеры использовавшегося кода.

Пример фрагментов кода модуля учёта сотрудников

Как можно заметить, декларация форм напоминает таковую в HTML, но с гораздо более богатыми элементами стандартного графического интерфейса, не ограниченного возможностями браузера. Прикладному программисту не надо управлять соединением с сервером баз данных, внедрением SQL-запросов, обработкой сетевых ошибок и многим другим, потому что код уже находится внутри процедур адресного пространства СУБД, обеспечивая максимальную производительность обработки данных. При этом, на минуточку, на дворе 1996 год, никто из веб-разработчиков пока не выходит за рамки postback-ов , динамическое обновление форм без перегрузки всей страницы, предоставляемое Ultima-S, в AJAX появится через 10 лет. А изначально поддерживаемые трёхмерные, стиля Excel, сетки-таблицы с закладками в динамических формах до сих пор доступны лишь в сторонних компонентах.

Номенклатура базовых классов и системных служб позволяла пользоваться полуфабрикатами прикладного назначения: от управления жизненным циклом документа, доступом к папкам до бухгалтерских абстракций, позволявших задействовать механизмы материального и финансового учёта. Для реализации нового типа документа и отражения его в системе управленческого учёта предприятия программисту требовалось работы на 1–3 дня.

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

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

Приведу мнение коллеги по проекту, Владимира Иванова, аналитика и руководителя группы разработки бухгалтерской подсистемы. Роль функционального архитектора или, в терминах MSF [107], менеджера продукта он называет просто «маркетолог».

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

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

Следуйте совету Джобса: «Обычные художники заимствуют – великие воруют». Для меня, как руководителя группы разработки бухгалтерского модуля, существовала проблема: никто не мог поставить задачу. Системный архитектор был «не совсем в теме», маркетолог со знанием продукта отсутствовал. Но мне в голову пришла удачная идея начать копировать макроязык и систему настроек 1С, одновременно обеспечивая совместимость с объектной моделью Ultima-S. Если бы разработчики Ultima-S, до того как взяться за написание кода, провели тщательное изучение архитектур аналогов на рынке, все было бы иначе. Можно было бы передовую платформу Ultima-S приспособить к куче хороших идей у 1С и «Галактики». Я в то время часто общался с экспертами «Галактики», они серьёзно опасались, что мы именно так и сделаем: реверс-инжиниринг и переписывание в новой технологии. Ресурсы для этого у нас были. Но, увы, сделали только частично, а 1С – это все-таки модель малого бизнеса, тогда как мы целились в сектор Enterprise, где была «Галактика».

Учитесь у лидеров рынка, их успех не от «просто так». Я получил два важных опыта в этом проекте – объектно-реляционное моделирование и проблемно-ориентированные конструкторы, которые популяризовал Нуралиев. Могу сразу сказать: Нуралиев круче. Дело в том, что его функциональная архитектура была следствием изучения потребности рынка и типовых сценариев внедрения. Наш

бухгалтерский модуль из Ultima-S до сих пор живёт и здравствует в нескольких холдингах, которые не раз оценивали миграцию на Axapta, но оставались все равно на нём. Концепция 1С плюс возможность Transact SQL-программирования – мечта многих разработчиков бизнес-решений. Нуралиева много раз просили это сделать, но он держался за свой подход, чтобы поддержать кросс-платформенность [108].