//TODO – основа ваших будущих технических ограничений и разочарований, запланированная сегодня.
Сокращенный перевод статьи «Don’t delay your technical debts!».
В этой статье большая часть сценариев будет взята из сферы фронтенда/веб-разработки, но все сказанное в полной мере можно применять к разработке программ в целом.
Давайте для начала разберем, что такое «технический долг»
У этого термина из профессионального сленга есть много определений. Для простоты примем, что
технический долг в сфере разработки это предполагаемая стоимость дополнительной работы, которую придется проделать из-за того, что вы выбрали простое и быстрое решение вместо лучшего, реализация которого заняла бы больше времени.
Выбор более короткого пути может быть сделан в связи с недостатком времени, ресурсов, возникновением неотложной ситуации, а также просто по финансовым соображениям. Этого не всегда можно избежать, но следует обязательно учитывать при дальнейшей разработке. Как сказано в названии, долги просто нужно возвращать, и это не значит, что вообще нельзя брать в долг.
Почему нельзя затягивать с возвратом технического долга?
Тут все просто: долги всегда накапливаются, и в большинстве случаев – нелинейным образом.
Даже денежный долг следует возвращать как можно скорее. Если вы используете кредитную карту для своих финансовых потребностей, вы понимаете, сколько проблем возникнет, если хотя бы один месяц затянуть с выплатами. Некоторые кредитные карты предусматривают кредит под 13-15% ежемесячно или под 40% в год. Но что если заплатить по счету все без остатка, не откладывая и уложившись до конца отведенного срока? Обойдетесь без существенных убытков. В общем, чем дольше вы не возвращаете долг, тем тяжелее бремя для вашего кошелька.
То же самое касается технического долга. Разница в том, что в этом случае никакие технические средства не помогут оценить объем «процентов по кредиту», поскольку следует учитывать не только деньги, но и человеческий фактор.
Долг продукта и технический долг
Необходимо разбираться, является ли пропущенный кусок техническим долгом или же долгом продукта. Давайте рассмотрим вариант последнего.
Представьте, что есть сайт для блогов, он содержит набор статей (примерно, как на нашем сайте). На подобных сайтах (medium/wordpress) бывает функционал, позволяющий пользователю увидеть приблизительное время, необходимое для чтения отдельной статьи (например, «около 5 минут», «10 минут» и т.п.). Благодаря этой фиче пользователь может сразу решить, стоит ли ему сделать закладку на эту статью, оставить среди открытых вкладок браузера, прочитать сразу или сварить себе сначала чашечку кофе. А может, стоит перебраться на диван для комфортного чтения. Это распространенный функционал, полезный для читателей блогов. Выглядит примерно так:
Наш сайт не имеет такого функционала (в настоящее время, но когда-нибудь он у нас будет). Это просто долг продукта, а не технический долг. В конечном итоге мы можем и вообще не реализовать эту фичу.
Чем отличается технический долг
Однако, узнав, что наличие такой фичи — обязательное требование, я могу решить реализовать ее статически, т. е., указать для каждой статьи вручную приблизительное время чтения, например, «10 минут». Время чтения каждой отдельной страницы я буду определять, исходя из ее длины и средней скорости чтения пользователей, скажем, 50 слов в минуту. Вот эта реализация уже похожа на технический долг. Почему? Потому что в техническом плане есть лучшее решение.
Поскольку каждая статья генерируется с помощью генератора статических сайтов (jekyll), можно реализовать функцию, которая будет принимать в качестве входящих данных длину поста, предсказывать время чтения и привязывать его к каждой статье. Этот подход лучше, потому что:
- не зависит от мнения автора,
- в будущем функцию можно будет откорректировать.
Такой долг кажется чем-то простым, но представьте, что после того как я вручную проставил на сотне статей время чтения, исходя из длины каждой статьи (т.е., потратил на все это много времени), я узнаю, что мои читатели на самом деле читают с другой скоростью, скажем, 100 слов в минуту. При моем подходе мне придется вручную поменять данные на всех предыдущих страницах, сделав все вычисления по новой. В дальнейшем выяснится, что время чтения вообще зависит от категории поста: статьи с отрывками кода читаются медленнее, чем просто текст. И снова потребуется пересчет времени для всех постов. Это простой пример долга, вынуждающего нас каждый раз вносить множество изменений.
Поддержка этого функционала в течение длительного времени будет очень тяжелой задачей, поскольку сайт для блогов это очень много статей. Было бы куда лучше, если бы этот функционал продукта был разработан с учетом будущих требований, причем в разработке должны учитываться и технические аспекты.
Сравнение с кредитом
Несмотря на то что это очень маленький и простой пример, количество дополнительной работы здесь также будет зависеть от размеров технического долга.
Проще говоря, если вы взяли кредит в 100 долларов под 10% годовых, вам нужно будет заплатить в конце года лишние 10 долларов, а если при той же ставке вы взяли 20 миллионов, проценты составят 2 млн.
Наш десятидолларовый пример не идет ни в какое сравнение с 2 миллионами долларов. Но суть не в сумме выплат, а в размере ставки по кредиту. Какой бы маленькой она ни была, итоговые выплаты все равно будут расти в зависимости от срока кредита и суммы кредита. С техническим долгом то же самое. Чем дольше вы откладываете его возврат, тем больше за это придется заплатить, и не важно, много вы взяли или мало.
Побочные эффекты
Кроме денежного и временного аспектов, у технического долга есть несколько других, побочных эффектов, приводящих к нежелательным вещам.
Раздражение и демотивация команды разработчиков
Это один из самых значительных побочных эффектов, действие которого проявляется все больше с течением времени. Если в ходе работ все время добавляются серьезные проблемы, а продукт в техническом отношении не дотягивает до предмета искусства, это часто раздражает разработчиков, а раздражение, в свою очередь приводит к другим побочным эффектам. Кроме того, это демотивирует и деморализует команду.
Болезнь «не сломано – не трожь»
Если долг огромен, разработчики, фактически, не решаются даже браться за масштабную задачу, которая поначалу была крошечной. Это приводит к тому, что они предпочитают закрывать глаза на проблему, если только обстоятельства не вынуждают разбираться с ней. Последний гвоздь в крышку гроба – распространение такого подхода на всех разработчиков, команды, руководство и компанию в целом. Это огромный урон для культуры любой компании, и оправиться от него нелегко.
Ограничения в проектировании
Если часть системы страдает от технических ограничений, потребитель тоже будет страдать. Когда какой-то важный сервис (скажем, аутентификация) может обрабатывать только «х» api-вызовов в минуту, проектирование функционала других частей продукта будет подгоняться под эти ограничения. Таким образом, появляются ограничения в проектировании множества сервисов и продукта в целом.
Реактивная разработка продукта вместо проактивной
С устаревшей системой всегда приходится искать обходные пути для реализации новейших функций и трендов. Это вводит продукт в реактивный режим и отнимает саму возможность проактивной разработки. То есть, все новые вещи реализуются только в результате внешнего давления.
Технический долг всегда сравнивают с денежными кредитами, как в этом посте. Но есть и другие варианты для сравнений, помимо показателей, поддающихся измерению. Например, здоровье. Чем дольше вы откладываете поход к врачу, тем сложнее будет протекать лечение, а порой можно досидеться и до необратимых последствий.
Итак, есть ли у вас существенные технические долги? Займитесь ими сейчас, потому что то, что не делается сразу, с большой вероятностью не сделается никогда.
О том, как разработчику справиться с техническим долгом, читайте в следующей части.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]