Бывает, так увлекаешься работой, что начинаешь пить чай прямо за рабочим местом. И уже не важно, полупустая у тебя кружка или наполовину полная — почти наверняка чай в ней успел остыть. С ошибками всё наоборот. На них мы как раз смотрим пристально и эмоционально: видим в них источник опасности, понимаем, что попытка исправить одну ошибку часто порождает другие, и только иногда смеёмся над «это не баг, а фича», когда находим неожиданно полезное поведение системы.
А что, если и правда относиться к ошибкам не только как к угрозе, но и как к точке рождения новой логики, новой функции, новой услуги? Не в смысле объявлять любой баг фичей, а в смысле: воспринимать ошибку как сигнал к переосмыслению связки «исходные данные → результат». Бред? Давайте по порядку.
Настоящий бред — это когда к ошибочному результату приводят продуманные, логичные, признанные практикой действия. Система «по бумаге» выстроена правильно, все шаги понятны, но на выходе — поведение, которое никого не устраивает.
Любое исправление такой ошибки — это не только «починка». Это усложнение среды: новый фрагмент логики, новый обходной путь, новый слой. Так накапливается то, что мы называем техдолгом: быстрые костыли, которые кажутся разумными сейчас, но делают систему всё более хрупкой со временем. На этапе разработки все соглашаются, что важно держать в голове принципы построения, видеть систему целиком, учитывать развитие продукта. Но как только появляется конкретный баг, мы почти автоматически подставляем костыль — и очень редко можем честно оценить, как это повлияет на архитектуру через год или два. Не потому что глупые — потому что в сложных системах это действительно почти невозможно просчитать заранее.
Я не призываю бросаться в другую крайность: переписывать всё с нуля при каждом отклонении или, наоборот, заваливать систему костылями до конца её жизни. Скорее речь о том, чтобы иногда смотреть на ошибку с другой стороны:
- это действительно отклонение от задуманного поведения или симптом того, что «задуманное» было слабым местом в модели;
- эта ошибка требует срочной «заплатки» или может быть переосмыслена как повод выделить новую явную функциональность;
- мы сейчас реально улучшаем систему или просто гасим симптом, перенося проблему в будущее.
Ошибки — и правда палка о двух концах. Но интересно не то, к какому концу они ближе, а куда по этой палке бежим мы: в сторону усложнения ради спокойствия «здесь и сейчас» или в сторону пересборки логики ради более простой и честной системы завтра.
0 комментариев