Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Содержание кода в одном стиле

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

Так вот, со всеми программистами, с которыми мне приходилось плотно работать, ни один со мною не согласен :-)
Хотелось бы услышать ваше мнение опытные господа.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ух, больше 10 лет прошло. С переходом индустрии от больших и толстых монолитов с ООД и тоной коду, на зоопарк михросервисов — проблема конеш чуть мение актуальна.

не красивые, и воще требуют жуткого копи-пейсту

У меня был мексиканский коллега, который тоже исповедовал такой подход: хорошо помню как делал код ревью, где ему для достаточно простого изменения потребовалось 28 одинаковых правок кода в разных местах.

Підтримую автора на 200 відсотків хоча є прихильником чистого коду

«единообразное безобразие» — это довольно рациональный подход,
особенно в продуктовой разработке (не «для дяди»)

не зря же считается, что лучшее — враг хорошего.

Так вот, со всеми программистами, с которыми мне приходилось плотно работать, ни один со мною не согласен :-)
есть значительная мировоззренческая разница в подходах программиста, который сразу пришел на позицию девелопера (сразу в офицеры), и
программиста, который побывал в окопах тестинга.
критичность мышления различна,
если «офицеру с младых ногтей» самому протестить — Фи,
то
цикл «создания» бага -> потОм его обнаружение, оформление -> фикс -> проверка
растягивается на месяцы. Фиксит обычно кто-то другой, времени мало, вникать непросто — вставил костыль -> заработало, ок.

сорри за некоторый оффтоп.

Идея интересная.

Я бы сюда еще кастомер саппорт первым местом поставил.

А почему "

каждый программист применяет совй подход

«? У проекта нет архитектуры? Или есть, но ее консистентность никто не контролирует? Проводится ли код ревью? Ну и бороться копипастой с зоопарком подходов — звучит как «алкоголь против наркотиков» :)

А почему

каждый программист применяет совй подход

? У проекта нет архитектуры? Или есть, но ее консистентность никто не контролирует? Проводится ли код ревью? Ну и бороться копипастой с зоопарком подходов — звучит как «алкоголь против наркотиков» :)

У проекта нет архитектуры?

Архитектур много разных на разных уровнях... вы какой уровень имеете ввиду ?

Или есть, но ее консистентность никто не контролирует?

опять таки вы какой уровень имете ввиду ?

Проводится ли код ревью?

вот код ревью в условиях когда надо и самому много писать, и собеседники «толковые и настойчивые» — тяжелый процесс :-) А главное с условием «содержим все в одном стиле» воще никто не согласен, собственно потому я сюда и написал свой вопрос.

Ну и бороться копипастой с зоопарком подходов — звучит как «алкоголь против наркотиков»

копипаста — это просто как пример, я не в коем случае не сетую за то чтобы все «проблемы» решались ей.

Тут не важно какой уровень. Возьмем Ваш пример — ждбц и хибернейт. Выбор того или иного решения должен быть частью архитектуры и проект пишется в соответствии с этим. Т.е. никаких «хочу хибернейт, мне для резюме », если это выходит за рамки архитектуры. Побочный эффект — может вызывать вопли типа «контора навязывает мне средства разработки, хочу творить..», но как и кто должен эти рамки поддерживать — другой вопрос. Брукс, «Мифический человеко-месяц», 2 глава, рекомендую, как раз по этому поводу.

все дело в балансе — копипаст однозначно зло. очень геморно его «декопипастить» , паттерны и просто разрабатывать не ломая существующую архитектуру — нормально, особенно если нет полного coverage или в тиме много участников — тогда рефакторинг приводит к гемору с мержингом и совместимостью

еще в «больших архитектурах» есть такие архитектурные ошибки «подобия», которые обычно касаются «продуктовых» контор. это когда есть, например, ну складская программа, а тут надо CMS сделать, и вроде как естественно, что проще «выкусить» из складской программы теже ACL, немного подправить и запользовать, потом появляется необходимость в каком нить «календаре» и уже по накатанному «вырезается и немного подправляется»

в результате получаются переполненные костылями, глюками и лишней функциональностью тулзы , в которых реализация не полностью подходит под задачи

либо генерятся супер-пупер либы, с сумашедшими настройками и поддержкой «всего и сразу» , пользоватся которыми может только их оригинальный разработчик и то, только после дозы веществ

В данном случае идет речь про одну и туже программу. Когда надо добавить новую функциональность. Но скорей всего в ближайшем будущем новое прийдеться переплитать со старым.

Если вы копипастите код, в одном проекте, следовательно ваш код изначально г*вно. Есть такое понятие как метрики кода. И я думаю, что IDE которым Вы пользуетесь, сможет ответить на вопрос «Мой код отличный?».

И еще одно. Я из чужого кода узнал очень много ПОЛЕЗНЫХ вещей, которые существенно улутшили понимание и мой стиль написания кода.

Есть такое понятие как метрики кода. И я думаю, что IDE которым Вы пользуетесь, сможет ответить на вопрос «Мой код отличный?».

. Вы забыли, что самоя главная метрика кода всех времен и народов — «в продакшене, работает, клиенты не жалуються». И вы пойдите еще докажите вашему ПМу, что стоит потратить время на стремный рефакторинг того что и так работает, видите ли, только по тому что копи-пейст это не труъ и не одобрямс.

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

«в продакшене, работает, клиенты не жалуються».

всё отлично, пока цена саппорта и расширяемости спагетти-кода приемлема.

ПМ \ заказчик должен понимать, что за плохой код он платит бабло-часами.

Если бизнес-модель конторы «кузница кадров» то другого кода там обычно и не водится.
В других случаях есть масса вариантов.
Важно понять — готова ли контора платить за совершенство?
Если нет — то это и есть ответ на вопрос «надо ли переживать по поводу плохого дизайна?».

Как вариант, можно просто поменять проект\контору.

Просто когда главный критерий:

«в продакшене, работает, клиенты не жалуються».

удовлетворен, говнистость большенства остальных метрик оцениваеться восновном както сугубо субъективно. Например тот же копи-пейст, который везде и всегда освещаеться как самое страшное зло, имхо в ряде случаев являеться приемлимым решением (это тема отдельного холивара).

И еще одно. Я из чужого кода узнал очень много ПОЛЕЗНЫХ вещей, которые существенно улутшили понимание и мой стиль написания кода.

Здесь сугубо имхо — брать на заметку лучче из «хорошо» написанного кода, а не из какого попало.

Даже из хренового кода, можна черпать полезное. Например то, как писать не надо)

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

Если у вас есть возможность, посмотрите на свой код теперь, год назад, 2 года назад...

Или вы про дартаньянов, которые видя что код «не правильный!» (не нравитсо) переколбашивают код за день до релиза?

Я не про то и не про другое.
Похожий гипотетический, несколько утрированный юзкей про зоопарк технологий.
Например — повсеместно на проэкте применяеться ждбц.
Приходит новый программист, и говорит «ждбц фу, хайбирнейт рулез», и начинает использовать хайбирнейт в новом модуле.
О совместимости со старым кодом он не думает, потому что старый код он не особо знает, старый код плохо писанный, и его много, да и воще сроки горят.
В результате имеем две технологии доступа к данным... причем не совместимые вообще.

И когда к нам приходит реквест который требует того или иного объедениния старого кода с новым мы получаем...

Данный пример понятен.
Если хибернейт внетряется как следующий шаг, то это развитие. А если вы пишите как хотите, а я буду как я хочу — то согласен подход гнилой.

Простите, но исходный пост я не понял. Могли бы вы показать на примере?

То что я имел в виду весьма похоже на на более низком уровне.

Ну например если брать тот же ждбц. Код который генерит скуэль из бинов по старинке находиться в отдельных вынесеных фектори. Приходит программист номер2 и пишет скль рилейтед код прямо в самом бине. Приходит программист номер3 и делает хитрую генерацию по рефлекшену в совершенно другом месте. Все эти подходы вполне работают и даже уживаються до поры до времени. Но я бы предпочел чтобы все было написано используя единый подход.

Если я вас правильно понял, то я, так же как и вы, осуждаю :)

Ибо если человек уже внедряет что-то новое, то желательно обсудить это со всеми и прорефакторить предыдущею версию, насколько это возможно.

Підписатись на коментарі