Про код-ревью (обзор кода, code review) уже слышали очень многие, но вот про архитектурное ревью (архитектурный обзор) практически единицы. В реальной работе применяет его еще меньшее количество людей. И, к нашему глубокому сожалению, его не используют даже большие и широко известные команды. Скажу сразу, его нужно использовать полноценно или в упрощенной форме не только большим командам, но и маленьким. По крайней мере, в этом случае выполнение обзора архитектуры заставит исполнителя задуматься перед решением поставленной задачи. А научиться думать - это очень хороший и полезный навык.
Мы будем рассматривать некоторый свой вариант реализации. Применение такого подхода, если вдруг появится желание, скорее всего будет Вашим собственным.
Структура статьи:
- Вступление
- Какие проблемы решает архитектурное ревью?
- Какую пользу мы получаем?
- Кто проводит, выполняет эту процедуру?
- Как выглядит бизнес процесс ведения задачи с использованием архитектурного обзора?
- Как проводить процесс архитектурного ревью?
- Несколько примеров из практики
Вступление
АРХИТЕКТУРНОЕ РЕВЬЮ могут называть еще architectural review, software desing review, active desing review, ревью/обзор архитектуры приложения и т.д. применительно к разработке ПО. Мы его обычно называем сокращенно - АРХИТЕКТ-РЕВЬЮ, и далее часто будем пользоваться этим термином. Обратите внимание! Архитектурный обзор в рамках этой статьи никак не связан с архитектурой зданий, строений и сооружений. Мы далее будем говорить про процесс разработки программных продуктов, а не про стройку и все что там происходит.
Архитектурный обзор проводится при разработке программного обеспечения. Он позволяет выявить потенциальные проблемы и недостатки, выработать более оптимальные пути разработки, подобрать правильную архитектуру решения, повысить качество решения.
Ошибка, которая может быть обнаружена на этапе нашего обзора архитектуры в исправлении почти бесплатна и является более дорогой если находится на этапе код-ревью (проверки кода). Например, иногда при обзоре кода может быть выявлено, что выполненное решение является полностью не верным и требуется выполнить его удаление и решение снова.
И совсем страшный и неприятный случай - это, когда ошибка выявляется уже в процессе длительной работы пользователей в приложении. Т.е. когда пользователи начали пользоваться новым механизмом начали вносить данные и в этот момент выясняется, что оно не работает так как надо и требуется не только выполнить его снова, но и обработать в последствии наборы внесенных данных. Задача обработка данных обычно является достаточно сложной. В некоторых случаях не решаемой автоматически и требующей дополнительного привлечения пользователей.
Мы будем рассматривать эту процедуру к входящим задачам внутри команды разработки. Не только как внешняя оценка технического задания поступившего на разработку. Т.е. более приземленно и упрощенно. Цель повысить качество разработки, когда в команде много специалистов среднего уровня, джунов.
С помощью архитект-ревью вы еще сможете привить повысить культуру разработки, т.е. сначала проектировать, а потом начинать разработку. Иными словами включать голову. Т.е. мы переходим от принципа «я кодирую» к подходу «я понимаю что я кодирую».
Самый положительный эффект с точки управления - это влияние на сроки разработки, повышение предсказуемости сроков завершения.
Какие проблемы решает АРХИТЕКТ-РЕВЬЮ?
Архитект-ревью отличается от код-ревью определенными моментами. Давайте определим отличия и назначения этого ревью:
- оно проводится до начала разработки и предназначено для устранения возможных проблем при начале разработки, до фактического начала решения задачи (до кодирования).
- позволяет избежать создания дублирующегося функционала. Это поможет уменьшить количество грязного кода, вы будете меньше проводить рефакторинг.
- найти подходящий механизм в конфигурации для реализации задачи.
- определиться с архитектурой нового решения.
- позволяет сосредоточиться на разработке сверху вниз, а не наоборот.
- может проводиться в процессе разработки, для исправления выявленных ошибок.
Итак, код-ревью по факту проверяет результат созданного кода. А архитект-ревью нужно для выбора правильной архитектуры, правильного решения задачи до начала фактической разработки. Рассмотрим на достаточно простом, но довольно часто встречающемся примере.
Например, к нам приходит задача - добавить новый реквизит в документ. И соответственно у вас есть несколько вариантов решения. И не всегда создание реквизита в конфигураторе будет правильным решением, мы же помним что в типовых конфигурациях есть механизмы добавления реквизитов в пользовательском режиме.
И так у вас могут быть следующие варианты:
- добавить новый реквизит в конфигурацию
- добавить новый реквизит в расширение
- использовать механизм дополнительных свойств
- использовать механизм дополнительных реквизитов
- отказать в добавлении нового реквизита (да, если выясняется, что запрашивается какая-то околесица или подобная штука не требуется), реквизит выполняющий подобные функции уже существует.
- отправить на дополнительный анализ
Хороший экономический эффект архитектурное-ревью позволит получить при создании нового механизма, подсистемы.
Нам поставили задачу - создать механизм взаиморасчетов. Этот механизм должен выполнять контроль взаиморасчетов, позволять получать отчетность. Мы определились, что механизм будет позволять вести расчеты в рамках договоров, накладных или распоряжений (заказов). С точки зрения контроля, то добавление составного типа для измерения объекта расчетов не вызывает проблем.
Но вот с точки зрения отчетности, как нам рекомендует разрабатывать 1С идти от требуемых отчетов, будут проблемы. Т.к. пользователю ссылка в отчете не очень хороший вариант, ему хочется увидеть номер, дату, контрагента, договор (если расчеты не по договорам) и т.д.
Т.к. отчеты используют СКД, то пользователь спокойно выберет их через точку. Тут еще у нас добавляются RLS и внезапно у нас появляются проблемы с получением отчетности. А это один из самых часто используемых отчетов в оперативных базах, если не брать товарные остатки.
Поэтому более оптимальным вариантом будет добавить новую сущность, справочник, который будет содержать необходимую информацию.
Какую пользу мы получаем?
Давайте остановимся на ключевых моментах, которые Вы сможете приобрести благодаря включению в свой процесс архитектурного обзора.
В результате его проведения Вы сможете получить оценку объема требуемых работ. Для большого проекта Вы сможете сразу создать набор задач, оценить сложность решения, получить примерное время решения.
Вы снижаете риски получения некачественного или не работающего кода, потери времени, сил, средств, репутации, вероятности появления фейлов при работе решения. Наконец, улучшиться культура разработки.
И как было сказано выше во вступлении - стоимость исправления ошибок до реализации практически бесплатна, за исключением накладных расходов на сам процесс обзора.
Используя архитектурное-ревью мы повышаем управляемость разработкой - получаем более адекватную оценку сроков разработки и повышаем предсказуемость сроков завершения.
Кто проводит, выполняет эту процедуру?
Вариант 1. Выделенная команда архитект-ревью
Во-первых, это командная задача. Тут обязательно должен присутствовать:
- Архитектор или эксперт. Человек, который очень хорошо знает целевую конфигурацию; понимает как взаимодействуют между собой механизмы из различных подсистем; обладает большим опытом в разработке и может предложить примеры реализаций по обсуждаемому вопросу. В основном архитектор отвечает за целостность архитектуры конфигурации и работает с крупными и средними блоками (т.е. он не обязан знать каждую строчку кода и каждое поле регистра регистр). Т.е. он отвечает фактически за то, что если мы добавим какое-либо изменение/доработку, то соседняя подсистема или механизм не сломается.
- Аналитик или тот человек, кто осуществляет коммуникацию с заказчиком. Он переводит с языка бизнеса, заказчика на язык понятный разработчику. Очень хорошо если он также хорошо знает целевую конфигурацию.
- Специалист, который наиболее погружен в обсуждаемую область. Это особенно важно в том случае, когда в процессе принятия решения требуются более глубокие знания о функционировании дорабатываемого механизма. Иногда это может быть предполагаемый исполнитель задачи. Он может как раз являться тем специалистом, который достаточно сильно погружен в проблему и его знания очень актуальны.
- В зависимости от сложности задачи могут привлекаться дополнительные специалисты.
На этом этапе выбираются варианты решения задачи, для каждого варианта оцениваются плюсы и минусы. Выполняется мозговой штурм. Выбор правильного решения не бросается на разработчика.
Почему еще раз команда может быть полезна - для того чтобы выбранное решение было у нас более объективным и не зависело от мнения одного человека. Это в основном требуется для сложных задач. Для решения типовых задач или по кейсам готовым, вполне достаточно минимизировать количество участников.
Вариант 2. Подход через исполнителя и защиту им его решения
Задача выдается ответственному разработчику. Разработчик формулирует плюсы и минусы решения. Определяет механизмы, которые он будет использовать, что и как.
Далее, когда обзор выполнен, то он защищает свое решение перед комиссией из экспертов, архитектора, сеньоров. Состав людей, которые утверждают решение может состоять и из одного сеньора. Ни в коем случае нельзя отдавать процедуру утверждения джуну или мидлу.
На защите задаются вопросы к слабым сторонам решения, предлагаются другие альтернативные варианты решения.
Этот вариант очень здорово подходит для контроля роста и адаптации новых сотрудников, джунов.
Вариант 3. Самостоятельное плавание сеньора
Это кода опытный сотрудник при решении задачи сталкивается с проблемой или сомнениями. Тогда он самостоятельно созывает комиссию, т.е. созывает команду для проведения мозгового штурма, на котором обсуждаются вопросы, которые вводят его в сомнение. Данный подход имеет смысл применять для сеньоров, для тех людей которые могут и думают самостоятельно перед выполнением задачи.
Как выглядит бизнес процесс ведения задачи с использованием архитектурного обзора?
Рассмотрим как выглядит процесс ведения задачи с использованием архитект-ревью. Ранее мы уже рассматривали вопрос добавления в жизненный путь задачи процедуры код-ревью (Как завести у себя в команде код-ревью. Отвечаем на вопросы, По следам код-ревью).
Начнем со схемы статусов в жизни задачи. И конечно же наш новый статус должен располагаться где-то в начале жизненного пути задачи. Эта ситуация показана на схеме ниже. Обратите внимание, что данная схема может изменяться в зависимости от конкретной команды, но идея реализации должна быть похожа.
Тут у нас все достаточно прозрачно. Сначала мы формулируем задачу, потом выполняем обсуждение ее реализации. Если есть какие-то замечания и уточнения, тогда возвращаем задачу аналитику, тому кто отвечает за взаимодействие с заказчиком. При положительном решении передаем ее далее в разработку. Основной посыл заключается в том, что мы должны обдумать решение где-то до статуса задачи - "в работе".
Далее остановимся подробнее на людях и их функциональных ролях, которые у нас могут быть задействованы в процессе. Участники и их роли:
- Заказчик - тот, кто поставляет проблему. Заказчик может быть не только внешним, но и внутренним из разработки. Например, мы решили уменьшить технический долг и провести рефаторинг.
- Аналитик - переводит проблему в задачу. Общается с заказчиком, переводит картинку из его головы на язык понятный команде программистов. Формирует требования, условия, оформляет техническое задание на разработку.
- Команда АРХИТЕКТ-РЕВЬЮ или Архитектор - оценивает адекватность задачи (аналитик может не понимать проблем разработки и реализуемости требований) и выбирает и утверждает подход, решение, архитектуру.
- Разработчик - разработчик, кто выполняет задачу. Непосредственно, тот кто работает в поле называемом конфигурации 1С, кодирует, создает и творит, реализует задачу.
- ТКР разработчик - тот, кто проверяет код. Обычно это сеньоры, иногда мидлы и никогда джуны!
- Тестировщик - сотрудник (или команда), проверяет на ошибки. Ищет баги, проблемы и косяки в реализации задачи.
На рисунке ниже приведен условный процесс разработки с включением нашего нового статуса. Данная схема использует понятия, которые используются в jira. Разберем чуть подробнее:
- Сначала заказчик формирует проблему. Описывает ее как может. Обычно результатом его усилий является письмо или новый инцидент в системе баг трекинга.
- Далее мы перемещаемся на вторую дорожку ниже и в игру вступает аналитик. Который вчитывается в пожелания и проблему, пропускает ее через себя и созванивается, встречается с заказчиком. Результатом его усилий является создание новой истории и прикрепления ее к инциденту.
- Теперь эстафету перенимает наш архитектор. Ну, наконец-то, мы увидели, где можно применить такого специалиста. Мы проводим обсуждение того что затребовали сделать, читаем, думаем и выдаем резюме. В положительном случае тут могут рождаться задача или набор задач на разработку, которые подчинены пользовательским историям. На самом деле мы можем проводить обзор и в рамках одной задачи (см. схему выше). Например, мы можем создавать задачу, в которой описываем процесс разработки широкими мазками, а разработчик, далее перед непосредственным выполнением задачи будет защищать выбранную реализацию.
- И теперь приходит время непосредственной реализации задачи. Добавлению программного кода, метаданных и т.п., самопроверки разработчиком своего решения, выполнения процедуры тестирования и проверки решения заданным требованиям. Данную часть мы не стали разбивать на отдельные дорожки, исполнителей - тут достаточно обширная и отдельная процедура достойная отдельной статьи.
Как проводить процесс архитектурного ревью?
Подготовка. До проведения этой процедуры нам требуется провести ряд подготовительных работ, который зависит от объема и сложности задачи. Чем более глобальная задача стоит, тем нужно более серьезно подготовиться:
- Подготовить описание задачи - все что есть.
- Нарисовать процесс решаемой проблемы, например, бизнес процесс.
- Оценить требования к поставленной задаче - мы будем выяснять все ли понятно, адекватные ли требования и есть ли противоречия.
Процесс проведения архитектурного обзора:
1. Начало встречи. Во-первых, зачитывается задача, которую требуется решить. Уясняется что все понимают о чем идет речь.
2. Обсуждение. Во-вторых, задаются уточняющие вопросы. Это требуется для выявления противоречий, неясности, чтобы избежать проблем в дальнейшем.
Заказчик попросил выводить в отчете по реализациям разбивку в разрезе партий.
В реализациях не используются серии. Склады у нас ордерные и в настройках используется вариант указания серий по факту (т.е. указываются только в ордерах).
Соответственно у нас могут быть следующие варианты решения:
- Переключение политики учета серий на вариант по себестоимости. Это выглядит совсем не реалистично.
- Внести изменения в конфигурацию, чтобы пользователи могли указывать серии. Такое решение выглядит также не очень правдоподобно.
- В отчете раскидывать серии на реализации по ФИФО. Архитектурно более простой вариант, но он обладает одним недостатком - связь между реализациями и сериями будет достаточно условная, особенно если у нас происходит отгрузка по нескольким заказам в одном ордере.
В процессе обсуждения можно рисовать схему взаимодействия в UML, visio или тот же paint. Нужен инструмент где можно достаточно быстро нарисовать связи, потоки данных, движения данных.
Иногда когда не совсем понятно на словах, я могу использовать paint чтобы быстро нарисовать идею. Например, обсуждение добавления обмена между различными базами.
Инструменты:
Можно использовать BPMN схемы в рамках которых очень здорово показаны взаимодействия между пользователями по ролям, процессы внутри, потоки данных. Рисовать UML диаграммы MindJet. Да, взять хоть тот же самый paint на котором нужно нарисовать поясняющую картинку. Все то что вам будет удобно использовать.
Обратите внимание! Сейчас довольно часто проводятся обсуждения в онлайн формате - в тимз, скайп, пачке, зум и т.п. И у этих всех сервисов есть возможность записи видео. Если вы выполните запись, то потом достаточно удобно будет законспектировать основные мысли.
3. Вырабатываются варианты решения. Если решение есть, то предлагаются альтернативные варианты. Очень желательно подобрать подходящий паттерн или использовать существующие кейсы (варианты решения), правила разработки и примеры готовые на основе существующих механизмов конфигураций или подходов. Вот тут как раз и требуются знания эксперта или архитектора.
4. Проводится оценка предложенных решений. Выявляются проблемы и недостатки - для каждого варианта проводится оценка выставляются плюсы и минусы по набору критериев. Вопросы доступа, сложные не рациональные связи, избыточность и излишняя сложность. В результате мы получаем некую грубую оценку для всех вариантов и выбираем наиболее подходящее решения. Не стоит в этом случае играть в покер, как это принято в чистом SCRUM подходе, всегда решение должно приниматься взвешенно.
Определяется набор свойств, по которым будет осуществляться оценка эффективности решения:
• требуется доработка конфигурации,
• можно использовать расширение
• требуется добавление новых свойств существующих объектов - реквизиты, формы, состав типа
• требуется добавление справочников, регистров сведений, перечислений
• требуется добавление новых документов, новых регистров накопления (подчиненных регистратору), формирование новых движений
• требуется добавление новых ролей и ограничений
• разрабатывается новая подсистема
• разрабатывается новый механизм
• вносятся исправления в существующий механизм
• какие будут проблемы с обновлением типового решения, требуется реализация с механизмом минимального изменения конфигурации
• на сколько это костыльное решение
• можем ли мы отказать в решении задачи
• требуется ли уточнение, нужны ли дополнительные вопросы
• оценка времени решения
• количество разработчиков и других специалистов
• приведет ли данное решение к проблемам снижения производительности
• можно ли механизм заполнения, расчета, рассылки и т.п. вынести в фоновую обработку
• можно ли реализовать отдельной обработкой
5. Возврат на уточнение и согласование. В случае, когда появляются вопросы, которые требуется уточнить, то задача возвращается на дополнительную постановку и по результатам проводится повторное архитектурное-ревью.
Также бывают ситуации, когда принимается вариант решения и его требуется согласовать с заказчиком, то оно также возвращается на уточнение.
6. Принятие решения. В простом случае у задачи меняется статус и она идет в разработку. Если же это история, то на основе этой задачи создается набор, который уходит в пул задач на спринт и далее в реализацию разработчиком.
Несколько примеров из практики
В заключительной части нашей статьи мы приведем некоторые обобщенные примеры, которые мы составили по результатам общения с коллегами и собственного опыта. Особенно сильно вдаваться в детали мы не будем. Цель, которая тут преследуется - это показать приземленное положительное влияние на процесс разработки.
Задача: Требуется в документ способы отражения зарплаты добавит подразделение.
Цель: Упростить работу пользователя.
Условия: Конфигурация ЗУП.
Статус: Новая задача
Варианты решения:
- Снять конфигурацию с поддержки и добавить недостающий реквизит. К недостаткам такого решения можно отнести саму идею снятия с поддержки и дальнейшее обновление.
- Использовать механизм дополнительных реквизитов. Проблема - отсутствует тип или документ не включен в механизм дополнительных реквизитов.
- Использовать расширение. У этого механизма есть недостаток - требуется переносить достаточно много объектов в расширение, чтобы писать запросы.
Резюме:
В результате самым оптимальным вариантом можно считать - последний вариант с расширением. Хотя для кого-то будет нормальным и первый вариант - снять с поддержки и пуститься во все тяжкие.
Задача: Требуется реализовать некий план-фактный контроль исполнения плана закупок заказами на закупку.
Цель: Повысить управляемость закупками
Условия: Конфигурация ERP.
Создан свой документ плана закупок с новыми аналитиками. В документе заказ поставщику добавлена аналитика в табличную часть по новому плану.
В отчете требуется выводить данные между документом плана и заказом поставщику. Заказ поставщику считается фактом исполнения плана.
Статус: Задача находится в процессе реализации.
Результат обследования:
Исполнитель решения создал отдельный регистр расчетов плана, который состоял из нескольких измерений - "Объект расчетов", "План", "Валюта" и ресурсов - "Сумма расчетов". А также была выполнена обвязка.
Ошибка заключается в том, что в типовом механизме взаиморасчетов существуют три варианта: по заказам, по договорам и по накладным. И соответственно, когда у заказчика в условиях расчетов появилось значение по накладным, то система ушла в ошибку. Т.к. в этом случае справочник "объект расчетов" не создается (что логично, он будет создаваться в приобретении). Как мы видим, подобной проблемы удалось бы избежать, если провели обсуждение до начала реализации задачи.
Варианты решения:
- Учесть движения в документе приобретения товаров. В этом случае с движениями будет все ок, но вот логически возникают некоторые проблемы.
- Запретить использование варианта расчетов по накладным. Этот вариант зависит от процессов заказчика и если у него уже используются по накладным, то выглядит не очень жизненно.
- Заменить тип измерения "Объект Расчетов" - определяемый (фактически составной другими словами). В этом случае проблема исчезнет, но могут быть проблемы связанные с соответствиями между объектами расчетов и составным типом, если конечно это где-то потребуется.
Резюме:
Наиболее логичным выгляди последний вариант с заменой типа. По крайней мере он получается менее затратным с точки зрения реализации исправления.
Задача: Необходимо реализовать обмен между двумя базами ЕРП и БУХ выгрузки контрагентов
Цель: Избавиться от двойного ввода данных. Точка ввода база ERP как MDM система.
Статус: Новая задача.
Проблема: Данные в справочниках между базами не синхронизированы, не все поля заполнены.
Варианты решений:
- Установить соответствие по ИНН и КПП и грузить как есть. Пользователи как-нибудь разберутся.
- Установка многоступенчатого соответствия. Иными словами мы устанавливаем правило поиска соответствия по набору условий с различными приоритетами.
- Выполнить сведение данных перед настройкой обмена. В этом случае мы сначала выполняем сравнение данных между базами по некоторым наборам правил и исправляем вместе с пользователями. А далее устанавливаем простое правило поиска.
Резюме:
С точки зрения программиста - дали задачу и он начал писать правила обмена. Что там получится увидим по ходу реализации, т.е. принцип - будем решать проблемы по мере их поступления.
Самый оптимальный вариант, который хорошо снижает риски - последний вариант. Использование второго варианта позволит снизить ошибки обмена, но не избавит от бардака, хотя потребует меньшую вовлеченность в процесс сотрудников бухгалтерии.
P.S. Смогли посчитать, сколько раз в статье мы употребили фразу, обозначающую архитектурный обзор?
