Миф о модифицируемости Аксапта, или техническая эстетика.

[stavteam]

Как человек, отдавший Аксапте год своей жизни, хочу поделиться своими мыслями о распостраненном мифе - "Аксапта легко программируется, и в этом ее преимущество".
Действительно, среда разработки почти совершенна. Я не встречал более продвинутой RAD для бизнес-приложений. Есть отдельные проблемы - кривой построитель отчетов, неполноценный SQL, отсутствие перекрестных запросов (сводных таблиц), отсутствие даже намека на историчность данных, однако эти недоработки с лихвой компенсируются мощью расширенных типов данных, методов таблиц, групп полей, построителя запросов, сохраняемых фильтров и автоотчетов, настройкой прав доступа.
Если бы платформа продавалась отдельно - я бы купил ее для целей разработки заказного ПО. Однако - насколько легко модифицировать стандартный функционал, даже при наличии OOD и всех остальных удобств ?
Ответ - модифицировать Аксапту тяжело и в большинстве случаев нецелесообразно. Дело не столько в том, что код не документирован. И не в том, что специалистов мало, и они дорогие. И не в том, что стандартный функционал изначально написан криво.

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

Основная проблема заключается в том, что любое промышленное высокотехнологичное изделие очень тяжело поддается кустарной модификации. Есть у инженеров (я сам потомственный ) такой принцип - совершенная конструкция должна быть КРАСИВОЙ И ПРОСТОЙ. Опытному инженеру необязательно рассчитывать все узлы на прочность. Достаточно оценить внешний вид и сказать - "Это колосс на глиняных ногах. Смотри как некрасиво выглядит. Наверняка в этом месте будет концентратор напряжений." Или - “Такая сложная конструкция не будет работать”. И с большой долей вероятности будет прав.
Посмотрите на автомобили. Какая у них совершенная форма. Как все продумано. Кому придет в голову модифицировать кузов Порше, превращая его в грузовик ? Или как можно модифицировать бытовую стиральную машину ? Или соковыжималку ?
Это ПРАКТИЧЕСКИ НЕВОЗМОЖНО. Потому что, несмотря на поагрегатное проектирование, дизайн конечного изделия создается с учетом ВСЕХ требований. И на приборной доске автомобиля зачастую нет места для дополнительных устройств. Конечно, есть определенный тюнинг, однако мало кто тюнингует иномарку в гараже дяди Вани, хотя восьмерку наверняка ему доверит. У технологичных изделий тюнинг выполняется как правило авторизованными сервис-центрами, и то в очень ограниченных масштабах.
А все потому, что ДОБАВЛЕНИЕ СУЩЕСТВЕННОЙ ДОЛИ ФУНКЦИОНАЛА ПРИВОДИТ К НЕОБХОДИМОСТИ ПЕРЕСМОТРА ВСЕГО(!!!) ДИЗАЙНА. Это так, потому что в высокотехнологичном изделии все компоненты очень связаны, и друг на друга влияют. К сожалению, я пока не знаю удачных примеров "изделий-конструкторов", пригодных на все случаи жизни, хотя ощущаю очень горячее желание потребителей иметь такие изделия. Видимо - технология еще не дозрела. Или - экономически нецелесообразно это. В большинстве случаев конкретное изделие удовлетворяет конкретную потребность и имеет ограниченный набор функций. При этом оно технически совершенно и КРАСИВО.
Вернемся к Аксапта. Система создавалась с претензией на универсальность. Однако получился жесткий набор предопределенных функций. Например - дерево спецификаций. На первый взгляд - очень универсально, однако пример небезызвестной Глории-Джинс, с ее специфичными производственными приказами, процентовками и раскладками кроя, говорит обратное. В данном случае универсальность дерева BOM только мешает. Для того, чтобы удовлетворить реальную потребность компании необходимо дерево строго определенной структуры, где каждый его уровень имеет свою семантику, функциональность и набор атрибутов. Не нужны тут универсальные деревья, а нужны растения вполне определенного вида и свойства.
В этом случае можно модифицировать стандартные деревья, делая их нестандартными, но в итоге очень пострадает эстетичность решения. Продукт будет обладать очень неочевидным функционалом и пользовательским интерфейсом, его будет трудно понимать как программисту, так и пользователю. Будут проблемы с поддержкой. В данном случае целесообразно разработать заказное решение.
Сейчас я понимаю, что две вещи - эргономика данных и эргономика пользовательского интерфейса - очень важны в корпоративном ПО.
Эргономика данных предполагает несколько простых правил:

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

Эти правила легко соблюдать при итеративной разработки приложения "с нуля", и практически невозможно осуществить при "точечной" модификации готовой системы. В случае нашего дерева BOM мы получим несколько бизнес-сущностей в одной таблице, и несколько программистских абстракций. Кроме того – в сложную систему мы внесем еще больше сложности. А как показывает опыт - это неэстетично и плохо поддерживается.
Та же самая ситуация происходит с эргономикой пользовательского интерфейса, которому по определению следует быть простым, понятным и дуракоустойчивым. Желание "максимально сохранить стандартный функционал" приводит к неочевидности и неожиданности системы для конечного пользователя. И еще страшнее то, что при достаточно глубокой модификации часть стандартного функционала может не работать, или работать по другому, а из пользовательского интерфейса этого никак не видно, так как интерфейс универсален.
Необходимо сделать то, о чем я говорил вначале - пересмотреть ВЕСЬ дизайн c целью упрощения и придания эстетичности.
Я не сторонник универсальных решений. Универсальность всегда создается ценой сложности и громоздкости. Я считаю, что клиент платит за конечную функцию, и вправе требовать удобств. Я знаю только одну универсальную программу для бизнеса. Называется Excel. К сожалению, не поддерживает многопользовательской работы, транзакций, имеет ограничения на объем данных, и поэтому применим только в сольной работе.
В настоящее время RAD-средства прогрессируют очень быстро, и очень скоро затраты на разработку ERP-системы под заказ станут меньше стоимости (лицензия + внедрение) тяжелых систем. Это понимает MS. Поэтому для нее так важно удержать под своим контролем именно технологии, а не продукты. Это понимает 1С, развивая в первую очередь платформу, а не функционал. Но я думаю, что работать с этими RAD-средствами должны не наши клиенты, а фирмы-разработчики. Все-таки это наша профессия .