Такая картинка возникает у меня после общения с людьми на конференциях и тренингах. Справедливости ради, это относится не только к аналитикам. Всех интересует примерно одно: как выбирать технологии, покажи универсальные паттерны, дай алгоритмов и чеклистов для проектирования всего.

“Чем больше паттернов, тем лучше!” — реальное высказывание участника одного из воркшопов. Штош, внесем безумия в рабочие будни.

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

Чем больше паттернов, тем хуже. Как-то запускали продукт, где разработку лидировал разраб, который незадолго прочитал книгу о паттернах для конкретного стека. Так вот, он реализовал там ВСЕ паттерны. Зачем?

Не существует универсальных алгоритмов, чек-листов и принципов, потому что все они выводятся из контекста и опыта авторов. Если что-то “работало” у них, не значит, что будет “работать” у вас. И не факт, что будет “работать” у этих же гурей в будущем. Это еще не затрагиваем вопрос вкусовщины и личной предвзятости.

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

Только есть проблемка — без них попытки использования паттернов, технологий и прочих базвордов равносильны блужданию в темной комнате с молотком и микроскопом. Повезет — забьем гвоздь, нет — засыпем пол осколками. Еще в окно можно выйти.

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

Вообще, пост задумывался как нативочка к обновленному курсу по интеграции и архитектуре но рефлексировать интереснее, чем продавать. Зато сформулировал для себя, зачем делаю его. Мы учимся видеть задачу, самостоятельно изобретать решения и мыслить трейд-оффами. А еще добавили блоки про хранилища данных и работу с докером-кубером-мешами, начинаем в воскресенье.