#чистый_код — Public Fediverse posts

Обработка исключений, возникших при обработке исключений

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch ? Там ведь код тривиальный! Но это только на первый взгляд. Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

https://habr.com/ru/articles/1035762/

#безопасное_программирование #чистый_код #обработка_исключений

0.0023 секунды на генерацию: зачем я собрал «стальной» движок на PHP в эпоху жирных CMS

Превед участникам регаты! Все началось в те времена, когда интернет был диким, модемы выли, а тру-кодеры мерили крутость не количеством звёздочек на Гитхабе, а чистотой своего кода и умением впихнуть невпихуемое в пару килобайт. Я начинал вариться в кодинге ещё в золотую эпоху RUWAP (2007–2014гг). Потом был перерыв, и вот, год назад я решил вернуться. Зайдя в современную веб-разработку, я испытал культурный шок. Простые визитки и блоги теперь весят мегабайты, тянут за собой гигабайты зависимостей из npm и ворочаются на сервере по полсекунды. Ангуляры, Реакты, монструозные Drupal и WordPress — всё это превратило веб в вязкое болото. Нам с моей напарницей-нейросетью Асси (Аськой) стало тошно. «Низачот!» — подумали мы.

https://habr.com/ru/articles/1020412/

#вебразработа #ииассистент #cms #php #css #производительность #оптимизация #антибот #наследие #чистый_код

Как я отсеиваю 90% кандидатов одной архитектурной задачей

Всем привет! Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода. Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами. Надеюсь, она будет вам полезна!

https://habr.com/ru/articles/1015160/

#собеседование #архитектура #solid #чистый_код #чистая_архитектура #интервью #оценка_кандидатов #найм_разработчиков #отсев_кандидатов

Как я отсеиваю 90% кандидатов одной архитектурной задачей

Всем привет! Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода. Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами. Надеюсь, она будет вам полезна!

https://habr.com/ru/articles/1015160/

#собеседование #архитектура #solid #чистый_код #чистая_архитектура #интервью #оценка_кандидатов #найм_разработчиков #отсев_кандидатов

Как я отсеиваю 90% кандидатов одной архитектурной задачей

Всем привет! Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода. Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами. Надеюсь, она будет вам полезна!

https://habr.com/ru/articles/1015160/

#собеседование #архитектура #solid #чистый_код #чистая_архитектура #интервью #оценка_кандидатов #найм_разработчиков #отсев_кандидатов

Как я отсеиваю 90% кандидатов одной архитектурной задачей

Всем привет! Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода. Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами. Надеюсь, она будет вам полезна!

https://habr.com/ru/articles/1015160/

#собеседование #архитектура #solid #чистый_код #чистая_архитектура #интервью #оценка_кандидатов #найм_разработчиков #отсев_кандидатов

Cucumber должен умереть: Как с помощью BDR превратить код в отчеты без регулярок и регистрации?

В прошлой статье «Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?» мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход. Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации... Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты. Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting) . Почему классический BDD (Gherkin) - это ошибка? Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

https://habr.com/ru/articles/994732/

#playwright #bdr #bdd #allure_report #qa_automation #чистый_код #автотесты #автотестирование #автотестировщик #автоматизация_тестирования

Как работает чистый код

Как работает чистый код? Ниже моё облыжное мнение о том, почему «Чистый код» — чистой воды инфоцыганщина, и почему если вы слышите в аргументации собеседника эти слова — нужно бежать, ведь разговаривать с зомби бессмысленно. Click to reveal the Clean Rant

https://habr.com/ru/articles/983334/

#чистый_код #clean_code #паттерны #парадигмы #идиоматичный_код

Чистый код на React: практики, которые делают проект поддерживаемым

В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений. В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.

https://habr.com/ru/articles/981846/

#react #чистый_код #архитектура_фронтенда

[Перевод] Не делайте рефакторинг как Дядя Боб (вторая редакция)

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко. Возможно, причиной восторга стала мысль о том, что я смогу снова разнести его примеры кода, как сделал в своей первой статье. Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО. А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад. Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать). Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче! Невероятно! Но я забегаю вперёд…

https://habr.com/ru/companies/ruvds/articles/973104/

#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/

#чистый_код #айти #разработка #бекенд #фронтенд #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 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы. Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем». Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.

https://habr.com/ru/articles/962528/

#чистый_код #искусственный_интеллект #бизнеспроцессы

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/

#разработка #структура #взаимодействие #команда #документация #проектирование #чистый_код #понятность #стандарты

Как упростить разработку: опыт и размышления (компиляция из моей переписки)

В процессе разработки программного обеспечения часто возникает вопрос: нужно ли заранее проектировать структуру кода и устанавливать строгие правила, чтобы облегчить работу команды? Недавний диалог между разработчиками Азазелем и Сашей проливает свет на этот вопрос и предлагает интересный взгляд на организацию процесса разработки. Азазель предложил идею, которая кажется логичной и полезной:

https://habr.com/ru/articles/944946/

#разработка #структура #взаимодействие #команда #документация #проектирование #чистый_код #понятность #стандарты

Как упростить разработку: опыт и размышления (компиляция из моей переписки)

В процессе разработки программного обеспечения часто возникает вопрос: нужно ли заранее проектировать структуру кода и устанавливать строгие правила, чтобы облегчить работу команды? Недавний диалог между разработчиками Азазелем и Сашей проливает свет на этот вопрос и предлагает интересный взгляд на организацию процесса разработки. Азазель предложил идею, которая кажется логичной и полезной:

https://habr.com/ru/articles/944946/

#разработка #структура #взаимодействие #команда #документация #проектирование #чистый_код #понятность #стандарты

Как упростить разработку: опыт и размышления (компиляция из моей переписки)

В процессе разработки программного обеспечения часто возникает вопрос: нужно ли заранее проектировать структуру кода и устанавливать строгие правила, чтобы облегчить работу команды? Недавний диалог между разработчиками Азазелем и Сашей проливает свет на этот вопрос и предлагает интересный взгляд на организацию процесса разработки. Азазель предложил идею, которая кажется логичной и полезной:

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. Но, если вы не так много времени тратите на изучение тонких нюансов языков программирования — надеюсь, вам понравится одним глазочком заглянуть в этот мир.

https://habr.com/ru/articles/935568/

#Rust #C++ #rvalue #lvalue #чистый_код

Оверинжиниринг: простое сложным языком

Оверинжиниринг — это когда простую задачу решают так, словно строят космический корабль: с абстракциями, фабриками и паттернами «на будущее». Разбираем живые примеры, почему так происходит и как находить баланс между гибкостью и простотой.

https://habr.com/ru/articles/933412/

#оверинжиниринг #архитектура #чистый_код #паттерны_проектирования #паттерны_программирования #kiss #yagni #тестирование #python #антипаттерны

Как писать красивый и чистый код питонистам?

Статья рассказывает, как писать чистый и понятный код на Python. Освещены ключевые темы: правильные именования переменных, грамотное комментирование и докстринги, логическое разделение кода (внутри файла и на модули), использование типизации для ясности, а также обработка ошибок через исключения вместо магических значений. Советы помогут новичкам и опытным разработчикам делать код читаемым и поддерживаемым.

https://habr.com/ru/articles/925620/

#python #python3 #программирование #чистый_код #гигиена_кода

Java. Практические советы по написанию чистого кода

Привет, Хабр! Давайте сегодня обсудим качественный код. Конечно, основные принципы очевидны: читаемость, поддерживаемость, эффективность. Но в этой статье я хочу поделиться не сухой теорией, а практическими приемами, которые мы с коллегами выработали в процессе наставничества над начинающими автотестировщиками. У нас сформировалось несколько рекомендаций и лайфхаков, о которых я расскажу далее.

https://habr.com/ru/companies/reksoft/articles/924350/

#тестирование #чистый_код #стандарты_разработки #практика_использования #начинающим_автотестировщиками #лайфхаки

Прочитал «Чистый код», чтобы вам не пришлось

Пересказываю культовую книгу Роберта Мартина "Чистый код" с примерами на C#. Узнайте, как создавать код, который читается как проза: от магии имен переменных и идеальных функций до безупречных тестов и архитектуры, которая не рухнет при первом требовании заказчика. Полный гид, ваш код станет предметом гордости, а не источником кошмаров.

https://habr.com/ru/articles/922424/

#Чистый_код #роберт_мартин #полезно #техники_написания_кода #код #программирование #архитектура

Как NASA ошиблись в исходном коде планеты

Баги в коде — явление нередкое, но сегодня мы исследуем не просто ошибки, а настоящие космические баги! Что скрывает проект, созданный в недрах NASA? Готовьте свои шапочки из фольги! Поехали!

https://habr.com/ru/companies/pvs-studio/articles/915850/

#статический_анализ #pvsstudio #java #nasa #open_source #static_analysis #чистый_код #совершенный_код

Go-микросервисы: Стандартизация архитектуры с Clean Architecture и DDD

Go-разработчики часто сталкиваются с парадоксом: изначально простой и понятный проект со временем превращается в сложный для поддержки монолит. ✔️ Бизнес-логика оказывается размазана между слоями? ✔️ Замена базы данных требует переписывания половины кода? ✔️ Новым разработчикам требуется недели, чтобы разобраться в проекте? В этой статье мы разбираем практическое применение DDD и Clean Architecture в Go . Обсуждаем возможный стандарт структуры микросервиса . Оптимизируем существующие. 🔥 Для разработчиков, которые хотят создавать проекты, остающиеся поддерживаемыми даже через годы развития.

https://habr.com/ru/articles/911018/

#clean_architecture #domain_driven_design #ddd #golang #разработка #архитектура #стандарт_golang #чистый_код #чистая_архитектура #паттерны_разработки

В поисках хорошего стиля. Часть 2. Пишем свой линтер на Go для golangci-lint

Привет! Меня зовут Артём Блохин, я Go-разработчик в команде интеграций Островка. Сегодня поговорим о линтинге кода. Если бы «Сумерки» были про код, Эдвард — был линтером, а Белла — легаси-кодом, их диалог звучал бы так:

https://habr.com/ru/companies/ostrovok/articles/908768/

#golang #golangcilint #линтер #статический_анализ #анализ_кода #ast #чистый_код #островок #styleguide #плагины

Разбираем архитектуру. Часть 1. Чистая архитектура и её корни: история и взаимосвязи

Предисловие Цель этой статьи - объединить и кратко изложить все базовые архитектурные подходы: их терминологию, концепции и отличительные черты. Собрать всё воедино, чтобы можно было относительно быстро вникнуть в основы. Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose. Однако по мере проработки деталей стало очевидно: чтобы обсуждать структуру приложения предметно и аргументированно, необходимо сначала заложить общую теоретическую основу, чтобы читатель понимал, о чем речь. Так родилась идея вынести базовые концепции архитектуры и проектирования в отдельную публикацию — не перегружать материал сразу всем, а построить серию объёмных, но логично связанных статей.

https://habr.com/ru/articles/905148/

#чистая_архитектура #чистый_код #ооп #проектирование_систем #терминология #шаблоны_проектирования #луковичная_архитектура #гексагональная_архитектура #solid #grasp

GRASP: почему настоящая архитектура начинается не с SOLID

Хочу начать с личной предыстории. Давным-давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие. Также не обошли меня и классические принципы проектирования — SOLID , KISS , DRY — и, думаю, каждый читатель добавит сюда свои. Безусловно, это всё важные и фундаментальные вещи. Но однажды на горизонте появилось DDD — предметно-ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления. Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах. Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает? Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты-значения, спецификации, фабрики и т.д. — но не учит проектировать саму предметную область . Складывалось ощущение, что мы это уже откуда-то должны были знать . А откуда — остаётся загадкой.

https://habr.com/ru/articles/900140/

#GRASP #паттерны_проектирования #архитектура #DDD #SOLID #OOP #чистая_архитектура #чистый_код

Моем Код с Мылом

Разберём ключевые принципы именования переменных, проектирования функций и других аспектов, чтобы писать код, который будет понятен вам и вашей команде спустя годы. Читать!

https://habr.com/ru/articles/882794/

#clean_code #чистый_код #роберт_мартин #обзор #обзор_книги #читабельность_кода #читаемый_код #поддержка_кода

Основы чистого кода на Python (PEP8, SOLID, ООП) ::: часть 1

Когда вы уже написали несколько своих небольших пет-проектов, вы начинаете понимать что чистый код, архитектура и другие паттерны программирования начинают иметь смысл. В масштабируемых, командный или коммерческих проектах это несет особую ценность. Изучив эти принципы, новички получат представление о построении надежных, гибких и легко тестируемых приложений, что позволит им сохранить ясность кодовой базы и возможность ее сопровождения по мере роста их проектов. В этой статье мы разберем: что такое PEP8, что такое SOLID и какие есть правила написания чистого кода. А во второй части мы разберем что такое poetry, тесты и методологии разработки.

https://habr.com/ru/articles/836678/

#python #clean_code #clean_architecture #pep8 #SOLID #DRY #KISS #unixway #чистый_код #ООП

Костыли из 90-х и принцип HTML First

Кадр из презентации Frontmania 2022: Kilian Valkhof — Stop using JavaScript for that Недавно на Хабре публиковался перевод статьи «Вам не нужен для этого JavaScript» с примерами, где код JS легко заменить на HTML. На самом деле возврат к основам HTML, простым сайтам и читаемому коду без сложных фреймворков — довольно популярная идея. Сейчас всё больше сайтов создаётся по принципу HTML First .

https://habr.com/ru/companies/ruvds/articles/793680/

#ruvds_статьи #HTML #CSS #JS #JSSS #костыли #Netscape_Navigator #PWA #SVG #GSAP #Svija_Vibe #HTML_First #React #чистый_код #WASM #WebAssembly #Tailwind #Tachyons #hyperscript #Alpine

[Перевод] Грязный код

Эдсгер Дейкстра: «Грязно и быстро — мне это не понравится» «Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code В этом эссе я хочу рассказать о том, как пишу код. Я буду называть свою методику «грязным кодом», потому что часто нарушаю рекомендации «чистого кода» — популярной концепции написания кода. Вообще, я на самом деле не считаю свой код абсолютно грязным: местами он немного уродлив, но по большей части я им доволен, и он достаточно прост в поддержке, обеспечивая при этом разумные уровни качества. Кроме того, я не пытаюсь своим эссе убедить вас писать грязный код. Скорее, я хочу показать, что таким способом можно писать достаточно успешное ПО, и, надеюсь обеспечить некий баланс в обсуждениях методологий разработки ПО. Я программирую уже довольно давно и видел разнообразные подходы к обеспечению работоспособности ПО. Кто-то любит объектно-ориентированное программирование (я тоже), другие умные люди его ненавидят. Кому-то нравится выразительность динамических языков, кого-то она бесит. Кто-то успешно выпускает программы, строго следуя концепции Test Driven Development, другие добавляют в конце проекта несколько сквозных тестов, а многие остаются где-то посередине этих крайних точек. Я был свидетелем проектов, выпускавших и поддерживавших успешное ПО на основе всех этих разнообразных подходов. Поэтому повторюсь, что моя цель не убедить вас, что мой способ кодинга единственно возможный, а показать вам (и в особенности начинающим разработчикам, которых легко запугать терминами наподобие «чистого кода»), что можно иметь успешную карьеру программиста, пользуясь множеством различных подходов, и что мой — один из них.

https://habr.com/ru/companies/ruvds/articles/865026/

#htmx #чистый_код #принцип_единой_ответственности #test_driven_development #юниттесты #интеграционные_тесты #ruvds_переводы

Make It Right! Максимум пользы, минимум проблем: рекомендации по написанию API автотестов на Python

Привет, Хабр! Меня зовут Катерина, я инженер по автотестированию в команде онлайн-кинотеатра PREMIER и сегодня я хотела бы поделиться с вами своим опытом в написании API автотестов на Python. Я работаю в сфере автотестирования уже довольно давно и на практике встречаю проекты из разных сфер деятельности (банкинг, ритейл, телекоммуникации, строительство, развлечения и др.) зачастую, работая над ними, я сталкивалась с одной общей проблемой - код автотестов был тяжелым в понимании и плохо масштабируемым. Приходилось его капитально рефакторить, а это совсем невесело;) В этой статье я хочу поделиться советами, как сделать ваш код более «чистым», легким в понимании и расширении. Мне всегда хочется думать, что тот, кто будет работать с моим кодом в будущем, будет думать обо мне и моём коде в положительном ключе, а не ругаться на него. Если вы разделяете мою философию, прошу под кат.

https://habr.com/ru/companies/gazprommedia/articles/772888/

#python #pytest #qa_automation #api_testing #тестирование #автоматизированное_тестирование #codestyle #чистый_код #тестирование_вебсервисов

CodeStyle на Flutter-проектах: базовые принципы и правила — шаблон на все случаи жизни

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. Хочу в очередной раз поднять важную тему — CodeStyle. Думаю, что все понимают преимущества единообразного, понятного, красивого кода. Но к сожалению, оформить единые правила для всей команды — это большая задача, и выделить на нее время получается не всегда. Мы решили эту ситуацию изменить. Недавно я осознал, как сильно раздражает разбираться с долгосрочными проектами, которые мы развиваем годами. За это время команда неизбежно меняется, и каждый разработчик привносит свой уникальный стиль. Как результат, понять, что хотел сделать предыдущий автор, бывает настоящим испытанием. Именно поэтому мы с коллегами решили внедрить единый стандарт разработки, которым я теперь делюсь с читателями Хабра. Надеюсь, собранные здесь правила помогут вам сэкономить пару-тройку рабочих часов, но главное — сберегут нервы.

https://habr.com/ru/companies/agima/articles/873576/

#codestyle #flutter #dart #мобильная_разработка #чистый_код #bloc_flutter #литеры_для_flutter #автоматизация_кода

CodeStyle на Flutter-проектах: базовые принципы и правила — шаблон на все случаи жизни

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. Хочу в очередной раз поднять важную тему — CodeStyle. Думаю, что все понимают преимущества единообразного, понятного, красивого кода. Но к сожалению, оформить единые правила для всей команды — это большая задача, и выделить на нее время получается не всегда. Мы решили эту ситуацию изменить. Недавно я осознал, как сильно раздражает разбираться с долгосрочными проектами, которые мы развиваем годами. За это время команда неизбежно меняется, и каждый разработчик привносит свой уникальный стиль. Как результат, понять, что хотел сделать предыдущий автор, бывает настоящим испытанием. Именно поэтому мы с коллегами решили внедрить единый стандарт разработки, которым я теперь делюсь с читателями Хабра. Надеюсь, собранные здесь правила помогут вам сэкономить пару-тройку рабочих часов, но главное — сберегут нервы.

https://habr.com/ru/companies/agima/articles/873576/

#codestyle #flutter #dart #мобильная_разработка #чистый_код #bloc_flutter #литеры_для_flutter #автоматизация_кода

CodeStyle на Flutter-проектах: базовые принципы и правила — шаблон на все случаи жизни

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. Хочу в очередной раз поднять важную тему — CodeStyle. Думаю, что все понимают преимущества единообразного, понятного, красивого кода. Но к сожалению, оформить единые правила для всей команды — это большая задача, и выделить на нее время получается не всегда. Мы решили эту ситуацию изменить. Недавно я осознал, как сильно раздражает разбираться с долгосрочными проектами, которые мы развиваем годами. За это время команда неизбежно меняется, и каждый разработчик привносит свой уникальный стиль. Как результат, понять, что хотел сделать предыдущий автор, бывает настоящим испытанием. Именно поэтому мы с коллегами решили внедрить единый стандарт разработки, которым я теперь делюсь с читателями Хабра. Надеюсь, собранные здесь правила помогут вам сэкономить пару-тройку рабочих часов, но главное — сберегут нервы.

https://habr.com/ru/companies/agima/articles/873576/

#codestyle #flutter #dart #мобильная_разработка #чистый_код #bloc_flutter #литеры_для_flutter #автоматизация_кода

CodeStyle на Flutter-проектах: базовые принципы и правила — шаблон на все случаи жизни

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. Хочу в очередной раз поднять важную тему — CodeStyle. Думаю, что все понимают преимущества единообразного, понятного, красивого кода. Но к сожалению, оформить единые правила для всей команды — это большая задача, и выделить на нее время получается не всегда. Мы решили эту ситуацию изменить. Недавно я осознал, как сильно раздражает разбираться с долгосрочными проектами, которые мы развиваем годами. За это время команда неизбежно меняется, и каждый разработчик привносит свой уникальный стиль. Как результат, понять, что хотел сделать предыдущий автор, бывает настоящим испытанием. Именно поэтому мы с коллегами решили внедрить единый стандарт разработки, которым я теперь делюсь с читателями Хабра. Надеюсь, собранные здесь правила помогут вам сэкономить пару-тройку рабочих часов, но главное — сберегут нервы.

https://habr.com/ru/companies/agima/articles/873576/

#codestyle #flutter #dart #мобильная_разработка #чистый_код #bloc_flutter #литеры_для_flutter #автоматизация_кода

Лучшие практики создания отказоустойчивых систем

Разработка отказоустойчивых систем представляет собой важнейшую компетенцию для инженеров, занятых созданием распределённых и масштабируемых приложений. Под отказоустойчивостью понимается способность системы сохранять работоспособность в условиях сбоев отдельных компонентов или недоступности внешних сервисов. В данной статье рассматриваются практики обеспечения устойчивости на уровне программного кода, в частности в контексте серверных приложений, реализованных на языках Python и Java. Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.

https://habr.com/ru/articles/896638/

#python #java #spring_boot #aiohttp #безопасность #отказоустойчивые_системы #отказоустойчивость #чистый_код

Лучшие практики TypeScript: Строгая типизация, гибкость и производительность

TypeScript давно стал неотъемлемой частью современного фронтенда, но чтобы действительно раскрыть его возможности и избежать подводных камней, важен опыт и осознанное применение его возможностей. В этой статье мы рассмотрим углубленные практики работы с TypeScript, которые могут улучшить производительность и читаемость кода в крупных проектах.

https://habr.com/ru/articles/859016/

#typescript #best_practices #типизация #Frontend #дженерики #Утилитарные_типы #чистый_код #javascript #types

Полезные практики написания поддерживаемого кода на PHP

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

https://habr.com/ru/articles/814995/

#php #symfony #dependency_injection #best_practices #чистый_код

Графические оболочки FFmpeg

Считается, что работа в консоли эффективнее GUI по нескольким причинам. Во-первых, там быстрее набирать команды, чем двигать курсором. Во-вторых, на CPU, память и GPU не ложится лишнее бремя графической оболочки, так что любые процессы быстрее выполняются в консоли. Но есть люди, которые всегда предпочтут GUI . Они считают графический интерфейс «наиболее эффективным и удобным способом работы на десктопе». На самом деле они во многом правы, в том числе для специфических задач видеообработки важно сразу видеть результат. FFmpeg — изначально консольная утилита. Но её популярность крайне высока. Поэтому появляются всё новые варианты графических оболочек для FFmpeg, чтобы доступ к инструменту получили абсолютно все пользователи.

https://habr.com/ru/companies/ruvds/articles/778262/

#ruvds_статьи #ffmpeg #графические_оболочки #GUI #транскодинг #многопоточность #чистый_код #Антон_Кирнов #FFmpeg_61 #VapourSynth #Staxrip #LosslessCut #Shotcut #KDEnlive #H264 #HEVC #AV1 #ffmpegwasm