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

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

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

Принцип разделения ответственности

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

Когда Люк работал с Flake8 и одновременно присматривался к Pylint, у него сложилось впечатление, что 95% ошибок, выдаваемых Pylint, были ложными. У других разработчиков был иной опыт взаимодействия с этими анализаторами, поэтому Люк решил детально разобраться в ситуации и изучить его работу на 11 тыс. строк своего кода. Кроме того, он оценил пользу от Pylint, рассматривая его как дополнение к Flake8.



Люк (Luke Plant) — один из британских разработчиков, на чью статью с разбором популярных анализаторов кода мы недавно наткнулись. Линтеры изучают код, помогают найти ошибки и сделать его стилистически согласованным со стандартами и кодом, который пишут разработчики в вашей команде. Самые распространенные из них — Pylint и Flake8. Мы в Leader-ID их тоже используем, потому с радостью сделали перевод его статьи. Надеемся, что она обогатит и ваш опыт работы с этими инструментами.

Фильм “Аэроплан”, 1980г.

Примерно так я себя чувствовал, когда выливал очередной рефакторинг на прод. Даже если весь код покрыть метриками и логами, протестировать функционал на всех окружениях — это не спасет на 100% от факапов после деплоя.

Первый факап

Как-то мы рефакторили наш процессинг интеграций с Google Sheets. Для пользователей это очень ценный функционал, т.к. они используют много инструментов одновременно, которые нужно связывать между собой — отправлять контакты в таблицу, выгружать ответы на вопросы, экспортировать пользователей и т.д.

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

Через 20 минут пользователи написали, что интеграция не работает. Отвалился функционал отправки данных в Google Sheet — оказалось, что для дебага мы отправляем данные в разных форматах для прода и локального окружения. При рефакторинге мы задели формат для прода.

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

Еще в декабре мне попалась одна совершенно замечательная статья на английском, посвящённая использованию системы типов языка для более широкого класса задач, для повышения надежности приложений и простоты рефакторинга. К сожалению, в тот момент я был слишком занят написанием статей по ФП, которые крайне важно было написать, пока свежи воспоминания. Но теперь, когда с этой задачей я справился, наконец дошли руки перевести эту замечательную заметку. Оригинальный язык примеров — Хаскель, но я решил переписать их на раст, для более широкого охвата аудитории. Однако язык тут совершенно неважен, советы этой статьи я применяю в ежедневной разработке на вполне себе "приземлённых" C# и TypeScript, так что если вы просто стараетесь писать надёжный и поддерживаемый код, то, вне зависимости от языка, статья вам будет в тему.

Благодарю за вычитку и помощь в переводе Hirrolot, funkill и andreevlex

Есть вопрос, который я никак не могу раскусить. Казалось бы, по нему есть масса информации: книги, статьи, доклады. Но сложность и многогранность темы не позволяет сразу ухватить суть. Поможешь мне в этом?

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

Что такое Domain Driven Design?

Микросервисная и модульная системы — это типы архитектуры IT-решений.

При работе с модулями мы дорабатываем коробочную версию существующего IT-продукта.

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

Доработка состоит в создании модулей с недостающим функционалом.

Новые модули получаем путём переиспользования частей монолита (ядра или других модулей).
Бизнес-логика прописывается внутри монолита: для программы (приложения, сайта, портала) есть одна точка входа и одна точка выхода.

При работе с микросервисами мы создаём IT-продукт с нуля, составляя его из «кирпичиков» — атомарных микросервисов, отвечающих за отдельный небольшой процесс (отправить письмо, получить данные по заказу, сменить статус заказа, создать клиента и т. п.).
Набор таких блоков объединяется бизнес-логикой в общую систему (например с помощью BPMS). Несмотря на наличие связей, каждый блок автономен и имеет свои точки входа и выхода.

Большинство IT-продуктов для наших заказчиков начинаются с модульной разработки. Часть из них со временем эволюционируют до микросервисов. Для другой части микросервисы не нужны. В этой статье мы рассмотрим, почему это именно так и какие критерии помогают определиться, нужно ли внедрять микросервисы или стоит придерживаться работы с модулями.

Как спроектировать продукт, чтобы не зарыть деньги в землю

На каком этапе создания продукта или системы подключать архитектурное проектирование системы, чтобы потом не было мучительно больно за потраченные деньги? Как решить, совмещать ли CQRS и микросервисы.

Всем привет!

Я сделал перевод и набил субтитры на знаменитый доклад Рича Хикки — Simple Made Easy (Простое сделать лёгким). Впервые на русском языке.

Доклад впервые был представлен в 2011 году на конференции Strange Loop.

@octokit/rest изначально не является оригинальной разработкой GitHub, и представляет собой адаптацию github — самого популярного пакета 2017 года от пользователя @bkeepers. В этом посте будем говорить про @octokit/rest — теперь официальный JavaScript SDK для GitHub REST API.

Всем привет! Хочу рассказать, как мы применили чистую архитектуру в платежной платформе.
Сегодня наша платежная платформа представляет собой целый агрегатор самых разных финансовых решений, хотя продукт достаточно молодой, ему не более 1,5 лет.

Аннотация:

1. Пример реализации нового функционала в классе через добавление «флажка».
2. Последствия.
3. Альтернативный подход и сравнение результатов.
4. Как избежать ситуации: «Архитектурный оверкилл»?
5. Момент, когда приходит время всё менять.

Архитектура: искусство делать излишнее необходимым.

Фредерик Кислер

Ни для кого давно уже не секрет, что для любого web-сервиса на протоколе SOAP с сообщениями в формате XML верным и проверенным временем решением является предварительная разработка XML Schema (xsd-схемы), описывающей типы данных и структуру XML сообщений. При этом подходе у разработчиков существует явное преимущество: у них есть строгие стандартизированные правила по структуре сообщений, которые заданы в схеме, число правил конечно, и они позволяют автоматизировать проверку любого нового сообщения в формате XML.

OpenBSD позиционируетcя как защищённая ОС. Однако за последние несколько месяцев в системе найден ряд уязвимостей. Конечно, в этом нет ничего экстраординарного. Хотя некоторые уязвимости довольно необычные. Можно даже сказать, критические. У разработчиков OpenBSD несколько принципов, как обеспечить безопасность. Вот два из них:

• избегать ошибок;
  
• минимизировать риск ошибок.

Не все согласны, что этих принципов достаточно, чтобы строить защищённые системы. Мне кажется, есть смысл изучить, работает ли подход OpenBSD, или он изначально обречён.

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

Достоевский дал миру Великого Инквизитора с его «зачем же ты пришел нам мешать?».
Ильф и Петров — Великого Комбинатора.
Та эпоха уже закончилась, эта — еще не началась.

Привет! Меня зовут Евгений, я Python-разработчик. Последние полтора года наша команда стала активно применять принципы Clean Architecture, уходя от классической модели MVC. И сегодня я расскажу о том, как мы к этому пришли, что нам это дает, и почему прямой перенос подходов из других ЯП не всегда является хорошим решением.

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

Задача

Добавить в приложение систему оповещения пользователей через СМС-сообщения с возможностью выбора провайдера.

Решение

Оптимальным решением, на мой взгляд, является добавление собственного компонента.
Компонент — это блок программы с четко определенным набором действий (контрактом), способный решать возложенные на него задачи посредством различных драйверов. Так, например, встроенный компонент Cache может использовать драйвера: file, memcached или redis.

При построении нашего компонента, мы применим принцип проектирования Мост, тот же принцип, на котором построены компоненты Laravel.

Итак, приступим.

Можно бесконечно холиварить о том, является ли GitLab хорошим продуктом. Лучше посмотреть на цифры: по итогам раунда инвестирования оценка GitLab составила 2,7 млрд долларов, в то время как предыдущая оценка была $1,1 млрд. Это означает бурный рост и то, что компания будет нанимать все больше и больше фронтенд-разработчиков.

Так выглядит история появления фронтенда в GitLab.



Это график количества фронтендеров в GitLab, начиная с 2016 года, когда их не было вообще, и заканчивая 2019-м, когда их стало уже несколько десятков. Но сам GitLab существует 7 лет. Значит, до 2017 года основной код на фронтенде писали бэкенд-разработчики, хуже того, бэкенд-разработчики на Ruby on Rails (ни в коем случае никого не хотим обидеть и ниже поясним, о чем идет речь).

За 7 лет любой проект, хотите вы того или нет, устаревает. В какой-то момент рефакторинг становится невозможно больше откладывать. И начинается полный приключений путь, конечный пункт которого никогда не достигнуть. О том, как это происходит в GitLab, рассказал Илья Климов.

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

Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.