Да, вы не ошиблись. В интернете и так уже полно статей с хорошими рекомендациями и туториалами для разработчиков. Какое-то их количество вы можете найти и в моем блоге. Эта статья, уж извините, будет отличаться от них коренным образом, но только в лучшую сторону! Я расскажу о пяти смертных грехах, которые можно совершить в коде. Благодаря этим отвратительным практикам любой, кому придется работать с вашим кодом, вас возненавидит. Если вы готовы принять это тайное знание, то поехали.
Плохая практика №1: делайте из названий головоломки
Для разогрева возьмем что-нибудь простое. Хорошим началом будет добавить в названия переменных и функций побольше сокращений. Знаю, знаю: все говорят, что хорошие названия должны как можно яснее описывать назначение. Ну там handleFormSubmit, getUserConfiguration или parseCustomerInformation. Но мы за хорошим не гонимся.
Чтобы получить наихудший результат, старайтесь почаще сокращать слова и вводить аббревиатуры. Тогда следующему разработчику придется поломать голову, чтобы понять, что вы подразумевали. Вот несколько неплохих примеров: handleBtnClick, getConfig, parseInfo. Они не дают слишком много информации, но их вполне можно провести через инспекцию кода. Дополнительно усложнить восприятие помогут ненужные сокращения типа btn, func, config, cb.
А уж с названиями переменных вообще можно развернуться. У вас есть список неподтвержденных пользователей? Не называйте его uncofirmedUsers, ограничьтесь простым users. Тогда следующий разработчик будет вынужден читать весь код, который возвращает переменную, чтобы понять, в чем тут суть. Никаких discountedProducts этому бедолаге, простого продукта в названии с него вполне хватит.
Если хотите добавить еще перчинки в названия, можно поиграть с регистром. Коллеги вас убить будут готовы, гарантирую. Вместо того, чтобы создавать что-нибудь в духе readXmlDocument (то есть начинать аббревиатуры с заглавной буквы, как простые слова, по заветам хороших практик), всегда можно соорудить метод readXMLDocument, в который сразу не вникнешь и нужно внимательнее вчитываться.
Конечно, на инспекции кода могут попытаться пресечь всё это безумие, но ваша задача – бороться. Неважно, ради чего – из-за того, что лень править, или из желания сохранить свою репутацию скандалиста. При любом раскладе здесь главное не забывать: вы всегда можете пообещать всё поменять к следующему pull request-у и надеяться, что к тому времени все уже простят и забудут (скорее всего, так и случится).
Плохая практика №2: пишите крайне сложный код
Тут кроется возможность доказать, что вы – истинный Рик Санчез от программирования. Нужно просто делать код чуть более заумным, чем требуется. Возможно, вам удастся применить обобщение, чтобы можно было дважды использовать три строчки кода, за счет создания метода, который принимает пять параметров. Возможно, вы захотите сократить три строки кода до одной при помощи хитроумного тернарного оператора с тройным вложением. Дайте волю своему воображению!
Читать и поддерживать код после этого, разумеется, станет труднее. Но это ведь наверняка будет головной болью ваших коллег, а не вашей? Ну и отлично.
Так что давайте, покажите, что вы настоящий хакер. Советую как можно активнее использовать цепочки методов, вложенные условные операторы, раздутые дизайн-паттерны и однострочники, которые задействуют хипстерские, нишевые возможности языка. Ведь зачем писать Date.now(), если можно получить тот же результат несколько более загадочным +new Date()? Уверен, что другие участники проекта с большим чувством благодарности будут зависать над кодом в попытках понять, что вообще происходит.
И не забывайте: чем больше вы намудрите и наоптимизируете в коде, тем сложнее с ним будет потом вашим коллегам. Десять очков вам за каждую функцию reduce и сто – за каждый рекурсивный вызов. К завершению проекта вы такими темпами выбьетесь в настоящие профессионалы, с чем и поздравляю.
Третья плохая практика: импортируйте по максимуму
Признаю: с предыдущей техникой могут возникнуть проблемы на этапе инспекции кода. Но зато если вы пишете на JS или PHP, то у вас в начале чуть не каждого файла будет целая куча инструкций import/use. Многие разработчики во время инспекции на них даже не смотрят, сразу переходят к тому, что считают самой мякоткой. Именно поэтому зависимости – идеальная возможность наплодить ужасов в коде.
Вот представьте, что у вас есть некий view UserSubscriptions в приложении на React. Вы создаете файл с вспомогательной функцией calculateTimeToSubscriptionEnd. Прекрасно. Но где же его разместить? В отдельной директории, где хранится всё, из чего выстраивается доменная логика подписок и платежей? Нет, конечно. Положите лучше рядом с тем view, который только что создали.
Так вы мыслите на перспективу, потому что когда у вас наконец появится панель администрирования (а в ней – view Subscriptions), ничто не сможет вам помешать импортировать вспомогательную функцию из пользовательских view. И никто, скорее всего, не заметит, потому что никому нет дела до импортирования. Так вы свяжете два совершенно посторонних модуля и устроите ад на земле для каждого, кто попытается провести рефакторинг или внести изменения. Уж поверьте, ничто не доведет разработчика до безумия быстрее, чем проект с ужасной структурой.
Вы, вероятно, скажете: «Ну, не такая уж это и серьезная помеха». Неопытные разработчики долгое время не будут пытаться что-то исправить. Будут мучиться с этой неразберихой из убеждения, что, наверное, здесь нельзя ничего трогать. Каждая новая попытка разобраться в структуре приложения будет вызывать страдания. А если что-нибудь связанное с функцией обновят или удалят, то станет еще хуже. Путаница не велика, но от нее будут страдать все, пока не найдется какой-нибудь герой, который всё починит. Возможно, это даже будете вы.
Четвертая плохая практика: прописывайте разное поведение для одних и тех же функций
Вы считаете себя человеком творческим, художественно одаренным? Тогда вот идея для пыток, которая вам понравится.
Мир – место непредсказуемое, и никто никогда не говорил, что всё будет работать по одному принципу. И что последовательность и предсказуемость – залог продуктивной работы разработчика и успеха проекта, тоже никто не говорил… в смысле, говорили-то многие, но сегодня мы их не слушаем. Мы намерены испортить кому-нибудь день, подбросив ему в кодовую базу схожие функции, которые ведут себя немного по-разному.
Например, предположим, что у вас есть функция валидации, которая возвращает true, если данные валидны, и сообщение об ошибке, если что-то не так. Что если следующий валидатор будет возвращать false или undefined для корректных данных? Все планы аккуратно прописать проверку данных формы посыплются. Вот и хорошо.
Или, скажем, можно в каждой функции принимать аргументы в новом формате. Пусть в одной принимаются ID пользователей, а в другой – только весь объект целиком (даже если по факту нужен только ID). А может, у вас получится затребовать электронную почту пользователя? Это как следует попортит кровь разработчику, которому передадут ваш код.
Уверен, что вы придумаете еще более остроумные способы удивить коллег – непредсказуемым можно сделать всё что угодно. Долой последовательность, да здравствует произвол! И еще: никогда не думайте на уровне кодовой базы в целом, старайтесь добавить чего-нибудь интересного в каждый файл по отдельности. Другими словами, будьте не инженером, а художником. Другие разработчики в команде будут ненавидеть вас всей душой – потому, разумеется, что вы опередили своё время.
Пятая плохая практика: копируйте всё подряд
Если вы воплотите это в жизнь, к вашему коду точно никто не захочет притрагиваться. Не разбивайте общую логику по разным функциям, классам или компонентам. Просто копируйте и вставляйте нужные строки из файла в файл. В конце концов, код у вас очень ценный и безукоризненный, пусть люди на него любуются на протяжении всего проекта. Дайте ему блеснуть!
Однако это не единственная причина для дупликации. В случае обновлений разработчикам придется вносить изменения сразу в несколько файлов. Более того, если кто-то пропустит один или несколько случаев копирования логики (а если с тестами в проекте туго, кто-нибудь обязательно пропустит), то ему придется перепахивать код на второй, а то и на третий раз. Что может быть веселее, чем выискивать повторяющиеся фрагменты по сотням файлов в кодовой базе? Уверен, ваши коллеги оценят.
Помните: хорошо провести абстракцию сложно и требует много времени, так что не заморачивайтесь этим – просто копируйте код по мере необходимости. На инспекции кода к этому отнесутся с пониманием. А если нет, то можно потратить сэкономленное время на объяснение, почему ваш бесценный код обязательно нужно воспроизводить. Всё получится, я в вас верю.
Ну ладно, мне тут сатана звонит, закругляюсь.
Само собой, это шуточная статья. Не делайте того, что я здесь писал (серьёзно, не надо, я не развожу на слабо). Делайте наоборот:
- следите, чтобы названия были ясными и информативными;
- пишите простой, понятный для всех код;
- создавайте четкую структуру проекта;
- не забывайте о последовательности и предсказуемости в интерфейсах;
- разделяйте общую логику там, где это возможно без ущерба для ясности.
Да, и никогда не злите своих коллег. В сообществе программистов ходит поговорка: пишите код так, будто дальше с ним будет работать серийный убийца. Никто же не хочет портить отношения с серийным убийцей? То-то же. Но мне такая логика не нравится. Мне кажется, лучше писать код так, будто дальше с ним будете работать вы сами. Просто спросите себя: «Хотел бы я столкнуться с этим фрагментом, после того как забуду, зачем его писал?».
