~~Философия~~ статья начинается с удивления. В данном случае я отметил для себя то, как по-разному начинающие разработчики реагируют на сложности, с которыми сталкиваются. Например, когда надо сделать выбор - какое решение взять, чтобы избежать ошибок? Кажется, все сталкиваются с такими неудобными вопросами. Давайте попробуем разобраться.

Итак, как же реагируют разработчики?

Вариант первый - все будет хорошо. Гонки, побочные эффекты, утечки памяти - если и слышал, то это все какие-то прохладные истории из скучных книжек. Где-то у кого-то когда-то было. Таймауты на запросы добавлять не буду, да и код ответа можно не проверять, работает же.

Вариант второй - все будет хорошо, надо только учесть все потенциальные проблемы. Возьмем лучшие паттерны. Перехватим все исключения, Сделаем идеально, тогда уж точно заживем. Словами классика - “но чтобы это была такая бумажка, при наличности которой ни Швондер, ни кто-либо иной не мог бы даже подойти к дверям моей квартиры”. Проблема в том, что нет такой бумажки.

Я немного приврал в начале, что речь пойдет только о начинающих разработчиках. В книге “Мифический человеко-месяц” Фредерик Брукс описывает эффект второй системы на примере весьма опытной команды. Он рассказывает о последствиях желания учесть все проблемы, с которыми они столкнулись на прошлых проектах. На мой взгляд, это самый проблемный вариант. Ведь чтобы с него переключиться, необходимо признать свою слабость, ограниченность и относительность. Это сложно.

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

Суть проблемы

Если немного обобщить, то это не про баги, а про неопределенность.

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

Вопрос не в том, как избежать неопределенности, а как с ней жить

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

Что применяется для проектов с большой неопределенностью? Гибкие методологии. Что они предлагают?

Итеративность. Начинаем итерацию с формулирования гипотез, заканчиваем их проверкой
Бережливость. Делаем и планируем столько, сколько нужно и когда нужно. Не раньше, не позже, не больше, не меньше
Реализм. Не делаем идеально, а делаем достаточно хорошо

То есть дейлики, доска, ретро, и т.д. - это просто вариант реализации. Суть же в том, как сделать работу в условиях неопределенности возможной.

Как это применить в разработке? Закладывайте метрики и логи на этапе проработки фичи. Формулируйте гипотезы и наиболее дешевые варинты проверки - прототипы. Закладывайте failure modes - что может пойти не так, как вы об этом узнате, и что будете делать дальше.

Вопрос не в том, произойдет ошибка или нет. Вопрос в том, будет ли у вас достаточно информации, чтобы найти причины.

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

Подводя итоги

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

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

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

Memento mori