Я как-то писала пост про борьбу с неизбежным... Но иногда, ты борешься-борешься, а в итоге тебя настигает эффект пестицида. 🤦♀️
Эффект пестицида — это явление, при котором со временем применение пестицидов становится менее эффективным из-за адаптации вредителей.
В биологии это означает, что чем больше мы травим вредителей, тем лучше они адаптируются. В проектировании (разработке) все аналогично: если долгое время использовать одни и те же подходы без адаптации, то они перестают решать реальные проблемы и создают новые.
У эффекта пестицида есть 4 механизма, которые приближают сам эффект.
🦠 Развитие устойчивости
Архитектурные паттерны, которые раньше работали, больше не приносят пользы.
Решили, что микросервисы – это круто, и спроектировали систему на их основе. Первые пару лет все отлично, но со временем оказывается, что зависимости между сервисами усложнились, а сопровождать стало дороже, чем монолит.
Что делать?
- Регулярно пересматривать архитектурные решения, а не следовать трендам.
- Оценивать границы применимости паттернов (что хорошо для одного проекта, может сломать другой).
- Закладывать гибкость в архитектуру вместо слепого следования модным подходам (да, про бережливое проектирование).
🌍 Нарушение экосистемного баланса
Фокусируясь на одной части системы, мы создаем проблемы в другой
Добавили кэшированную базу, в которую льются данные из баз в разных ДЦ. Получили единство данных... Но внезапно выяснилось, что теперь сервис ведет себя непредсказуемо из-за несогласованности данных между кэшем и основной БД.
Что делать?
- Принимать архитектурные решения системно, а не точечно.
- Оценивать потенциальные побочные эффекты изменений.
- Всегда задавать вопрос: «А что может сломаться?»
🔄 Эффект возврата
Рефакторинг вместо улучшения возвращает старые проблемы.
Когда-то приняли решение разделить модули системы на независимые сервисы, но спустя пару лет решили «упростить» поддержку и свести все обратно в монолит, но без этапа реинжениринга. В результате возвращаемся к тем же проблемам, которые изначально пытались решить.
Что делать?
- Фиксировать причины архитектурных решений (ADR).
- Помнить, что нет универсальных решений – любое проектное решение имеет trade-offs.
⚠️ Необходимость усиленной обработки
Чем больше усложняем архитектуру, тем сложнее ее поддерживать.
Решили использовать слоистую архитектуру и строго разграничили уровни. Все красиво! Но теперь каждая правка требует изменения на нужных уровнях… А еще нужны разработчики, которые из этого не сделают "болотце"!
Что делать?
- Оценивать реальную стоимость усложнения архитектуры.
- Балансировать между гибкостью и простотой.
- Не вводить паттерны, если они не решают конкретную проблему.
- Не вводить паттерны, которые не соразмерны навыкам команды.
Мораль (какая-то дурацкая): думай и думай в разных направлениях :)
И знаете, маленькое признание: я очень боюсь оказаться в ситуации, когда сама ВЫРАЩУ НЕУБИВАЕМОГО ТАРАКАНА-МУТАНТА! 🪲И в этом страхе, мне очень жаль, что для айтишников не придумали супервизоров, как у психологов и психотерапевтов! Я б пошла!
❓А вопросов у меня к вам 2:
1️⃣ Встречались ли вы с последствиями воздействия пестицидов?
2️⃣Нужен ли вам "супервизор"? А может быть вы нашли уже его... ПОДЕЛИТЕСЬ!
#architecture
