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