Мальчик с пальчиком и токсичный техдолг
YouTube | Подкаст | Слушать

Внутри романа «Серебряные коньки» Мэри Додж вложена гораздо более известная история о мальчике, который спас всех от наводнения благодаря своей самосознательности. Там говорится о том, как маленький мальчик, случайно обнаруживший маленькую струйку воды в плотине, поняв, чем это грозит засыпающему Харлему, заткнул дырку своим пальцем, и прождал так до самого морозного утра, когда его обнаружили местные жители и заделали пробоину. Он известен как «Герой Харлема».

Этот небольшой рассказ — прекрасная иллюстрация той канвы, в которой принято рассуждать о техдолге. Когда в проекте возникает ситуация, когда нужно срочно сделать что-то, чаще всего мы рассуждаем так: «давайте мы сейчас сделаем вот такой некрасивый хак, а уже потом переделаем по уму». Даже если человек сам себе не очень верит, то хотя бы ради соблюдения традиций, нужный набор слов произнести очень важно. Следуя нарративу того маленького рассказика, предлагается сейчас, на время релиза, буквально на недельку, заткнуть дыру пальцем, а потом, как срочность схлынет, переделать как надо.

На практике же получается, фабула должна быть такой: мальчик прождал всю морозную ночь, а потом — все утро. На следующий день никто не пришел, и через день. Через 200-300 лет его скелетик обнаружил бы спешащий прохожий, который, поворчав о варварских методах починки пробоин, убежал бы по своим делам дальше. А лет через 500 мальчика бы похоронил, даже не заметив, бульдозер, сваливающий землю для новой насыпи поверх старой.

Принято считать, что такой техдолг разъедает проект, и если его не отдавать, то рано или поздно он, проект, сложится под грузом костылей. Однако мой 17-летний опыт работы говорит об обратном: парадоксальным образом именно такие костыли оказываются намного более живучими, чем прочий код, который строится на века. Более того, именно такие костыли вызывают меньше всего проблем в сопровождении.

Вместе с тем, есть другой тип техдолга, намного более опасный. Токсичнее ваших коллег! Это когда мы закладываем какую-то архитектуру на будущее с подчеркнутыми точками расширения, однако этого будущего так никогда и не наступает. И наша астронавтика так и остается пестрой игрой ума, торчащая во все стороны разными острыми углами, на которые ежедневно натыкаешься, даже зная, где они расположены. Например, этим может быть некоторое дерево классов с наследованнием вместо пары функций, делающих очевидный минимум. Мы думали, что классов будет больше, а их больше не стало. Или DI вместо простого модуля с настройками. Или сложный фреймворк для валидации 5 полей в 2 JSON’ах. Будущее еще не наступило, а код уже толстый. Как забытые игрушки, которые достают только для того, чтобы протереть под ними пыль, вместо того, чтобы просто выкинуть.

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

В психологии есть неплохая теория, почему это так, но о ней бы хотелось поговорить потом. А сейчас, уже напоследок, подумать вот о чем: все эти сложные решения берутся не от глупости, а как best practices из статей или конференций. Конструктивно все эти материалы выглядят так: была проблема, сделали X, стало хорошо. И мы думаем, что сделав X, избежим проблемы, которая у нас может возникнуть. Здесь есть ловушка: проблема может и не возникнуть, а X уже у нас.

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

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