Comments 15
Это всё на любителя, я топлю за грязный код. Есть два популярных алгоритма для поиска информации, деревья и хешмапы. Чистокодеры слишком заморачиваются и пилят структуру в виде дерева, мелкий скрипт на 2к строк раскидывают в 20+ файлов по 50-100 строк, тот кто этот код писал год спустя не сходу разберëтся от куда читать нужно начать и что с чем связано. Если всю логику в один фаил описать то VSCode сбоку всю структуру покажет, читать можно как сверху так и снизу, Ctrl+F быстрый поиск по ключу.
Давайте писать чистый код, если вроде все понятно! Но стоп, а почему мы вообще пишем грязный код?..
почему мы вообще пишем грязный код?
Потому что каша в голове. Мы слишком часто пишем код до того, как разобрались с задачей. Если сначала все в голове разложить по полочкам, то код будет писаться быстро и чисто. Ну и вопросы в духе "как назвать переменную" или "на какие функции поделить код" просто исчезнут, потому что у всех сущностей и действий уже будут человеко-понятные названия в голове, останется только записать их на конкретном языке. Но мы - программисты, а не аналитики, мы делаем чик-чик и в продакшен.
мы делаем чик-чик и в продакшен
Именно на этот ответ я и напрашивался. Времени очень часто не хватает.
Время - это отговорка. На самом деле, если человек не пишет чистый код, то он просто не понимает, как это сделать. Либо понимает с трудом, и над каждой строчкой думает, как её вычистить. Но при достаточной сноровке чистый код пишется быстрее, чем грязный. Главное предназначение чистого кода - снять когнитивную нагрузку с программиста во время чтения кода. А поскольку во время написания кода его приходится многократно перечитывать, то если пишешь чисто, то будешь писать быстрее.
при достаточной сноровке чистый код пишется быстрее, чем грязный
В джейсоноукладке — несомненно. В мало-мальски серьезных задачах, решение которых вообще неочевидно — отнюдь.
Значит ваша сноровка уже достаточна для того, чтобы джейсоноукладку считать простой задачей. Но ещё недостаточна для того, чтобы чувствовать себя уверенно при решении серьёзных задач.
Коллеги довольно часто просят меня помочь им, поэтому я очень много раз наблюдал за процессом создания грязного кода. Так вот, чем меньше уверенность в своих действиях, тем грязнее получается код. Терминальный случай — это когда код копируют со Stackoverflow, а потом тыкают в него палкой до тех пор, пока он хоть как-то не заработает, а потом в коде илёт смешение naming conventions, неиспользуемые переменные, отступы разные.
Ну и опять же, я замечал за собой, что если приходится писать что-то на малознакомом мне языке, то у меня почти всегда выходит грязно. Именно по причине отсутствия опыта в работе с этим языком.
Может просто голову включать когда пишешь код, советы из серии капитан очевидность не думал что об этом надо читать отдельно
Тут много, с чем хочется поспорить, но про одно смолчать просто не могу. Вот правильная регулярка для пароля:
const passwordRegex = /^.{8,}$/Во-первых, запрещать использовать UTF-8 в 2025 году — это фу, а во-вторых, люди давно уже осознали, что длинные фразы куда легче запомнить и сложнее взломать, чем эти «цифры и спецсимволы».
Так. Холивар про удалёнку на этой неделе был. Теперь будет холивар про то, пророк Дядя Боб или Антихрист. Завтра Рюмин дропнет статью про то, как кто-то нанял пролетариев за 20 тысяч отмывать пакетики с собачьими какашками, пролетарии пьют, стартапер шикует на получающиеся 40 тысяч в месяц на четверых фаундеров. Будет холивар о том, нужен ли Рюмин. Послезавтра график видимо плотный, так как нужно будет за один поругаться на тему того, дефицит или безработица на рынке труда и заменит ли нас всех ИИ (правда, про ИИ было на выходных, а сегодня выложили статью от эпигона Рюмина, но там слишком много прибыли).
Колесо Санхабры.
Статья мне понравилась, было пару моментов где я что-то не знал.
1) Ошибка в тексте «Он гораздо корочеи проще для восприятия, не так ли?» (Не знаю можно ли тебе еще редактировать)
2) Пример про смешанные уровни абстракции с принтером просто кайф, и он реально дает понять смысл.
3) НО вот практический пример #2 где мы выносим проверку строки в отдельную функцию и блок с проверкой и выбрасыванием ошибки в еще одну функцию. Это просто жесть, можно абстрагировать ради абстракции и сделать просто огромной количество кода, функций которые наоборот только запутают и поддерживать их будет все тяжелее и тяжелее со временем.
ПУГАЕТ с каким настроением ты это преподносишь, цитирую «Проверка на то, является ли тип транзакции 'UNKNOWN', конечно, не сложна для понимания, но она определённо требует большего осмысления» Большого осмысления ? Осмысления проверки строки ? Мне кажется тут надо либо поменять формулировку либо привести другой пример либо ты меня забайтил на комментарий)))
Я просто думаю никто не считает такой вид смешанной абстракции сложным и вообще проблемой. И как ты сам выразился « не стоит выделять функции просто ради самого выделения.»
Я просто представляю ситуацию человека с блокирующим приоритетом и он заходит в эту Мега-сосмыслом функцию))) или не дай бог их таких сотни…
Его же просто разорвет
Вообщем прошу тебя поменяй эту часть, как по мне очень сильно портит впечатление от статьи в целом.
Привет, не совсем согласен с тобой насчет примера с транзакциями.
1) Функция validateTransaction может заключать в себе больше логики, чем просто проверку строки "UNKNOWN". Даже в примере она также пробрасывает в себе исключение, см. раздел про ошибки.
2) Даже если функция просто проверяет какое-то условие, как например:
transaction.type === 'PAYMENT' - в этом нет ничего плохого. Подобные проверки различных условий повторяются в приложении и удобно просто переиспользовать готовую функцию, а не писать каждый раз заново transaction.type === TransactionsTypes.Payment импортируя enum и т.д. К тому же, это полезный прием рефакторинга, (см. Мартин Фаулер "Рефакторинг Javascript") Замена переменой запросом, чтобы не злоупотреблять локальными переменными
Тема сугубо субъективная и не является призывом писать именно так и никак иначе, просто делюсь размышлениями на этот счет
Лично я часто пишу первую версию грязно, потому что на обдумывание грамотной архитектуры тупо нет времени. Лепишь просто какой-то нереальный треш в одну страницу. Так очень легко дебагать, все в одном месте. А потом когда уже все нормально работает и начинаешь масштабироваться и дублировать кучу кода - делаешь рефакторинг. Мне кажется, это здоровый подход, если речь о бизнесе, где каждый твой час - это реальные деньги
Программирование — это искусство находить золотую середину между стремлением к идеальному коду и реальными ограничениями времени.
Неправильное понимание сути вопроса. А вопрос не в ограничении по времени, а в угадывании хотелок клиента (удачности заложенной под его хотелки архитектуры) , возможностях выбранного языка, долговечности выбранный технологий.
Сама постановка вопроса звучит глупо. Совершенный код есть здесь и сейчас. Завтра это уже будет говнокод)
Чистый код