Совершенный код *

В публикации речь пойдет о подходах в разработке ПО. Речь пойдет о некой компании, которой никогда не существовало и порядки, заведенные в ней – это исключительно собирательный образ. Если вы решили, что в вашей компании очень похожая ситуация, то это совпадение.

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.

В этой статье попробуем разобраться, почему ООП — худшее, что было придумано в программировании, как оно стало таким популярным, почему опытные программисты Java (C#, C++ и т.п.) в принципе не могут считаться крутыми инженерами, а код на Java - хорошим.

Чистый код — это не просто стиль программирования, это философия, которая делает ваш код понятным, поддерживаемым и эффективным. В этой статье мы разбираем ключевые принципы написания чистого кода: от правильного использования уровней абстракции и разделения функций до борьбы с глубокой вложенностью и неожиданными побочными эффектами. Вы узнаете, как избегать распространённых ошибок, таких как смешение уровней абстракции, избыточные проверки и сложные управляющие структуры. Мы также рассмотрим, как полиморфизм, фабричные функции и обработка ошибок могут помочь вам писать более чистый и читаемый код. Статья подойдёт как начинающим, так и опытным разработчикам, которые хотят улучшить свои навыки и сделать свой код более профессиональным.

Всем привет! Я Екатерина Васильева, старший инженер по автоматизации тестирования в InfoWatch, и сегодня хочу поделиться своими наработками в области автотестирования веб-сайтов. В процессе работы нужно было работать со сторонними сайтами – в нашем случае это были VK, Telegram, Yandex Messenger, Whatsapp, и попросить разработчиков создать специальные ключи для автотестов было невозможно. Поэтому на данном проекте пригодился мой десятилетний опыт в автотестировании, в частности – составлении локаторов. Так как сайты сторонние была особенно актуальна тема стабильных локаторов. В статье делюсь информацией, необходимой для составления устойчивых локаторов – то есть таких, которые не нужно будет часто менять. Это крайне необходимо для автоматизации, когда локаторы вполне могут поменяться из-за обновления тегов и их атрибутов программистами, например, во время рефакторинга или написания нового функционала.

Здравствуйте! Сегодня мне хотелось бы обсудить с вами один армейский принцип, который может оказаться невероятно полезным при написании и поддержке вашей кодовой базы.

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

Подходов, советов и принципов существует очень много, и их можно отобрать и классифицировать по-разному, в зависимости от того, чему отдать приоритет. В данном случае я отобрал то, что влияет на поддерживаемость кода, надежность и удобство работы с системой.

Я исхожу из того, что по мере развития система должна упрощаться: упрощаться кодовая база, увеличиваться прозрачность работы компонентов и их взаимодействия. Звучит абсурдно, ведь новые фичи добавляются и добавляются. Но в то же время разработчики лучше понимают, с чем имеют дело — проясняется предметная область и сценарии использования. Выявляются похожие по смыслу вещи, они объединяются. Неудачные решения заменяются на более удачные.

Принципы, которые я перечислю дальше, конечно не 100-процентная истина. Как всегда, все хорошо к месту. Например, если сопоставляются два варианта, и обычно, при прочих равных, один вариант лучше, то все-равно найдется ситуация, когда лучше использовать другой вариант. Но даже сама идея о том, что существуют варианты и есть некий критерий выбора, поможет принять осознанное решение.

Когда это все может пригодиться? На стадии дизайна, при реализации и на код-ревью. Другими словами — всегда.

Итак, вот несколько идей, которые можно использовать, когда нужно сделать выбор.

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

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

В мире видеоигр эмуляторы стали настоящей находкой для поклонников классических проектов. PPSSPP — один из самых популярных эмуляторов для PlayStation Portable (PSP), который позволяет нам вновь окунуться в атмосферу любимых игр, но уже на современных устройствах. Однако чтобы играть без сбоев и лагов, нужно убедиться, что код эмулятора хорошо написан.

Всем привет!

Это перевод статьи Clean Code in Python. В данной статье Nik Tomazic рассказывает о чистом коде, его преимуществах, различных стандартах и принципах, но что самое главное– он дает общие рекомендации по написанию чистого кода. Прочитав данную статью в оригинале, я понял, что это именно то, что я хотел бы прочитать в самом начале своего пути разработки на Python. Именно это и вдохновило меня на создание первого перевода, а вместе с этим, и первой публикации на Хабре.

Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.

Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

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

Допустимые глобальные переменные и предполагаемая экономия памяти.

Вот уже 20 лет я преподаю программирование в университете Буэнос-Айреса. На курсе программной инженерии мы изучаем паттерны проектирования, и одна и та же «схема» повторяется раз за разом, вызывая почти де жа вю. Я убедился в этом на нескольких проектах и при обращении со свободным ПО, которым мне приходилось пользоваться:

Как «по волшебству» в коде возникает паттерн синглтон.

Миллионы пользователей ежедневно заходят на Яндекс Маркет. И одна из ключевых задач сервиса — показывать им точные сроки доставки на поиске и в корзине. При пиковых нагрузках это около 40 тысяч запросов в секунду. Как обеспечить столь быструю и точную обработку данных о доставке?

Привет, Хабр! Меня зовут Никита Деревянко. Я руковожу разработкой логистической платформы Яндекс Маркета. Люблю играть в шахматы, бильярд и программировать. Изучаю японский язык, чтобы тренировать мозг и смотреть аниме в оригинале. Расскажу о том, как построить логистический runtime на Go, не являясь Golang-разработчиком. Рассмотрим, как справиться с большим объёмом данных и какие преимущества может (или не может) предложить Golang для масштабной задачи.

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

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