Тема дня: рисуем архитектуру или давайте говорить на одном языке.

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

Причина таких недопониманий - разный бэкграунд. ФПшник и ООПшник будут очень долго спорить об одном и том же, совершенно не понимая термины друг друга. Ну не учат нигде архитектуре - универсальному языку, на котором по-хорошему должны разговаривать разработчики. Потому что в ИТ мы попадаем в основном через небольшие проекты и халтурки, самообразование и курсы типа "Сделаем первое мобильное приложение".
Как бороться с этим?

Добавьте контекст. Оформите его схемами и выложите в Readme файл. Одной Dynamic view достаточно, чтобы разработчики начали понимать друг друга и мыслить одинаково.

У нас было около 4-5 бесполезных обсуждений архитектуры приложения до появления схемы. Как только она появилась - стороны конфликта примерились и наконец-то появился конструктив.

Сколько бы фронтенд разработчики не объясняли бэкендщикам, что их АПИ неудобно, пусть и правильно, бэкендщику очень сложно понять боль фронтендщика. У нас же "JSON API", это стандарт, признанный всеми, чего вам ещё не хватает?
Рисуешь Sequence diagram, на которой видно, что для загрузки главной страницы требуется 7 последовательных запросов, и бэкенд разработчик меняется в лице.

ИМХО: уважающий себя разработчик должен уметь рисовать схемы. Я уж не говорю про communication skills, это другая больная тема.
В данном посте и на 5% не раскрыта правильное проектирование и документирование архитектуры и не претендует на это. Это лишь первый шаг)