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