Проектирование и рефакторинг *

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

В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.

Как понять, что мы проектируем REST API правильно? Никак. Смотреть на публичную API‑документацию крупных систем, диссертацию Роя Филдинга, или на то, что уже есть в проекте. И исходя из этого принимать решения о том, как будут выглядеть новые REST API методы.

В этой статье я хочу представить результаты исследований REST API сервисов управления задачами Trello и Todoist, чтобы показать, какие решения являются хорошими стандартами проектирования, а какие нет, но всё равно применяются на практике.

Сделаю это с помощью спорных вопросов, которые вам могут задать на собеседовании, и которые могут встретиться в реальной работе.

Архитектура — это всегда баланс между контролем и гибкостью. Микросервисы (MSA) хороши тем, что чётко разделяют логику, дают независимое масштабирование и удобны в отладке. Каждый сервис сам за себя, отвечает за конкретную зону ответственности и общается с другими через API — обычно REST или gRPC. Вроде бы идеальная схема, но со временем возникает проблема: сервисов становится всё больше, а их связи усложняются.

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

Введение

WebSocket — это протокол, обеспечивающий двустороннюю коммуникацию между клиентом и сервером, идеально подходящий для приложений, где необходима передача данных в реальном времени, таких как чаты, уведомления и онлайн-игры

Socket.IO — это библиотека, которая расширяет возможности WebSocket, предоставляя механизмы автоматического переподключения и fallback-режимы для более стабильной работы в нестабильных сетевых условиях

В этой статье мы рассмотрим, как работают эти технологии, какие задачи решают, их преимущества и ограничения, а также покажем, как быстро настроить сервер и клиента для работы с WebSocket и Socket.IO.

Здравствуйте, меня зовут Дмитрий Карловский и я.. стараюсь сложные вещи рассказывать простым языком, а простые вещи — эзоповым. И часто оказывается так, что в процессе упрощения и структурирования, на самом видном месте обнаруживаются скелеты древних динозавров, присыпанные мутными формулировками так, что долгие годы их никто не замечает. Что ж, если вы хотите окончательно разобраться в уровнях изоляции транзакций и гарантиях порядка операций, до давайте копать вместе.

С момента написания предыдущей статьи я находился под пристальным вниманием. Попытка опубликовать материалы на англоязычных платформах обернулась фиаско — в первые же минуты легионы последователей тайного братства обрушились с критикой:

— Нет никакой организации! — вопили они.

Подозреваю, что слежка велась через мой телеграм-канал.

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

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

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

Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про Dependency Inversion Principle, потому что это, пожалуй, один из самых важных принципов SOLID, понимание которого дает ключи к архитектуре программного обеспечения. 

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

Всем привет!

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

Рассмотрим в этой статье несколько наиболее распространенных паттернов проектирования в Golang, дополнив их практическими примерами.

Фасад, Стратегия, Прокси, Адаптер

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

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

Всем привет! Мы — команда разработчиков NiceOS (на данный момент развиваем проект Z (сервер), следующий этап проект X - рабочая станция с графической оболочкой). В нашей статье расскажем, как именно мы сделали (и продолжаем развивать) собственную серверную дистрибуцию Linux, заточенную под российские реалии: требования к сертификации, поддержку ГОСТ-криптографии, локализацию и работу с отечественным оборудованием.

Сегодня NiceOS Z — это легковесная серверная ОС без графического окружения, которая умеет:

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

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

SRP не SRP

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

В эпоху повального увлечения AI кажется, что достаточно взять OpenAI API, найти проблему, написать сложненький промпт (или их цепочку) и готово — ваш следующий единорог уже на подходе. Однако реальность, как всегда, оказывается намного сложнее и это мираж технологической простоты. В этой статье — рассуждения о том, почему базовая технология или стек целиком — это лишь верхушка айсберга в создании успешного продукта, и почему даже имея доступ к самым передовым технологиям, создать по-настоящему ценный продукт остается сложной задачей.

Раз в несколько лет возвращаюсь к задаче создания алгоритма для наиболее вероятного прогноза на основании ошибок предыдущих прогнозов. Кажется, поиск истины завершён успешно... Или нет? (демо web приложения в конце)

Предложенный вариант алгоритма определения наиболее предсказуемого "вранья" не претендует на абсолютную истину, но имеет под собой вполне устойчивый фундамент

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

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

В этой статье речь пойдёт о фреймворке коллекций в Java. Относительно недавно (в 3 кв. 2023 года) эта библиотека вновь слегка обновилась. Я ознакомился с обновлениями, и скажу, что они меня разочаровали.

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

Итак случившееся обновление - добавление последовательных версий интерфейсов в коллекции, а именно SequencedCollection, SequencedSet и SequencedMap. Такие последовательные коллекции ещё во времена Рапиры, кажется, называли кортежами.

Во времена пика интереса к NoSQL базам данных простоватые K-V хранилища были несколько обойдены вниманием - отчасти это понятно, вещь не очень "инновационная", можно даже сказать старинная. В то же время своя "ниша" у них находится до сих пор (не считая того что они используются в более сложных БД в качестве индексов).

В то же время в обычной SQL-ной базе проекта порой "не хватает" такого общего K-V хранилища для разнородных (семантически) записей. В своих проектах я такую обычно завожу. Среди коллег этот подход порой вызывает негатив :)

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