Итак, Вы – руководитель разработки (главный инженер, архитектор и т.п.) большой системы. После здравых размышлений Вы (обосновано) выбираете для системы микросервисную архитектуру. Далее Вы (и опять обоснованно) разделяете систему на микросервисы, продумываете API, рисуете стрелочки и диаграммы и можно программировать.

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

В этой статье мы рассматриваем два принципа: «Данными владеет только владелец» и «Локальность данных». Понимание принципов, понимание возможностей проектирования доступов к данным позволит Вам спроектировать устойчивые и надежные системы. 

FreeAIr - это расширение (vsix) для Visual Studio 2022/2026, которое позволяет использовать локальную или корпоративную LLM внутри Visual Studio для помощи программисту. Это не Copilot, а независимая разработка авторов из РФ. FreeAIr не содержит spyware, никуда не отправляет ни код, ни переписку, ни телеметрию (ничего не отправляет), и поэтому может использоваться в компаниях, где использование внешних LLM запрещено политикой конфиденциальности.

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

Итак, Вам не повезло, Вы – техлид (тимлид, главный инженер etc) большого и старого проекта на C#, который был написан в доисторические времена, когда async еще не завезли. Проект старый и большой, но живой и развивается. Может быть даже, что проект использует современный .NET, современную версию C#, но вот незадача – не использует async, а очень бы хотелось.

 Как осуществить такой рефакторинг и какие трудности ожидают на этом пути?

Вспомните, как часто менеджеры просили Вас оценить трудозатраты? И Вы методом научного тыка давали им сроки, которые, конечно, превышали.

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

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

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

В этой заметке описана концепция организации производства ПО «Merge Request как транзакция изменения системы, и где в ней возникает eventual consistency». Описывается идея, что МР должен содержать полный список изменений по каждой таске, какие плюсы и минусы этой концепции свойственны а также как её внедрять.