Видео старое.

https://www.youtube.com/watch?v=N5ci6ZSlq5k

Комментарий на ютуб к видео:

Для 1С применимо большое число паттернов.
MVC - это энтерпрайз-шаблон стоящий в стороне от обычных ОПП-шаблонов. В 1С его применение в интерфейсах уже вшито и для разработки интерфейсов его применять не нужно - все уже сделано разработчиками платформы. Подмена существующего обработчика события - это просто использование существующего вшитого механизма, а не разработка системы по шаблону MVC. Действительно применить MVC можно при взаимодействии со внешним оборудованием или путем применения внешних компонент. Отчеты 1С не реализованы по MVC, совсем! Только если через отчет можно редактировать данные или он ведет себя как динамический список, что маловероятно ))

Есть шаблоны GRASP и GoF. GRASP - более базовые, выведены как обобщение GoF. И для 1С, как и для любой здравомыслящей разработки, очень желательны. Нарушение High Cohesion, Low Coupling и особенно Information Expert ведет к нарушению инкапсуляции и полному бардаку в системе, что собственно и наблюдаем во многих доработанных типовых конфигурациях. Скорее всего это и имелось ввиду когда речь в вебинаре заходила о плохом коде.

Из паттернов GoF очень полезны "Фасад" и/или "Адаптер". Без них например сделать подсистему-плагин, подходящую под разные конфигурации построить не получится. Придется под каждую конфигурацию с нуля писать решение. Фасад-адаптер между регистрами типовой конфигураций и механизмами плагина можно написать свой под каждую конфигурацию, тогда основную функциональность можно не переписывать.

Шаблоны "Прокси" / "Декоратор" можно применять чтобы расширить функциональность типовых общих модулей, хотя в этом случае мы действуем не механизмами ООП, а менее подходящим под это процедурным подходом.

Паттерн "Шаблонный метод" часто применяется в 1С , хотя применяющие обычно этого не осознают ))

Очень хотелось бы увидеть вебинар ориентированный именно на соблюдение принципов GRASP и возможностей применения GoF шаблонов. MVC - это не то, что на данный момент избавит программистов 1С от плохого кода, мы почти не можем в него вмешиваться и шансов применить мало.

И в добавок, применение шаблонов не избавляет от говнокода. Злоупотребление шаблонами - это тоже антипаттерн. К счастью в 1С злоупотребить паттернами почти невозможно, потому что они сейчас применяются практически только разработчиками типовых конфигураций. Разработчикам 1С на местах хорошо бы хотя бы начать ))

Рубрика "Великие цитаты великих людей".

Александр Орефков :

На самом деле одинэсники вовсю используют самые лучшие паттерны, тщательно отобранные заботливыми методистами и разработчиками платформы 1С.

Когда ты пишешь свой тупой код для простенькой управляемой формы, на самом деле ты юзаешь
model\-view\-controller с double\-way data binding в three\-layered\-data\-app\-engine, сдобренный
high level object\-relation\-mapping на базе declarative metadata description, имеющей свой
platform\-independed query language, c declarative data\-driven user interface, complete transparent serialization и domain\-oriented programming language.

В чём разработчики 1С отличаются от западных коллег, так это в пиаре. Те любят любой фигне дать громкое имя и носиться с ней, как с писаной торбой.

#1С

https://t.me/rd_1c

Группа 1С-специалистов Дагестана

https://uc1.1c.ru/course/pishi-kod-gramotno/ Интересный курс. Правда у Никиты Федькина свое мнение))

Telegram

wiki 1С. База знаний, мысли и заметки.

Продолжаю знакомиться с наследием Никиты Зайцева. У нас же есть классификация скиллов (джун, сеньор, мидл, архитектор, эксперт и т.д.). Тут же подходит именно - "легенда". Слушаю его подкасты здесь https://radio1centerprise.mave.digital/ или здесь https…

?️?️ TDD (Test Driven Development) — разработка через тестирование — практика разработки программ, при которой вначале пишут тесты для функциональности, которую хотят создать, затем — реализацию этой функциональности. Когда всё заработает — рефакторят код.

Основные принципы TDD:

?Прежде чем писать код реализации некоей возможности, пишут тест, который позволяет проверить, работает ли этот будущий код реализации, или нет.
?Прежде чем переходить к следующему шагу, тест запускают и убеждаются в том, что он выдаёт ошибку.
?Создают реализацию возможности и добиваются того, чтобы она успешно прошла тестирование.
?Выполняют, если это нужно, рефакторинг кода.

Стандартный цикл разработки состоит из трёх этапов:

?Красная зона. На этом этапе пишут тест, который точно упадёт с ожидаемой причиной. Если причина падения теста не совпадает с ожидаемой, переходить к реализации функциональности рано.
?Зелёная зона. На этом этапе пишут функцию, которая проходит этот тест. Цикл короткий, поэтому реализация должна быть максимально простой.
?Синяя зона. На этом этапе рефакторят код тестов и реализации. Проводить рефакторинг в синей зоне безопасно, потому что вся функциональность, которую рефакторинг затрагивает, уже покрыта тестами. Если что‑то по пути сломается, об этом тут же узнают.

Плюсы TDD:

?Более высокое качество кода.
?Улучшенная модульность. Каждый компонент тестируется сам по себе, при этом программисты исходят из того, что модули должны уметь работать друг с другом.
?Быстрое обновление.
?Улучшенное понимание кода. Каждый тест — это одновременно и документация к функциям, а это помогает всем лучше понять, что именно делает программа.

Минусы TDD:

?Нужно больше времени на написание кода и тестов.
?Для хороших тестов нужен большой опыт.
?Некоторые тесты сложно написать. Например, тестирование графического интерфейса автоматизировать сложно.

❓ А вы используете TDD на проекте?

И полезный стрим на тему как это в 1С https://www.youtube.com/live/Nb6EYlTnC18

? @top_1c

https://www.youtube.com/watch?v=kodwDM86YWc