Неопределенность может порождаться тем, что нам не всё известно о технологии, о бизнесе, о пользователе, объеме данных в системе, продолжительности жизни кода, а также другими неизвестностями, о которых мы даже не подозреваем (за расширенным списком примеров обратитесь к 2020 году).
В ситуации, когда будущее неопределенно, продолжительность цикла выходит на первый план. Скорость позволяет мне извлекать ценность из собственного кода: я быстрее осваиваю новые навыки, вред от плохого кода или отдельных ошибок в неплохом коде сводится к минимуму и продукт быстрее выходит на рынок.
Любые препятствия плохо влияют на продолжительность цикла. Они лишают меня возможности превращать неопределенность в определенность – а в этом и состоит суть обучения. Быстрое обучение формирует наиболее устойчивую ценность, оно выступает своего рода коэффициентом, на который умножается качество кода и архитектуры впоследствии. Есть такая поговорка «Писать значит переписывать», перелагая ее на код, можно сказать: «Писать код – значит проводить рефакторинг».
Исходя из этого, вот несколько причин, почему не нужно бояться писать паршивый код. Точнее сказать, почему не нужно бояться писать больше паршивого кода.
Это улучшает навыки написания кода
Если вы хотите научиться программировать, лучший способ для этого – практика. Как я для себя установил, читать можно сколько угодно, но пока не наберешь код своими собственными пальцами, информация не будет удерживаться. Написание кода – не то, чему можно научиться за день, это определенный способ мышления и подход к решению проблем, а также набор сведений об инструментах и вычислительных средах. Единственный способ углубить необходимые знания – работать с этими инструментами и средами. Каждый раз, как я что-то пишу, я подготавливаю почву для того, чтобы следующий раз прошел проще и результат получился лучше.
Это помогает снова испытать радость от созидания
Когда пишешь паршивый код, основная цель – как можно быстрее получить что-либо на выходе. А это означает прямой путь к тому удовлетворению и ощущению успеха, которое возникает, когда что-то – что угодно – начинает работать. Я написал первую строку кода тридцать лет назад, и, тем не менее, меня по-прежнему охватывает восторг каждый раз, когда удастся привести очередной кусок кода в рабочее состояние.
Это позволяет изучить нерабочий код или нерабочую систему
Иногда в системах что-то не работает. Как я мог убедиться, именно это дает богатые возможности чему-то научиться. Самые ценные уроки я вынес не из какого-нибудь заранее просчитанного компромиссного решения о качестве кода, а из тех случаев, когда поведение системы совершенно не укладывалось в мои ожидания.
К тому же, когда выкладываешься, стараясь написать безупречный код, появляется эмоциональная вовлеченность в его корректную работу. Если по завершению возникают какие-то ошибки, первым делом начинаешь искать внешнюю причину. Ну а о функционировании паршивого кода душа не болит. Если что-то идет не так, то просто исходишь из того, что код и есть «самое слабое звено», и сразу начинаешь разбирать его и систему по косточкам, попутно узнавая много нового. Такой подход стимулирует любознательность и не портит настроение.
Код никогда не бывает замкнут сам в себе. Любой неожиданный сбой по умолчанию предполагает, что в работе системы есть что-то, чего я не понимаю. А значит, любая ошибка – идеально сконструированный индивидуальный урок, адаптированный для максимальной отдачи от обучения.
Это учит устранять баги
Когда я пишу код, у меня имеется несколько стандартных каналов обратной связи. Когда я пишу паршивый код, эти каналы начинают работать на более высокой частоте. Естественно, передо мной встает острая необходимость разобраться в том, на что и как смотреть, чтобы оценить функционирование кода. Каждая попытка писать код приводит к более глубокому пониманию инструментов – иногда осваиваешь какие-нибудь горячие клавиши для редактора, иногда пишешь скрипт, чтобы автоматизировать тот этап тестирования, который до этого проводил вручную. Суть в том, при написании кода совершенствуются и сами инструменты, и мое умение с ними работать.
Это помогает исследовать проектное поле
Когда я пишу код, реализующий какие-то незнакомые мне функции (то есть практически всегда, иначе это уже рефакторинг), у меня нет представления о проектном поле. Я не знаю, что в принципе возможно, из-за недостатка сведений.
Тем, кто учится рисовать, иногда дают такое задание: нужно сделать 5-10 черновых набросков на заданную тему, а затем выполнить по 5-10 вариантов для каждого наброска. Это и есть исследование проектного поля. Иногда я ловлю себя на том, что сравниваю два возможных варианта архитектуры, а ведь это сильно сужает рамки того, что возможно на самом деле – гипотетических вариантов архитектуры, скорее всего, десятки. Когда пишешь много паршивого кода, получаешь доступ к большему количеству вариантов. Он приводит в определенную точку, с которой открывается новый, более полный обзор возможностей.
Сниженные ожидания освобождают мысль и развязывают руки
Знаю, что уже говорил об этом в предыдущих пунктах, но изменения в душевном состоянии, когда я глушу самолюбивое стремление, чтобы в коде было «всё правильно», колоссальны. Вместо досады и раздражения и испытываю любопытство, радость открытия и удовлетворение от достигнутого результата. Даже если все прочие доводы были бы ошибочны, паршивый код следовало бы писать почаще просто ради собственного психологического здоровья.
В заключение
Опытные разработчики-сениоры любят поговорить о том, каким «должен быть» код. Часто это описания какой-то недосягаемой земли обетованной, где они и сами никогда не бывали. Некоторые из этих «должны» складываются во фреймворки, которые помогают расставить приоритеты при проектировании систем. Самые лучшие прямым текстом указывают на необходимость понимать, когда правило применять не следует. Но в конечном счете, все они приносят пользу, пока направляют вас, и перестают приносить пользу, если начинают вас тормозить.
Иными словами: не теряйте направления, но со спокойной душой позвольте себе писать паршивый код здесь и сейчас.
Комментарии (23)
ramiil
28.01.2022 14:29+10Плохой совет. Есть несколько причин писать тяп-ляп.
Одноразовый код - срипты всякие там. Написал, запустил, удалил. Так себе идея, но трудозатраты должны окупаться эффектом.
Срочность - код нужен сейчас и нужен рабочим. Канает не всегда, а только если потом отрефракторишь. А как мы знаем - лень и гордыня - лучшие друзья програмиста, так что не стоит говнокодить ради скорости. Хороший программист пишет и быстро, и хорошо, а главное - мало.В остальном - не рекомендую.
OnYourLips
28.01.2022 18:11+4Для каждой задачи есть наиболее приемлемое (хотя бы по оценке) качество кода. Повышать качество кода выше тогог, которое требует задача - просто трата времени.
Простой пример: мне надо сделать за несколько дней бекенд для одного второстепенного фронтенда, который точно не будет сильно развиваться и хорошая архитектура не окупится. Поэтому я считаю, что правильное решение - использовать какой-нибудь фреймворк типа Laravel или Django, чтобы слепить что-то на них на коленке без всяких этих doctrine или sqlalchemy. При этом я считаю их плохим выбором для длительных проектов, подталкивающих к некачественному коду (в частности в них антипаттерн ActiveRecord из коробки).
Myclass
28.01.2022 14:31+6Совет, писать — тяп-ляп — не имеет места для существования. Должно быть только — старайтесь быть всегда лучше, если не получилось сейчс написать хороший код, постарайтесь, чтобы в селд. раз это получилось. Надо всегда расти в лучшую сторону.
amarao
28.01.2022 15:21+6Не совсем так. Существует exporatory programming, когда проверяешь правильность идеи. У этого кода нет шансов на продакшен, и люди, которые ради скелета-идеи на 300 строк пишут тысячу строк бойлерплейта по best practice просто теряют суть exploratory programming.
masai
28.01.2022 22:55+1Так 300 строк бойлерплейта ради идеи — это и есть плохой код.
А вести функцию вместо копипасты не только не сложнее, но ещё и время сэкономит. Просто нужна привычка.
molybdenum
28.01.2022 14:36> причин, почему не нужно бояться писать паршивый код.
не надо бояться писать код. а потом учиться отличать парщивый код от хорошего
iiwabor
28.01.2022 15:44+6Когда я вижу свой код годичной давности, который я тогда считал хорошим - мне хочется его полностью переписать.
Когда я вижу свой код двухлетней давности и еще ранее - мне хочется плакать от горя...
Gedeonych
28.01.2022 16:25+5А самое весёлое, что так происходит у всех. Даже у тех кто десятилетия этим занимается.
KongEnGe
28.01.2022 17:30+4Нет. Мне, как и многим ровесникам, практически всегда уже нравится свой код, написанный в последние 10-15 лет (из почти 30 в профессии) не в условиях давления дедлайном. Более того, иногда даже выскажешься в духе последних абзацев "Человека-невидимки":
— Шесть, маленькое два сверху, крестик и закорючка. Господи, вот голова была!
Gedeonych
28.01.2022 17:55+1А я за 30 лет всё ещё постоянно недоволен своим кодом. И чувствую что буду всегда недоволен. Всегда можно сделать лучше чем уже есть. Отсюда каждый раз "конфликт желаний" - перфекционизм или "поменьше заморачиваться". "Всегда нравится свой код" было удивлением для меня прочитать. Среди коллег незнаю ни одного такого кому бы всегда нравился свой код. Прим.* Естестественно имеется ввиду не синтаксис, а структура, алгоритмы, взаимоотношения и пр.
KongEnGe
28.01.2022 18:13Синтаксис не главное, хотя и он уже давно устаканился. Куда больше радует массовое соблюдение хороших практик, когда предусмотрено все, что предусматривал бы и сегодня для комфортного сопровождения по жизненному циклу.
quaer
28.01.2022 20:26+1Является ли код плохим, если он написан хорошо, но вот то, что он делает - продумано плохо?
moonster
28.01.2022 21:48+3Хороший код отличается от плохого тем, что решает больше проблем, чем создает. ) Не пишите плохой код.
GospodinKolhoznik
28.01.2022 21:56+1С другой стороны, если проблему можно решить за деньги, то это не проблема, а траты. А если код наш, а деньги заказчика, то хороший код отличается от плохого тем, что за него хорошо заплатили!
Racheengel
29.01.2022 01:37+2Принцип SPIFE - stable, performant, intuitive, functional, extendable - работает именно в таком порядке (если, конечно, речь не о прототипе, который проверят и сотрут).
На первом месте стабильность как основа качества продукта. Продукт должен работать, не вылетать и не виснуть.
На втором производительность, в т.ч. максимальное быстродействие и оптимальное потребление ресурсов. По сути один из залогов первого принципа.
Далее идёт интуитивность работы с продуктом - чем проще с ним работать, тем лучше. Возможно, не основное для разработчика, но очень важно пользователю.
Функционал идёт позже, т.к. он может наращиваться и улучшаться итеративно, когда уже стабильно работают основные фичи.
И, наконец, расширяемость - должна присутствовать для обеспечения нового функционала.
Вывод простой - некрасивый, но функциональный, быстрый и стабильный код лучше падающего и тормозящего красавца :)
0x4eadac43
29.01.2022 13:27+1В статье нет определения, что такое плохой код с точки зрения автора. Только что-то про время, которое тратится на написание кода. Поэтому сложно как-то анализировать советы, которые автор дает. Сколько разработчиков спросишь, столько получишь мнений о том, чем хороший код отличается от плохого. Будут лишь общие соображения, которые, опять таки, субъективны. Лично я стараюсь не участвовать в дискуссии о качестве кода, пока не определены четкие критерии. Несколько примеров:
если код не решает задачу - плохой; покрываем тестами, чтобы проверить
если код нельзя понять, без помощи автора (при этом доменную область надо знать, конечно) - плохой; множество вопросов на ревью типа "а это зачем? а что это обозначает? зачем это понадобилось?" и т.п.
если требуется в деталях разобрать код, чтобы понять основную идею решения - плохой; на ревью уходит очень много времени (даже при небольшом количестве кода)
если код "медленный" или потребляет необоснованно много ресурсов (когда это важно) - плохой; можно добавить замеры (бенчмарки), иногда просто очевидно (использование unordered_map для 3 элементов)
сложность можно оценивать формально, например, посчитать цикломатическую сложность функции
в конце концов, код не следует coding style - плохой; используем линтер
Что-то меня разнесло. Короче, если разговаривать в терминах плохой-хороший без конкретики, - терять время. Что, собственно, я и сделал, написав этот ненужный комментарий.
mr_writer
29.01.2022 23:15Мало того, что не понятно о каком плохом коде идет речь, так еще и суть плохого кода сводится к обучению и исследованию. При этом вывод преподносится, как будто это применимо и к результату, тому, что идет в продакшен в долгой перспективе.
В прочем, кажется мне, что мешать не стоит. Чем больше людей пишут плохой код тем крепче на ногах стоят наши качественно реализованные проекты. Можно даже подхалтурить, все равно не упадет, конкуренты все равно хуже, на плохом коде работают.
zzzzzzzzzzzz
30.01.2022 01:06+1А автор знатный тролль!
Подкину ещё пунктик, чего уж стесняться. За хороший код вам заплатят один раз, а за плохой будут потом доплачивать ещё и за исправления. Оттачиваемый годами талант говнокодера состоит в том, чтобы нащупать тот хрупкий баланс, когда количество багов максимально, но не превышает тот предел терпения, за которым заказчик решает выкинуть код и начать сначала.
Myclass
30.01.2022 01:39Бог ты мой, как это правильно. Ведь каждый день с такими сталкиваюсь. И не только в программировании. Везде. В каждом ремесле. В Германии говорят про это Kopfmonopol те. Монополия одной головы. И подразумевается именно негативный подконтекст, когда человек вокруг себя создаёт биосферу, где только он знает как в каждой ситуации справится с задачей, не важно это код, Excel таблица, определённые и неподписанные папки с документами, в нужных местах перекрытие трубы итд. И вроде всё делают и ни к чему не подкапаешься, но делают специально так, что кроме них никто это не сделает. Хотя сама проблема или работа тривиальна.
i360u
Мне кажется, что такой "плохой" код могут позволить себе писать только очень неплохие разработчики. Потому, что сперва нужно построить архитектуру, устойчивую к такому "плохому" коду и к частым его изменениям. А это, само по себе, уже очень непросто и требует большого опыта.