ADR, архитектурные тесты и кейсы из прода: ресурсы, которые реально меняют код

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом». Вы знаете, чем кончаются плейлисты «Посмотреть потом». В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub . Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

https://habr.com/ru/articles/1001010/

#architecture #DDD #CQRS #clean_architecture #ADR #software_design #software_architecture #best_practices #system_design #microservices

Проблема не в разработке, проблема в управлении: если виноватых нет, виноватый назначается

Когда я начинал карьеру в ИТ в роли разработчика, я довольно рано начал слышать одну и ту же фразу от более опытных коллег и руководителей: «Тут проблема не в разработке. Тут проблема в управлении». Эта фраза всплывала в самых разных контекстах — когда срывались сроки, когда продукт не давал ожидаемого результата, когда архитектура начинала сыпаться, а команда выгорала, продолжая делать работу ради работы. Она звучала убедительно и как будто бы всё объясняла, но в этом и заключалась проблема: такая формулировка работает как универсальное объяснение, которое не требует ничего уточнять. Она не заставляет указывать причину, место возникновения или критерии доказательства — и потому разговор неизбежно уходит в абстракцию, где управление превращается в туманную смесь «не той культуры», «не того мышления» и «не тех людей». Как говорил Луначарский, дайте мне томик Ленина — и я найду в нём такую цитату, которая способна объяснить любое явление в этой вселенной.

https://habr.com/ru/articles/996918/

#продуктовая_разработка #системное_мышление #software_development #управление_разработкой #архитектура_процессов #инварианты #управляемость #жизненный_цикл #software_architecture #development_process

[Перевод] Что такое Архитектура ПО?

Всем привет! Читая очередную книгу по архитектуре ПО, я в который раз столкнулся с новым определением того, что же это такое. И всё бы ничего — я уже как будто привык к этому, но буквально те же самые авторы давали совсем другое определение в предыдущей книге! — Да сколько можно! — подумал я. И тут во мне проснулось любопытство: а сколько вообще таких определений от разных авторов? Есть ли какое-то общепризнанное мнение? Как оказалось, нет — разные авторы, фреймворки и спецификации дают разные определения. SEI (Software Engineering Institute) даже составил документ около 10 лет назад со списком разных определений. Но в рамках исследования для этой статьи я понял, что и он неполный. При это анализируя разные определения, я заметил закономерности. Поэтому в данной статье я постараюсь не просто привести список определений, но также сгруппировать и проанализировать их. В конце статьи я оставлю ссылки на ресурсы, чтобы любой желающий мог сам ознакомиться с источниками.

https://habr.com/ru/articles/988560/

#архитектура_по #архитектура_системы #software_architecture #software_architect #software_architecture_and_design #software_architecture_design #архитектура_програмного_обеспечения #дизайн_систем #дизайн_программного_обеспечения #architecture

[Перевод] Важность хороших Errors и Warnings на Product уровне

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

https://habr.com/ru/articles/987186/

#software_development #программирование #software_architecture #errors #warnings #разработка_приложений #разработка #разработка_по #разработка_сайтов #разработка_мобильных_приложений

[Перевод] Как проводить архитектурные ревью за 30 минут вместо 3 часов

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

https://habr.com/ru/companies/otus/articles/980762/

#архитектурное_ревью #software_architecture #архитектурные_решения #технический_долг #ADR #нефункциональные_требования #масштабируемость #надежность #ревью

Архитектура Laravel: 7 ловушек и практичные решения

Laravel завоевал авторитет у бизнеса и программистов за эффективность решения задач. Автор не раз встречал суждение среди коллег, что опыт разработки на Symfony и Laravel равнозначны. Это миф. Ниже — 7 ловушек Laravel и практичных решений без отказа от фреймворка.

https://habr.com/ru/articles/970642/

#laravel #symfony #php #dddlite #software_architecture

Как мы Best Practices в Java анализатор внедряли

История о том, как мы переписывали приложение под DI контейнеры, разбирали зависимости, рисовали графики, чтобы в этом не потеряться, и молились, чтобы ничего вдруг не сломалось.

https://habr.com/ru/companies/pvs-studio/articles/944164/

#java #dependency_injection #guice #software_architecture #clean_code #static_analysis #inversion_of_control