Technical-Debt

Если вы читаете это, возможно, кто-то в вашей организации оправдывал сохранение той древней системы COBOL или тех серверов эпохи Pentium, которые пылятся в углу центра обработки данных. Вы слышали, как это называют «технической задолженностью», «необходимым злом» или — моё любимое — «мы перенесём это в следующем квартале» (мы оба знаем, что этого никогда не произойдёт). Но что, если я скажу вам, что ваши устаревшие системы на самом деле могут приносить вам пользу?...

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

Я начну с признания: ваш технологический стек, скорее всего, неправильный. Не может быть неправильным, а именно неправильным. И знаете что? Мой тоже был неправильным. На самом деле, я готов поспорить, что если вы можете назвать весь свой технологический стек, не заглядывая в документацию, есть хорошие шансы, что вы что-то чрезмерно усложнили. Позвольте мне объяснить, почему это происходит, и, что более важно, что с этим делать. Соблазнительный танец «лучшего в классе» Вот где большинство проектов идут не так....

Ваша кодовая база — это хаос. Вы это знаете, и ваша команда тоже. У одной функции 47 параметров. Переменные названы в честь ваших кошек. И где-то там комментарий 2015 года гласит: «TODO: исправить это перед запуском в производство», и голос в нём звучит всё более отчаянно. Естественно, вы поступаете как любой уважающий себя разработчик: берёте обязательство провести масштабную рефакторинг-спринт-доработку. Две недели, думаете вы. Может быть, три. Вы красиво перепишите всё, примените шаблоны проектирования, словно они выходят из моды, и выйдете победителем с кодовой базой, настолько чистой, что по ней можно будет есть....

Представьте: вы торопитесь закончить работу до срока, который приближается быстрее, чем белка, напившаяся кофе. Ваша команда могла бы создать «идеальное» решение примерно за три недели. Или вы можете запустить рабочую версию завтра, стратегически сократив некоторые этапы. Добро пожаловать в искусство намеренного технического долга — где умные shortcuts становятся суперспособностями, а не грехами. В отличие от случайных ошибок в коде, возникающих после ночных сессий кодирования (#Виноваты), намеренный технический долг — это осознанный компромисс — рассчитанный риск, который даёт вам пространство для манёвра сегодня, планируя уборку на завтра....