Есть 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, прежде чем изобрети очередной никому не нужный велосипед на костылях
- давайте писать меньше шизокода
- давайте учиться соблюдать принцип Бритвы Оккама и не усложнять код без причины
- давайте экономить свое мыслетопливо и своей команды
Ну и буду рад комментариям как в поддержку манифеста, так и его критике.
