Есть такие, кто считает, что нет оснований для использования отдельного понятия архитектор 1С. Дескать, архитекторы это, например, Растрелли или Гауди, а мы тут немного другим занимаемся. Разработка программного обеспечения и проектирование зданий может и являются родственниками, но уж очень дальними. И, в конце концов, есть уже один достаточно широко используемый термин: разработчик. Зачем плодить лишние сущности и ссылаться при этом на что-то постороннее? Некоторое время назад автор и сам был одним из тех, кто так считал. Но все-таки различать разработчиков ПО и архитекторов ПО имеет смысл. И я попробую раскрыть его.
Архитектор это тот, кто в состоянии представить себе будущее здание со всеми необходимыми деталями, как бы построить его у себя в голове. В этом смысле аналогия между проектированием зданий и разработкой ПО вполне себе уместна. В принципе, любой разработчик программного обеспечения постоянно выстраивает у себя в голове довольно сложные, а порой и очень сложные конструкции. Но есть один нюанс. Это элемент контакта с реальностью. Я, например, не будучи архитектором в классическом смысле этого слова, могу представить себе какое-нибудь красивое здание. Но не факт, что его можно будет построить. А если и можно (техника сейчас творит чудеса), то вполне может оказаться, что жить в нем будет не так, чтобы очень удобно.
Мы, разработчики ПО, вообще не ограничены такими вещами, как физика и сопротивление материалов и можем построить «все». Тем более важен момент «удобства». Объясню это на конкретном примере.
Задача, которая будет рассматриваться далее, достаточно известна. Описываемые здесь решения, не являются какими-то эталонами. В рамках данной статьи я хочу продемонстрировать не столько сами решения, сколько отличия в работе архитектора и разработчика.
В каком-то смысле учетные системы довольно однообразны. В сущности, здесь все сводится к двум операциям: накопить и распределить. Но все же и тут можно встретить нетривиальные ситуации. Возьмем обработку операции расхода товаров. На первый взгляд все вроде бы просто. Товар передается покупателю со склада или из магазина. Товара стало меньше, значит надо вычесть соответствующее количество из регистра. Сложность в том, что в результате у нас может образоваться отрицательный остаток в регистре и этот случай нам надо не игнорировать, а каким-то образом обработать.
С этого момента пути разработчика и архитектора расходятся. Разработчик действует индуктивно, если можно так выразиться. В отличие от архитектора, который применяет дедуктивный подход, он хватает задачу за хвост и вытягивает ее шаг за шагом. Ход его рассуждений следующий. Для начала надо отследить образование отрицательного остатка. Подсчитаем остаток товара на момент до проведения документа. Вычтем из него количество, указанное в документе. Если результат отрицательный, то вот она проблема. Зафиксируем ее каким-то образом, например, запретим проводить документ. Все сходится? Все сходится. Где подвох? Подвох в том, что позиций в документе может быть очень много. Получение остатков по каждой из них может занять определенное время. А еще у нас много не только позиций в документе, у нас много одновременно работающих пользователей. Это означает, что к тому моменту, как мы подсчитаем остаток по последней позиции в документе, остаток по первой может измениться. Значит, нам надо позаботиться о том, чтобы исключить такое. Будем устанавливать блокировку на регистр на все время, пока мы занимаемся вычислением остатков и поиском среди них отрицательных значений.
Но иногда пользователей бывает не много, а вот прям очень много. Если сделать так, то мы получим очередь документов, ждущих снятия блокировки. Проведение документов в таком стиле станет узким местом. Чтобы его расшить, надо что-то придумать.
Хорошо, думает разработчик, буду проводить документ без проверки, зато быстро. А проверку прикручу после проведения. Если в результате проведения документа возникнут отрицательные остатки, тогда отменю проведение документа.
Так рассуждает разработчик. Ход мыслей архитектора совсем другой. Мы обрабатываем операцию расхода. Соответственно, уменьшаем остатки. Может возникнуть отрицательное значение? Может. Что с этим делать? Запретить такую операцию? Тут надо разобраться. Что означает операция расхода в нашей системе? Это резервирование товара под будущее действие с ним или регистрация факта отпуска товара? Резервировать больше, чем есть в наличии нежелательно. Придут два покупателя, претендующие на один и тот же товар, и надо будет это как-то разруливать.
Но у нас тут кассовые чеки из магазина, расходные ордера со склада. Явно не резервирование. Для резервирования товара у нас отдельный документ предусмотрен. Тогда что делать с документом расхода, который не резервирование? Запрещать операцию, при выявлении отрицательных остатков? Ни в коем случае! Ровно по той же причине, по которой нельзя разрешать резервирование товара сверх имеющегося остатка, нельзя запрещать проведение документа, который регистрирует свершившийся факт. Потому что это может привести к той же самой ситуации с двумя покупателями и одним товаром. Мы же не зарегистрировали в системе факт расхода. Как следствие, у нас на остатках числится то, чего в реальности уже нет.
Мы не можем допустить, чтобы наша система отставала от реальности. Поэтому будем проводить документ как есть. Да, наличие отрицательных остатков без сомнений означает, что расхождение с реальностью имеет место быть. Но сам по себе отрицательный остаток не несет опасности перерезервирования. Наличие отрицательного остатка в регистре это ни что иное, как сигнал о том, что есть расхождение с реальностью. И этот сигнал полезен. Его не надо заглушать.
Но как практически обработать такую ситуацию? Вывести сообщение пользователю при проведении документа о появлении отрицательных остатков? Нет смысла. Пользователь забудет об этом через 5 минут. Если сигнал полезен, его надо бережно сохранить. Вот и решение. Будем регистрировать отрицательные остатки в отдельном регистре (журнале). Там же можно будет предусмотреть возможность назначить ответственного за разбор ситуации, добавить статус разбора и комментарий. А для того, чтобы формирование этого журнала не мешала основной работе пользователей в высоконагруженных системах, можно сделать это в отдельном процессе, который будет активизироваться в периоды наименьшей нагрузки.
Вот такие два подхода. Надеюсь их демонстрация немного проясняет разницу между разработчиком 1С и архитектором 1С.
В преддверии запуска курса «Архитектор 1С» мои коллеги из OTUS проведут бесплатный вебинар, который предоставит вам глубокое понимание процесса установки, настройки и управления платформой 1С в среде серверов. Вы также узнаете о конфигурации кластера 1С и основных параметрах, которые влияют на его работу. Зарегистрироваться можно по этой ссылке.
