Technical-Debt

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

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

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

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

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