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

См. часть 1 – «лишний» этап».

См. часть 3 – этика тестирования.

Что такое дизайн расширения?

Давайте для начала разберемся с названием. Функциональный дизайн разработки, технический проект, описание доработок и т.д. У разных интеграторов я встречал разные названия этого проектного артефакта, но поскольку я апологет внедрения одинэсочки по методологии ЭЙМ, то далее в этой статье я буду называть этот проектный артефакт так как это принято в ЭЙМе – дизайн расширения (см. MD.050, MD.060 и MD.070).

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

Умение мыслить абстрактно – это ключевой навык функционального архитектора. Именно поэтому регулярное участие в написании дизайнов расширений является одной из практик, которые позволяют программисту или аналитику вырасти в функционального архитектора (см. главу «про строительный материал»).

Важный момент. Дизайн расширения – это не техническое задание. Т.к. техническое задание (даже уточненное или частное) – это прежде всего требования, которые подаются на вход дизайна расширения. И это не перепись уже написанного программного кода с названием разработанных методов. Т.к. программный код как раз таки пишется на основании дизайна расширения.

Далее разберемся для кого мы пишем этот проектный артефакт. Кто его будет читать.

Чтец №1 – программист. Тут все очевидно. Программист трансформирует дизайн расширения в программный код. Желательно в работающий и желательно без технического долга. Обратите внимание, что нет никакого противоречия, если программист сначала сам напишет дизайн расширения, а затем напишет программный код.
Чтец №2 – аналитик. На основе написанного аналитик проводит юнит-тестирование.
Чтец №3 – технический архитектор. Контролирует целостность метаданных в рамках системы, оптимальность выбранного решения с технической точки зрения.
Чтец №4 – функциональный архитектор. Контролирует логическую целостность в рамках системы, соответствие выбранного решения заявленным требованиям.
Чтец №5 – руководитель проекта. Контролирует полноту покрытия заявленных требований доработками.
Чтец №6 – ИТ-служба заказчика. Согласовывает концепцию решения, оценивает выбранное решение с точки зрения дальнейшей эксплуатации системы.

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

Когда бизнес-заказчик попросил функционального архитектора объяснить, что написано в дизайне расширения

Разобравшись с чтецами, поговорим о том, кто пишет этот проектный артефакт. Тут все зависит от проектной технологии, принятой в интеграторе. Это может быть как аналитик, так и программист (см. главу «про строительный материал»).

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

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

Разберемся со структурой дизайна расширения.

Титул. Как писать титулы я вас учить не буду, поэтому... Хотя нет. Все-таки буду. Нумерация дизайнов расширений д.б. сквозной. Наименование д.б. смысловым, а не бездушным шифром из непонятных цифр и букв. Наименования д.б. унифицированы – все дизайны расширений про отчеты должны называться в одном стиле, все дизайны расширений про НСИ в своем, и т.д. Дело в том, что к дизайну расширения очень часто приходится возвращаться по ходу выполнения проекта. Так же, как мы убедились выше, у него много чтецов. Поэтому важно максимально быстро находить и идентифицировать дизайн расширения среди множества других.
Требования. Дизайн расширения не пишется в вакууме. Дизайн расширения всегда порожден каким-либо требованием, сформированным в рамках анализа бизнес-процессов. Или ошибкой, возникшей в рамках эксплуатации системы. На основе этого раздела контролируется, что все требования, для которых нужно доработать систему, покрыты дизайнами расширений. Это позволит на старте эксплуатации системы избежать сюрпризов, что какие-то доработки банально забыли сделать (а то всякое в жизни бывает – например, одна моя знакомая как-то забыла прийти на собственную свадьбу).
Действия пользователя. В этом разделе описывается какие действия должен сделать пользователь, чтобы функция системы была выполнена. Именно на этот раздел будет опираться аналитик, когда будет готовить сценарий юнит-тестирования. Также в рамках этого раздела функциональный архитектор контролирует, чтобы механика работы пользователя в системе была унифицирована. Действия пользователя, также как и логика расширения, описываются в разрезе функций системы. Причем состав функций системы в обоих разделах должен совпадать.
Концепция. Этот раздел опционален. Для простых доработок его можно пропустить. А вот для комплексных доработок, где много функций системы и связь между ними не совсем очевидная, заполнение раздела критично. Также этот раздел является идеальным местом для записи архитектурных решений (см. главу «про записи архитектурных решений»).
Логика расширения. Когда-то то мне дали универсальный совет по написанию дизайна расширения. Думаю, будет уместно привести его здесь. «Логика в логике, все остальное не в логике». Этот раздел, пожалуй, является сердцем дизайна расширения. Из этого раздела становится понятно, как должна работать система после доработки. В каком порядке разместить элементы управления на форме – пишем в логике. Какие отборы прописать в динамическом списке – здесь же. Как построить выборку для отчета – здесь же. Какие проводки должен сделать документ при проведении – здесь же. Как заполнить печатную форму – здесь же. Какие манипуляции должно выполнять рабочее место – здесь же. И т.д. Даже такие специфические дизайны расширений, как ролевая модель или интерфейс системы, также в основном описываются через этот раздел.
Дизайн метаданных. Все новые объекты метаданных системы, их атрибутивный состав и типы этих атрибутов прописывается именно здесь. Если логика расширения является достаточно «свободным» разделом, т.к. главное донести мысль как должна работать система, то дизайн метаданных заполняется максимально утилитарно, строго в соответствии со структурой описания каждого типа объектов метаданных (класса).
Используемые настройки системы. Последний раздел по порядку, но не по значимости. В этом разделе описывается как д.б. настроены параметры системы и заполнено НСИ, чтобы расширение заработало. Ни раз встречался с ситуацией, когда при заполнении этого раздела, выявлялись ошибки или неточности, допущенные в предыдущих разделах. По тому как работает с этим разделом специалист, пишущий дизайн расширения, можно многое сказать о компетенции этого специалиста – пытается ли он заглянуть в будущее и «примерить» функционал на реальные данные или нет.

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

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

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

Как управлять с помощью дизайна расширения?

Что из себя представляет дизайн расширения разобрались. Теперь давайте поговорим о том, как управлять с помощью этого проектного артефакта.

Обращаю внимание, что в этой статье я рассматриваю дизайн расширения в контексте внедрения систем с высоким уровнем кастомизации. Например, когда от вендора в разрабатываемой системе только БСП или когда в проекте много больших доработок.

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

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

Но вернемся к системам с высоким уровнем кастомизации.

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

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

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

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

Если же пара «аналитик + программист» слабоватая, то про дизайн расширения, как ни странно, тоже можно «забыть». Архитектор все-таки должен заниматься архитектурой, а не этим вашим микроменеджментом. А когда всплывут проблемы, нужно просто включить режим «пожарной команды», поднять дизайн расширения, пройтись по всем разделам (а как мы выяснили выше там нужны все разделы) и построчно проверить исполнение проектного артефакта. В большинстве случаев проблема будет состоять в том, что какой-то кусок дизайна расширения или не выполнен вообще, или выполнен не так как прописано в проектном артефакте.

Внимательный читатель спросит, если в обоих случаях мы «забыли» про дизайн расширения, то тогда куда девать сэкономленный нейроресурс пока идет разработка и юнит-тестирование. В проектном бизнесе с этим никогда не было проблем. Функциональный архитектор может заняться написанием хорошего сценария сквозного функционального тестирования (все же уже запрограммировано «в уме» – понятно, что и как будет делаться в системе). Может заняться разработкой монолитной ролевой модели (все же уже запрограммировано «в уме» – понятно какие объекты будут в системе). Может заняться проработкой дорожной карты загрузки исторических данных (все же уже запрограммировано «в уме» – понятно какие приемники будут в системе). Ну или может написать статью для Хабра. Тоже дело полезное.

Заключение

Резюмируем, написанное выше:

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

P.S. Небольшой бонус для тех, кто стойко доскроллил до конца статьи.

Программирование «в уме»