« Назад

Популярные антипаттерны разработке ПО

В мире разработки ПО есть ряд плохих подходов, которые говноеды, борющиеся против добротности и прогресса, неизменно стараются воспроизводить в каждом своем продукте или технологии. Собственно, пристрастие к плохим решениям пожалуй и отличает относительно нормальные разработки от говноедских и отвечает на вопрос "да какая разница ?". Работая с нормальной технологией в иногда натыкаетесь на странности и проблемы, с плохой - постоянно с ними боретесь.

Казуальное форматирование кода

Это когда код программисту правильно отформатировать без специальных средств тяжело. Например если он форматируется отступами как в питоне или форте или вложенными скобочками как в лиспе. Или смешиваются стили как в руби и го. Или много специальных символов как в перле или хаскеле. Вообще, ряд языков исторически создававшихся как "скриптовые", т.е. предназначенные для создания небольших программ преимущественно автоматизирющие операции через вызов других программ. В таких языках насыщенность синтаксиса упрощает читабельность лаконичного и функционально насыщенного кода. В языках программирования общего назначения ценность высокой функциональной концентрации уступает место архитектурной обусловленности, т.е. важнее снановится наоборот разделить функционал по подсистемам. Однако, многие скриптовые языки попытались вырастить до универсальных начав создавать на них достаточно сложные системы и там где краткость и выразительность выручала она стала задачу развития и поддержки программных систем усложнять. В таких языках как руби или пхп даже если код отформатировать правильно и аккуратно, он выглядит неоднородно, грязновато и тяжело для чтения и понимания.

Сюда же относится Венгерка, путающий стиль кодирования в C#, VisualBasic дающий неоднородное форматирование и требующий лишних нажатий шифта для написания кода или смешение его с Си-стилем, когда слова в именах методов разделяются подчеркиванием, а ссылочных типов по венгерке как в руби и некоторых из мира вендового С++.

Автовывод типов

Бестолковый подход, когда объявление переменных начинается с одного и того же ключевого слова var, let а функций function, fun, def вместо того чтобы явно указывать тип возвращаемого значения или переменной это делают с другой стороны или совсем не делают. В результате код напоминает простыню одних и тех же ключевых слов и надо напрягаться чтобы увидеть за ним логику.

В некоторых корявых технологиях таких как Swift например эти ключевые слова используются даже в объявлениях мемберов классов, что делает их трудно отличимыми от вычисляемого блока кода.

Кроме того, когда среда разработки или редактор не умеют вычислять возвращаемые значения код без документации или поисков по исходникам становится писать очень сложно, т.к. вы не знаете какие типы принимает и возвращает функция и не можете догадаться, из-за чего приходится тратить время на поиск ее описания. Опять же по какой-то закадной неудаче автовывод вместе с динамической типизацией используется чаще всего в прикладной разработке и вебе, т.е. там, где код пишется скорее наспех и абы как, где дополниельна помощь компилятора в обнаружении ошибок и предотвращении их попадания "в продакшин" пришлась бы очень кстати.

Подавление ошибок и исключений

Специальные символы глушащие вывод ошибок навроде @ в пхп, методы подавляющие исключения как в C# все это искушает разработчика писать небезопасный и плохой код, который будет обязательно сложно и дорого поддерживать.

Слабая типизация

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

Смешение бизнес-логики и представления

Эту ересь можно видеть от начала времен, когда в очередной раз какой-то даже вроде грамотный перец нет нет да и вклеит теги и многострочные литералы прямо в код. Старые Server Pages, ColdFusion, React, и даже Scala'вский Lift ломают раскраску в редакторах, дарят вермишелевые коды из хтмл или иксемель в перемешку с программным кодом, все потому, что кружевная логика шепчет "может теперь проканает ?"

Отрицание ООП, интерфейсов и "сложности"

Сейчас появилось поддерживаемое говноедами течение за то, что объектно-ориентированный подход это плохо, т.к. он позволяет допускать некоторые неоднозначности и мол если вернуться к процедурному стилю, то все сразу запоет. Это не так, от процеДУРного стиля в свое время как раз ушли потому, что он побуждает дублировать код, писать его длинными функциями в сотни строк кода и огромными модулями в тысячи строк.

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

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

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

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

Среднее (0 Голоса)
Средний рейтинг 0.0 звезд из 5.


Пока нет комментариев. Будь первым.