Позорные проблемы типового кода 1С с обратной совместимостью

Программисты 1с не любят типовые конфигурации.

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

В одном месте кода получали основной банковский счет организации при заполнении документа:

БанковскийСчетОрганизации = ЗначениеНастроекПовтИсп.ПолучитьБанковскийСчетОрганизацииПоУмолчанию(СтруктураПараметров);

Стала возникать ошибка, что не заполнено поле КорреспондирующийСчет.

Ошибка возникала в процедуре Справочник.БанковскиеСчетаОрганизаций.ПолучитьБанковскийСчетПоУмолчанию:

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

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

В итоге я сделал заплатку:

&Вместо("ПолучитьБанковскийСчетПоУмолчанию")
Функция дор_ПолучитьБанковскийСчетПоУмолчанию(СтруктураПараметров)
	Если НЕ СтруктураПараметров.Свойство("КорреспондирующийСчет") Тогда
		СтруктураПараметров.Вставить("КорреспондирующийСчет", Неопределено);
	КонецЕсли;                            
	Если НЕ СтруктураПараметров.Свойство("ИсключитьСчетаВВалюте") Тогда
		СтруктураПараметров.Вставить("ИсключитьСчетаВВалюте", ложь);
	КонецЕсли;                            
	
	Результат = ПродолжитьВызов(СтруктураПараметров);
	Возврат Результат;
КонецФункции

При переходе с 11.5 на 11.6 разработчики типовой конфигурации УТ решили полностью переписать код, даже там, где можно было бы не плодить ошибки, наплодили. Абсолютно не подумали о тех, кто пользуется их кодом. Для костылестроительной фирмы это было бы еще допустимо, но для фирмы, пишущей на всю страну — ПОЗОР.

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

В мире «большого» программирования для такой проблемы есть четкая терминология:

⦁ Breaking Changes (Ломающие изменения / Нарушение обратной совместимости)
Главная причина боли. Это ситуация, когда обновление функции или API ломает существующий код, который до этого успешно работал. В зрелых экосистемах принято сохранять Backward Compatibility (обратную совместимость): если в функцию добавляются новые параметры, их делают необязательными (указывают значения по умолчанию) или создают новую функцию, оставляя старую рабочей.
⦁ Tight Coupling (Жесткая связность)
Проблема, когда внешний код слишком сильно зависит от внутренней реализации функции (в данном случае — от точного состава полей структуры параметров). Изменение одного винтика в модуле приводит к каскаду ошибок по всей системе.
⦁ Defensive Programming Violation (Нарушение принципов защитного программирования)
Код платформы или типовой конфигурации ожидает «идеальный» вход и сразу падает в ошибку, вместо того чтобы безопасно обработать отсутствие необязательных ключей (как раз то, что пришлось исправлять через Свойство()).
⦁ API Rot / Code Smells (Деградация API и «Дурной код»)
Ситуация, когда разработчики базового продукта хаотично меняют сигнатуры функций от версии к версии без соблюдения стандартов проектирования (например, правил семантического версионирования SemVer), превращая работу с экосистемой в постоянную латание дыр.

Среда: УТ 11.6.1.53. Объем: 0.5 час