- в вашей программе ошибка и она не работает!
- чего же вы хотели, если не сделали настройки!
- какие еще настройки? в интерфейсе только одна кнопка!
- так они не тут, а в регистре НастройкиОбработок - я их описал в документации в пункте 31.7 в подпункте 2
- у нас есть документация???
- есть! она устарела, но этот пункт все еще актуален...
О каких контрактах речь? Речь про обязательство наличия у объектов и модулей некоторой функциональности, без которой система в целом будет работать неправильно: список реквизитов с указанными именами и типами, обработчики определенных типов оповещений, экспортирование требуемых публичных методов и так далее.
Пример проблемы. Один программист реализовывает проверку документов с запретом продажи ниже себестоимости - это просто подписка на определяемый тип с вызовом экспортной функции из модуля документа, которую он добавил во все документы из подсистемы продаж. Второй программист разрабатывает новый документ отгрузки со склада, который в целом правильно работает согласно ТЗ, но аналитики при запуске решают, что отгрузка же ведь может быть на покупателя и потому новый документ нужно включить к остальным в определяемый тип "продажным документов". И тут внезапно документ перестает работать и выдает ошибку несуществующей экспортной функции.
👆 Можно ли избежать подобных проблем?
1) Использовать регрессионное тестирование при подготовке релиза.
2) Добавить юнит-тесты при старте, которые перепроверяют выполнение системных контрактов.
3) Программировать в безопасном стиле - т.е. в самих функциях контролировать их применимость: проверить через метаданные существование реквизитов объектов, а внешние методы вызывать через Try/Except.
✍️ С одной стороны так нарабатываются технические практики, которые свидетельствуют о зрелости команд разработки. А с другой стороны, это же просто искусственные ограничения самоконтроля для платформы 1С, которые годами не устраняют с аргументацией: "вам это не надо!".
#1С #пятница - посвящается дню отправки пожеланий на @platform_suggestions