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

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

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

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

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

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

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

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

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

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

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

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

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

• Breaking Changes (Ломающие изменения / Нарушение обратной совместимости)
  
  Главная причина боли. Это ситуация, когда обновление функции или API ломает существующий код, который до этого успешно работал. В зрелых экосистемах принято сохранять Backward Compatibility (обратную совместимость): если в функцию добавляются новые параметры, их делают необязательными (указывают значения по умолчанию) или создают новую функцию, оставляя старую рабочей.

• Tight Coupling (Жесткая связность)
  
  Проблема, когда внешний код слишком сильно зависит от внутренней реализации функции (в данном случае — от точного состава полей структуры параметров). Изменение одного винтика в модуле приводит к каскаду ошибок по всей системе.

• Defensive Programming Violation (Нарушение принципов защитного программирования)
  
  Код платформы или типовой конфигурации ожидает «идеальный» вход и сразу падает в ошибку, вместо того чтобы безопасно обработать отсутствие необязательных ключей (как раз то, что пришлось исправлять через Свойство()).

• API Rot / Code Smells (Деградация API и «Дурной код»)
  
  Ситуация, когда разработчики базового продукта хаотично меняют сигнатуры функций от версии к версии без соблюдения стандартов проектирования (например, правил семантического версионирования SemVer), превращая работу с экосистемой в постоянную латание дыр.

Среда: УТ 11.6.1.53.