Comments 27
Мне кажется, что такой "плохой" код могут позволить себе писать только очень неплохие разработчики. Потому, что сперва нужно построить архитектуру, устойчивую к такому "плохому" коду и к частым его изменениям. А это, само по себе, уже очень непросто и требует большого опыта.
Плохой совет. Есть несколько причин писать тяп-ляп.
Одноразовый код - срипты всякие там. Написал, запустил, удалил. Так себе идея, но трудозатраты должны окупаться эффектом.
Срочность - код нужен сейчас и нужен рабочим. Канает не всегда, а только если потом отрефракторишь. А как мы знаем - лень и гордыня - лучшие друзья програмиста, так что не стоит говнокодить ради скорости. Хороший программист пишет и быстро, и хорошо, а главное - мало.
В остальном - не рекомендую.
Не совсем так. Существует exporatory programming, когда проверяешь правильность идеи. У этого кода нет шансов на продакшен, и люди, которые ради скелета-идеи на 300 строк пишут тысячу строк бойлерплейта по best practice просто теряют суть exploratory programming.
Так 300 строк бойлерплейта ради идеи — это и есть плохой код.
А вести функцию вместо копипасты не только не сложнее, но ещё и время сэкономит. Просто нужна привычка.
Полностью поддерживаю! Писать "proof of concept" код с использованием лучших практик и наворачивания каких-то безумно сложных мега-масштабируемых абстракций - это значит транжирить собственное время или время заказчика/работодателя. Особенно опасно это делать на ранних стадиях стартапа.
Пишите код какой угодно, но в дев вливайте чистый.
не надо бояться писать код. а потом учиться отличать парщивый код от хорошего
Надо стараться все делать хорошо: плохо оно само получится.
Когда я вижу свой код годичной давности, который я тогда считал хорошим - мне хочется его полностью переписать.
Когда я вижу свой код двухлетней давности и еще ранее - мне хочется плакать от горя...
А самое весёлое, что так происходит у всех. Даже у тех кто десятилетия этим занимается.
Нет. Мне, как и многим ровесникам, практически всегда уже нравится свой код, написанный в последние 10-15 лет (из почти 30 в профессии) не в условиях давления дедлайном. Более того, иногда даже выскажешься в духе последних абзацев "Человека-невидимки":
— Шесть, маленькое два сверху, крестик и закорючка. Господи, вот голова была!
А я за 30 лет всё ещё постоянно недоволен своим кодом. И чувствую что буду всегда недоволен. Всегда можно сделать лучше чем уже есть. Отсюда каждый раз "конфликт желаний" - перфекционизм или "поменьше заморачиваться". "Всегда нравится свой код" было удивлением для меня прочитать. Среди коллег незнаю ни одного такого кому бы всегда нравился свой код. Прим.* Естестественно имеется ввиду не синтаксис, а структура, алгоритмы, взаимоотношения и пр.
Является ли код плохим, если он написан хорошо, но вот то, что он делает - продумано плохо?
Хороший код отличается от плохого тем, что решает больше проблем, чем создает. ) Не пишите плохой код.
Принцип SPIFE - stable, performant, intuitive, functional, extendable - работает именно в таком порядке (если, конечно, речь не о прототипе, который проверят и сотрут).
На первом месте стабильность как основа качества продукта. Продукт должен работать, не вылетать и не виснуть.
На втором производительность, в т.ч. максимальное быстродействие и оптимальное потребление ресурсов. По сути один из залогов первого принципа.
Далее идёт интуитивность работы с продуктом - чем проще с ним работать, тем лучше. Возможно, не основное для разработчика, но очень важно пользователю.
Функционал идёт позже, т.к. он может наращиваться и улучшаться итеративно, когда уже стабильно работают основные фичи.
И, наконец, расширяемость - должна присутствовать для обеспечения нового функционала.
Вывод простой - некрасивый, но функциональный, быстрый и стабильный код лучше падающего и тормозящего красавца :)
Мало того, что не понятно о каком плохом коде идет речь, так еще и суть плохого кода сводится к обучению и исследованию. При этом вывод преподносится, как будто это применимо и к результату, тому, что идет в продакшен в долгой перспективе.
В прочем, кажется мне, что мешать не стоит. Чем больше людей пишут плохой код тем крепче на ногах стоят наши качественно реализованные проекты. Можно даже подхалтурить, все равно не упадет, конкуренты все равно хуже, на плохом коде работают.
А автор знатный тролль!
Подкину ещё пунктик, чего уж стесняться. За хороший код вам заплатят один раз, а за плохой будут потом доплачивать ещё и за исправления. Оттачиваемый годами талант говнокодера состоит в том, чтобы нащупать тот хрупкий баланс, когда количество багов максимально, но не превышает тот предел терпения, за которым заказчик решает выкинуть код и начать сначала.
Бог ты мой, как это правильно. Ведь каждый день с такими сталкиваюсь. И не только в программировании. Везде. В каждом ремесле. В Германии говорят про это Kopfmonopol те. Монополия одной головы. И подразумевается именно негативный подконтекст, когда человек вокруг себя создаёт биосферу, где только он знает как в каждой ситуации справится с задачей, не важно это код, Excel таблица, определённые и неподписанные папки с документами, в нужных местах перекрытие трубы итд. И вроде всё делают и ни к чему не подкапаешься, но делают специально так, что кроме них никто это не сделает. Хотя сама проблема или работа тривиальна.
Пишите плохой код и не стыдитесь этого