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

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. Смогли посчитать, сколько раз в статье мы употребили фразу, обозначающую архитектурный обзор?

См. также

Основные блоки и возможности 1C: ERP Управление предприятием 2

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

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

22.02.2024    633    0    Koder_Line    1    

3

Система ТОиР. Функциональные возможности 1С:ТОиР Управление ремонтами и обслуживанием оборудования

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

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

24.11.2023    1151    0    Koder_Line    0    

0

В релизе 1С:ТОИР КОРП 3.0.7.1 — более гибкие инструменты для обходов оборудования и управления персоналом, новое рабочее место для приемки оборудования из ремонта

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

В августе 2023 года увидел свет новый релиз 3.0.7.1 системы 1С:ТОИР КОРП. Третья, наиболее прогрессивная редакция решения для управления ремонтами и обслуживанием оборудования на платформе «1С:Предприятие», активно развивается, обогащаясь новым функционалом и раскрывая всё более широкие возможности для пользователей, которые стремятся повысить эффективность управления активами. Что изменилось в системе с выходом нового релиза?

01.09.2023    1200    0    Desnol_Soft    0    

2

Технологии информационного моделирования теперь доступны в 1С:ТОИР КОРП

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

В августе 2023 года команда разработчиков «Деснол Софт» завершила разработку модуля интеграции 1С:ТОИР КОРП, ред. 3.0 с системой Renga цифрового комплекса 1С:BIM 6D. 1С:BIM 6D — это российский интегрированный программный комплекс для цифровизации предприятий строительной отрасли в соответствии с технологией информационного моделирования (ТИМ / BIM — Building Information Modeling). Он включает в себя BIM-систему Renga, а также ряд отраслевых решений «1С», позволяющих работать с информационной моделью на всех этапах жизненного цикла строительных объектов.

16.08.2023    468    0    Desnol_Soft    0    

2

Сравнение конфигураций 1С:Управление нашей фирмой и 1С:Управление торговлей

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

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

14.08.2023    2064    0    Koder_Line    8    

2

Цифровое лето в разгаре: вышел новый релиз 1С:ТОИР КОРП 3.0.6.1

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

Речь пойдет о новом релизе 1С:ТОИР КОРП редакции 3.0, в котором мы продолжаем развитие системы. Наша команда разработчиков сосредоточилась в этом релизе на трех направлениях — инструментах управления, информативности отчетов и юзабилити системы. Всего в релиз вошло более 30 изменений, что делает его одним из самых крупных. А теперь — обо всем подробнее.

04.07.2023    733    0    Desnol_Soft    0    

1

Голосовой ввод, несколько подписантов документов, превью файлов популярных форматов и другие "вкусные" фишки 1С:Документооборот 3.0

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

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

19.06.2023    1205    0    Koder_Line    1    

4

Кастомизация "на лету"

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

В статье пойдет речь о 14 решениях, построенных на одной архитектуре (таких решений больше, но я выбрал самые интересные). Я сделаю краткий обзор, но постараюсь, конечно, рассказать о каждом инструменте, чтобы было понятно. Все решения, о которых я буду говорить, родились на практике и применены в ходе моей работы IT-директором бурно развивающейся нефтесервисной компании. Некоторые из них были выложены на Инфостарте в открытый доступ и уже немного разошлись по стране, поэтому не исключаю, что кто-то из здесь присутствующих их даже использовал. А для партнеров 1С я зачастую раздаю NFR-версии – я не коммерсант и люблю нести в мир добро.

26.04.2016    42159    0    1c-intelligence    45    

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

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

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

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

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

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

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