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

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

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

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

В этом топике я не пытаюсь доказать, что тесты бесполезны. Это скорее мои размышления вслух и личная попытка нащупать их реальную ценность. Некоторые идеи в процессе всё-таки зацепили - но скорее как частные случаи, а не что-то универсальное.

Я программирую уже больше шести лет. На самом деле существенно больше (на свой первый аутсорс на PHP я попал примерно в 2016 году), но осознанно подходить к своей карьере я начал не сразу. За это время я вполне успешно поработал в довольно разных местах, от маленьких стартапов до международных компаний.

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

Доброго времени суток, Хабр!

Сегодня хотел бы поговорить об анемичной модели — одном из самых дискуссионных топиков (особенно для приверженцев DDD) и о том, как, по моему мнению, правильно её готовить. Для кого-то анемичная модель — это антипаттерн, тогда как для других это единственный правильный способ реализации приложений. Многие использовали её годами и даже не знали, как она называется, и что кем-то она считается антипаттерном. Реальность же такова, что анемичная модель — это инструмент, который может подходить или не подходить в зависимости от ситуации, но при этом является очень популярным и, по факту, «стандартом де-факто» для многих программистов и организаций. Хотя в последние годы я и вижу тенденцию к тому, что DDD и, соответственно, богатая доменная модель становятся всё популярнее, пока что, по моему мнению, им далеко до популярности анемичной модели.

— Я не продаю часы, — ответил я.

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

— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.

— У всех есть такая ставка, хотят они того или нет.

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

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

Почему же я сразу не назвал своей часовой ставки?

Имена

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

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

Всем привет! Зачастую чтобы в чем то разобраться полезнее один раз увидеть конкретный пример чем несколько раз прочитать заумное описание.Решил написать ряд небольших статей для начинающих, в которых дать краткое описание основных паттернов проектирования и привести лаконичные примеры их использования. Данная статья, как можно догадаться из названия =), посвящена поведенческим паттернам.

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

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

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

sched – планировщик событий из Python

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

Основные виды моделирования поведения:

1)    Диаграммы поведения в UML

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

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

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

В прошлой части мы разобрали:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

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

1. Как не допустить появления связанной архитектуры и сразу сделать хорошо?

2. Как исправить уже связанную архитектуру?

В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.

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

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

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

Старейшины говорят, что это история о масштабировании SaaS-приложения, но я таких слов не понимаю — слишком заумно. Для меня это история о золоте, драконах с всё возрастающим аппетитом и фермерах, которые кормят этих драконов.

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

Что делать, когда одна ферма больше не может прокормить всех? Как не дать городу сгореть от драконьего гнева? Зачем строить заморские колонии и создавать параллельные измерения?

За 10 лет наше королевство прошло путь от маленького города с одной фермой до федерации независимых государств, специализированных поселений и городов в параллельных мирах. И да, драконы всё ещё голодны.

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

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10¹²⁰. Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10⁷⁸ до 10⁸² атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов.

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

Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов.

Основная идея: разделить общее состояние объектов и вынести его в отдельное место, чтобы не плодить кучу дубликатов данных и экономить место.

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

Одним из важнейших этапов в проектировании Информационной системы является выявление бизнес-объектов и их детализация на сущности Предметной области. По результатам этих активностей можно спроектировать модель хранилищ данных. Чаще всего такие работы выполняют параллельно с этапом описания бизнес-процессов.

Как всегда, объявим цели текущего шага: определить и задокументировать сущности Предметной области и способы их взаимодействия. Спроектировать модель хранилищ данных.

Таким образом мы расширяем наш домен решений, добавляя в него – модель данных.

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

Это можно сделать огрублено, приблизительно, упрощенно.

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

2)   Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся.

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

Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.).

Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

Один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций.

Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код, который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисов, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса и фиксирует прогресс и актуальные состояния в БД.

Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"

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

А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.

Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.