🔬Мелкая декомпозиция, как она ускоряет разработку в разы?

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

Если честно, я был убежден, что в Додо это очевидно всем, но недавно меня спросили: "А в чем плюс мелкого дробления задач?" Я рассказал на пальцах. Но меня еще раз спросили. Я снова рассказал. Но МЕНЯ ЕЩЕ РАЗ СПРОСИЛИ СЕГОДНЯ. Решил расписать, чтобы просто кидаться ссылочкой.

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

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

👯‍♀️ Две команды делали два новых сервиса. Сервисы предельно схожи по функционалу. В обоих нужно было собирать из шины сообщения и показывать цифры на телевизоре (разумеется в красивой оболочке, чтобы было секси и все такое).

Первая команда выбрала путь самурая: выкатить сразу некий рабочий мвп, который можно показать в пиццерии. До момента состояния пригодного к демонстрации сервис разрабатывался только на дев стендах и локально.

Вторая команда выбрала вариант с выкаткой пустого сервиса в прод и постепенным доведением, мелкими шагами, до пригодного для демки вида.

Казалось бы, первый вариант правильный. Зачем тратить место на проде, если сервис еще не готов? Вот тут и произошла загвоздочка!

В какой-то момент в командах произошла одна и та же ошибка: сообщение из шины консьюмилось неверно и приводило к падению приложения. Разумеется на момент ошибки это было неизвестно, поэтому команды взялись за разбирательства

У команды номер один в момент поломки был готов и фронт и бэк, поэтому матрица диагностики состояла из трех вариантов:

1️⃣ Сломан бэк, фронт в порядке
2️⃣ Бэк в порядке, сломан фронт
3️⃣ Самый худший вариант: Сломано и то и другое.

У команды номер два матрица диагностики была такая:
1️⃣ Что-то сломано в бэке.

Чувствуете разницу? Три варианта против одного. Более того, в случае, если команда один сломала и фрон и бэк, то поиск проблемы усложняется многократно!

У команды два диагностика минимальна: "Мы выкатили коммит, где всего десять строчек. В них что-то видимо и сломалось."

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

В первом случае выкатка заняла время разработки + долгое время диагностики. (2 месяца в сумме)

Во втором случае только время разработки. (1 месяц в итоге)

И это то самое преимущество, которое дает мелкое дробление задач — устойчивость перед так называемыми Черными Лебедями. Вроде все очевидно.

И вы спросите, Димас, ну все же очевидно! Почему тогда люди не понимают, что дробить задачи нужно мелко?

Дело в том, что, если, у обеих команд все пошло бы гладко, то вся эта матрица проблем свелась бы к нулю. И тогда мелкая декомпозиция и время её выкатки не сильно отличится от времени выкатки БОЕВОГО МЕГАКОНЯ.

Тут я упомяну Канемана в суе. У него есть хорошая теория, что человеческое сознание делится на две системы Система 1 и Система 2.

Система 1 - это штука, которая работает быстро, не тратит энергию мозга, но и результаты выдает скверные. Она задействуется всегда, по делу и без.

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

Так вот. Чтобы расписать вышеприведенную матрицу надо напрячь мозги. Более того, нужно еще где-то на подкорке понимать, что может случиться ⬛️ 🦢Черный Лебедь. А это мысль неприятная, думать её тоже больно, что дополнительно толкает мозг думать проще "Выкатим все разом, ну там же ломаться нечему!"