Technical-Debt

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

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

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

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

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