Как работает чистый код
Как работает чистый код? Ниже моё облыжное мнение о том, почему «Чистый код» — чистой воды инфоцыганщина, и почему если вы слышите в аргументации собеседника эти слова — нужно бежать, ведь разговаривать с зомби бессмысленно. Click to reveal the Clean Rant
https://habr.com/ru/articles/983334/
#чистый_код #clean_code #паттерны #парадигмы #идиоматичный_код
Чистый код на React: практики, которые делают проект поддерживаемым
В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений. В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.
[Перевод] Не делайте рефакторинг как Дядя Боб (вторая редакция)
Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко. Возможно, причиной восторга стала мысль о том, что я смогу снова разнести его примеры кода, как сделал в своей первой статье. Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО. А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад. Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать). Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче! Невероятно! Но я забегаю вперёд…
https://habr.com/ru/companies/ruvds/articles/973104/
#ruvds_перевод #рефакторинг #дядя_боб #чистый_код #программирование #java #роберт_мартин
[Перевод] Не делайте рефакторинг как дядя Боб. Я вас умоляю
Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования. В итоге его практики переняли многие разработчики, одни из которых почитают их как святыни, а другие воспринимают, скорее, в качестве ориентиров, нежели строгих правил. Но, как бы вы к этому ни относились, сам дядя Боб смотрит на них не как на руководства. Он следует этим практикам всецело и очень редко допускает исключения. Так что можно подумать, что его примеры рефакторинга из книги как минимум окажутся лучше среднего кода, который вы встречаете в повседневной работе, или хотя бы будут согласовываться с другими распространёнными советами. Можно подумать...
#ruvds_перевод #дядя_боб #мартин_роберт #чистый_код #рефакторинг #java
[Перевод] Не делайте рефакторинг как дядя Боб. Я вас умоляю
Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования. В итоге его практики переняли многие разработчики, одни из которых почитают их как святыни, а другие воспринимают, скорее, в качестве ориентиров, нежели строгих правил. Но, как бы вы к этому ни относились, сам дядя Боб смотрит на них не как на руководства. Он следует этим практикам всецело и очень редко допускает исключения. Так что можно подумать, что его примеры рефакторинга из книги как минимум окажутся лучше среднего кода, который вы встречаете в повседневной работе, или хотя бы будут согласовываться с другими распространёнными советами. Можно подумать...
https://habr.com/ru/companies/ruvds/articles/970488/
#ruvds_перевод #дядя_боб #мартин_роберт #чистый_код #рефакторинг #java
О современной разработке. Часть 1: Моки — это технический долг
Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад. На тот момент я, еще студент последнего курса универа, только получил свою первую работу в IT... Как сейчас помню свои эмоции. Наконец-то, спустя годы подготовок и отказов, вот, наконец получаешь свойпервый «настоящий» проект. Осмотревшись по сторонам, понимаю, что кругом меня не то что других джунов нет, но даже мидлов. Сплошные синьоры и лиды, как тогда казалось — грозные дядьки, с большим опытом... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂. Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает? Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.
https://habr.com/ru/articles/969926/
#разработка_приложений #тестирование_по #java #kotlin #mock #чистый_код #качество_кода #mockito #mocking_objects
Главная проблема «чистых архитектур»
Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются. Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».
https://habr.com/ru/articles/965812/?utm_source=habrahabr&utm_medium=rss&utm_campaign=965812
#чистый_код #айти #разработка #бекенд #фронтенд #backend #frontend #архитектура #чистая_архитектура #it
Главная проблема «чистых архитектур»
Откройте любой пулл-реквест в проекте с любой "чистой архитектурой" и вы скорее всего увидите не обсуждение бизнес-логики, а срач. "Это нельзя класть в UseCase, это логика домена!", "Зачем тут еще один DTO, мы же просто поле прокидываем!", "Этот интерфейс не нужен, у нас никогда не будет другой реализации!". Полагаю, очень много людей с таким сталкиваются. Эта статья - о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, - как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не "следует всем концепциям".
https://habr.com/ru/articles/965812/
#чистый_код #айти #разработка #бекенд #фронтенд #backend #frontend #архитектура #чистая_архитектура #it
Как техдолг убивает и спасает проекты одновременно
Технический долг - неизбежная часть любого проекта. С течением времени даже хорошо написанный код может стать сложным для понимания и сопровождения. Часто разработчики, сталкиваясь с чужим или собственным кодом, испытывают отвращение - и только после проверки истории изменений гита понимают, что автором кода являлись они же. Эта статья - не лекция. В интернете полно материалов про технический долг с графиками, квадратиками и теориями. Будем честны: большинство просто игнорирует его. Здесь мы попробуем посмотреть на технический долг так, как он есть на практике - как финансовый инструмент . Как кредитная карта с высоким процентом и мелким шрифтом: ею можно пользоваться, чтобы держаться на плаву, но потеря контроля может стоить проекту слишком дорого. Так и как же им управлять?
https://habr.com/ru/articles/963876/
#чистый_код #разработка #айти #фронтенд #бекенд #backend #frotend #качество_кода #it #информационные_технологии
Как пробить днище проекта техдолгом без смс и регистрации
Вот давайте начистоту. Открываешь ты такой таск, видишь кусок кода, написанный полгода назад, и твоя первая мысль - "Господи, какой идиот это писал?". Потом git blame показывает твое имя. Классика. Этот момент, когда ты встречаешься со своим техническим долгом лицом к лицу. В сети полно статей, где техдолг раскладывают по квадрантам, рисуют красивые графики и сыплют терминами, от которых хочется заснуть. Это все академическая чушь, которая почти всегда бесполезна в реальной разработке, когда у тебя дедлайн вчера, а продакт принес еще пачку "гениальных" идей с интеграцией единорогов прямо в UI. Эта статья - не очередная лекция. Это попытка поговорить о техдолге как о том, чем он и является - финансовом инструменте. Как кредитная карта с конским процентом и мелким шрифтом в договоре. Ты можешь использовать ее, чтобы выжить, но если потеряешь контроль - она сожрет тебя и твой проект.
https://habr.com/ru/articles/962916/
#IT #качество_кода #техдолг #техподдержка #backend #frontend #разработка #itинфраструктура #чистый_код #продукт
Будет ли важна чистота кода в ближайшем будущем
В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят. Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы. Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем». Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
ORM в Node.js — когда от него больше вреда чем пользы. Почему вам, не нужен дополнительный абстрактный слой
Object-Relational Mapping (ORM) — технология, призванная «поженить» реляционную природу SQL-баз (PostgreSQL, MySQL, SQLite и т.п.) с объектной моделью языков программирования. Она настолько популярна, что её пытаются реализовать даже в необъектных языках — например, в Go или Erlang. Если в Java без ORM действительно неудобно, то в экосистеме Node.js (и TypeScript в частности) ситуация принципиально иная. И ORM здесь — зачастую избыточная абстракция. В большинстве случаев рациональнее обойтись компактным SQL-билдером который сильно упрощает построение запросов, оставляя над ними полный контроль, и который совсем не занимается управлением объектами. Почему в Node.js ORM почти не даёт преимуществ...
https://habr.com/ru/articles/959518/
#orm #typescript #javascript #nodejs #sql #чистый_код #чистая_архитектура #базы_данных
TypeScript или Rust: когда переписывать сервис и какие выигрыши ждать
Вы тоже хоть раз ловили себя на мысли: «А может, ну его, этот Node.js — перепишем всё на Rust, и будет летать?» Поздравляю — вы не одиноки. Я тоже через это прошёл. В этой статье я разложу по полочкам, когда действительно стоит лезть в Rust , а когда лучше остаться на TypeScript и просто выспаться. Без фанатизма, маркетинга и с примерами из практики.
https://habr.com/ru/articles/954872/
#javascript #архитектура #фреймфорки #программирование #react #solid #принципы_разработки #вебразработа #чистый_код #легаси
Борьба с техническими долгами: как не допустить разрастания костылей в коде
Привет, Хабр! (И тебе, отчаянный страдалец, зашедший сюда в перерыве между дебагом очередного if (a == b) { return true; } else { return false; } . Мы знаем, ты не виноват, так вышло). Каждый разработчик хоть раз в жизни прилаживал к своему коду «костыль». Знакомое чувство, правда?
https://habr.com/ru/articles/950016/
#костыли #баги #чистый_код #разработка #python #javascript #1с #битрикс #архитектура #c++
Как упростить разработку: опыт и размышления (компиляция из моей переписки)
В процессе разработки программного обеспечения часто возникает вопрос: нужно ли заранее проектировать структуру кода и устанавливать строгие правила, чтобы облегчить работу команды? Недавний диалог между разработчиками Азазелем и Сашей проливает свет на этот вопрос и предлагает интересный взгляд на организацию процесса разработки. Азазель предложил идею, которая кажется логичной и полезной:
https://habr.com/ru/articles/944946/
#разработка #структура #взаимодействие #команда #документация #проектирование #чистый_код #понятность #стандарты
Скрытая грамматика: почему len() — это полисемия, а хороший код — набор идиом. Как филология объясняет «чистый код»
Оживленная дискуссия под моей первой статьей ( https://habr.com/ru/articles/940782/ ) показала: разговор о единстве языка со сферой программирования задевает многих за живое. Тем не менее, cпасибо всем за сотню комментариев, сохранений и невероятно полезного и ценного опыта! Однако язык — это не просто словарь, а динамическая система, в которой слова живут, взаимодействуют и порождают смыслы, выходящие за пределы их словарных значений. Следующим логическим шагом, таким образом, становится переход от статики «слова» (имени) к динамике «высказывания» (кода в действии). Вместе с тем один из наиболее сильных и частых аргументов от скептиков звучал примерно так: «весь код — это чистая, бездушная логика для машины». На мой взгляд, это самое большое заблуждение в этой индустрии. Знали ли вы, что оператор + в вашем коде семантически богаче, чем многие слова в русском языке? Или что конструкция if not my_list — это не просто синтаксис, а настоящая идиома, которая отделяет «носителя языка» от «иностранца»? Задача настоящей работы — исследовать, как в строго детерминированной среде кода возникают сложнейшие семантико-прагматические явления, свойственные живому языку. Давайте забудем про имена и заглянем в самое сердце кода — в его грамматику и риторику. Пристегните ремни безопасности :)
https://habr.com/ru/articles/941110/
#цифровая_филология #лингвистика #чистый_код #читаемость #идиомы #космотекст
SOLID для начинающих Unity-разработчиков: простыми словами и с примерами из жизни
SOLID для начинающих Unity-разработчиков. Разбираю 5 принципов программирования через аналогии из жизни. Каждый принцип - с примерами кода на C# .
https://habr.com/ru/articles/940620/
#solid #unity #c# #просто_о_сложном #принципы_программирования #чистый_код #для_начинающих #разработка_игр
Почему лучшие программисты — это филологи (сами того не подозревая). Что общего у переменной temp и прозвища «Очкарик»?
Привет, Хабр! Меня зовут Артем Лакомов, я филолог из МГУ. Да, вы не ослышались. И сегодня я хочу поговорить с вами о самой главной (и самой дорогой) боли в IT, но с совершенно неожиданной стороны. Каждый из вас хоть раз в жизни видел код, от которого хотелось плакать или же тихо ненавидеть свою работу. Код с переменными вроде data, res, temp. Код, где есть один гигантский класс, который делает абсолютно всё, и коллеги с любовью (или ужасом) называют его godObject. Все привыкли думать, что это просто «плохой стиль» или «технический долг». Но что, если я скажу вам, что это — не техническая, а языковая проблема? И что у монструозного godObject гораздо больше общего со школьным прозвищем «Толстый» , чем вы думаете? Последние несколько лет я занимаюсь тем, что применяю классическую лингвистику к программному коду. И я обнаружил поразительную вещь: правила, по которым вы даете имена переменным и классам, практически дословно повторяют законы, по которым в любом человеческом коллективе — от школьного класса до команды разработчиков — возникают прозвища. Давайте я покажу вам, как теория прозвищ, разработанная великим отечественным лингвистом А.В. Суперанской, вскрывает то, о чем инженеры только догадывались интуитивно, но, увы, не могли сформулировать.
https://habr.com/ru/articles/940782/
#цифровая_филология #коммуникация #лингвистика #чистый_код #именование #космотекст #компетенции_тимлида
SOLID: Шпаргалка для собеседования и работы
Краткая шпаргалка с определениями принципов. Под катом плюсы/минусы SOLID, чтоб пройти собеседование на мидла\сеньора\архитектора, а в работе принять осознанное решение: «Применять ли здесь SOLID?»
https://habr.com/ru/articles/935926/
#solid #чистый_код #принципы #ооп #собеседование #собеседование_вопросы #проектирование
[Перевод] Думай как компилятор: позиции и значения в Rust
Некоторое время назад мне попался в Интернете вопрос о таком синтаксисе в Rust: *pointer_of_some_kind = blah; Автору вопроса было интересно, как компилятор понимает такой код, особенно, если в данном случае используется не ссылка, а умный указатель. Я написал ему пространный ответ, но потом подумал, что стоило бы ещё развернуть этот текст и переработать в статью для блога, на случай, если такой вопрос интересует и более широкую аудиторию. В настоящее время я не работаю над компилятором Rust и, в сущности, никогда не работал, но семантику языка я знаю хорошо. Если вы корифей Rust, то этот пост может быть вам не слишком интересен, разве что вы хотели бы подробнее разобраться с категориями значений в Rust. Но, если вы не так много времени тратите на изучение тонких нюансов языков программирования — надеюсь, вам понравится одним глазочком заглянуть в этот мир.
