Memento mori

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

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

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

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

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

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

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

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

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

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

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

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

• Итеративность. Начинаем итерацию с формулирования гипотез, заканчиваем их проверкой

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

• Реализм. Не делаем идеально, а делаем достаточно хорошо

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

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

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

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

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

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

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

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