[Из песочницы] Зомби-код. Код, живущий своей жизнью
Предлагаю читателям «Хабрахабра» перевод статьи «Zombie Code When Maintainability Goes Out Window».
Ты бодрый, проворный, быстрый и ты пишешь код, как ветер. Но ты пишешь изменяемый код, который максимально легко может быть исправлен в будущем другими.
Да, скажешь ты? Почему?
Ты не задумывался, что твой код устареет через год? Разве тебя не волнует, что какой-то будущий разработчик испортит нетронутую красоту твоего тщательно обработанного решения? Разве ты не восхищался случайно встреченным, незаменимым, но совершенно устаревшим комком грязи? Хотел бы ты скорее написать зомби-код, который никто кроме тебя не сможет понять, код, который будут расценивать со страхом и трепетом, код, который будет вечно жить в компании, потому что никто не осмелится его изменить?
Это не легко, но ты можешь это сделать. С небольшим усилием, ты можешь развить свои навыки и дисциплину, которые дадут тебе возможность не только немедленно написать код, но и превзойдут уровень «так себе» и ты напишешь окончательный, оставшийся в живых – зомби-код, который продолжит «ходить» по земле и после того, как ты уйдешь.
А теперь как же это сделать:
Ничего не проверяй
Тесты – пустая трата времени. Они дают иллюзию надежности и могут показать, как работает твой код кому-то еще. Если ты должен провести тесты, сделай это в последнюю очередь и заяви, что они верны. Разумеется, не проводи тестирование вначале и не используй тесты для помощи кому-то — такая разработка простой путь к пониманию и изменению.
Никакого рефакторинга
Во-первых, если код работает, не исправляй его. Во-вторых, ни у кого нет времени разрабатывать изящность и простоту. Разработка через тестирование (TDD), при необходимости, допускается, но только, если ты не можешь без этого обойтись. Да и в конце концов «технический долг» заключается в продаже средств для измерения характеристик ПО.
Пиши код, который невозможно понять
Скрыть возможности твоего кода вполне возможно. Прежде всего, давай классам и методам такие имена, чтобы они заявляли о том, что делают, а не об их обязанностях. Имена, такие как «Получение предыдущей закупки для некоторого продукта», слишком длинные и информативные. «Просмотр информации» будет намного лучше. А еще лучше просто «Просмотр». Да здравствуют общие имена!
— Используй обобщенные названия, к примеру, «Buffer», «Temp» и «Х», как можно чаще;
— Используй аббревиатуры и сокращения для названия интерфейсов;
— Используй родовую структуру не только для экономии времени и усилий, но и, чтобы спутать информацию о типах данных;
— Используй типизированные структуры в нетипизированных коллекциях;
— Записывай все подряд в массивы;
— Копируй и вставляй полусвязную структуру по всему коду, потом изменяй ее, чтобы она соответствовала различным данным и ситуациям, но не переименовывай значения и не изменяй комментарии;
— Иногда (но не слишком часто) давай переменным имена, подразумевающие неверные типы, например, обозначь число с плавающей точкой «MessageText»;
— Передавай по значению параметры типа Object или String, и никогда не инкапсулируй значимые типы;
— Если ты должен ввести константы, давай им такие же имена, как их значения. Или используй греческие буквы;
— Комментарии – возможность добавить шум и неверное направление. Лучшие комментарии объявляют, что делает код, и даже после изменений кода остаются прежними;
— Помни, что человек, читающий твой код, должен видеть только то, что код делает, а не как он это делает: открытое соединение, получение результатов, обработка записей, возврат результатов, и т.д. И ни при каких обстоятельствах не используй базовую терминологию по делу.
Пиши нечитаемый код
Чтение кода других людей – пустая трата времени, это может испортить твой творческий стиль. Отстаивай свои собственные стандарты и никогда не комментируй их.
Табуляция – это расточительство. Код компилируется быстрее без всех этих лишних отступов, к тому же разделение может сделать код более читабельным. Пиши все в одну строку так долго, как это возможно.
Модульность – это ограничение. Ты можешь хранить все решение у себя в голове, так зачем распространять их через многочисленные классы и методы?
Сложность – это прекрасно, а излишняя сложность и того лучше. Намного лучше использовать последний функционал языка, который позволит тебе написать две непонятных строчки кода, а не пять очевидных. Если же кто-то спросит, заяви, что это улучшит эффективность и/или посмейся над их незнанием тайных особенностей языка, которые ты использовал.
Пиши несгибаемый код
Применяй так много архитектурных решений, как только можешь и придерживайся их, не смотря, ни на что.
Не делись информацией
Никогда не объясняй, почему твой зомби-код что-то делает. Избегай своих сокомандников или разговоров о проекте, над которым ты работаешь. Твои товарищи по команде могут предполагать и досаждать советами, или ты можешь случайно показать то, что поймут твои сокомандники. А это нежелательно.
Воздержись от парного программирования. Это попусту потратит твое время на вопросы, ответы на которые уже есть в коде. Если уж совсем загнали в угол, просто опиши, что делает твой код.
Если тебе приходится работать с кем-то по электронной почте. Жди не менее двух дней между ответами и часто меняй свой почтовый ящик.
Обойди или нарушь, так называемые, «политику», «стандарты» или «процессы», которые могут помешать твоим злодейским планам. Они обещают тебе «улучшение качества» и «экономию времени», но вранье.
С другой стороны, если тебе пришлось руководить другими разработчиками, ты можешь выпускать свою политику, директивы и вносить изменения в процессы так часто, как ты этого захочешь. Но никогда не объясняй зачем все это.
Новые разработчики в команде, особенно новички, должны метаться из огня да в полымя без ориентации, образования или поддержки. Удостоверься, что их вопросы проигнорированы или высмеяны что на них давят, пытаясь от них избавиться. Если ты действительно хочешь заставить заплатить их по счетам, заблокируй доступы к Google и Stack Overflow.
Никакой DevOps. Никогда
DevOps методов и специалистов следует избегать. Настрой все вручную, так как тебе нравится и меняй все, когда тебе этого захочется. С подозрением относись к системам управления – представь свой код свету, только когда все будет готово. Обязательно используй псевдоним и ничего не раскрывай в сообщениях.
Можно, конечно, пытаться избежать участия в непрерывном общении с командой и/или обмене информацией, но не стоит делать так слишком часто.
Если ты должен документировать, делай это ужасно.
Если ты должен писать внешнюю документацию, пиши ее так, чтобы только ты смог понять написанное. Никогда не расшифровывай сокращения и пропусти несколько важных шагов – ты должен был стараться, чтобы понять код, значит остальные тоже должны попотеть. Сохрани документацию некорректно и задай неверные тэги поиска.
Не ищи готовые решения
Это признак слабости. Выясни все самостоятельно от первых источников. Библиотеки других людей сомнительны. Пиши свои собственные фреймворки.
Пиши код для зомби-апокалипсиса
Если ты последовательно применишь все эти советы, то твои программы станут ходячими мертвецами, зомби, которые постоянно разлагаются, но никогда полностью не умирают. Все эти усилия сохранят твой код и после твоего ухода.
Запомни, что нужно написать код так, как будто следующий человек, который притронется к нему, будет яростным психопатом, который знает, где ты живешь. Но это вряд ли произойдет, потому что они будут слишком заняты, борясь с твоей толпой зомби.
Просто не подписывайся своим именем.
