Недавно я одобрил pull request от коллеги с таким описанием: «Сделано костыльно, но мне не хватает сегодня времени реализовать это лучше». И тогда я задумался: когда же будет устранен этот «костыль»? На память приходит много случаев, когда я сам или мои коллеги отправляли в работу код, который нас не вполне устраивал (с точки зрения простоты поддержки, качества, чистоты, из-за проблем с функциональностью, неважного пользовательского опыта и т.д.). С другой стороны, воспоминаний о том, как мы реально возвращались к чему-то и вносили необходимые изменения, у меня гораздо меньше.
Где-то я читал (к сожалению, сейчас не могу найти источник) такую мысль: «Чем дольше что-либо остается неизменным, тем меньше вероятность, что оно изменится в будущем». Иными словами, начиная с того момента, как мы отправили в релиз «костыль», шансы на то, что он будет исправлен, неуклонно снижаются с течением времени. Если сегодня мы его не устраним, завтра вероятность станет ниже. Послезавтра она еще снизится, через неделю – еще, через месяц – еще…
По моим наблюдениям, эта закономерность работает, и, думаю, на то есть несколько причин. Как ни странно, причины эти заключаются не том, что мы лентяи, нам не хватает профессионализма или просто плевать на всё. И даже не в менеджерах продукта, которые злодейски заставляют нас переходить к новой функциональности и не дают ничего чинить. Причин несколько, и они взаимосвязаны.
Чем больше времени отделяет вас от момента, когда был написан код, тем хуже вы его понимаете. Вы меньше помните о том, какие функции он выполняет, какие функции должен выполнять и каким образом, где он используется и так далее. А если вы не помните все предполагаемые сценарии использования, то не можете быть уверены, что проведете тесты для всех из них.
Соответственно, вас начинает тревожить мысль, что любое изменение, которое вы внесете, может вызвать сбои в каком-то сценарии использования, который вы не учитываете. Да, хорошие тесты отчасти решают эту проблему, но многие ли из нас готовы полностью положиться на свои наборы тестов даже в тех случаях, когда код нам не слишком хорошо знаком?
Такой ход мысли порождает опасения, которые препятствуют переменам. Преимущества от усовершенствования кода не перевешивают риска что-нибудь испортить.
Чем дольше с чем-нибудь живешь, тем сильнее привыкаешь к такому положению вещей. С течением времени проблема всё меньше и меньше воспринимается как проблема.
В качестве примера: я недавно переехал. В первые несколько дней, пока мы распаковывали вещи, не хватало ни времени, ни сил заново собрать каркас для кровати. Это не было для нас приоритетной задачей – можно без проблем поспать и на матрасе, лежащем на полу. Хватало других дел, требующих нашего внимания.
В конце концов, у нас всё-таки дошли руки до сборки… спустя полгода после переезда. На первых порах было как-то странно проходить мимо частей каркаса, разложенных на полу. Но потом мы привыкли и в конечном счете вообще перестали об этом задумываться.
Эта причина проистекает из двух предшествующих. На одной чаше весов у нас неполадка, с которой мы уже сжились и которую опасаемся подвергать изменениям. Она связана для нас с большими рисками и малыми преимуществами. На другой чаше весов – что-нибудь из нового, что мы хотели бы реализовать или доработать. Поток этих новинок никогда не иссякает.
Выбор представляется очевидным. И так каждый раз.
Хоть мы и понимаем, что код «плохой», выстраивать новую функциональность поверх него нам всё-таки приходится. Причем такая необходимость возникает быстро, прежде чем у нас появится возможность что-то исправить. И вот теперь у нас на руках код, который завязан на «плохом» фрагменте и, вероятно, выйдет из строя, если мы что-то в этом фрагменте изменим.
К примеру, мы прописали валидацию данных на слое UI. Однако мы понимаем, что валидацию данных следует проводить на доменном слое и, соответственно, рассчитываем перенести код «как-нибудь потом». Спустя некоторое время мы пишем какой-то код на доменном уровне с расчетом на то, что данные, полученные от UI, уже валидны. А значит, если мы уберём валидацию из UI, то этот новый код посыплется.
А вот более серьезный, архитектурный пример. «Для начала мы возьмем неструктурированную базу данных (вроде mongoDB), так как пока не представляем, какие у нас будут данные. Мы хотим располагать возможностью быстро и легко менять их форму. Когда модель данных стабилизируется, можно будет вернуться к этому вопросу».
Я работал на три разные компании, которые рассуждали именно таким образом. И во всех трех историях я обнаружил нечто общее:
Но перейти на другую базу данных они не могут – слишком много функциональности выстроено на основе исходной.
Итак, теперь мы понимаем: если не исправить проблему сразу, то существует большая вероятность, что всё так и останется. И что? Почему это так важно было понять?
Потому что это позволяет нам принимать взвешенные решения. До сих пор мы полагали, что выбираем между «исправить сейчас» и «отложить исправление на какой-то неопределенный момент в будущем». Теперь мы можем обозначать свои варианты с большей честностью: «исправить сейчас» или «смириться с тем, что не исправим никогда». Это уже совсем другой разговор, значительно более реалистичный.
Исходя из этого осознания мы можем точнее расставлять приоритеты. Если мы понимаем, что ситуация относится к разряду «сейчас или никогда», то, возможно, нам удастся поставить важный фикс впереди всего остального, вместо того чтобы забросить его в ту черную дыру, которую представляют собой нижние 80% бэклога.
Более того, это осознание может помочь нам в соглашениях и организации процессов. В прошлом у моей команды был принят распорядок, который хорошо себя показал: сразу после завершения любого проекта нам отводилось время на «уборку». Команда не переключалась на следующую крупную задачу, едва только функциональность ушла в релиз. У нас был определенный срок, чтобы исправить всё, что требует внимания и в противном случае навсегда осталось бы нетронутым.
Если мы так и будем продолжать надеяться, что задача, которая вечно откладывается, в один прекрасный день будет решена, то никогда ничего не починим. Если же мы признаем, что у нас есть только небольшое окно возможностей что-то предпринять, то сможем строить реалистичные планы, которые подтолкнут нас к действию.
Для иллюстрации: мысль о том, чтобы написать эту статью, пришла мне в голову вчера вечером, когда принимал душ. Выйдя из душа, я рассказал о ней жене. Она сказала: «Вот иди и напиши сразу, а то никогда этого не сделаешь». И точно. Сравните эту статью, написанную и опубликованную, с целым списком «идей для статей», которые так и не материализовались. Я не написал их «как-нибудь потом».
Пожалуй, прислушаюсь к собственному совету и пойду удалю этот список.
Где-то я читал (к сожалению, сейчас не могу найти источник) такую мысль: «Чем дольше что-либо остается неизменным, тем меньше вероятность, что оно изменится в будущем». Иными словами, начиная с того момента, как мы отправили в релиз «костыль», шансы на то, что он будет исправлен, неуклонно снижаются с течением времени. Если сегодня мы его не устраним, завтра вероятность станет ниже. Послезавтра она еще снизится, через неделю – еще, через месяц – еще…
По моим наблюдениям, эта закономерность работает, и, думаю, на то есть несколько причин. Как ни странно, причины эти заключаются не том, что мы лентяи, нам не хватает профессионализма или просто плевать на всё. И даже не в менеджерах продукта, которые злодейски заставляют нас переходить к новой функциональности и не дают ничего чинить. Причин несколько, и они взаимосвязаны.
Утрата контекста и уверенности
Чем больше времени отделяет вас от момента, когда был написан код, тем хуже вы его понимаете. Вы меньше помните о том, какие функции он выполняет, какие функции должен выполнять и каким образом, где он используется и так далее. А если вы не помните все предполагаемые сценарии использования, то не можете быть уверены, что проведете тесты для всех из них.
Соответственно, вас начинает тревожить мысль, что любое изменение, которое вы внесете, может вызвать сбои в каком-то сценарии использования, который вы не учитываете. Да, хорошие тесты отчасти решают эту проблему, но многие ли из нас готовы полностью положиться на свои наборы тестов даже в тех случаях, когда код нам не слишком хорошо знаком?
Такой ход мысли порождает опасения, которые препятствуют переменам. Преимущества от усовершенствования кода не перевешивают риска что-нибудь испортить.
Нормализация
Чем дольше с чем-нибудь живешь, тем сильнее привыкаешь к такому положению вещей. С течением времени проблема всё меньше и меньше воспринимается как проблема.
В качестве примера: я недавно переехал. В первые несколько дней, пока мы распаковывали вещи, не хватало ни времени, ни сил заново собрать каркас для кровати. Это не было для нас приоритетной задачей – можно без проблем поспать и на матрасе, лежащем на полу. Хватало других дел, требующих нашего внимания.
В конце концов, у нас всё-таки дошли руки до сборки… спустя полгода после переезда. На первых порах было как-то странно проходить мимо частей каркаса, разложенных на полу. Но потом мы привыкли и в конечном счете вообще перестали об этом задумываться.
Приоритетные задачи
Эта причина проистекает из двух предшествующих. На одной чаше весов у нас неполадка, с которой мы уже сжились и которую опасаемся подвергать изменениям. Она связана для нас с большими рисками и малыми преимуществами. На другой чаше весов – что-нибудь из нового, что мы хотели бы реализовать или доработать. Поток этих новинок никогда не иссякает.
Выбор представляется очевидным. И так каждый раз.
Теперь вы зависите от плохого кода
Хоть мы и понимаем, что код «плохой», выстраивать новую функциональность поверх него нам всё-таки приходится. Причем такая необходимость возникает быстро, прежде чем у нас появится возможность что-то исправить. И вот теперь у нас на руках код, который завязан на «плохом» фрагменте и, вероятно, выйдет из строя, если мы что-то в этом фрагменте изменим.
К примеру, мы прописали валидацию данных на слое UI. Однако мы понимаем, что валидацию данных следует проводить на доменном слое и, соответственно, рассчитываем перенести код «как-нибудь потом». Спустя некоторое время мы пишем какой-то код на доменном уровне с расчетом на то, что данные, полученные от UI, уже валидны. А значит, если мы уберём валидацию из UI, то этот новый код посыплется.
А вот более серьезный, архитектурный пример. «Для начала мы возьмем неструктурированную базу данных (вроде mongoDB), так как пока не представляем, какие у нас будут данные. Мы хотим располагать возможностью быстро и легко менять их форму. Когда модель данных стабилизируется, можно будет вернуться к этому вопросу».
Я работал на три разные компании, которые рассуждали именно таким образом. И во всех трех историях я обнаружил нечто общее:
- Сейчас, спустя годы они по-прежнему сидят на mongoDB.
- Они в высшей степени недовольны mongoDB.
Но перейти на другую базу данных они не могут – слишком много функциональности выстроено на основе исходной.
И что дальше?
Итак, теперь мы понимаем: если не исправить проблему сразу, то существует большая вероятность, что всё так и останется. И что? Почему это так важно было понять?
Потому что это позволяет нам принимать взвешенные решения. До сих пор мы полагали, что выбираем между «исправить сейчас» и «отложить исправление на какой-то неопределенный момент в будущем». Теперь мы можем обозначать свои варианты с большей честностью: «исправить сейчас» или «смириться с тем, что не исправим никогда». Это уже совсем другой разговор, значительно более реалистичный.
Исходя из этого осознания мы можем точнее расставлять приоритеты. Если мы понимаем, что ситуация относится к разряду «сейчас или никогда», то, возможно, нам удастся поставить важный фикс впереди всего остального, вместо того чтобы забросить его в ту черную дыру, которую представляют собой нижние 80% бэклога.
Более того, это осознание может помочь нам в соглашениях и организации процессов. В прошлом у моей команды был принят распорядок, который хорошо себя показал: сразу после завершения любого проекта нам отводилось время на «уборку». Команда не переключалась на следующую крупную задачу, едва только функциональность ушла в релиз. У нас был определенный срок, чтобы исправить всё, что требует внимания и в противном случае навсегда осталось бы нетронутым.
Если мы так и будем продолжать надеяться, что задача, которая вечно откладывается, в один прекрасный день будет решена, то никогда ничего не починим. Если же мы признаем, что у нас есть только небольшое окно возможностей что-то предпринять, то сможем строить реалистичные планы, которые подтолкнут нас к действию.
Для иллюстрации: мысль о том, чтобы написать эту статью, пришла мне в голову вчера вечером, когда принимал душ. Выйдя из душа, я рассказал о ней жене. Она сказала: «Вот иди и напиши сразу, а то никогда этого не сделаешь». И точно. Сравните эту статью, написанную и опубликованную, с целым списком «идей для статей», которые так и не материализовались. Я не написал их «как-нибудь потом».
Пожалуй, прислушаюсь к собственному совету и пойду удалю этот список.
