readme.md

About

Ограничения, цели и проблемы - которыми мы руководствуемся при разработке методологии

---

• Мы видим нашу цель, как баланс между идеологией и простотой
• Мы не сможем сделать серебряную пулю, которая подходит всем

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

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

🚫 Ограничения

Поэтому стоит понимать следующее:

• Не выйдет: очень просто, очень понятно, для всех

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

  • Пример из математики — теория графов.
  • Пример из физики — квантовая механика.
  • Пример из программирования — архитектура приложений.

• Возможны и Желательны: простота, расширяемость

🎯 Цели

• Интуитивная понятность для широкого круга разработчиков

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

  Т.к. даже со всем будущим инструментарием - будет недостаточно того, чтобы методологию понимали только проженные сеньоры/лиды

• Изложить в методологии причины и решения наших повседневных проблем при разработке проектов
• А также - приложить ко всему этому инструментарий (cli, линтеры)

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

  Just imagine: разработчик пишет код в рамках методологии и у него проблемы возникают раз в 10 реже, просто потому, что другие люди продумали решение многих проблем.

🔥 Проблемы

А в чем, собственно говоря, были проблемы?

Если вкратце:

• Проект и его архитектуру понимает только один человек

  Чаще всего - изначальный автор

  См. также

  • "Сложно добавить человека в разработку"
  • "На каждую проблему - у каждого свое мнение как обходить" (позавидуем ангуляру)
  • "Не понимаю что происходит в этом большом куске монолита"
  • и т.д.

• Тьма-тьмущая неявных сайд-эффектов при разработке/рефакторинге

  Т.е. "все зависит от всего"

  См. также

  • "Фича импортит фичу"
  • "Я обновил(а) стор одной страницы, а отвалился функционал на другой"
  • "Логика размазана по всему приложению, и невозможно отследить - где начало, где конец"
  • и т.д.

• Сложно переиспользовать/модифицировать логику

  Либо большая папка components, либо для каждого случая пишет все с нуля - без shared-модулей

  См. также

  • "У меня в проекте есть n-реализаций одной и той же бизнес-логики, за что приходится ежедневно расплачиваться"
  • "В проекте есть 6 разных компонентов кнопки/попапа/..."
  • "Свалка хелперов"
  • и т.д.

Более подробно - "Об архитектуре"