Интернет буквально кишит статьями, повествующими о том, как вы можете улучшить ваши навыки разработки. Эти статьи гласят о “лучшей коммуникации”, “работе в команде”, “постоянном обучении” и прочем.
Но я расскажу вам, о чем вы еще не читали. Как быть хреновым. Все верно — в этой статье вы узнаете о двадцать одном способе быть хреновым разработчиком. Не будем терять времени, приступим.
Форматирование кода только делает его читабельней. Хреновые кодеры знают, что неформатированный код тяжело читать и поддерживать. Поверьте, вы можете свести с ума своих товарищей-разработчиков, если после правок будете постоянно возвращать код с разным форматированием. Причем ни в коем случае не делайте отступы.
Информативные имена только делают код более понятным. Если вы по истине хотите быть хреновым, то используйте для имен переменных буквы. Если их не хватает, то используйте короткие бессмысленные сокращения вроде MsgN
или FuncMan
. Одно из моих излюбленных — имя метода DoStuff
.
Ничто так не показывает ваше желание создать плохой код, как отказ от написания тестов. Особенно прекрасно в этом то, что со временем ваш код становится все хуже и хуже, что позволит завестись в нем еще большему числу багов.
Плотное сжатие элементов кода существенно повышает степень его хреновости. Во-первых, его будет действительно тяжело менять и обновлять. Во-вторых, так тестирование и отладка пройдут веселее, поскольку изменение в одной части приложения может привести к появлению багов в неожиданных местах по всему коду. Что может быть хреновее?
Этот пункт один из моих любимых. Убедитесь, что в коде присутствуют методы, выполняющие множество задач. Дополнительные очки можно получить за глубокое внедрение большого числа инструкций if
. Немногое сможет сравниться в хреновости с необходимостью многократно жать PgDn, чтобы просмотреть весь метод.
Полное игнорирование принципа единственной ответственности в коде создаст много проблем в перспективе. Зачем разделять функциональность по различным классам, когда гораздо проще добавить методов в уже существующий? Вы можете создать неограниченное число проблем, наделив класс множеством обязанностей.
Хардкодьте везде. Используйте реализацию при каждой возможности. Игнорируйте мощные возможности языка вроде абстрактных классов и интерфейсов. Эти элементы только облегчат поддержку вашего кода, но ведь вам совсем этого не надо.
Хреновые кодеры верят, что все развитие кончилось в первый их день выхода на работу. Стремление развиваться в том, что вы и так уже знаете, только ведет к написанию хорошего кода и использованию более совершенных техник. Хреновые кодеры так не делают.
Если бы фраза “На моей машине работает” была бы плохим аргументом, то ее бы никто никогда не использовал. Перед отправкой файла отчета убедитесь, что он содержит хреновое описание проблемы и не сообщает этапов по ее воспроизведению. Мой любимый выглядит так: “Этот функционал неисправен полностью”. Так вы гарантируете реально тяжелый процесс обслуживания разработчику, который будет вынужден исправлять баг. Еще лучше, если этим разработчиком станете вы. Месяца три спустя.
Если бы Notepad не было достаточно для написания кода, то Microsoft ни за что бы не вывел его на рынок. Зачем заставлять себя изучать Intellisense, горячие клавиши или любые другие подручные средства? Они только уменьшат хреновость кода и ускорят процесс разработки.
Быть может, однажды вам все же придется устранять баг. Знаю, знаю — кто хочет этим заниматься? Но если все же придется, то при любом раскладе не используйте отладчик. Вместо этого просто используйте вызов консоли или быстрый вызов диалогового окна ShowMessage
. Этого достаточно, чтобы утвердиться в роли хренового кодера.
Это всегда весело. Обязательно удалите что-нибудь в методах записи. Внесите изменения, когда получите значения методом чтения. Поверьте, это принесет вам уйму радости.
Визитной карточкой хренового кода является сложность внесения изменений и обновлений. Постоянные повторения — это хороший способ усложнить обновление. Используйте множество магических чисел. Зачем объявлять константу в одном месте, когда можно использовать литерал в 34 местах?
Опыт? Да кому он нужен? Да что эти старперы вообще знают? То, что они уже все это видели и совершали ошибки, будучи молодыми, еще не значит, что вы тоже не должны их совершать. В конце концов, как можно стать опытным, если вы уже изначально можете делать вещи хреново?
Еще один известный способ — позвольте диапазону экземпляров класса полностью затеряться в лабиринте параметров метода. Переиспользуйте объект везде, где можете — зачем тратить все эти вызовы new
, когда можно передать существующий экземпляр через половину приложения посредством цепочки из семи вызовов метода? Неотслеживаемые утечки памяти — еще один отличительный признак хренового кода.
Этот совет, наверное, самый ценный. Никогда не быть на 100% уверенным в состоянии переменной — это гарантия написания плохого кода. Если вы не можете выяснить как, где и для чего назначено значение переменной, то точно не стоит надеяться на устранение бага, связанного с ее неопределяемым состоянием.
Это особенно эффективно в языках, чувствительных к регистру. Чтобы написать баги, которые сложно найти, просто чуточку меняйте регистр имени переменной в JavaScript. Хотите больше? Используйте l и 1 поочередно.
Обязательно засорите код множеством комментариев, не имеющих значения. Особенно таких, которые объясняют, что вы делаете там, где это фактически делает код. Например, разместите //Очищаю список заказа
прямо перед вызовом OrderList.Clear
. Этот способ будет еще эффективнее, если отделить комментарии от описываемого ими кода.
Ничто так не взрывает мозг, как логическое выражение со множеством модификаторов not
. Серьезно, сделайте много таких, и ваш код реально станет тяжело читать.
Еще один классический прием — запутывать людей функциями, которые могут выполнять два различных действия:
Тогда вы можете вызвать ее, используя супернепонятное выражение:
processOrder(False);
Дополнительные баллы за двойное отрицание! Совершенная тарабарщина!
Еще один яркий признак хренового кодера — коммитить примерно раз в две недели, отправляя кучу разных изменений в одном наборе, а вдогонку прикрепить сообщение “Проверяю всю кучу изменений и правок”. Могу вас заверить, что одно только это уже гарантирует вам статус хренового разработчика.
Вот вы и ознакомились с двадцать одним способом сделать ваш код хреновым. Хренового вам кодинга!
Перевод статьи Nick Hodges: Twenty-one ways to be a Crappy Software Developer
Комментарии