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

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

Всё перечисленное программист мог сделать на макрорасширении над языком 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].

Наследование объектов и объект-контейнер с визуальным конструктором. Ultima-S построена на идее наследования классов, как современный вариант PostgreSQL. Если брать модель 1С – это наследование только на системном уровне и отказ от наследования в бизнес-уровне в пользу конструирования путём сложения комбинаций объектов в объект-контейнер с помощью визуальных конструкторов. Модель 1С сильней. Быстрее создаёт новые сущности, за счёт разделения системного уровня и конструктора, она также надёжнее, так как настройщики очумелыми ручками не могут залезть в ядро.

Прикладная разработка не место для эстетического наслаждения от красот технологий. Это бизнес. Ultima-S сильно пострадала от того, что стала чем-то вроде лаборатории Xerox в 1980-х, где масса людей апробировала разные технологии, научилась и пошла делать другие проекты в Apple и Microsoft. Архитектурные эксперименты оправданы, если маркетолог видит преимущества в архитектуре товара, которые преобразуются в удовлетворение потребностей клиентов. Надо оценивать эффективность архитектуры не в терминах красот, а в терминах трудозатрат. Пользователю все равно, он не видит что там внутри. Но он видит, что система дорабатывается медленно или валится с ошибкой. Для меня был огромный плюс, что я познакомился в этом проекте с MS Project и стал в нем анализировать трудозатраты программистов. Выводы были интересные. Я заметил, что программисты и технологии могут выглядеть невзрачно, но давать невероятные эффекты по скорости и надёжности кода в терминах низких трудозатрат, и наоборот, вроде бы красивые решения могут превращаться в «чёрную дыру» для бюджета проекта.

На деле Ultima-S показала, что идея реализации сервера приложений средствами СУБД жизнеспособна и эффективна, также она совместима с лучшими функциональными практиками на рынке, как, например, моделирование в 1С. Но отсутствие маркетолога на проекте в качестве его лидера не дало технологиям добиться коммерческого успеха, который пришёл уже к системам – наследникам Ultima-S.

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

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

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