Практика чистого кода на 1С
Рассказываю о подходах к разработке на 1С. Показываю на что обращаю внимание, когда пишу код на 1С. Разбираю некоторые особенности архитектуры БСП. Показываю, как делают интерфейсы в типовых и что это такое
Рассказываю о подходах к разработке на 1С. Показываю на что обращаю внимание, когда пишу код на 1С. Разбираю некоторые особенности архитектуры БСП. Показываю, как делают интерфейсы в типовых и что это такое
Но в анкету предзаписи попадают новички. Новичков не так много, но есть. Ребята, это курс для опытных 1С разработчиков.
Курс для тех, кто хочет писать код на уровне типового кода. Прям писать с нуля, а не дорабатывать. Курс для тех, кто хочет понимать принципы работы типового кода.
Анкета предзаписи тут: https://forms.gle/eVnHV4wLJR4EkQmK6
Скрины с кодом со стрима для ленивых.
Объявляю челендж.
Если кто-то решит задачу принципиально другим способом и решение будет лучше моего, то переведу автору кода 10 000 руб.
Задача: автоматическое начисление арендной платы с использованием разных провайдеров договоров.
Код присылайте в комментарий под этим постом. Решения принимаю до понедельника 23 октября 23:59:59
«А я использую 1C:EDT. Стараюсь писать без ошибок и замечаний со строгой типизацией»
«Новый опыт ЕДТ с его проверками или анализ Сонаром - сразу меняет стиль. Но максимально новый опыт - это включить строгую типизацию в ЕДТ и начать писать сотни функций-конструкторов, назначение которых только в описании типов параметров, результатов запросов и промежуточных структур»
Чаще всего писали о строгой типизации в EDT и анализ кода Сонаром или Феникс БСЛ. В этот список еще добавлю АПК. Это минимальный набор, который улучшит оформление кода, покажет, что существуют базовые стандарты. Сонар, Феникс, EDT не знают об архитектуре приложения, не расскажут как правильно организовать цепочку вызовов. Не подскажут, какие структуры данных лучше использовать. Не проверяют правильность выбора имена переменных и методов. Только человек такое может.
Кто-то вспоминал об изучении кода типовых. Программист не поймет код типовых, тк не знает концепцепций. Это как учить иностранный язык: слышишь только те слова, которые знаешь.
На созвоне вспоминали сертификацию на специалиста и эксперта. Подготовка к сертификатам мозги немного вправляет, но сертификация не о чистом коде.
«Я один раз работал с ревью кодом по истине с хорошим человеком, больше не работал и да сложно понять, какой код ты пишешь, только ревью спасёт. Но не всем заходит, не все готовы принимать критику, видел как это принимают в штыки, мать вашу, бесплатный опыт в штыки, жесть, не понимаю таких людей)) ревьюти меня полностью!»
Тут согласен. Это самый быстрый способ. Только найти толкового наставника сложно. Это должен быть человек, который профессионально пишет на нескольких языках, например Дмитрий Решитко. Человек, который видит общее и без проблем находит интерфейсы в 1С, хотя остальным кажется, что в 1С интерфейсов нет. Хороший наставник должен нормально объяснять, а не намекать каждый раз, что ты просто тупой. Если знаете таких ребят, то держитесь за них крепко. Я от силы четырех человек знаю, которых называю хорошими наставниками по чистому коду, а список контактов 1С программистов у меня большой.
«Читаю, читаю, и все жду, когда у Евгения появится отсылка к литературе не 1С.
А когда добрался про место с книгами ойкнул: Не дало?!!(
Да как же не дало, а вся рефлексия откуда? От типовых»
Можно самому учить другие языки и читать книги: Чистый Код Роберт Мартин, Грокаем алгоритмы, Совершенный код Макконнелла. Только кто проверит, что ты правильно все понял и пишешь действительно хорошо, а не оверинженеришь?
Кажется, кроме наставника вопрос не решается. По крайней мере я не знаю как.
Провести сегодня стрим? Показать, как пишу 1С код? Будет полезно?
Когда программист решает одноразовую задачу, то тратить время на обдумывание архитектуры и писать чистый код смысла нет. Накладные расходы превышают пользу. Нашел подходящее место для изменения и говнокодишь. Принцип «и так сойдет» подходит для одноразовых задач. Не берем в расчет автоматизацию систем критически важной инфраструктуры, работа которой может повлиять на жизнь и здоровье людей и окружающей среды. 1Сники с такими проектами не сталкиваются.
Когда программист автоматизирует условно-постоянные процессы, то чистый код тоже не нужен. Пример таких процессов: работа завхоза, работа с архивом. Это второстепенные процессы для бизнеса. Второстепенные процессы меняются медленно. Процесс изменится лет через пять и тогда проще автоматизировать процесс с нуля на современном стеке.
Автоматизацию условно-изменяемых процессов опасно делать на говнокоде. К таким процессам относятся: продажи, производство, ремонты. Заказчик собирает большой бэклог хотелок для условно-изменяемых процессов. Программист знает какие будут изменения, какие блоки связаны друг с другом. Заказчик меняет требования каждый месяц, неделю, день. Бизнес меняется, чтобы конкурировать в быстро меняющемся мире. Говнокодить в этом случае тоже можно, но постепенно вносить изменения становится сложнее и сложнее. Меняешь учет продаж, а отваливается учет ремонтов.
Программист на конференциях слышит, что в 1С подвезли тесты. Честно осваивает сценарное тестирование, но это долго, дорого и не факт, что покрываешь все сценарии. Менять код по-прежнему страшно. Программист узнает о юнит тестах. Юнит тесты писать быстрее, но лапшичный код препятствует внедрению юнит тестирования. Программист не применял паттерны, не понимает, что такое программный интерфейс, не знает принцип открытости/закрытости, не применяет инверсию зависимости, а бизнес логика намешана с получением данных. Программист на проекте не один. Команда ненавидит хранилище, ругаются, что кто-то долго занимает модуль. Проблема не в хранилище, а в коде. Команда написала сильно зацепленный код, нарушающий принцип единственной ответственности.
Часто команда собирается и выносит вердикт: «Давайте перепишем базу с нуля». Бизнес не идет на такую авантюру. Почему-то парни в костюмах знают, что команда через пару лет повторит успех. Придет новый лид и снова скажет: «Все говно, переписываем с нуля». А если бы команда писала чистый код и инвестировала время в чистую архитектуру, то переписывать с нуля не пришлось бы.
Верные рассуждения? Что думаете? Кто сколько раз переписывал с нуля и получал такой же результат?
Понравилось, как на https://refactoring.guru/ написали:
Зачем знать паттерны?
Проверенные решения. Вы тратите меньше времени, используя готовые решения, вместо повторного изобретения велосипеда. До некоторых решений вы смогли бы додуматься и сами, но многие могут быть для вас открытием.
Стандартизация кода. Вы делаете меньше просчётов при проектировании, используя типовые унифицированные решения, так как все скрытые проблемы в них уже давно найдены.
Общий программистский словарь. Вы произносите название паттерна, вместо того, чтобы час объяснять другим программистам, какой крутой дизайн вы придумали и какие классы для этого нужны.
Боль 1С мира — третий пункт. Нет общего словаря, кроме старой и новой методики проведения😁 Поэтому пишем костыли. Проще совместно разрабатывать, если разговаривать так: давай добавим адаптер, лучше сделай через фабричный метод, используй прокси.
Наставник, который учит меня писать чистый код, наехал на неверное употребление словосочетания «слабосвязанный код». Наставник из мира 1С, поэтому иногда почитывает посты в ЖК.
Исправляюсь. Правильнее сказать, что код «сильнозацепленный». Выделяют два понятия:
Low Coupling - слабое зацепление
High Cohesion - сильная связность
Это шаблоны проектирования GRASP. В GRASP девять шаблонов.
Функции должны быть слабо зацеплены (связанны), но при этом хорошо, чтобы функция была сильно связана (или просто сильная), т.е. выполняла только одно назначение.
Зацепление — мера зависимости одного кода от другого, а не связность.
Что думаете, прав мужик?
По ф12 переходишь только по прямой зависимости. По условной в конфигураторе нельзя перейти. В ЕДТ с этим лучше.
Но делая прямую зависимость, получаешь сильносвязанный код, который сложно адаптировать под новые требования. Потому лучше пренебречь удобством быстрого перехода ради быстрой доработки. Не делайте, как неуклюжие франчи: быстро где-то что-то дописать, закомментировать, найдя по цепочке вызовов. Это плохой путь.
Всегда сначала разбираемся что-где есть.
Писать код с прямой зависимостью проще, по ф12 перемещаться проще. Зарабатывать деньги проще, чем писать слабосвязанный код. Код, который легко модифицируется под новые требования.
Я сам хейтил умников и говорил: « В 1С все это не нужно». Изменил мнение, когда написал три игры на говнокоде, а потом увидел слабосвязанный код и чистую архитектуру. Понял, почему я столько мучался. Проблема не в изменении требований, а в неумении писать чистый код.
На этом рубрику паттернов закрываю, тк тема мало для кого актуальна. Если вдруг этот пост наберет 50 репостов, тогда подумаю над возобновлением рубрики.