Некачественный код, с моей точки зрения - это программный код в моменте работающий, но крайне неэффективный или неподдерживаемый в на длинных дистанциях. Это не такой программный код, который вредит системам прямым образом или замышляет что-то нехорошее. Но в то же самое время, это такой код, который имеет скрытые дефекты - которые приводят к проблемам спустя какое-то время, или в каких-то обстоятельствах.
Плохой программный код - это часто код, который сделан исключительно из корыстных побуждений. Такой код рождается в ситуациях, когда скорость получения результатов ставится превыше всего остального. Превыше внутреннего голоса совести и критических взглядов на вопросы качества. Его источником могут быть как "горящие" супер-срочные проекты, так и проекты над которыми работают программисты со слишком большой любовью к деньгам. В моменте, а именно к точке сдачи проекта заказчику, такие проекты несомненно показывают решение поставленной задач. Но настоящая боль наступает потом - когда в проекте накапливается какое-то количество данных, либо же требуется дальнейшее усовершенствование программного продукта.
Я считаю, что программист должен любить свою работу. Важно любить программный код, который ты пишешь. Только такой подход позволяет получать хорошие результаты. Ну а если тебе не нравится программировать, или бесит проект который ты делаешь, не лучше ли сменить профессию?
Так вот. Как я считаю, лучше своевременно распознавать плохой код, и заведомо отказываться от его написания. Это касается как кода, который выходит из рук уважаемых коллег, так и слетающего с собственной клавиатуры. Умение вовремя опознать и предотвратить внедрение такого кода в жизнь, бережёт хрупкую психику программиста от ненужной повторной работы. И вот некоторый список признаков, который с моей точки зрения ему присущь.
Отсутствие внятной структуризации 🔃
Программирование - это творческий процесс упорядочивания. Это талант описания окружающего нас мира, и способность к трансляции некоторых представлений о мире в программы. В конечном итоге, любой физический объект или процесс (с точки зрения программирования, например в парадигме ООП) - это условный класс с набором полей и методов. Чем более очевидно такая абстракция упакована в программный код - тем такой код лучше.
Некоторые программисты (особенно начинающие) периодически грешат лёгким отношением к вопросам структуры и архитектуры приложения. Таким образом, иногда рождаются "супер-универсальные" методы / функции / классы, условным размером в несколько тысяч строк. В результате, внутреннее поведение некоторой программы перестаёт понимать как сам программист, так и его коллеги / партнёры.
Хороший стиль - это декомпозировать задачу на более мелкие задачи. Разбивать сложный код на более простой код. И в конечном итоге, создавать понятные структуры и модули - простые и удобные. Не наоборот.
ООП головного мозга 🤯
Другая крайность в вопросах структуризации - чрезмерная любовь к упорядочиванию и декомпозиции. К сожалению, излишне детальное разбиение объектов на под-объекты, является ничуть не лучшей практикой, чем полный хаос в программном коде. Потому что, бесконечная декомпозиция, в конечном итоге, порождает такой же точно хаос и отсутствие ясной структуры.
В какой-то момент, яростному приверженцу парадигмы объектно-ориентированного программирования может показаться, что его программа недостаточно "объектно-ориентирована". Эти мысли приоткрывают двери безумия, и толкают программиста в бесконечные дебри дробления классов и структур на более мелкие составные части. В какой-то момент, это уже не остановить - и программа превращается в целый ворох разрозненных элементов, бесконечно вложенных друг в друга.
Любители 6 НФБК - так же передаю большой привет из этого пункта!
Золотой молоток 🏆
Предположим, что некий программист успешно освоил парочку работающих паттернов. И влюбился в этим приёмы. Шло время, он всё применял и применял эти паттерны, получая предсказуемые результаты. Руководство хвалило его за высокое качество, и в какой-то момент программист уверовал во всеобъемлющую универсальность выбранных им инструментов. И вот, по удивительному стечению обстоятельств, теперь эти паттерны можно найти в абсолютно всех его последующих программах. Круто? Нет, не круто!
Золотой молоток - это привычка освоить пару-тройку работающих подходов к программированию, и тащить их в любые проекты. Даже если проект сделан принципиально в другом стиле. Даже если эти подходы и инструменты совершенно не нужны в этих проектах. Абсолютно никакие внешние факторы не имеют значения - сложно остановить влюбленного программиста, идеализирующего несколько работающих в его руках техник.
По сути своей, золотой молоток это разновидность лени, и нежелание программиста искать оптимальные пути решения к конкретной задаче.
Это нежелание программиста учиться новому. Вот здесь в большом разборе мы писали об этом антипаттерне гораздо более подробно. Рекомендуем к чтению!
Спагетти-код 🍜
Сложно дать точную и однозначную характеристику спагетти-коду - настолько он многолик и многообразен, в различном авторстве у различных людей. В целом же, спагетти-код это отсутствие выработанной привычки к ясному структурированию программ. Так же, это излишнее усложнение методов, и подход к программированию "на отвали". Туда же относится привычка бездумно копировать одни и те же фрагменты кода, вместо выделения их в универсальные методы и функции.
Вот что говорит про спагетти-код Википедия:
Спагетти-код это плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, особенно содержащая много операторов GOTO (особенно переходов назад), исключений и других конструкций, ухудшающих структурированность. Самый распространённый антипаттерн программирования.
Спагетти-код назван так, потому что ход выполнения программы похож на миску спагетти, то есть извилистый и запутанный. Иногда называется «кенгуру-код» (kangaroo code) из-за множества инструкций «jump».
В настоящее время термин применяется не только к случаям злоупотребления GOTO, но и к любому «многосвязному» коду, в котором один и тот же небольшой фрагмент исполняется в большом количестве различных ситуаций и выполняет очень много различных логических функций.
Иными словами, если твой код становится похож на тарелку с лапшой - значит, что-то пошло не так. В нашей супер-прекрасной статье из прошлого про греховную жизнь программистов есть отдельный пункт на эту тему.
Поток лавы 🌋
Ещё один классический антипаттерн программирования - поток лавы. Здесь речь идет о том, что в условном проекте сохраняется большое количество нежелательного (лишнего, устаревшего, неиспользуемого, ненужного, плохо структурированного, непонятно кем написанного) кода только потому, что этот самый код очень проблемно оттуда изъять.
Например, здесь речь может идти о программных продуктах, созданных годы или десятки лет назад. Часть библиотек, подходов к программированию, модулей и других составных частей у таких продуктов уже значительно устарела. Но чтобы перевести проект на новые рельсы, требуется большие инвестиции в реструктуризацию и доработку продукта. Именно такие ситуации часто и называются "поток лавы" - когда дешевле оставить код "как есть", чем углубляться в его рефакторинг.
Другая сторона "лавового кода" - это бездумное копирование каких-то частей кода, и последующая интеграция этого кода с другими частями программы. Иначе говоря - вместо создания универсального метода или функции, программист начинает заниматься копипастой одного и того же кода с "небольшими доработками". В итоге, вместо красоты и изящества, мы получаем "мешанину из кода и библиотек", которые чем-то напоминают непрерывной поток лавы из жерла вулкана.
Отсутствие документации 😳
Что может быть ужасней, чем сложная библиотека со 100 методами, никакой из которых не содержит технической документации? Суть да дело, а я с таким сталкивался. "Программируем наудачу", "Кладём кирпичи без помощи рук" или "Забиваем гвозди вслепую" - наверное такие метафоры из реальной жизни можно привести, описывая подобный случай из жизни.
Как-то раз, в далёкие времена, когда термин "Искусственный интеллект" у большей части людей ассоциировался с фильмами типа "Терминатор" или "Матрица", а про ChatGPT ещё слыхом никто не слыхивал, попалась мне в руки нейросетевая библиотека для распознавания отпечатков пальцев. Задача была предельна проста - организовать контроль доступа на большом объекте через оптические сканеры отпечатков пальцев, используя вышеуказанную ИИ библиотеку.
Каково же было моё удивление, когда к этой библиотеке не обнаружилось абсолютно никакой документации, а разработчики предложили "не переживать по этому поводу, а просто присылать на Email вопросы по методам, если их названия и имена аргументов вызовут сомнения". Шутка была в том, что библиотека являлась частью более крупного проекта, и её разработчики не планировали отдавать продукт в третьи руки. Просто все привыкли работать в узком коллективе именно таким образом (без документации), а руководство проекта и вовсе не заморачивалось над такими "мелочами". В результате, родилась такая вот забавная история. К слову сказать, проект сделать всё-таки удалось, хотя это было совершенно не просто.
Непредсказуемый код / goto 🔗
Про использование оператора goto у нас есть отдельная статья. К слову сказать, она оказалась на данный момент одной из наиболее популярных среди прочих. В двух словах, goto - это оператор безусловного перехода на метку внутри программы. Это такой специальный оператор, благодаря которому можно игнорировать последовательность выполнения кода, и прыгать по программе туда-сюда.
Программирование устроено таким образом, что программный код выполняется линейно, сверху вниз, с переходами внутрь методов и функций если таковые указаны. После выполнения методов и функций, последовательное выполнение программного кода продолжается.
Использование перехода типа goto (как правило в высокоуровневых языках), напрочь ломает последовательность выполнения кода. Так, в какой-то неожиданный момент можно обнаружить "поток" выполнения программы совершенно в неожиданных местах, и с явным отсутствием последовательности. Goto радикально уменьшает читабельность и предсказуемость программ.
На днях - третья часть. Кто такой "Злой" и каковы его принципы.
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Для тех, кто хочет не просто читать о программировании, а начать свой путь джедая прямо сейчас, приглашаю на Boosty! Там эксклюзивный обучающий материал по программированию для любого уровня подготовки. А ещё там можно посмотреть, как автор выглядит в жизни. Жми сюда и полетели!🚀
P.S.2 Ещё у меня есть Telegram-канал. Там посты чуть проще и веселее. Ссылка
P.S.3 Предлагаю делиться в комментариях личным взглядом на плохие подходы к программированию. Случаи из жизни и поучительные истории из IT приветствуются!
