Эта статья о техническом долге имеет несколько положительных моментов, в том числе:

Работа над «техническими вопросами» работает лучше всего, когда она основана на историях. Кодовая база, вероятно, нуждается в работе везде, но выигрыш будет получен только там, где будет работать код по причинам, связанным с пользователем. Если никакие истории не пройдут через какую-то жестокую область, работа над ней в значительной степени напрасна.

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

Этот подход имеет как минимум следующие преимущества:

• поддерживает «самый разумный» поток историй;
• предоставляет помощь от всех командных талантов;
• обеспечивает всю команду, чтобы научиться поддерживать чистоту кода;
• фокусирует улучшение именно там, где это необходимо;
• не тратит впустую улучшение, которое «может» понадобиться;

Я видел, как качество кода очень сильно влияет на долгосрочную производительность, поэтому я уверен, что о технических долгах нужно заботиться. Я думаю, что пост выше имеет смысл, но я не очень уверен насчет последних двух пунктов. Я заинтересован в том, чтобы узнать реальный опыт получения выгод от очистки технического долга, даже если он не связан с пользовательскими историями.

Какие положительные преимущества вы получили от очистки базы кода и избавления от технического долга? Какие методы вы использовали, чтобы получить работу?

Я могу привести один пример из моего опыта.

Около 10 или 12 лет назад я унаследовал приложение от команды разработчиков, которые в конечном итоге покинули компанию (слишком долго, чтобы попасть сюда ...). Система представляла собой крупную отечественную систему генерации отчетов промежуточного программного обеспечения. Он работал каждую неделю по ночам и генерировал около 2 десятков отчетов Excel для руководителей высшего звена компании из списка Fortune 500. Когда я унаследовал это, потребовалось приблизительно 5-6 часов, чтобы бежать и в течение любой данной недели потерпеть неудачу по крайней мере 2 ночи.

Я не был счастливым туристом, получившим этот беспорядок.

Первоначально мой план состоял в том, чтобы просто остановить кровотечение и устранить основную причину сбоев. После того, как я освоился с базой кода, я начал искать места, где можно было бы провести рефакторинг и добавить стабильность и производительность. В течение примерно двух лет я внесла множество изменений в систему. Мы удалили эту систему пару лет назад, и в этот момент весь процесс занял 45 минут и не вызывал никаких проблем в течение многих лет.

Много работы ушло на погашение технического долга, но оно того стоило. Было приятно не получать никаких телефонных звонков в середине ночи, когда система вышла из строя. Было приятно зайти в офис в монринге и увидеть только хорошие новости в журналах.

(За исключением ... Через пару лет я столкнулся с одним из главных разработчиков этой системы. Он спросил меня, как у нее дела, и я сказал ему, насколько плоха система. Он на самом деле извинился и сказал, что знает, что это будет горстка, чтобы поддержать после того, как он уехал и хотел, чтобы он сделал лучшую работу над этим).

По моему опыту, преимущества очистки кода наиболее заметны, когда мне приходится поддерживать код там, где очистка еще не выполнена. Там, где была проведена очистка, мои изменения состоят из чтения кода, определения одного или двух мест, которые необходимо изменить, и перехода оттуда. Если очистка не была выполнена, добавьте начальный шаг чтения кода пару раз и попытайтесь выяснить, о чем думал автор (иногда я), когда писал его.

устранение технического долга дает меньше технической поддержки и лучшую основу для улучшений

всегда

У меня был один опыт, когда я руководил командой Site Performance у моего предыдущего работодателя. Каждую ночь, в течение часа или двух часов, веб-сайт, который отслеживался моей командой, падал ниже приемлемых порогов производительности из-за того, что бот быстро удалял информацию с сайта. Меры, предпринятые группой для решения этой проблемы, заключались в том, чтобы войти в систему администрирования вручную и заблокировать IP-адреса, которые вызывали проблемы. Само собой разумеется, это стоило одному члену команды часов сна почти каждую ночь. Я заметил, что происходит, и сам взял BlackBerry по вызову на несколько дней, чтобы посмотреть, насколько это плохо, и дать моей команде немного отдохнуть.

Через несколько дней я просто пошел к владельцу бизнеса команды и сообщил им, что если бы мы не внедрили автоматизированную систему блокировки, такую, чтобы у ботов было бы гораздо сложнее повлиять на производительность сайта, мы, вероятно, потеряли бы некоторые, если не все члены команды, из-за усталости и выгорания. Они согласились, и мы внедрили систему, которая позволяла нам спать по ночам. Владелец бизнеса понимал, что стоимость нескольких дней или недели разработки была минимальной по сравнению со стоимостью найма / обучения новых инженеров.

Относительно последних двух пунктов: я понимаю, откуда это происходит, как объяснено в его первоначальном посте :

Или, возможно, переназначить некоторых разработчиков для решения этих технических вопросов, в то время как остальная часть команды продолжает заниматься пользовательскими вопросами? Это может повлиять на скорость команды, но что с того?

«И что» равняется: владелец продукта и другие деловые люди становятся несчастными. А когда мама несчастна, все несчастны.

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

Вещи, которые не влияют на общую производительность, менее интересны для очистки, но следует очень тщательно оценить влияние этих моментов. Чаще всего они оказывают косвенное влияние, которое может быть довольно существенным.

Самая большая выгода, которую организация получит в результате погашения технического долга, - это избегание сложного процента. Ниже приведен пример в записи блога, который показывает, как основная сумма задолженности по техническому долгу всего за пять лет увеличилась с 160 тыс. До 430 тыс. Долларов. Программисту, занятому полный рабочий день, понадобится исключительно на обслуживание этой суммы долга. Это поможет сделать это в перспективе для лиц, принимающих решения!

От blog.acrowire.com .