Есть 3 проблемы кода, с которыми встречаешься в программировании: Хардкод, Говнокод и Шизокод.
Давайте поговорим об этом.
Хардкод
Это известная всем проблема, когда программист из-за спешки или лени пишет код без учета переменных. Пожалуй самый частый случай — домен сайта. Он может меняться от окружения к окружению и часто доставляет массу хлопот. Тут все просто. В разных платформах это решается по разному. Главное соблюдать соглашения и правила принятые в рамках платформы.
Обычно проблемы этого класса быстро обнаруживаются и легко лечатся.
Говнокод
Это более сложная проблема. Часто субъективная. Грубо говоря — это нарушение стиля кода, принятого в голове, команде или сообществе.
Есть разные стили кода в зависимости от платформы и даже иногда внутри платформы:
Это из мира php. В других сообществах ситуация похожая. Сюда же можно отнести истории про таб, таб через 2 пробела или таб через 4 пробела и т. д.
Здесь же возникает проблема чистого кода… например длинные функции на 3-4 страницы, что критикуется. Это не всегда конечно плохо, но часто можно такие функции сделать короче, разбить на ряд коротких функций, каждая из которых решает свою задачу.
Обычно эти проблемы легко лечатся через софт и контроль принятых стандартов в конкретной команде.
Высший пилотаж, когда разработчик может переключаться между разными стилями кода в зависимости от проекта.
Плохо когда разработчик нарушает стиль кода принятый в команде или считает свой любимый (часто единственно выученный) стиль кода единственно правильным.
Не бывает правильных стилей кода. Бывают утвержденные стили в команде или общепринятые стили.
Тоже относительно простая проблема и легко решаемая.
Шизокод
Вот это менее популярная проблема, но часто наиболее дорогостоящая.
Шизокод — происходит от понятия шизофрении. Выжимка из Википедии:
Шизофрени?я (от др.-греч. ????? «расщеплять», «раскалывать» + ???? — «ум, мышление, мысль»), ранее лат. dementia praecox («слабоумие преждевременное») или схизофрени?я — эндогенное полиморфное психическое расстройство или группа психических расстройств, связанное с распадом процессов мышления и эмоциональных реакций.
Тут 2 важных тезиса: раскалывание и слабоумие. Которые являются причинам шизокода.
Идеальный код — тот который не написан. Шизокодеры не знакомы с этим понятием.
Если коротко то шизокод, это код, который нарушает принцип Бритвы Оккама.
Выжимка из Википедии:
«Бритва (лезвие) О?ккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама. В упрощенном виде он гласит: «Не следует множить сущее без необходимости»
Выражается в том что разработчики начинают усложнять код и архитектуру без веских на то причин. Или вескость причин существует только в их воображении.
Воображаемые проблемы — корень плохого ПО
Есть 2 основных симптома: изобретение велосипедов на костылях и размножение слоев абстракции.
Изобретение велосипедов на костылях
Выражается в том что разработчики ввиду плохой способности обучаться вместо поиска оптимальных решений/методов в рамках платформы и существующей архитектуры начинают изобретать велосипеды/костыли.
Примеры:
- Написание своих CMS/фреймворков птм что у существующих есть фатальный недостаток
- Блог на Symfony. При том что весь мир для этого использует WordPress.
- Интернет-магазины на Laravel, при том что есть WooCommerce (№1 в мире), Magento (тоже хорошо), 1С-Битрикс (на худой конец, лучше чем Laravel)
- Встречал ситуацию когда верстка была на Bootstrap, но разработчик решил написать свои стили для меток (label). Что мешало добавить класс label, который уже есть в Bootstrap?
- Излишним функциям, методам и классам нет исчисления, которые можно было избежать используя уже готовые библиотеки и методы в используемых платформах
Бесконтрольное размножение слоев абстракции: лишние классы, наследования, методы
Внимательный читатель мог заметить конфликт с говнокодом. В одном случае проблем в том что функция или класс слишком длинный, а тут проблема в том что возникает наоборот избыточное дробление сущностей.
Тут нужно отметить что это одна из крайностей, границу которой не всегда просто соблюсти.
С одной стороны плохо все пытаться решать одной функцией на 3 страницы или класс который содержит в себе HTML и механики шаблона и где-то выгоднее разбить код на несколько функций/классов/компонентов, каждый из которых решает свою задачу. Это одна крайность.
С другой стороны плохо простой код разбивать на 5 классов в каждом из которых 3-4 метода по 3-4 строки, со множеством бесполезных наследований, когда можно обойтись одним или двумя с минимальным наследованием или даже без наследования если этого можно избежать.
Последствия лишних и плохих абстракций
Размножение методов, классов, наследований без веских причин — это лишний код и рост слоев абстракции.
У всего есть цена, как и у лишних абстракций:
- удоражается обучение новых разработчиков
- чем больше кода, тем больше точек отказа, тем больше ошибок
- усложняется диагностика и отладка кода
Проблема конечности мыслетоплива
Чем больше слоев абстракции, наследований, методов, тем больше нужно мыслетоплива для изменений, улучшений и диагностики проблем.
А рабочий объем мыслетоплива конечен и часто его нехватка влечет очень большие затраты на разработку.
Каждый разработчик, который делал диагностику и изменение шизокода упирался в дефицит мыслетоплива. Но не все это осознавали.
Видео, в котором объясняется что такое мыслетопливо и дается простое упражнение на 1 минуту, которое позволяет вспомнить ощущение дефицита мыслетоплива на простом примере:
Это наезд на ООП, классы и наследование?
Отнюдь. Однако доля правды в этом есть. В функциональном стиле проще наговнокодить, но шизокодить там сложно. ООП же с одной стороны дает множество преимуществ, но и открывает простор для шизокода.
ООП, классы и наследование — это не плохо и не хорошо. Это инструменты. Я лично их использую.
Однако у меня есть ряд собственных правил:
- Классы пишу почти всегда из-за инкапсуляции, но часто мне хватает Синглтонов, статических методов и stateless
- Там где есть частоиспользуемый метод — пишу функции, которые часто являются лишь обертками для методов какого-либо класса, но иногда функция это просто функция без класса и это хорошо там где уместно.
- Классы stateful — да, но реже и опять же только там где есть веские причины
- Наследования еще реже, и только там где на то есть веские причины (стараюсь уменьшать слои абстракции и экономить мыслетопливо в команде)
Резюме
Мы много говорим о хардкоде и говнокоде т.к. они понятны и легко осязаемы. А вот шизокод часто остается безнаказанным, птм что его сложнее выявить и понять объем вреда от него. А объем вреда от него возможно больше чем можно представить с наскоку.
Мой манифест простой:
- лучше изучить принцип Best of breed, прежде чем изобрети очередной никому не нужный велосипед на костылях
- давайте писать меньше шизокода
- давайте учиться соблюдать принцип Бритвы Оккама и не усложнять код без причины
- давайте экономить свое мыслетопливо и своей команды
Ну и буду рад комментариям как в поддержку манифеста, так и его критике.
Комментарии (87)
amaksr
04.08.2018 19:21+2Прочитал статью. Все равно непонятно, как именно надо кодить, чтобы было правильно.
Naglec
04.08.2018 19:27+1Очень просто: чтобы стороннему программисту было понятно как это работает.
JustDont
04.08.2018 19:36+3Это вообще ни разу не просто.
Проекция «на себя» не работает — я пишу, мне всё понятно.
Проекция «на коллег» не работает — коллеги тоже могут оказаться теми еще извращенцами.
Проекция «на всех» не работает по очевидным причинам.
Писать «как принято» — опять же, не панацея. Потому что «как принято» может быть объективно плохо, и тогда с этим надо в меру возможностей бороться, а не вливаться.maxxannik Автор
04.08.2018 21:55Думаю тут вопрос стиля кода.
Скажем если я в проекте на Symfony то буду писать с PSR, CamelCase & MVC (Model View Controller).
А если в проекте с WordPress, то буду писать в их стандарте с snake_case & EDA (Event Driven Architecture).
Те кто привык к MVC с трудом понимают EDA и наоборот. Хотя вроде бы язык один — php.
У каждой платформы свой стиль и своя архитектура, которую нужно понимать и придерживаться. Тогда внутри команды будет больше взаимопонимания.
VolCh
04.08.2018 22:22«Как принято» — лучший выбор по умолчанию, если это «как» достаточно формализовано или, хотя бы, явно видится из кода. Да, потом можно поднимать вопрос о изменении этого «как», притом способом исключающим появление нового кода в стиле «раньше так было принято», но по умолчанию нужно разобраться а как же принято здесь и сейчас.
Samouvazhektra
04.08.2018 20:12+1Так, чтобы через год не плеваться от своего говнокода :-)) И если плеваться тянет — это хорошо!
maxxannik Автор
04.08.2018 21:52Боюсь я не в силах ответить на этот вопрос. Как минимум на данном этапе. Скорее цель статьи — собрать больше точек зрения и попробовать приблизиться к пониманию. Свои принципы описал в статье. Можно узнать точки зрения кого-то еще.
Daddy_Cool
05.08.2018 01:26+1Чего вам непонятно-то? Русским по белому же написано — не пишите плохо, пишите хорошо!
Samouvazhektra
04.08.2018 20:00+1Пункт 3 действительно, очень специфичный. И на первый взгляд вроде кажется правильным и логичным, но… для абстрактного кода в ваккууме. На самом деле нельзя классы/методы рассматривать вне контекста и задачи. Где-то и функция-портянка на 300 строк норм, а где-то классы на 2- 3 метода дадут гораздо больше профита.
Есть очень большая разница, когда ты просто решаешь конкретно поставленную задачу, с целью чтобы работало, и когда пишешь приложение/библиотеку которая должна поддерживать расширяемость и иметь определенную гибкость. Когда работаешь один, и когда работаешь в команде.
Переабстракция — это плохо. Особенно в языках не поддерживающих перегрузку. Но когда класс смешивает в себя кучу разной логики из разных кейсов и слоёв — это тоже не есть гуд. Лучше 10 небольших классов отвечающих за свои юз-кейсы и сферы взаимодействия, чем один супер-класс на все и вся… и, конечно же, обязательно синглтон.
Это понимание прийдёт с опытом и временем. SOLID, паттерны, чистый код — придуманы и написаны давным-давно. Но даже на 100 раз прочитав про них, на практике до них еще нужно дойти. (и да… это не панацея, иногда их можно и даже нужно нарушать :-) )maxxannik Автор
04.08.2018 22:18-1Действительно без конкретной ситуации сложно объяснить все эти абстрактные ядра :)
Думаю тут важный момент — бритва Оккама. Речь именно про нее :)
Это лучший из известных мне способов объяснить абстрактно про излишнюю абстрактность :) Но боюсь он не идеален и не всем понятен с наскоку.
Если взять бритву то далее есть две ситуации:
— пишем все в 1 классе до тех пор пока нет веских причин разбивать его на подклассы
— появилась веская причина? разбиваем класс на разные классы
Какие могут быть причины? Их много:
— основной класс стал слишком большим и не понятным
— нужно разбить код на шаблоны и логику
— нужно часть функционала переиспользовать в других классах
и т д
Но бывает что причина только одна… разработчику хочется уталить свою жажду красоты и показать что он знает что такое наследование… и вот мы получаем кучу бесполезных классов, наследований и лишних слоев абстракции…VolCh
04.08.2018 22:26Дико сомневаюсь, что есть такая причина в заметных количествах на реальных проектах. Основная причина появления «лишних» по чьему-то мнению абстракций, субъективно, непонимание кейсов когда они окажутся полезными или мнение, что вероятность этих кейсов пренебрежимо мала, типа смены базы данных или фреймворка.
maxxannik Автор
04.08.2018 22:47-1Безусловно в большом проекте бывают ситуации когда кто-то простое не понимает зачем тут эта швабра подпирает дверь. Он ее убирает и происходит извержение вулкана )
Тема весьма спорная и в отрыве от конкретной ситуации сложна для обсуждения.
Конечно говнокодинг и хардкодинг встречаются чаще. Их и лечить проще.
Однако шизокодинг существенно дороже. Мы тут зацепились за идею с излишним наследованием. Что действительно редкое проявление шизокодинга. Но все же бывает.
Гораздо чаще встречается ситуация когда разработчики начинают свои костыли пилить (при условии наличия существующих методов), фреймворки, CMS или делать Интернет магазин/Блог на чистом Laravel. На мой взгляд причина одна и таже — разработчик не удосужился изучить существующие решения. И начал пилить велосипед. И это дорого. Очень дорого обходится бизнесу.Samouvazhektra
04.08.2018 23:01+1CMS или делать Интернет магазин/Блог на чистом Laravel
то есть по-вашему уже нет смысла разрабатывать блоги, cms и магазины, потому что всё уже давно придумано и написано?
Иногда действительно встречаются, мягко говоря, неудачные поделия… но в конце-концов, лучше уж на Laravel чем хардкод с нуля
maxxannik Автор
04.08.2018 23:11на мой взгляд — надо применять паттерн Best of breed.
для сайта я возьму WordPress. для магазина WooCommerce.
если мне надо написать какое то хитрое веб приложение — Laravel.
для API предпочту NodeJS или Go.
если что то системное то мб Python/Go.
тут мб куча факторов:
— мода на тот или иной фреймворк/язык
— компетенции команды
— адекватность инструмента задаче
Всегда приходится делать выбор исходя из множества факторов. Идеальных инструментов под все задачи пока не придумали.
VolCh
05.08.2018 09:38+1Может и не происходить, это может быть задел на будущее. Точнее, если произошёл, то убиравший просто ошибочно принял нужный код за лишний.
С существующими решениями двойная ситуация: бизнесу может очень дорого обойтись изучение cсуществующих решений, особенно если в итоге будет принято решение писать-таки интернет магазин на чистом ларавеле. Ну или будет выбрана магента, разработчик потратит какое-то время на минимальное изучение, что-то сделает особо не вникая, в итоге будет криво, небезопасно и т. п., хотя на ларавеле было бы нормально, потому что разработчик его уже хорошо знает.
Samouvazhektra
04.08.2018 22:56+1Но бывает что причина только одна… разработчику хочется уталить свою жажду красоты >и показать что он знает что такое наследование… и вот мы получаем кучу бесполезных >классов, наследований и лишних слоев абстракции…
Вот чего-чего, сколько разных архитектурных косяков и глупых решений я ни делала, но никогда не было мыслей воспользоваться наследованием (или каким-то паттерном) только для того чтобы показать какую-то красоту и то, что умею наследование (или какой-то паттерн). Мне кажется такое впечатление создается от того, что не возможно узнать в действительности почему и зачем так делалось… какие-то другие планы или изначальные требования, или недостаточное понимание требований разработчиком… Или просто ваше непонимание причин их использования.
maxxannik Автор
04.08.2018 23:15Везунчик. Я тоже до последнего времени страдал только от Говнокода и Хардкода. Но оно было не так затратно. А вот Шизокод долго не мог осознать. Ну а его проявление в куче классов пока что встретил лишь 1 раз. Но подумалось что причина та же самая… отсутствие желания у разработчика следовать стандартам и лучшим практикам, использованию существующих методов и функций, а вместо этого написать 10 своих классов и потом раскидать их по всей системе через 3-4 наследования в каждом. Насчитал более 300 строк кода и более 10 классов, которые можно было уместить в 3-4 строки кода и уже существующие методы внутри платформы. Решил что природа этого заболевания та же самая что и желание разработчиков писать свои CMS/фреймворки )
Но это не точно )
Hardcoin
05.08.2018 16:01Где-то и функция-портянка на 300 строк норм,
В случае php она никогда не норм. Всегда можно выделить какой-то независимый кусок с читаемым именем.
wlr398
04.08.2018 20:13+1Можно ещё выделить разновидность шизокодинга — криптокодинг.
Некоторые языки позволяют сооружать совершенно страшные конструкции, в которых даже автор спустя время не сразу разберётся. Хотя при большом желании в любом языке можно накриптокодить.
otvorot2008
04.08.2018 20:57+9Шизокодинг
МыслетопливоПохоже, принцип бритвы Оккама нарушен уже в самой статье, хотя и упоминается в ней)
VolCh
04.08.2018 21:071) видимо имелось процедурное программирование, а не функциональное. Слово function PHP оно про процедурное прежде всего.
2) и ПП, и ФП, и ООП позволяют создавать, или даже созданы для создания абстракций. Было бы желание, ООП тут не виноватое.
3) ООП было создано для уменьшения потребления «мыслетоплива» в процессе работы над конкретной задачей за счёт инкапсуляции. Грубо говоря, если в знакомом приложении для решения задачи нужно разбираться больше чем в трёх слоях наследования или композиции, значит или задача недостаточно декомпощирована, или инкапсуляции по сути нет.VolCh
04.08.2018 22:184) но часто мне хватает Синглтонов, статических методов и stateless
Не очень понятно, что тут значит stateless, но синглтоны и статические методы обычно сильно усложняют понимание, тестирование и отладку. Основное разумное применение статических методов в PHP или реализация порождающих паттернов, или обход отсутствия автозагрузки функций. Всё остальное, обычно, обходится путями более пригодными для дальнейшей поддержки.maxxannik Автор
04.08.2018 22:37> Не очень понятно, что тут значит stateless
Это значит что класс не хранит состояние (переменные, константы и т д) и применяется только для инкапсуляции методов. Такой стиль часто встречается в WordPress (например некоторые классы в WooCommerce). Обе платформы №1 в своих сегментах. Ну и в некоторых закрытых Enterprise проектах такое встречал.
Сам часто пишу именно в этом стиле. Птм что он с одной стороны дает возможность быстро писать код на старте не думая о будущем, а с другой стороны потом быстро переходить в любой из стилей по необходимости: Синглтон, классы с наследование, ФП и т. д.
Это из моего опыта: Enterprise, eCommerce, веб-приложения… на разных платформах: flat php, Laravel/Symfony, WP/WooCommerce…
Идеальный мир условно достижим на MVC фреймворках типа Laravel/Symfony. Но это в теории. На практике серьезных проектов на их базе не встречал. Только API и простые микросервисы/веб приложения.Samouvazhektra
04.08.2018 23:07-2кгм… брать WordPress за образец...
Идеальный мир условно достижим на MVC фреймворках типа Laravel/Symfony. Но это в теории. На практике серьезных проектов на их базе не встречал
<_sarcasm>Действительно, какие могут быть серьёзные проекты на Laravel и Symfony… весь мир ведь вертится вокруг вордпресс… </_sarcasm>
После этих строчек стало всё понятно :-) Вам предстоит еще долгий путь
maxxannik Автор
04.08.2018 23:18+2> После этих строчек стало всё понятно :-) Вам предстоит еще долгий путь
дай то бог )
надеюсь что вы уже не в конце своего пути )
TaskForce141
04.08.2018 22:03Глобальное потепление — это плохо.
Мой манифест простой:
- давайте меньше глобальное потепление
Не совсем понятно, о чем статья. На выбранный стиль изложения можно было бы закрыть глаза, но я не увидел основного — предложенного решения названной проблемы. По сути проблема названа абстрактная, а в ней — возможные причины, с которыми и можно было бы согласиться, но не в предлагаемой формулировке. Например, точно НЕ в такой:
В функциональном стиле проще наговнокодить, но шизокодить там сложно.
На мой взгляд, все описанные в статье проблемы с кодом так или иначе можно объяснить одним — допущением их существования разработчиком, который этот код писал. Решаться, следовательно, они должны через создание препятствий, которые будут «мешать» разработчику идти на подобные допущения. Опускаю случаи, когда наличие упомянутых проблем может быть в определенной степени оправдано:
— недостатком квалификации, обусловленный отсутствием опыта, а не слабоумием
— недостатком ресурсов (время/деньги), потому что чистый код — это хорошо, но порой решение нужно уже вчера
В остальных же случаях:
— проблема «хардкода» и нарушений стиля решается через применение практики code review с соответствующими требованиями к тем, кто их проводит
— «тем больше точек отказа, тем больше ошибок» — через применение практики непрерывной интеграции; при этом важно не просто наличие тестов как таковых, а наиболее полное покрытие кода, которое позволило бы выявлять неочевидные ошибки
— переизбыток/недостаток абстракций, проблемы с архитектурой — зависят от опыта конкретного разработчика на конкретной должности; решения для общего случая, на мой взгляд, нет
Во всех случаях в целом, особенно в последнем, проблемы нередко могут совершаться из-за наличия уже существующих, появившихся из-за неверно принятых решений в прошлом. В итоге их количество растет подобно снежному кому, потому что сделать «не идеально» получается правильнее (в контексте ограниченных ресурсов), чем менять архитектуру и переписывать все с нуля.
Суть манифеста, думаю, я понял, просто вместо простого перечисления проблем хотелось бы слышать:
— с предложением решений называемой проблемы
— без лексики, пригодной для «курилки»
— с логическими рассуждениями, когда в конкретном стиле чаще встречаются ошибки по конкретным причинам, а не «просто потому что»maxxannik Автор
04.08.2018 22:03+1> без лексики, пригодной для «курилки»
можно пример лексики которая не пригода и пригодна?
reimax
04.08.2018 22:46+1пишут собственные CMS/фреймворки
то есть любая новая cms или фреймворк — зло?maxxannik Автор
04.08.2018 22:54-1это смотря с какой стороны посмотреть :)
думаю ничто не зло в абсолютном выражении. везде есть частичка добра )
но я встречался с проектами на своих CMS/фреймворках, где 80% времени приходилось тратить на угадывание логики ее авторов. а это не просто и очень дорого )
потому для себя решил что лучше буду работать с каким то платформами из топ-3, а лучше топ-1 )reimax
05.08.2018 00:39странное мнение.
это смотря с какой стороны посмотреть :)
и
Решил что природа этого заболевания та же самая что и желание разработчиков писать свои CMS/фреймворки )
нужно как то определится, либо частичка добра, либо заболевание…Iqorek
05.08.2018 01:03нужно как то определится, либо частичка добра, либо заболевание
Про CMS не скажу, но фреймворки обычно пишутся, для того что бы кто то другой мог переиспользовать какую то часть кода под себя. По факту, если вы не будете заниматься продвижением своего фреймворка, о нем никто не узнает и никто кроме вас его использовать не будет. Смысл тратить время?VolCh
05.08.2018 09:51Фреймворки обычно пишутся для того, чтобы создавать новые приложения без написания одного и того же кода. И обычно не для абстрактного «кого-то», а для себя. Потом может быть принято решение опубликовать фреймворк для общего использования, но это не обязательно.
Iqorek
05.08.2018 13:02Угу, но подразумевается, что мы один раз напишем и будем использовать еще раз. В реальности получается что в 90+% случаев никто не использует это вторично, каждый новый проект вы говорите себе, нет, этот фреймворк не очень вышел и он устарел, вот сейчас у нас есть шанс написать все с нуля и на этот раз правильно, красиво и по феншую. Так же подразумевается, что на написание фреймворка мы не тратим дополнительного времени и получаем его бесплатно, но так ли это на самом деле? Вместо того что бы решать конкретную задачу, мы пытаемся ее решить не самым простым способом, а самым гибким, так что бы код потом можно было переиспользовать и это берет дополнительное время, иногда во много раз больше, чем требовалось на простое решение задачи, но мы говорим ладно, сегодня построим велосипед, зато завтра быстро поедем.
У вас другой опыт написания фреймворков?VolCh
05.08.2018 23:12Такого не встречал, чтобы писали новый фреймворк с каждым новым проектом. Обновление, развитие фреймворка- да.
Нет, не подразумевается. Подразумевается, что сейчас мы вложимся в создание/развитие фреймворка, зато следующие проекты будем делать быстрее. Инвестиции типа.Iqorek
05.08.2018 23:58Новые проекты не каждый день же появляются. Через год, два фреймворк обрастает такой бородой… Как это бывает, в начале была задача 1, под нее сделали архитектуру и все хорошо спланировали, потом задача немного поменялась, градусов на 178. Код написан, архитектуру уже так просто не исправишь, в бой идут костыли и пластырь, переписывать некогда, дедлайн то никуда не делся. Сентиментов к фреймворку уже никто не испытывает.
Подразумевается, что сейчас мы вложимся в создание/развитие фреймворка, зато следующие проекты будем делать быстрее. Инвестиции типа.
Какой процент инвестиций по факту отбили?
зато следующие проекты будем делать быстрее
Откуда вы знаете, какие задачи вам нужно будет решать завтра? Вы же не делаете одно и тоже. Может задачи завтрашнего дня, лучше решать завтра? Хотя бы будет известно, что нужно сделать, плюс завтра у вас будет больше опыта и вы сможете подобрать лучшее решение, чем сегодня?VolCh
06.08.2018 00:25Фреймворки обычно делают не на первом, и даже не на втором проекте. Когда замечаешь, что из проекта в проект пишешь один и тот же по сути инфраструктурный код, то и наступает время задуматься о фреймворке. Сторонний или свой в целом детали.
По хорошему свой фреймворк не должен решать задачи завтрашнего дня. Он должен аккумулировать удачные решения задач вчерашних, и иногда внедрять сегодняшних.Iqorek
06.08.2018 10:30Инфраструктура, общие библиотеки это еще не фреймворк. Фреймворк это то, что обязывает вас писать код каким то конкретным способом и больше никак. Например соблюдать naming convention, чтобы «магия» фреймворка сработала или имплементировать какой то интерфейс, что бы ваш код можно было «воткнуть» в фреймворк. И общие библиотеки и фреймворки для повторного использования какого то кода, но разница между ними, что с общими библиотеками вы пишете свободный код, который делает вызовы из общих библиотек. Фреймворки же ограничивают свободу действий. Несмотря на то что можно сказать что фреймворки стандартизируют, но не все задачи можно привести к одному стандарту и получается что иногда вы будете вынуждены писать костыли, что бы остаться в рамках фреймворка.
При этом я не утверждаю, что фреймворки это зло, никогда так не делайте. Я говорю делайте это только когда это что то дает.VolCh
06.08.2018 10:38Я знаю чем отличается фреймворк от библиотеки. Но не всегда фреймворки ограничивают свободу действий, бывает, что ты просто волен выбирать использовать что-то из фреймворка, или делать свою реализацию. Грубо, отнаследовался от класса фреймворка и не надо больше ни о чём думать, магия, но если поведение фреймворка не устраивает, то просто не наследуешься, а пишешь всё сам, пока не придёт понимание, что эту логику пора во фреймворк перенести.
Iqorek
06.08.2018 10:56Каждый волен по своему определять, но фреймворк это прежде всего каркас, нет каркаса, нет ограничений, нет фреймворка.
Библиотека для логирования, это всего лишь библиотека, она ничего не ограничивает и не имеет каркаса, но например реализация патерна dependency injection, это фреймворк, потому появляются ограничения на формат кода.VolCh
06.08.2018 12:04Каркас необязательно должен быть ограничивающими рамками, он может быть несущими конструкциями, на которые по желанию навешиваются более-менее стандартные элементы, но такой каркас не запрещает в нестандартных случаев создавать самонесущие элементы или воздвинуть рядом новый каркас.
reimax
05.08.2018 13:01VolCh опередил с ответом. я думаю, что далеко не все разработчики пишут фреймворки, чтобы о них потом узнали. ну точно не ради этого.
Iqorek
05.08.2018 13:19Около лет 10 назад в интернетах прогремела статья, не смог найти оригинал, пишу по памяти, «10 признаков настоящего программиста» и один из пунктов был, «вы написали минимум один фреймворк», любой кто читал эту статью воспринимал этот пункт как «вызов принят». Начался какой то ад, люди перестали решать задачу и начали думать а как же мне тут запилить фреймворк, получалось плохо, 3 строчки кода превращались в 300, потому что 3 строчки это не фреймворк, это курам на смех, но если их обернуть несколько раз слоями абстракций будет самое то.
так же см ответ
Olevv
04.08.2018 22:49PSR для того и сделали, чтобы код был понятным, хоть ты из Канады, Индии, Китая, странно когда команда приняла другой стандарт, это как бы вызов сообществу, фигню вы придумали и нам это не удобно.
С другой стороны плохо простой код разбивать на 5 классов в каждом из которых 3-4 метода по 3-4 строки, со множеством бесполезных наследований, когда можно обойтись одним или двумя с минимальным наследованием или даже без наследования если его можно избежать.
А что в этом плохого, если класс и методы выполняют ровно то что и должны?
Можно разбить класс на 10 методов, главное интерфейсы не перегружать, а если методы непонятно названы, и тебе нужно переходить в метод чтобы понять что он делает, тогда вопрос к автору кода, а это уже другая история.
Понятный и поддерживаемый код это когда в команде разрабоки 80% его понимают, всегда найдутся те кому чужой код говно.maxxannik Автор
04.08.2018 22:51+1Если родительский класс переиспользуется — ничего плохого.
Ключевое слово — излишество. Когда можно обойтись без наследования — надо обойтись без него. Птм что лишний слой абстракции — это нарушение бритвы Оккама. И там много негативных последствий.
Речь не о том что наследование это абсолютное зло и плохо. А о ситуации когда оно делается без причины. Если не встречались с таким — бамбалейо. Поздравлямба и все такое. Все впереди )
KirEv
05.08.2018 00:07в статье ориентир на какой-то идеальный мир, где лишь код и ничего более…
вернемся чуть дальше — а там стоит менеджмент, и очень часто в развивающейся компании нужно срочно вносить некоторые изменения, одни критичны для стабильной работы, другие — не очень, но задевают несколько мест программы\логики\етс., в таких условиях нужно чтобы работало, тупо чтобы работало, и побыстрей, никому из выше стоящих не интересна чистота кода, я уже не говорю про стартапы, где лепится черт и что, куча логик, по многу раз переделывается, лишь таск «рефакторинг» где-то в будущем даст время привести все в порядок.
davidovsv
05.08.2018 00:27-1Просто уже пора слезть с PHP и начать использовать нормальные языки и фреймворки в точности для того, для чего они были созданы :)
SergejSh
05.08.2018 06:25Чем же вам PHP не угодил? Он ведь создан для Web разработки.
И список нормальных языков для Web.davidovsv
05.08.2018 12:56PHP был создан как язык шаблонов, а не как язык разработки. SSI имел ограниченную функциональность, а в Perl, на котором тогда делался веб-бэкэнд, нормального языка шаблонов не было. Как замена print из кода в Perl он был хорош, чтобы по-быстрому лепить странички. Но потом из него зачем-то стали делать полноценный язык. При том фундаменте, который был заложен в PHP вплоть до версии 3.x, на нём слишком просто писать плохо, что и происходит до сих пор.
Сейчас, к счастью, ситуация с языками для веб гораздо лучше. Есть отличные языки шаблонов (и, главное, быстрые парсеры), например, шаблоны в Django (и его расширение Jinja2, для которого есть поддержка не только в Python). Для легких случаев есть Mustache.
Насчет замены PHP как языка для веб-бэкэнда: Python (Django, aiohttp), JavaScript (он ужасен, но nodejs сделал из него хороший инструмент для «херак-херак и в продакшен»), Java (главное, не тащить J2EE-стэк — сейчас есть хорошие легковесные фреймворки), функциональные языки (много разных вариантов на выбор).SergejSh
05.08.2018 15:35+1Из нормальных языков вы еще C# не указали.
По поводу PHP. Это инструмент который позволяет относительно быстро (быстрее чем Perl) обучиться и начать писать работающий код. Качество кода напрямую зависит от самого программиста и культуры разработки в коллективе где он работает. Можно и на строго типизированном языке говнокод написать.
Вообще же выбор языка как инструмента очень важен.
VolCh
05.08.2018 23:15«был создан», «стали делать». Что сейчас не устраивает? Ну и на PHP реализованы свои языки шаблонов типа Smarty или Twig. Заменить PHP на бэкенде можно чаще всего, но зачем?
davidovsv
05.08.2018 23:48PHP меня ничем не устраивает. Не нужно его заменять, лучше сразу обойтись без него. Зачем себя мучить, если есть нормальные языки? Мой комментарий был об этом.
VolCh
06.08.2018 00:29+1Чем PHP ненормален тогда? Есть нюансы, но они есть у всех языков. Нет чего-то что есть в некоторых других, но есть и то, чего нет в некоторых других. Есть плюсы и минусы и для бизнеса, и для разработчиков. Но так же и со всеми языками.
davidovsv
06.08.2018 00:35Чтобы лучше объяснить, позвольте узнать, какие языки вы используете и как долго?
altrus
06.08.2018 04:29+1Какая разница, что человек использовал? От этого зависит «ненормальность» PHP?
Объясните его минусы по сравнению с другими распространенными языками для wеb программирования. И сразу можно указывать минусы тех языков, по сравнению с PHP.davidovsv
06.08.2018 11:05Проще всего объяснить на сравнении. Но чтобы сравнение имело смысл, оно должно быть с языком, с которым человек знаком. Абстрактные «в этом языке лучше это, а в том то» не работают, пока не начнешь на нём писать. Для меня PHP был адом (до него мой бэкграунд был на C/C++, Perl и Java — для веб разработки). Но потом ко мне попал проект на Python/Django, и я офигел от того, насколько удобным и продуманным может быть язык и фреймворк, и больше на PHP не писал.
altrus
06.08.2018 11:11Это ваше личное субъективное предпочтение, и вы так и не обозначили ни одного объективного критерия, по которому PHP был бы «ненормальным»
davidovsv
07.08.2018 00:13Разумеется, это моё субъективное мнение. На объективность не претендую. Чуть ниже в комменте подробно изложил своей мнение.
VolCh
06.08.2018 07:40Сейчас основные PHP и TypeScript. А так много было, от ассемблера и Форта через C* и Java до Ruby и Python. Но вот как-то последние лет 20 PHP основной, может пару лет на нём не писал, но возвращался.
davidovsv
07.08.2018 00:11Чтобы ответить на ваш вопрос, сравню ключевые (для меня) аспекты PHP с Java и Python (для веб я их использовал больше всего). Остановлюсь на двух: простоте входа в разработку и базовых принципах языка. Есть и другие, но эти, пожалуй, сильней всего влияют на моё субъективное восприятие языков.
- Простота входа в язык и разработку. Чем проще, тем хуже, т.к. простой вход позволяет начать кодить, не особо разбираясь в разработке вообще. Как результат, большое количество чужого ужасного кода, с которым приходится работать. Это про разработку больших систем. С точки зрения быстрой разработки странички, которую никто никогда не будет поддерживать и повторно использовать, быстрый вход как раз плюс, но это не моя ниша.
PHP в этом плане слишком простой, что привело к появлению огромного количества недо-библиотек и недо-фреймворков, использование которых заставляет страдать. То же самое можно сказать о легаси-коде, которого в больших системах много.
На Java гораздо сложнее начать писать, и код на Java гораздо лучше (в среднем), чем код на PHP — я говорю про чужой код, который приходится поддерживать в больших системах. Свой код никто не мешает писать хорошо на любом языке.
Python тоже довольно прост, но, в отличие от PHP, его синтаксис изначально хорошо продуман и элегантен. Это приводит к тому, что на Python можно научиться писать быстро сразу хорошо. Да, разумеется, плохой код на Python тоже имеется (в больших системах), но его на порядки меньше. Т.е. вот если на PHP хороший код встречается как исключение, то на Python скорее наоборот — иногда встречается говнокод среди вполне годного кода. (Субъективно, без количественных метрик.)
- Базовые принципы языка. Язык создается на основе каких-то принципов, также язык создается человеком (группой людей), у которго есть определенные ценности и характер, что влияет на результат. PHP был создан, как я уже писал, как удобная замена Perl и SSI. С этой ролью он отлично справлялся (после того, как я первый раз увидел PHP, я больше ни разу не писал веб на Perl и SSI, это был настоящий прорыв). Стандартную библиотеку PHP наполняли стихийно — понадобилась функция, добавили. Там было (и есть?) много близких функций с разной нотацией. Потом стали добавлять объекты и классы, потом переделали, потом… (потом я ушел на Python, так что 6-ую версию уже не застал). В итоге (с учётом п.1) на PHP каждый писал и пишет, кто во что горазд. Язык не настаивает на том, какой должен быть код, как должны быть структурированы модули (и нужны ли они вообще) и т.п. Позже эти принципы были добавлены, но они не жесткие, поэтому для простоты и быстроты от них отказываются. Дополнительные проблемы создает динамическая типизация, которая в PHP рождает много проблем на этапе отладки. Результат: много плохого кода.
Java в этом плане дает гораздо меньше свободы. Плюс статическая типизация обнаруживает много тупых ошибок на этапе компиляции, а не в продакшене. Плюс принципы ООП, которые можно нарушить, но это настолько не удобно, что для этого нужна некоторая квалификация, что снижает вероятность ошибок (см. п. 1). Java не делали, чтобы можно было быстро лабать странички, её создавали для упрощения ООП-разработки (по-сравнению с C++, у которого достаточно высокий порог входа) и дальнейшего развертывания кода.
Python был создан, чтобы програмировать снова было в кайф. Базовые принципы языка Python таковы, чтобы на нем было удобно программировать. На нём просто писать хорошо. В Python так же хорошо реализованые такие аспекты языка, как динамическая типизация (она немного строже, чем в PHP, и ошибок, с ней связанных, меньше), встроенные типы (нет с ними путаницы), функциональные возможности. Это привлекает в Python-сообщество квалифицированных программистов, которые пишут хороший код.
Использование грамотно спроектированных и разработанных фреймворков во многом спасает ситуацию. В PHP они, вероятно, тоже есть. (Автор статьи положительно пишет о Wordpress, но говорить так, можно лишь сравненивая с другими PHP-фреймворками, продуктами и библиотеками. Остальные хуже, но Wordpress — это тоже адово адище, если сравнивать с действительно нормальными, например, Django. Я соглашусь, что не вполне корректно сравнивать пакетный продукт и фреймворк для разработки. В данном случае я говорю о Wordpress как о стартовом пакете для дальнейшей разработки продукта.)
Мой собственный опыт таков, что стоило мне уйти с PHP на Python, как количество головной боли в моей жизни, рожденной чужим кодом, с которым я должен дружить, стало исчезающе малым. Прямо волшебство.
Ну а на Java, после того, как туда добавили дженерики и функциональщину, асинхронность и пр., после того как программисты наелись корявым EE и паттернами разработки, а также посмотрели, как может быть коротко, просто и ясно на других языках, на Java стало гораздо приятней писать.altrus
07.08.2018 04:29А причем тут фреймворки, если разговор о языке? Фреймворк это модель, которую пишут какие-то программеры в силу своего развития и желания привязать других к своему продукту. Фреймворк не язык. На Python наверняка тоже написано много корявых фреймворков. Если Oracle или Google захотят написать CMS на PHP, они сделают это как надо.
Сравнивать PHP и Java это как сравнивать разговорный язык, и язык делегатов какого-нибудь математического симпозиума.
Вы сможете переписать простой «Hello world» блог на Wordpress на Java? Не на JSP, потому что это не Java, а на сервлетах. Просто представьте, как вы это делаете, и в добрый путь.davidovsv
07.08.2018 11:54Потому что это всегда разговор не только о языке, а об окружении, которое приходит (навязывается) с языком, а также о сообществе, которое языком пользуется и на этот язык влияет.
Язык определяет, какой код и как он будет написан. Также он косвенно определяет, кто будет на нём писать. Условно сравнивая с человеческими языками, можно говорить на языке из трёх матерных слов и вполне выражать всё, что нужно в повседневной жизни, но если посмотреть, какое окружение будет вокруг этого языка и кто будет на нём говорить, я бы в таком окружении жить не захотел.
Про ваш вопрос о простом блоге на Java: если говорить просто о блоге — да, это простая задача, не вижу ничего сложного (без JSP и даже сервлетов, хоть они и часть стандартного Java EE, просто есть лучшие варианты как для ядра, так и для frontend — можно даже вообще без серверных шаблонов обойтись). Если же говорить о переписывании Wordpress как о платформе, да, это задача сложная, но дело не в Java или PHP, а в сложности сделать архитектуру платформы хорошей (скопировать архитектуру Wordpress на любом языке — дурная идея).
- Простота входа в язык и разработку. Чем проще, тем хуже, т.к. простой вход позволяет начать кодить, не особо разбираясь в разработке вообще. Как результат, большое количество чужого ужасного кода, с которым приходится работать. Это про разработку больших систем. С точки зрения быстрой разработки странички, которую никто никогда не будет поддерживать и повторно использовать, быстрый вход как раз плюс, но это не моя ниша.
Zet_Roy
05.08.2018 01:30- Блог на Symfony. При том что весь мир для этого использует WordPress.
- Интернет-магазины на Laravel, при том что есть WooCommerce (№1 в мире), Magento (тоже хорошо), 1С-Битрикс (на худой конец, лучше чем Laravel)
Полный бред, выглядит как реклама WordPress.
SergejSh
05.08.2018 05:001)Не очень согласен с разделением кода на категории.
Стиль написания какой бы он ни был в моем понятии не делает код Говнокодом.
А вот излившее усложнение кода очень даже.
Но кроме усложнения могут быть наверное еще признаки говнокода (тут надо подумать).
2) Есть такой принцип Кiss.(делай это как можно проще). В википедии при описании его приведены цитаты нескольких известных людей и они тоже подходят как илюстрация к теме данной статьи. При этом идея несколько шире чем принцип Оккамы( Не плоди лишних сущностей).
DmitriyDev
05.08.2018 08:29В статье очень не хватает примеров плохого кода.
Например, прослойка между сторонним фраймворком и проектом, состоящую из пустых классов, это плохо или нет? Дополнительная обстракция, но может сэкономить кучу нервов при срочном апдейте.
barbos6
05.08.2018 08:36Код превращается в шизокод тогда, когда исполнитель начинает пользоваться паттернами КОП — Костыльно-Ориентированного Программирования.
С его костылированием, инкостыляцией, поликостылизьмом.
adeptoleg
05.08.2018 14:01А по моему чтоб не было хардкода не манифесты писать надо и явно не программистам а подзатыльник прописать надо тем кто дышет в спину, торопит, стоит над душей а потом удивляется с честным лицом а как так получилось. Ну или продайте нервов километров 100500 куплю бесплатно без смс :)
Audiophile
05.08.2018 14:24часто мне хватает Синглтоночасто мне хватает Синглтонов, статических методов и statelessв, статических методов и stateless
Синглтон — антипаттерн, статические методы — то ещё зло, и использовать их стоит разве что для альтернативных конструкторов. В авторе заметен большой поклонник Wordpress (который в плане кода является идеальным примером того, как не надо делать).
alex005
05.08.2018 18:19На самом деле, если есть ревью кода, который коммитит программист, и есть тот, кто понимает принципы чистого программирования, то проблемы грязного кода решаются просто.
picul
06.08.2018 12:21Грех №0 — хайпокод. Это когда начитываешься кучи статей с «манифестами», и руководствуешься ими, а не здравым смыслом.
geher
Я бы заметил, что шизокод поощряется. Слишком часто логика работы программы теряется за необозримой иерархией классов и функций, которые были объявлены и написаны только потому, что "не более трех (пяти) строк на функцию" и "не более трех (пяти) методов на класс", а не исходя из назначения класса или функции.
Все-таки частенько многостраничная простыня одной функции понятнее мешанины кода, разбитого на функции только из соображений формальных количественных метрик.
maxxannik Автор
Вроде бы мы в одном русле мыслим. Речь именно про проблему множественной иерархии классов.
Там где можно обойтись 1 классом Синглтоном — видишь вдруг наследования классов бесмысленных и беспощадных которые делаются 1 раз в рамках конкретной иерархии без переиспользования. И все их можно было бы без вреда соединить в 1 классе который решает свою задачу.
Там где можно обойтись 1-2 наследованиями — видишь 3-4 наследования из множества микроклассов.
Где то встречал фразу «не удачные абстракции». Но все ли одинаково поймут это )
maxxannik Автор
> Я бы заметил, что шизокод поощряется
Вот тут не понял. Хочется узнать личную оценку. Поощерение шизокода это хорошо или плохо?
geher
Поощрение шизокода — это плохо.
Все-таки бездумное строгое следование формальным метрикам до добра не доводит, особенно если граница допустимого очень занижена (три строки на функцию, как рекомендуют (а порой и требуют) некоторые — как-то маловато будет).
eGGshke
Мне кажется, что вы из крайности в крайность прыгайте. Простыня всегда будет читаться плохо. Но если следовать методикам: сначала код который работает, потом рефакторинг. В результате получится читаемый, рабочий, надёжный код.
geher
Простыня всегда читается плохо. Но она всегда читается лучше бездумно разорванного на фрагменты кода. Это как большая книга одним свитком и она же, порванная случайно на одинаковые кусочки.
Все-таки разбиение кода на модули и функции должно обуславливаться исключительно логикой алгоритма, а не формальными требованиями. И если имеется логичный связный блок в десять строк, то не стоит его разрывать в угоду правила, требующего не более трех строк.
Hardcoin
Логичный связанный блок на десять строк — да. А связанный блок на 300 строк — это кошмар. Если между первыми и последними строками есть связь — то пользоваться им невозможно. Поддерживать и дорабатывать крайне тяжело.
roscomtheend
Зато в случае реверса одна функция на 300 строк — подарок, 100 функция по 5 строк (в сумме уже не 300, и это без учёта заголовка) — наказание.
Hardcoin
Какого реверса? Вы имеете ввиду Git reverse commit? Какая разница гиту? Да и сам юзкейс непонятен. Что это за коммит, который затронет 100 функций? Как часто вы это делаете? Зачем?
roscomtheend
Я имею в виду что зачастую нужен реверс-инжиниринг. Это в теории или на сайтиках проще выкинуть, а иногда нужно разобраться как оно работает, имея крайне ограниченный набор (типа исходников после обфускации). Да, это не часто, но бывает. Не всем интересны задачи «наляпать во фреймворке формочек», это выглядит как точить одни и те же гайки на конвейере.
Hardcoin
Моя текущая работа наполовину состоит из такого реверс-инжиниринга. Я бы предпочел 10 последовательных условно-чистых функций с читабельными именами. Но нет, 300 строк "подарка", с такими неадекватными ифами, что я, при необходимости небольшой доработки, через раз выкидываю и пишу заново.
Не потому, что понять нельзя — понять можно, "подарок" же. А потому что дерево выполнения огромно, нереально внести исправления так, что бы не было хитрых неучтенных побочных явлений. Ладно хоть код достаточно старый (часть его — десятилетней давности). Искренне надеюсь, что больше так никто не пишет.
geher
Учитывая "типа исходников после обфускации" про "функций с читабельными именами" можно не мечтать.
roscomtheend
Интерфйсы и экспортируемые функции рулят — там имена хоть вменяемые и служат отправными точками. В остальном «спасибо, что не машинный код».
65536
Сложно представить неделимый монолит на 300 строк. Такое иногда случается, но всегда можно что-то вынести за скобки, даже если за этим не стоит никакой логики. Например, редко редактируемый фрагмент какой-то просто убрать в другой метод чтобы не мешался и не заставлял скроллить. Самым большим препятствием этому может служить использование большого количества общих переменных этой простыни и придется их большим списком в этот метод передавать и списком же возвращать.
А эти постулаты типа «метод должен быть не больше 20 строк» могут быть только пожеланиями, но никак не причиной реструктуризации кода на ровном месте. Разбиение программы на классы и методы в первую очередь должно быть подчинено логике самой программы, а не каким-то пожеланиям стилистическим.
maxxannik Автор
Готов согласиться. Проблема только в том что есть логика программы и здравый смысл?
Матеры разработчики это осознают благодаря эмпирическим знаниям.
Задача — найти некое описание, которое будет формализовано и понятно джунам/мидлам. Джуны как правило вообще не одупляют что почем. А мидлы часто буквально воспринимают рекомендации и начинают пилить 100500 функций на 3-4 строки и 55 классов с 1-2 методами — птм что так написано в библии Чистого кода.
Причем в РФ из за дефицита разработчиков часто мидлов и ставят сеньорами или тим лидами (из принципа — а лучше пока никого не нашли). Так и образуется рассадник шизокода, который спускается сверху теми кто до старшинства еще умом не дорос.