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

Команда аварийно-спасательных служб из одного человека

Если вы программист в начале своей карьеры и еще недостаточно хороши, чтобы быть частью команды или управлять ею, скорее всего, вы пишете весь код самостоятельно. С любым значительным проектом приходит сложность. На этапе прототипирования вы, скорее всего, сосредоточитесь на том, чтобы все работало. Вы хотите, чтобы ваша концепция работала. Стремление к достижению рабочего состояния настолько сильно, что затуманивает зрение. Это часто приводит нас к тому моменту, когда мы думаем: «Что мне нужно сделать, чтобы эта хрень работала?» Из-за этого непреодолимого побуждения вы, вероятно, уже сталкивались с состоянием кода, где все происходит от случая к случаю, уязвима, за ней трудно следить, ее легко сломать, трудно изменить, и постоянно требуется время, чтобы понять, чего вы там пытались достичь.

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

Офис мертвых писем

Итак, вам удалось получить работу, потому что вы достаточно долго тренировались, чтобы отвечать на глупые вопросы, которые вы никогда больше не встретите, и уже знаете, как использовать код, написанный кем-то другим. Поверьте, это все, что нужно. Теперь вы сталкиваетесь с другим вызовом. Как вы можете общаться наименее эффективным способом, чтобы никто на самом деле не понимал другого? Вы будете работать по крайней мере с одним человеком, который поделится с вами своей идеей и ожидает, что вы прочтете и его мысли. Всякий раз, когда вы говорите о технических деталях, их разум удобно отключается, так что они не улавливают ни слова из того, что вы говорите. Чаще всего вопросы будут сводиться к «ты сможешь?», а в качестве ответа ожидается «да». Им все равно как. Они не наняли вас, чтобы учить их. Таким образом, вы можете продолжать работать в одиночку с беспорядком, который вы создали ранее, пока он работает, и им все равно. Это также справедливо для более крупных команд с большим количеством разработчиков, за исключением того, что их не волнует только то, что им не нужно трогать ваш код. Таким образом, написание плохого кода по-прежнему является стандартом, и, не прилагая дополнительных усилий для коммуникации, он также остается таким. Просто придерживайтесь старой привычки пытаться решить все в одиночку и часто представляйте, что вы терминатор, решающий все проблемы человечества.

Идти в ногу с качеством

С этого момента вам нужно только немного сопротивляться тому, что заставляет вас улучшать свой стиль. Упорно игнорируйте чтение книг и статей на любую тему. Полагайтесь исключительно на StackOverflow и никогда не тратьте на получение ответов более пяти минут. Если вам нужно чему-то научиться, ограничьте себя изучением только технологий, таких как библиотеки, фреймворки, языки программирования, низкоуровневые API, но ни в коем случае не приближайтесь ни к чему, что претендует на то, чтобы обеспечить перспективу с высоты птичьего полета, к любым вещам более высокого уровня. Любой ценой избегайте всего, что содержит в названии «лучшие практики». Пусть чистота будет для вас ругательством. Слово «самоуверенный» также должно вызывать подозрения.

Лучшие практики для худшего кода

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

  1. Единое безопасное место, где можно управлять всеми

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

2. Код, аналогичный рекомендациям YouTube

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

3. Всегда разрубайте этот гордиев узел

Наткнулись на код, который хорошо структурирован и действительно делает то, что кажется? Не оставляй так! Попробуйте добавить к нему больше функций и включить / отключить их с помощью опций. Не забывайте, что вы можете вызывать что угодно из чего угодно. Всегда меняйте модификаторы доступа, если они не подходят. Лучше всего держать все методы общедоступными. goto был несправедливо изгнан из большинства языков программирования, но это не значит, что вы не можете прыгать по коду, вызывая функции или методы когда угодно и где угодно. Вы даже можете снова вызвать тот же метод. Не бойтесь использовать рекурсию! Прыгать от одного класса к другому, от одного метода к другому — все равно, что разрубить гордиев узел. Он просто пропускает ненужные части. Еще один способ сократить ситуацию — использовать асинхронные функции, когда это возможно. Распараллеливание просто делает все быстрее, верно?

4. Код должен быть каноническим

Никогда не пересматривайте свой подход. Код будто высечен на камне. Что бы ни было написано, это написано для вечности. Его можно только расширить, но нельзя изменить. Так развиваются каноны. Поэтому, если ваша функция не делает то, что вы хотите, просто добавьте еще один параметр и if внутри тела. Наличие менее трех состояний в теле функции не является здоровым. То же самое относится и к методам. Если у вас есть класс, убедитесь, что у вас есть как можно больше опций в качестве параметра конструктора, но пусть методы будут настроены с их собственными опциями. Не стесняйтесь повторно использовать что угодно, пока вы добавляете к нему новые параметры и условные блоки. Если по какой-либо причине вы не можете этого сделать, просто продублируйте оригинал и адаптируйте дубликат под свои нужды. Ваш лучший друг — это флаг, логическая переменная. Знаете ли вы, что у вас могут быть даже флаги в виде битов в двоично-кодированном числе? Представьте, сколько флагов можно втиснуть в длинный int!

5. Вы можете рассчитывать только на себя

Как уже упоминалось, хороший менталитет в программировании такой же, как у персонажей «Безумного Макса». Как вы могли полагаться на кого-то еще, кроме себя? Это просто делает вас уязвимым. Никогда не думайте о принятии помощи от кого бы то ни было. Это ловушка! Они хотят обмануть вас, использовать вас, ограбить вас. Просто реализуйте все сами. Не стесняйтесь изобретать велосипед каждый день. Это только увеличивает доверие компании к вам. В идеальном мире каждый код настолько запутан, что даже его создатель не может понять, что он делает, проверяя его через день после его написания.

Во всем виновата парадигма

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

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

Просто никогда не относитесь к ним серьезно. Следуйте моим мудрым советам, добавьте к ним свои врожденные инстинктивные решения, возможности безграничны. Вы можете испортить программу бесконечным количеством различных способов. Если повезет, вы легко превратитесь в худшего программиста!