Архитектурное ревью. Процесс разработки

30.10.23

Архитектура - Архитектура решений

Рассмотрим применение архитектурной проверки задач в процессе разработки.

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

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

Структура статьи:

  • Вступление
  • Какие проблемы решает архитектурное ревью?
  • Какую пользу мы получаем?
  • Кто проводит, выполняет эту процедуру?
  • Как выглядит бизнес процесс ведения задачи с использованием архитектурного обзора?
  • Как проводить процесс архитектурного ревью?
  • Несколько примеров из практики

 

Вступление

 

АРХИТЕКТУРНОЕ РЕВЬЮ могут называть еще architectural review, software desing review, active desing review, ревью/обзор архитектуры приложения и т.д. применительно к разработке ПО. Мы его обычно называем сокращенно - АРХИТЕКТ-РЕВЬЮ, и далее часто будем пользоваться этим термином. Обратите внимание! Архитектурный обзор в рамках этой статьи никак не связан с архитектурой зданий, строений и сооружений. Мы далее будем говорить про процесс разработки программных продуктов, а не про стройку и все что там происходит. 

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

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

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

Мы будем рассматривать эту процедуру к входящим задачам внутри команды разработки. Не только как внешняя оценка технического задания поступившего на разработку. Т.е. более приземленно и упрощенно. Цель повысить качество разработки, когда в команде много специалистов среднего уровня, джунов.

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

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

 

Какие проблемы решает АРХИТЕКТ-РЕВЬЮ?


Архитект-ревью отличается от код-ревью определенными моментами. Давайте определим отличия и назначения этого ревью:

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

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

 
 Пример простой задачи для разработки

 

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

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

 

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

 
 Более сложный пример задачи

Нам поставили задачу - создать механизм взаиморасчетов. Этот механизм должен выполнять контроль взаиморасчетов, позволять получать отчетность. Мы определились, что механизм будет позволять вести расчеты в рамках договоров, накладных или распоряжений (заказов). С точки зрения контроля, то добавление составного типа для измерения объекта расчетов не вызывает проблем.

Но вот с точки зрения отчетности, как нам рекомендует разрабатывать 1С идти от требуемых отчетов, будут проблемы. Т.к. пользователю ссылка в отчете не очень хороший вариант, ему хочется увидеть номер, дату, контрагента, договор (если расчеты не по договорам) и т.д.

Т.к. отчеты используют СКД, то пользователь спокойно выберет их через точку. Тут еще у нас добавляются RLS и внезапно у нас появляются проблемы с получением отчетности. А это один из самых часто используемых отчетов в оперативных базах, если не брать товарные остатки.

Поэтому более оптимальным вариантом будет добавить новую сущность, справочник, который будет содержать необходимую информацию.


Какую пользу мы получаем?

 

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

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

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

И как было сказано выше во вступлении - стоимость исправления ошибок до реализации практически бесплатна, за исключением накладных расходов на сам процесс обзора.

Используя архитектурное-ревью мы повышаем управляемость разработкой - получаем более адекватную оценку сроков разработки и повышаем предсказуемость сроков завершения.

 

Кто проводит, выполняет эту процедуру? 


Вариант 1. Выделенная команда архитект-ревью

 

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

  • Архитектор или эксперт. Человек, который очень хорошо знает целевую конфигурацию; понимает как взаимодействуют между собой механизмы из различных подсистем; обладает большим опытом в разработке и может предложить примеры реализаций по обсуждаемому вопросу. В основном архитектор отвечает за целостность архитектуры конфигурации и работает с крупными и средними блоками (т.е. он не обязан знать каждую строчку кода и каждое поле регистра регистр). Т.е. он отвечает фактически за то, что если мы добавим какое-либо изменение/доработку, то соседняя подсистема или механизм не сломается.
  • Аналитик или тот человек, кто осуществляет коммуникацию с заказчиком. Он переводит с языка бизнеса, заказчика на язык понятный разработчику. Очень хорошо если он также хорошо знает целевую конфигурацию.
  • Специалист, который наиболее погружен в обсуждаемую область. Это особенно важно в том случае, когда в процессе принятия решения требуются более глубокие знания о функционировании дорабатываемого механизма. Иногда это может быть предполагаемый исполнитель задачи. Он может как раз являться тем специалистом, который достаточно сильно погружен в проблему и его знания очень актуальны.
  • В зависимости от сложности задачи могут привлекаться дополнительные специалисты.

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

Почему еще раз команда может быть полезна - для того чтобы выбранное решение было у нас более объективным и не зависело от мнения одного человека. Это в основном требуется для сложных задач. Для решения типовых задач или по кейсам готовым, вполне достаточно минимизировать количество участников.

 

Вариант 2. Подход через исполнителя и защиту им его решения

 

Задача выдается ответственному разработчику. Разработчик формулирует плюсы и минусы решения. Определяет механизмы, которые он будет использовать, что и как.

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

На защите задаются вопросы к слабым сторонам решения, предлагаются другие альтернативные варианты решения.

Этот вариант очень здорово подходит для контроля роста и адаптации новых сотрудников, джунов. 


Вариант 3. Самостоятельное плавание сеньора


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

 

Как выглядит бизнес процесс ведения задачи с использованием архитектурного обзора?


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

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

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

 

 
 Пример схемы жизненного цикла задачи

 

 

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

  • Заказчик - тот, кто поставляет проблему. Заказчик может быть не только внешним, но и внутренним из разработки. Например, мы решили уменьшить технический долг и провести рефаторинг.
  • Аналитик - переводит проблему в задачу. Общается с заказчиком, переводит картинку из его головы на язык понятный команде программистов. Формирует требования, условия, оформляет техническое задание на разработку.
  • Команда АРХИТЕКТ-РЕВЬЮ или Архитектор - оценивает адекватность задачи (аналитик может не понимать проблем разработки и реализуемости требований) и выбирает и утверждает подход, решение, архитектуру.
  • Разработчик - разработчик, кто выполняет задачу. Непосредственно, тот кто работает в поле называемом конфигурации 1С, кодирует, создает и творит, реализует задачу.
  • ТКР разработчик - тот, кто проверяет код. Обычно это сеньоры, иногда мидлы и никогда джуны!
  • Тестировщик - сотрудник (или команда), проверяет на ошибки. Ищет баги, проблемы и косяки в реализации задачи. 

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

  • Сначала заказчик формирует проблему. Описывает ее как может. Обычно результатом его усилий является письмо или новый инцидент в системе баг трекинга.
  • Далее мы перемещаемся на вторую дорожку ниже и в игру вступает аналитик. Который вчитывается в пожелания и проблему, пропускает ее через себя и созванивается, встречается с заказчиком. Результатом его усилий является создание новой истории и прикрепления ее к инциденту.
  • Теперь эстафету перенимает наш архитектор. Ну, наконец-то, мы увидели, где можно применить такого специалиста. Мы проводим обсуждение того что затребовали сделать, читаем, думаем и выдаем резюме. В положительном случае тут могут рождаться задача или набор задач на разработку, которые подчинены пользовательским историям. На самом деле мы можем проводить обзор и в рамках одной задачи (см. схему выше). Например, мы можем создавать задачу, в которой описываем процесс разработки широкими мазками, а разработчик, далее перед непосредственным выполнением задачи будет защищать выбранную реализацию.
  • И теперь приходит время непосредственной реализации задачи. Добавлению программного кода, метаданных и т.п., самопроверки разработчиком своего решения, выполнения процедуры тестирования и проверки решения заданным требованиям. Данную часть мы не стали разбивать на отдельные дорожки, исполнителей - тут достаточно обширная и отдельная процедура достойная отдельной статьи.
 
 Эскиз схемы бизнес процесса жизни задачи bpmn

 

 

Как проводить процесс архитектурного ревью?


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

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

Процесс проведения архитектурного обзора:

1. Начало встречи. Во-первых, зачитывается задача, которую требуется решить. Уясняется что все понимают о чем идет речь.

2. Обсуждение. Во-вторых, задаются уточняющие вопросы. Это требуется для выявления противоречий, неясности, чтобы избежать проблем в дальнейшем.

 
 Пример противоречивого запроса от заказчика

Заказчик попросил выводить в отчете по реализациям разбивку в разрезе партий. 

В реализациях не используются серии. Склады у нас ордерные и в настройках используется вариант указания серий по факту (т.е. указываются только в ордерах).

Соответственно у нас могут быть следующие варианты решения:

  • Переключение политики учета серий на вариант по себестоимости. Это выглядит совсем не реалистично.
  • Внести изменения в конфигурацию, чтобы пользователи могли указывать серии. Такое решение выглядит также не очень правдоподобно.
  • В отчете раскидывать серии на реализации по ФИФО. Архитектурно более простой вариант, но он обладает одним недостатком - связь между реализациями и сериями будет достаточно условная, особенно если у нас происходит отгрузка по нескольким заказам в одном ордере.

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

 
 Пример обсуждения

Иногда когда не совсем понятно на словах, я могу использовать paint чтобы быстро нарисовать идею. Например, обсуждение добавления обмена между различными базами.

 

Инструменты:

Можно использовать BPMN схемы в рамках которых очень здорово показаны взаимодействия между пользователями по ролям, процессы внутри, потоки данных. Рисовать UML диаграммы MindJet. Да, взять хоть тот же самый paint на котором нужно нарисовать поясняющую картинку. Все то что вам будет удобно использовать.

Обратите внимание! Сейчас довольно часто проводятся обсуждения в онлайн формате  - в тимз, скайп, пачке, зум и т.п. И у этих всех сервисов есть возможность записи видео. Если вы выполните запись, то потом достаточно удобно будет законспектировать основные мысли.

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

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

 
 Примерный чек лист для оценки вариантов предложенных решений

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

 

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

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

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

 

Несколько примеров из практики

 

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

 
 Пример 1. Добавление реквизита в документы

Задача: Требуется в документ способы отражения зарплаты добавит подразделение.

Цель: Упростить работу пользователя.

Условия: Конфигурация ЗУП. 

Статус: Новая задача

Варианты решения:

  • Снять конфигурацию с поддержки и добавить недостающий реквизит. К недостаткам такого решения можно отнести саму идею снятия с поддержки и дальнейшее обновление.
  • Использовать механизм дополнительных реквизитов. Проблема - отсутствует тип или документ не включен в механизм дополнительных реквизитов.
  • Использовать расширение. У этого механизма есть недостаток - требуется переносить достаточно много объектов в расширение, чтобы писать запросы. 

Резюме:

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

 

 
 Пример 2. Случай по результатам аудита задач

Задача: Требуется реализовать некий план-фактный контроль исполнения плана закупок заказами на закупку.

Цель: Повысить управляемость закупками

Условия: Конфигурация ERP.

Создан свой документ плана закупок с новыми аналитиками. В документе заказ поставщику добавлена аналитика в табличную часть по новому плану. 

В отчете требуется выводить данные между документом плана и заказом поставщику. Заказ поставщику считается фактом исполнения плана.

Статус: Задача находится в процессе реализации.

Результат обследования:

Исполнитель решения создал отдельный регистр расчетов плана, который состоял из нескольких измерений - "Объект расчетов", "План", "Валюта" и ресурсов - "Сумма расчетов". А также была выполнена обвязка.

Ошибка заключается в том, что в типовом механизме взаиморасчетов существуют три варианта: по заказам, по договорам и по накладным. И соответственно, когда у заказчика в условиях расчетов появилось значение по накладным, то система ушла в ошибку. Т.к. в этом случае справочник "объект расчетов" не создается (что логично, он будет создаваться в приобретении). Как мы видим, подобной проблемы удалось бы избежать, если провели обсуждение до начала реализации задачи.

Варианты решения:

  • Учесть движения в документе приобретения товаров. В этом случае с движениями будет все ок, но вот логически возникают некоторые проблемы.
  • Запретить использование варианта расчетов по накладным. Этот вариант зависит от процессов заказчика и если у него уже используются по накладным, то выглядит не очень жизненно.
  • Заменить тип измерения "Объект Расчетов" - определяемый (фактически составной другими словами). В этом случае проблема исчезнет, но могут быть проблемы связанные с соответствиями между объектами расчетов и составным типом, если конечно это где-то потребуется.

Резюме:

Наиболее логичным выгляди последний вариант с заменой типа. По крайней мере он получается менее затратным с точки зрения реализации исправления. 

 

 
 Пример 3. Планирование обмена между базами

Задача: Необходимо реализовать обмен между двумя базами ЕРП и БУХ выгрузки контрагентов

Цель: Избавиться от двойного ввода данных. Точка ввода база ERP как MDM система.

Статус: Новая задача.

Проблема: Данные в справочниках между базами не синхронизированы, не все поля заполнены.

Варианты решений:

  • Установить соответствие по ИНН и КПП и грузить как есть. Пользователи как-нибудь разберутся.
  • Установка многоступенчатого соответствия. Иными словами мы устанавливаем правило поиска соответствия по набору условий с различными приоритетами.
  • Выполнить сведение данных перед настройкой обмена. В этом случае мы сначала выполняем сравнение данных между базами по некоторым наборам правил и исправляем вместе с пользователями. А далее устанавливаем простое правило поиска.

Резюме:

С точки зрения программиста - дали задачу и он начал писать правила обмена. Что там получится увидим по ходу реализации, т.е. принцип - будем решать проблемы по мере их поступления.

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

 

P.S. Смогли посчитать, сколько раз в статье мы употребили фразу, обозначающую архитектурный обзор?

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

вчера в 12:00    1197    0    comol    18    

19

Архитектура решений Бесплатно (free)

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

20.09.2024    827    0    amon_ra    7    

5

Архитектура решений Бухгалтер Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бухгалтерский учет Бесплатно (free)

При внедрении системы 1С:ERP нередко возникают ситуации, когда поведение программы кажется нелогичным и необъяснимым. Эти моменты могут вызывать замешательство и даже панику, подобно мифическим существам или загадочным явлениям.

12.08.2024    2905    0    user2096116    36    

8

Архитектура решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Можно ли, окружив СППР доработками, повысить её эффективность? Есть ли такие доработки в готовом виде на рынке? Дисклеймер: данная статья не повторяет мой доклад а лишь излагает мысли и акценты, которые докладчику показались прошедшими мимо слушателей. Если хотите посмотреть доклад, то можно купить доступ или дождаться публикации от Инфостарта.

19.06.2024    1412    0    roman72    0    

2

Архитектура решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье мы рассмотрим панель системы 1С: Аналитика - План фактный анализ реализации работ заказчикам и вывод о конфигурации 1С: ERP Управление строительной организацией.

24.04.2024    879    0    Koder_Line    1    

1

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Строительство Бесплатно (free)

В данной статье будет рассказано о том, что такое конфигурация 1С:Управление нашей строительной фирмой и какие она имеет функциональные особенности. А также отдельно будет расписан подробно процесс по планированию строительных работ, где будет отображён необходимый порядок оформления всей документации и отчётностей.

22.03.2024    827    0    Koder_Line    0    

2

Архитектура решений Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

22.02.2024    7050    0    Koder_Line    1    

4

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Бухгалтерский учет Управленческий учет Бесплатно (free)

Здравствуйте! В данной статье мы рассмотрим описание системы ТОиР и область ее применения, функциональные возможности и структуру 1С:ТОиР Управление ремонтами и обслуживанием оборудования. В современных условиях динамичных рыночных процессов и стремительного развития технологий, эффективное управление техническим обслуживанием, ремонтом и оборудованием становится ключевым фактором для обеспечения бесперебойной работы предприятий различных сфер деятельности. В этом контексте, система «Техническое Обслуживание, Ремонт и Оборудование» (ТОиР) на базе платформы 1С: Предприятие выступает как неотъемлемый инструмент для эффективного управления всем жизненным циклом технических средств.

24.11.2023    3421    0    Koder_Line    0    

0
Отзывы
6. ivanov660 4567 01.11.23 13:36 Сейчас в теме
(4) Читайте чуть внимательнее пункт "Процесс проведения архитектурного обзора". Не путайте с код-ревью, тут процесс идет до начала программирования. Образно говоря - мы встречаемся и обсуждаем как будет сделана задача - упрощенное понятие термина архитектурного ревью

Как выглядит процесс вживую (пример):
1. В календаре ставится встреча
2. В момент встречи собираемся в канале мессенджера участники.
3. Сначала идет рассказ про стоящую задачу или проблему, показывается все что есть - это может быть сообщение об ошибке, схема бизнес-процесса, техническое задание и т.п.
4. Если необходимо, то расшаривается экран и кто-то рисует к примеру в MindManager или что-нибудь из инструментов выступления Андрея. Зависит от задачи и ситуации.
5. Выдвигаются варианты решения с точки зрения архитектуры, подхода, методологии. Удачно, если есть готовые шаблоны, тогда они и предлагаются.
6. Оцениваются варианты решения. Опрашиваются участники.
7. Подводится заключение и оформляется результат. В формате:
[АРХ-РЕВЬЮ]
Было принято, что требуется добавить новый регистр накопления, регистратором будут такие-то документы и т.д.
kuzyara; A_Max; +2 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3081 30.10.23 12:29 Сейчас в теме
Не читал, но осуждаю )))
cheshirshik; user1285052; +2 Ответить
2. Serg O. 294 31.10.23 15:59 Сейчас в теме
3. ivanov660 4567 31.10.23 19:42 Сейчас в теме
(2)
1. Там Андрей рассказывает больше про взаимодействие с заказчиком и про используемые инструменты.
2. Тут я затрагиваю вопросы касаемо процесса разработки внутри команды.
4. BomjBandit 6 01.11.23 00:52 Сейчас в теме
Не читал, но осуждаю ©
Слова ради слов. А как вы делаете ревью в среде 1с? У вас стоит едт + гит, ревью проводите при пул реквесте? Сравниваете разраб. хран и релизный? Какие инструменты используете?
По-моему, самое главное в статье не описано.
cheshirshik; +1 Ответить
5. zqzq 25 01.11.23 10:49 Сейчас в теме
(4) Инструменты, это для ревью кода. А на этапе архитект-ревью кода ещё нет, как я понял. Поэтому неважно, хоть на бумажке.
ivanov660; +1 Ответить
6. ivanov660 4567 01.11.23 13:36 Сейчас в теме
(4) Читайте чуть внимательнее пункт "Процесс проведения архитектурного обзора". Не путайте с код-ревью, тут процесс идет до начала программирования. Образно говоря - мы встречаемся и обсуждаем как будет сделана задача - упрощенное понятие термина архитектурного ревью

Как выглядит процесс вживую (пример):
1. В календаре ставится встреча
2. В момент встречи собираемся в канале мессенджера участники.
3. Сначала идет рассказ про стоящую задачу или проблему, показывается все что есть - это может быть сообщение об ошибке, схема бизнес-процесса, техническое задание и т.п.
4. Если необходимо, то расшаривается экран и кто-то рисует к примеру в MindManager или что-нибудь из инструментов выступления Андрея. Зависит от задачи и ситуации.
5. Выдвигаются варианты решения с точки зрения архитектуры, подхода, методологии. Удачно, если есть готовые шаблоны, тогда они и предлагаются.
6. Оцениваются варианты решения. Опрашиваются участники.
7. Подводится заключение и оформляется результат. В формате:
[АРХ-РЕВЬЮ]
Было принято, что требуется добавить новый регистр накопления, регистратором будут такие-то документы и т.д.
kuzyara; A_Max; +2 Ответить
7. ig1082 281 01.11.23 21:21 Сейчас в теме
(6) Являюсь архитектором последние несколько лет.
У нас вариант 1, описанный вами - кроме меня есть еще 1 архитектор (с упором на бизнесовую часть),
всегда есть аналитик, часто разработчик. Аналитик + разработчик готовят прототип постановки.
По небольшим задачам ревью условное,
по объемным - иногда весьма бурные обсуждения.
Главное: не уходить в формализм и уметь слышать доводы других.
По редкости такого процесса: 5-10% у тех кого я собеседовал, оно было.
В общем, процесс нужный.
P.S. Надеюсь, пообщаемся на след. ивенте Инфостарта.
В этот раз очно был в Питере, но не успел на ваш доклад )
ivanov660; +1 Ответить
8. kuzyara 2077 22.12.23 11:29 Сейчас в теме
(7) Встречался с ситуациями когда архитекторы архитектурили, жарко спорили, выдавали текст, в лучшем случае с картинкой, и успешно расходились довольные своими усилиями. А когда начинаешь вникать в выдуманные ими решения - понимаешь что их идеальная картина мира совсем оторвана от реальности.

Поэтому считаю, что результатом должно быть не "экспертное" заключение, не красиво оформленный [АРХ-РЕВЬЮ], а прототип(скелет-код, демо) в виде ПРОВЕРЕННОГО РАБОТАЮЩЕГО решения.

"мы встречаемся и обсуждаем как будет сделана задача" - имитация бурной деятельности
"было принято, что требуется" - перекладывание ответственности

https://www.youtube.com/watch?v=EhtsPAdYOds
9. ivanov660 4567 09.02.24 11:57 Сейчас в теме
(8) Если задача сложная и не удается гарантировать адекватного решения, либо вообще не понятно правильно ли будет работать, то выполняется моделирование и/или создается прототип. И уже на основании этих шагов можно принимать решение о следовании предложенного варианта или искать другие пути реализации - проводится еще одно повторное архитектурное ревью. Т.е. количество таких встреч зависит от сложности задачи.
10. ivanov660 4567 09.02.24 12:02 Сейчас в теме
(8)
"мы встречаемся и обсуждаем как будет сделана задача" - имитация бурной деятельности
"было принято, что требуется" - перекладывание ответственности

Все зависит от команды и ее участников, в некоторых бывает и такое. Возможно вам не повезло. Мне встречались реально работающие структуры, которые нацелены на результат.
Оставьте свое сообщение