Сопоставление шаблонов (pattern matching) и исчерпывающие переключатели (exhaustive switches) объединяются для создания функциональных моделей данных, которые легко сочетаются с объектно-ориентированным ядром Dart. 💪
Проектирование и рефакторинг *
Реорганизация кода
Новости
Насмотренность в разработке: путь к чистому и качественному коду
В мире разработки программного обеспечения термин «Насмотренность» крайне редко встречается, в то время как дизайнеры постоянно всё насматривают 😅. Однако понятие насмотренности не менее важно для разработчиков, поскольку оно помогает понять, зачем и как нужно создавать красивый и чистый код.
Если вы только начинающий разработчик, вам будет полезно узнать как прокачивать насмотренность и что она дает.
4 вида распространённых ошибок в Event-Driven системах
В последние несколько лет в крупных компаниях наблюдается значительный рост внедрения event-driven (событийно-ориентированных) систем. Каковы основные причины этой тенденции? Это чистой воды хайп или есть веские причины, побуждающие к внедрению этой архитектуры? С нашей точки зрения, основными причинами, по которым многие компании выбирают этот путь, являются:
Сколько точек зрения у Архитектора в ИТ?
Судя по обилию статей «Кто такой архитектор в ИТ?» — нет общего понимания, чем он занимается, должен ли он вырасти из программиста или его можно сделать из системного аналитика. На самом деле ключевым качеством, которое сразу выделяет его среди остальных в ИТ, является способность смотреть на задачу с разных точек зрения. В статье приводится простой практический архитектурный кейс для очень известной системы, и выводы будут однозначные.
Истории
Анемичная модель предметной области и логика в сервисах
Анемичная модель предметной области (Anemic domain model) это такая модель, где сущности содержат только свойства, а бизнес-логика находится в сервисах. Ее противоположность это богатая модель предметной области (Rich domain model), где логика находится в сущностях, а cервиcы рекомендуют писать только в редких случаях.
В этой статье я хочу показать, почему логика в сервисах является более правильным подходом. Мы рассмотрим пример бизнес-требований и их реализацию с Anemic domain model.
Proof of Work и Proof of Stake для чайников
Привет, Хабр!
На старте блокчейн-технологий стояла задача создания системы, которая могла бы функционировать надежно и без централизованного контроля. Здесь помогают консенсусные алгоритмы. Консенсус в блокчейне — это согласие всех участников сети относительно ее текущего состояния, т.е это механизм, который позволяет децентрализованным сетям достигать общего согласия о том, какие транзакции считаются действительными и добавляются в блокчейн.
Для достижения консенсуса в блокчейне существуют механизмы Proof of Stake и Proof of Stake. Рассмотрим их в этой статье.
Пиррова победа Domain-Driven Design
TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.
DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.
Покрытие архитектуры as Code тестами
💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.
Мы пилили монолит — много нас, а он один. Полезные советы от команды Яндекс Еды
Про микросервисную архитектуру и переход на неё написаны сотни статей, однако почти все они больше теоретические и описывают ситуацию лишь верхнеуровнево. Редко где прочтёшь про то, как люди бесшовно вынесли высоконагруженный кусок монолита в отдельный сервис без даунтайма и факапов или даже с ними. Интересно узнать, какими же инструментами они пользовались, как подготавливались, каких подходов придерживались и какие выводы на будущее сделали. Всё это — полезный опыт, который может помочь избежать проблем. Вот я и подумал, что стоит им поделиться.
История импортозамещения: от BluePrism к SaluteRPA
Привет, Хабр! Я Смолин Максим, разработчик и администратор баз данных в продуктах RPA BluePrism и SaluteRPA в Блоке Технологий Сбербанка, руководитель ИТ-направления. Мы с командой развиваем продукт SaluteRPA — роботизированная автоматизация процессов Сбербанка. Я расскажу, почему нас не устраивала платформа от зарубежного вендора, и почему мы решились на создание собственной платформы роботизации.
В 2017 году в банке начали использовать систему RPA BluePrism. На этапе MVP всё было великолепно, но потом началось много вопросов. ЦПУ (центральное процессорное устройство) сервера БД зашкаливали за 95 %, процессы тормозили и не успевали отрабатывать в нужное время, инциденты сыпались как из рога изобилия. С этого момента началась наша работа по превращению софта, рассчитанного на малый бизнес, в софт уровня предприятия с тысячами роботов. В итоге она привела к написанию собственного продукта SaluteRPA.
Архитектура RPA BluePrism достаточно проработана. Но вот реализация на уровне БД имела много замечаний с нашей стороны. Что-то мы отправляли на переделку вендору, что-то дорабатывали сами, а что-то смогли реализовать только в своём продукте.
Забегая вперёд, скажу, что внедренные нами изменения позволили преодолеть ограничение RPA BluePrism в 100 роботов на одну БД и уверенно держать нагрузку до 500 роботов на одну БД.
Приложение викторины: внедрение Cardoteka и основные паттерны проектирования с Riverpod
Как здорово, что все мы здесь сегодня собрались.
Если очень хочется создать викторину, то почему бы и да! Но на пути будет много увлекательных происшествий. Эта статья на гране сумбурного изыскания лучших паттернов проектирования. Вот что рассмотрено:
• о слоях и взаимосвязях в архитектуре
• формула: 2x реактивность = Riverpod + Cardoteka
• особенности проектирования бизнес-логики
• лучшие паттерны для работы с Cardoteka
• определение репозиториев и про Trivia Api
• настройка github actions для деплоя web и релиза подписанных apk 🎁
И всё это под лязг пластмассовых катан. Прошу, вы устанете, но будет весело!
Правильный подход к модульной архитектуре
Эта статья строится на двух простых идеях:
• Каждое решение при проектировании программного продукта определяет пространство возможных вариантов на более поздних этапах. Это критически важно для понимания того, как и в какой последовательности стоит подходить к принятию проектных решений.
• Модули можно использовать для сохранения неопределённости в ключевых узлах, чтобы оставить больше свободы в дальнейшем.
Ближайшие события
Паттерн Aggregate Outside
Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.
GET запросы на практике: правила, принципы и примеры
Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.
Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.
Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).
Часто при проектировании мне помогала следующая идея: было бы здорово проектировать контракт так, чтобы при малейшем изменении/добавлении бизнес-правил его не приходилось сильно трансформировать, так как API является стыковочным звеном между разными слоями приложения. По ходу повествования я приведу пару примеров, чтобы проиллюстрировать такие изменения.
В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.
Челлендж по обработке миллиарда строк на Go: от 1 минуты 45 секунд до 4 секунд
Пару недель назад я прочитал о запавшем мне в душу челлендже по обработке миллиарда строк, поэтому захотел решить его на Go.
Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.
Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений, однако я проигнорировал те, что относятся только к Java.
Итак, вы унаследовали старую кодовую базу на C++. Что дальше?
Вы жили своей обычной жизнью, но внезапно, всё поменялось. Возможно, вы устроились в новое место, сменили команду или из вашей компании ушёл сотрудник.
Теперь вы отвечаете за кодовую базу на C++. Она большая, сложная и своеобразная; достаточно слишком долго на неё посмотреть, как она начинает разваливаться разными интересными способами. Иными словами, это легаси.
Но баги всё равно как-то нужно устранять, а ещё добавлять новые фичи. То есть вам нельзя просто закрыть на неё глаза или что ещё лучше, взорвать её динамитом. Она важна для компании. По крайней мере, для тех, кто платит вам зарплату. А значит, важна для вас.
И что делать теперь?
Не волнуйтесь, у меня такое случалось очень много раз и в разных компаниях (кто-то язвительный может спросить: а разве кодовые базы на C++ бывают какими-то другими?), выход есть, он не особо сложен и поможет вам действительно устранять баги, добавлять фичи, а то и когда-нибудь переписать её.
В этой статье я расскажу о том, что оказалось полезным для меня, и о том, чего стоит всячески избегать.
Валидация данных на уровне бизнес-логики приложения
Данная статья продолжает тему статьи «Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя».
Во многих бизнес приложениях для сущности User выдвигается стандартное требование: «При регистрации пользователя нужно проверять, что записываемый email уникальный, ни у одного другого пользователя такого больше нет».
Подобная задача предельно типовая и поэтому должна иметь типовое решения. Далее рассматривается решение, основанное на трёхслойной архитектуре, в которой каждый слой (layer) состоит из трёх подслоёв (sublayer). Такая архитектура была описана в статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных».
В качестве примера рассмотрим веб‑сервис, который получает запрос на создание нового пользователя и сохранение его данных в базе данных.
При получении запроса функционал веб‑сервиса десериализует данные пользователя в объект типа UserDTO. В этом объекте в поле Email находится адрес электронной почты нового пользователя. Этот адрес электронной почты должен быть уникален на уровне соответствующего поля таблицы Users, в которой в базе данных хранятся данные пользователей приложения.
Как перестать переусложнять и начать жить
Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?
В статье мы разберем что такое „переусложнение“, дадим ему определение и на реальных примерах разберем во что это выражается и как с этим бороться.
Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя
Слой Application - это не только про оркестрацию, но еще немного про бизнес-логику. Следует это простить и принять внутри себя. А иначе попытки продвинуться дальше в написании кода съедят программиста-перфекциониста живьем.
Можно долго искать решения, читать различные комментарии и книги про разделение бизнес-логики от приложения. И все равно ваша конкретная ситуация будет казаться вам уникальной, как будто ничего нельзя сделать либо надо снова переписывать Domain слой, дабы ни одно зернышко бизнес-логики не выпало за его пределы. А можно просто закрыть глаза на некоторые моменты, забыть об идеале и спать спокойно, рассчитывая, что все чудесным образом само разрулится.
Вклад авторов
-
SergeyT 594.4 -
m1rko 517.6 -
AloneCoder 504.8 -
alizar 455.7 -
marshinov 412.8 -
fillpackart 349.0 -
tangro 309.0 -
ph_piter 256.4 -
dartmessiah 233.0 -
m36 218.0