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

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

Попадаете вы на остров.

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

Как и зачем делать рефакторинг и более глубокий реинжиниринг?

Если вы работаете Enterprise-архитектором, вы наверняка слышали о микросервисной архитектуре и работали с ней. И хотя в прошлом вы, возможно, использовали REST в качестве слоя взаимодействия сервисов, всё больше и больше проектов переходят на событийно-ориентированную архитектуру (Event-Driven Architecture, EDA). Давайте разберем плюсы и минусы этого популярного подхода, ключевые проектные решения, которые он влечет за собой, и распространенные антипаттерны.

Три способа менять один объект из нескольких потоков. Больше нет

Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…

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

На самом деле их ровно три. Всё остальное — реализации и комбинации.

Эта статья — попытка навести порядок в голове. После неё вы сможете:

за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.

Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.

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

TL;DR: Оказалось проще формализовать и реализовать с нуля свой потокобезопасный движок формул Excel, чем оптимизировать уже готовый мутабельный движок epplus. Хотя позже я реализовал более простой в кодировании вариант, но гораздо более сложный с точки зрения архитектуры.

Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов

Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.

Потом пришёл сценарий: «Отменить заказ»

Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...

• Если доставка уже в пути - нужно создать возвратную накладную

• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы

• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже

• Если клиент повторил платёж - восстановить резерв и доставку

И я решил:

Самая сложная логика тут не в доменах, а между ними.

А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.

Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.

Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.

Разработка через типы (Type-Driven Development, TypeDD) — это методология программирования, при которой вы начинаете с написания определений типов, которые служат точной спецификацией вашей программы. Вместо того чтобы сначала писать код, а потом добавлять тесты или типы, вы используете компилятор как интерактивного ассистента, который направляет вас к созданию программы, удовлетворяющей заданным типам.

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

Но попробуем использовать его идеи на практике вне Idris.

Попробуем сравнить такие метрики как
1. Время проектирования (момент, после которого разработчик может больше не соприкасаться с предметной областью, а руководствоваться только ТЗ)
2. Время до выкатки на прод
3. Частота ошибок на проде (и как следствие, ущерб бизнесу и затраты на сопровождение)

Если меня на собеседовании спросят что такое ООП, то может получиться как в анекдоте " завыл, бился головой о стену, в общем ушёл от ответа". Любое простое определение ООП не полно, любое полное слишком сложно. Это показывает что ООП само в своих основах очень сложно, а на поверхности лишь видимая часть айсберга. Итак, пробуем дать краткое и герметичное определение, последовательно вводя минимум определений, чтобы были видны цели а не догма. Герметичное значит ясное и самодостаточное, не опирающееся (явно или неявно) на другие нетривиальные понятия. Всё по взрослому. Мне понадобилось много итераций. И на глубине я увидел чудовищ. Я конечно знал их и раньше, но думал что я просто дурак и не понимаю как просто с ними работать. Нырнул глубже и... они не пропали! Для любой сложной ООП системы они останутся с тобой.

ФП в отличие от него имеет крутую ступеньку входа но дальше сложность не растёт.

Habr, что это за поле «Целевая аудитория»?

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

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"

Статья «Что означает 10X» — это отредактированная версия записи в блоге « Вариации производительности среди разработчиков и команд: происхождение 10x ». В статье основное внимание уделяется исследованиям, которые подтверждают утверждение о 10-кратной разнице в производительности среди программистов.

TL;DR

Для случая разработки Excel 3.0 vs Lotus 1-2-3 разница в количестве строк кода в день различалась на порядок.

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

Постарался создать простой чек лист для принятия решения о выделения в микросервис конкретного домена.

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

Продолжение статьи об архитектурных паттернах для масштабируемости приложений.

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

Почему работа всегда сложнее чем кажется в начале?

Почему с течением роста проекта производительность программиста падает?

Почему читать код сложнее чем писать?

По мотивам Adidas Running (ex. Runtastic)

Как я бы проектировал это интересное, но малоизвестное у нас приложение в роли архитектора.

Предыстория

Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.

Адидас имеет объем продаж 20–30 млрд долл. в год.

Основной рынок – США, остальные страны – второстепенные рынки.