Вы молод, ловок, быстр, и можете кодить словно ветер. Но вы пишете настолько простой поддерживаемый код, что любой его может изменить?
Да, говорите? Зачем?
Вы разве не знаете, что он устареет уже через год? Не беспокойтесь, что в будущем какой-нибудь разработчик испортит первозданную красоту результата Вашего кропотливого труда? Разве Вы не восхищаетесь случайным хрупким, незаменимым устаревшим комком грязи? Вы бы не писали зомбикод, который никто не может понять, кроме Вас, и который читается со страхом и трепетом, и код, который будет жить вечно на предприятии, потому что никто не смеет его трогать?
Это не легко, но Вы можете это сделать. Приложив небольшие усилия, Вы можете культивировать првычки и дисциплины, которые позволят Вам не только сразу писать правильный код, но и превзойти этот уровень, написав финальный зомби-код, продолжающий ходить по земле после долгих лет жизни. Вот так:
Никаких тестов
Тесты — это пустая трата времени, дающие лишь иллюзию уверенности, показывающую как код может вести себя в различных ситуациях. Если Вы должны писать тесты, пишите их в конце, подтверждая верность. Определенно не пишите тесты в самом начале или не используйте их для развития дизайна кода, так как код может измениться.
Никакого рефактора
В первую очередь, если код работает — не трогайте его. Во-вторых, ни у кого нет времени на изменение элегантности кода и его упрощения. Основные тесты, при необходимости, могут либо крашнуть код, либо даровать ему жизнь. В конце концов, "технический долг" является просто составляющим для продажи программного обеспечния.
Написать непробиваемый код
Затенить намерения Вашего кода — это все для внедрения. Прежде всего, имена классов и методов должны говорить о том, что они делают, а что нет. Такие имена как «GetPriorPurchasesOfSameProduct» слишком длинны и не информативны. «ScanForLike» куда лучше. Еще лучше — просто «Scan». Только простое! Только хардкор!
Используйте общие имена как «Buffer», «Temp» и «X» как можно чаще.
Используйте сокращения и акронимы для имен интерфейсов.
Используйте универсальные структуры не только для экономии времени и сил, но также для обфускации информации.
Держите строгие типы структуы в безтипных коллекциях.
Делайте массивы из всего.
Копипастните полусвязанную структуру в новый код, затем измените его для соответствия различным данным и ситуации, но не переименовывайте ни одну из его областей или комментарии.
Иногда (не слишком часто) переменным дают имена, подразумевающие неправильные типы, такие как обозначение числового значения с плавающей запятой «MessageText».
Не пропускайте значения, используя «Object» или «String», и никогда не инкапсулируйте значения типов.
Если нужно назвать константы, называйте их также, как их значение, либо исползуйте в качестве названий греческие буквы.
Комментарии дают возможность добавлять шум и неверное направление — охватывают их необузданность. Лучшие комментарии просто описывают что делает код и теряют актуальность в то время, когда код изменяется.
Следует иметь ввиду, что человек, читающий код, должен видеть отражение того, что делает на уровне внедрения: открытие соединений, получение результатов, обработку записей и так далее. Ни при каких обстоятельствах Вы не должны использовать основную терминологию предметной области бизнеса.
Написать нечитаемый код
Чтение чужого кода — это пустая трата времени, и это может испортить Ваш творческий стиль. Настаивайте на Ваших собственных стандартнах и соглашениях, но никогда не документируйте их.
Пробелы — это расточительство. Код компилируется быстрее без всяких дополнительных символов, но разделение может сделать код более читаемым. Пишите все в одну линию, пока Вам нравится.
Модульность — это мелочь. Вы можете сохранить все решения в Вашей голове, так зачем разбивать код на несколько классов и методов?
Сложность — это красивая и, в большей степени, ненужная запутанность. Намного лучше использовать последние языковые функции, позволяющие Вам писать две неясных строк кода, чем написать пять строк с очевидными эффектами. Если кто-либо спрашивает, утверждайте насколько это эффективно и/или высмеивайте их за то, что они не познали тайные особенности языка, который Вы использовали.
Пишите негибкий код
Сделайте настолько много архитектурных решений, насколько Вы можете, и не отступайте от них ни за что.
Не обменивайтесь информацией
Никогда не объясняйте, что делает Ваш зомбикод. Фактически, избегайте камрадов по комманде, или, по крайней мере, изегайте разговоров о проектах, над которыми работаете. У камрадов могут быть предложения, включая раздражающие предложения, или Вы случайно можете подробно рассказать им о том, что и как делаете. Ни один из вариантов нежелателен.
Не делайте парное программирование, никогда, и избегайте ревью кода. Это глупо тратить свое время, отвечая на вопросы, на которые уже ответили в коде. Если Вас загнали в угол, просто опишите что делает этот код.
Если Вы должны взаимодействовать с кем-нибудь, делайте это через электронную почту, а затем выжидайте, по крайней мере, пару дней между ответами, и чаще меняйте адрес своей электронной почты.
Обходите или ниспровергайте любую так называемую «политику», «стандартны» или «процессы», которые могут вмешаться в Ваши мерзкие планы. Все причины, призывающие как «улучшить качество» и «экономить время» являются ложью или что-то в этом духе.
С другой стороны, если Вы отвечаете за других разработчиков, можете оформить изменять политику, директивы и процессы так часто, как Вам нравится, но никогда не объясняйте почему.
Новые разработчики в команде, особенно выпускники, должны быть сброшены в дальний угол, без ориентации, обучения и/или помощи. Удостоверьтесь, что их вопросы проигнорированы и/или высмеяны, и все время их тыркают, чтобы поставить на место. Если Вы действительно хотите заставить их внести свой вклад, блокируйте доступ к «Google» и «StackOverflow».
Никаких операций разработки (DevOps). Всегда.
Следует избегать DevOps и практикантов. Все настраивайте вручную и именно так, как Вам нравится, и изменяйте всегда, когда Вы хотите. Относитесь с подозрениями к системам контроля версий — регистрируйте события только тогда, когда все сделано. Обязательно используйте превдоним и не комментируйте коммиты.
Вы не можете избежать участия в непрерывной интеграции и/или поставке, но старайтесь как можно чаще уйти от этого.
Если нужно документировать — пишите плохо
Если Вы должны писать документацию, пишите так, что только Вы сможете ее понять. Никогда не определяйте аббревиатуры и не учитывайте несколько критических моментов — Вы должны немало потрудиться, чтобы понять их, как и все другие. Затем файл документа положите в неуместное место, указав неправильные теги для поиска.
Не смотрите на других
Это признак слабости. Изучайте все самостоятельно от первых принципов. Подозревайте библиотеки других людей. Пишите свои фреймворки.
Кодирование для зомби-апокалипсиса
Если Вы примените в практике все эти дисциплины, Ваши программы станут ходячими мертвецами, зомби, которые навсегда засядут в глубинах организаций, но никогда не умрут. Ваш код будет жить очень долго после Вашего ухода.
Такой код написан для жестоких психопатов, которые знают где Вы живете. Но вряд ли до этого дойдет, потому что они будут слишком заняты борьбой с Вашей ордой зомби)
Ну, и просто не пишите свое имя)
От переводчика
Текст перевел близким по смыслу с адаптацией под русскоговорящих. Сильно не пинайте)
