Как стать автором
Обновить
57.11

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

Реорганизация кода

Сначала показывать
Порог рейтинга
Уровень сложности

Делаем код-ревью правильно

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров21K

В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира.

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

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

Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.
Читать дальше →
Всего голосов 74: ↑72 и ↓2+70
Комментарии26

Проектируем микросервисы с Reactive Manifesto: 4 принципа распределенных систем

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров2.2K

Работаете с распределенными системами или только пытаетесь к ним подобраться? Проектировать такие системы с нуля бывает сложно и страшно: чтобы учесть все нюансы, нужен определенный багаж знаний. 

На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.

Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.

Читать далее
Всего голосов 26: ↑25 и ↓1+24
Комментарии3

Dart 3.1 и ретроспектива программирования в функциональном стиле в Dart 3

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров2.5K

Сопоставление шаблонов (pattern matching) и исчерпывающие переключатели (exhaustive switches) объединяются для создания функциональных моделей данных, которые легко сочетаются с объектно-ориентированным ядром Dart. 💪

Читать далее
Всего голосов 2: ↑2 и ↓0+2
Комментарии3

Насмотренность в разработке: путь к чистому и качественному коду

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров5.3K

В мире разработки программного обеспечения термин «Насмотренность» крайне редко встречается, в то время как дизайнеры постоянно всё насматривают 😅. Однако понятие насмотренности не менее важно для разработчиков, поскольку оно помогает понять, зачем и как нужно создавать красивый и чистый код.

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

Читать далее
Всего голосов 36: ↑26 и ↓10+16
Комментарии21

Истории

4 вида распространённых ошибок в Event-Driven системах

Время на прочтение8 мин
Количество просмотров5K

В последние несколько лет в крупных компаниях наблюдается значительный рост внедрения event-driven (событийно-ориентированных) систем. Каковы основные причины этой тенденции? Это чистой воды хайп или есть веские причины, побуждающие к внедрению этой архитектуры? С нашей точки зрения, основными причинами, по которым многие компании выбирают этот путь, являются:

Читать далее
Всего голосов 17: ↑15 и ↓2+13
Комментарии5

Сколько точек зрения у  Архитектора в ИТ?

Уровень сложностиПростой
Время на прочтение20 мин
Количество просмотров3K

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

Посмотреть со своей точки зрения
Всего голосов 12: ↑10 и ↓2+8
Комментарии0

Анемичная модель предметной области и логика в сервисах

Уровень сложностиСредний
Время на прочтение20 мин
Количество просмотров4.8K

Анемичная модель предметной области (Anemic domain model) это такая модель, где сущности содержат только свойства, а бизнес-логика находится в сервисах. Ее противоположность это богатая модель предметной области (Rich domain model), где логика находится в сущностях, а cервиcы рекомендуют писать только в редких случаях.

В этой статье я хочу показать, почему логика в сервисах является более правильным подходом. Мы рассмотрим пример бизнес-требований и их реализацию с Anemic domain model.

Читать далее
Всего голосов 11: ↑9 и ↓2+7
Комментарии133

UML: обзор основных типов диаграмм, диаграмма объектов. Часть 3

Время на прочтение3 мин
Количество просмотров6K

Хабр, привет! В прошлых статьях про UML (Часть 1, Часть 2) мы узнали что такое язык моделирования UML и зачем он нужен, а также рассмотрели диаграмму классов и диаграмму компонентов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме объектов.

Читать далее
Всего голосов 10: ↑8 и ↓2+6
Комментарии3

Proof of Work и Proof of Stake для чайников

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров3.1K

Привет, Хабр!

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

Для достижения консенсуса в блокчейне существуют механизмы Proof of Stake и Proof of Stake. Рассмотрим их в этой статье.

Читать далее
Всего голосов 18: ↑16 и ↓2+14
Комментарии16

Пиррова победа Domain-Driven Design

Уровень сложностиСложный
Время на прочтение7 мин
Количество просмотров11K

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.

Читать далее
Всего голосов 37: ↑34 и ↓3+31
Комментарии98

Покрытие архитектуры as Code тестами

Уровень сложностиПростой
Время на прочтение16 мин
Количество просмотров5.3K

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

Читать далее
Всего голосов 26: ↑24 и ↓2+22
Комментарии8

Мы пилили монолит — много нас, а он один. Полезные советы от команды Яндекс Еды

Уровень сложностиПростой
Время на прочтение14 мин
Количество просмотров17K

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

Распилить
Всего голосов 42: ↑39 и ↓3+36
Комментарии36

История импортозамещения: от BluePrism к SaluteRPA

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров1.2K

Привет, Хабр! Я Смолин Максим, разработчик и администратор баз данных в продуктах RPA BluePrism и SaluteRPA в Блоке Технологий Сбербанка, руководитель ИТ-направления. Мы с командой развиваем продукт SaluteRPA — роботизированная автоматизация процессов Сбербанка. Я расскажу, почему нас не устраивала платформа от зарубежного вендора, и почему мы решились на создание собственной платформы роботизации.

В 2017 году в банке начали использовать систему RPA BluePrism. На этапе MVP всё было великолепно, но потом началось много вопросов. ЦПУ (центральное процессорное устройство) сервера БД зашкаливали за 95 %, процессы тормозили и не успевали отрабатывать в нужное время, инциденты сыпались как из рога изобилия. С этого момента началась наша работа по превращению софта, рассчитанного на малый бизнес, в софт уровня предприятия с тысячами роботов. В итоге она привела к написанию собственного продукта SaluteRPA.

Архитектура RPA BluePrism достаточно проработана. Но вот реализация на уровне БД имела много замечаний с нашей стороны. Что-то мы отправляли на переделку вендору, что-то дорабатывали сами, а что-то смогли реализовать только в своём продукте.

Забегая вперёд, скажу, что внедренные нами изменения позволили преодолеть ограничение RPA BluePrism в 100 роботов на одну БД и уверенно держать нагрузку до 500 роботов на одну БД.

Читать далее
Всего голосов 6: ↑6 и ↓0+6
Комментарии2

Ближайшие события

One day offer от ВСК
Дата16 – 17 мая
Время09:00 – 18:00
Место
Онлайн
Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн
Антиконференция X5 Future Night
Дата30 мая
Время11:00 – 23:00
Место
Онлайн
Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург
Summer Merge
Дата28 – 30 июня
Время11:00
Место
Ульяновская область

Приложение викторины: внедрение Cardoteka и основные паттерны проектирования с Riverpod

Уровень сложностиСложный
Время на прочтение32 мин
Количество просмотров601

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

Если очень хочется создать викторину, то почему бы и да! Но на пути будет много увлекательных происшествий. Эта статья на гране сумбурного изыскания лучших паттернов проектирования. Вот что рассмотрено:

о слоях и взаимосвязях в архитектуре

формула: 2x реактивность = Riverpod + Cardoteka

особенности проектирования бизнес-логики

лучшие паттерны для работы с Cardoteka

определение репозиториев и про Trivia Api

настройка github actions для деплоя web и релиза подписанных apk 🎁

И всё это под лязг пластмассовых катан. Прошу, вы устанете, но будет весело!

Повеселиться и устать
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Правильный подход к модульной архитектуре

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров7.3K

Эта статья строится на двух простых идеях:

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

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

Читать далее
Всего голосов 6: ↑6 и ↓0+6
Комментарии4

Паттерн Aggregate Outside

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров6.5K

Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.

Читать далее
Всего голосов 25: ↑25 и ↓0+25
Комментарии17

GET запросы на практике: правила, принципы и примеры

Время на прочтение14 мин
Количество просмотров19K

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

Читать далее
Всего голосов 28: ↑26 и ↓2+24
Комментарии13

Челлендж по обработке миллиарда строк на Go: от 1 минуты 45 секунд до 4 секунд

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров22K

Пару недель назад я прочитал о запавшем мне в душу челлендже по обработке миллиарда строк, поэтому захотел решить его на Go.

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

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

Читать далее
Всего голосов 66: ↑64 и ↓2+62
Комментарии20

Итак, вы унаследовали старую кодовую базу на C++. Что дальше?

Уровень сложностиСредний
Время на прочтение21 мин
Количество просмотров15K

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

Теперь вы отвечаете за кодовую базу на C++. Она большая, сложная и своеобразная; достаточно слишком долго на неё посмотреть, как она начинает разваливаться разными интересными способами. Иными словами, это легаси.

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

И что делать теперь?

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

В этой статье я расскажу о том, что оказалось полезным для меня, и о том, чего стоит всячески избегать.
Читать дальше →
Всего голосов 71: ↑70 и ↓1+69
Комментарии26

Валидация данных на уровне бизнес-логики приложения

Уровень сложностиСредний
Время на прочтение2 мин
Количество просмотров3.6K

Данная статья продолжает тему статьи «Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя».

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

Подобная задача предельно типовая и поэтому должна иметь типовое решения. Далее рассматривается решение, основанное на трёхслойной архитектуре, в которой каждый слой (layer) состоит из трёх подслоёв (sublayer). Такая архитектура была описана в статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных».

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

При получении запроса функционал веб‑сервиса десериализует данные пользователя в объект типа UserDTO. В этом объекте в поле Email находится адрес электронной почты нового пользователя. Этот адрес электронной почты должен быть уникален на уровне соответствующего поля таблицы Users, в которой в базе данных хранятся данные пользователей приложения.

Читать далее
Всего голосов 8: ↑4 и ↓40
Комментарии29

Вклад авторов