К основному контенту

Технический долг - бьем на части и ликвидируем.

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

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

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

Как только вы дали слабину и приняли заведомо спорное (или компромиссное) решение, вы должны отдавать себе отчет - ваш баланс стал отрицательным. И если в самое ближайшее время вы его не выправите, дальше будет все сложнее и сложнее выделить время, ресурсы, деньги (нужное подчеркнуть) на то, чтобы исправить ситуацию.
Дальше хуже: теория разбитых окон проявится во всей своей красе.

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

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

Давайте вспомним, что мы обычно понимаем под техническим долгом. Согласно классическому определению, данному Уордом Каннигемом (Ward Cunningham), технический долг - это разница между идеальным техническим решением и тем решением, которое принимается сейчас.

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

Получается, что мы может говорить о следующих видах долга:
- долг реализации
- технологический
- процессный
- долг компетенции

IT, по мотивам cartmendum
Долг реализации: сюда можно отнести то, что обычно и понимают под техническим долгом, на мой взгляд узко смотря на эту проблему. Приобрести этот долг можно и приняв неправильные архитектурные решения (вот тут аккуратно, очень скользкий момент), и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Очень ярко это отражено в твите (18+), читайте комменты - это просто песня. Я прослезился. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.

Долг технологический приобретается через отказ от применения новшеств в языках,

фреймворках, инструментах. У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
Очень пересекается с Innovation Debt.

В кабалу процессного долга можно попасть отказываясь или затягивая принятие решений по применению Continuous Integration, XP-практик. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта).

Долг компетенции возникает из-за узкоспециализированной разработки, когда в команде есть
человек(и) с уникальными знаниями. Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям. Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации. А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".

Обо все этом мы сможем с вами поговорить на конференции BitByte, 25 апреля в Питере. Приходите, буду рад пообщаться. В том числе и про способы ликвидации долга. Не дайте импотеке управлять вами! :)

Мой отчет с выступления. Там же можно найти много полезных линков на эту тему.

Пишите комментарии здесь, может я излишне пессимистичен или все усложняю :)

Слайды с аналогичного выступления на IT Global Meetup SPb


ITGM#4 Технический долг 2.0 from Maxim Shulga

Список материалов, которые могут помочь разобраться с этим вопросом подробнее:

Материалы с сайта Уорда Канингема:
Technical Debt
Видео с объяснением что такое тех долг от Уорда

Попытка посчитать сколько может стоить долг

Мартин Фаулер про техдолг

Интересная статья Сергея Теплякова

Про долг компетенции

Выступление Бориса Вольфсона на тему технического долга, очень рекомендую

Видео доклада про технический долг с AgileDays'14

Еще интересно про тех.долг

Про неправильные метафоры технического долга.

"Не тратьте время на отслеживание технического долга" - интересные мысли.

Сборник статей по тех.долгу

"Технический долг как избыточный вес"

"Technical Debt: The Man, the Metaphor, the Message":
"The “debt” is the missing parts of our understanding of the problem and the necessary solution; not the quality of the code we write. Whatever code we write, we’re expected to write as well as we can. Always."

Комментарии

  1. Мсье Книберг имеет несколько иное мнение на сей счет - что типа не так уж и страшен зверь как его малюют.
    http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt





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

    ОтветитьУдалить
  2. Никита, на самом деле скорее всего "пилка" в диапазоне и получится. По-любому. Даже если все сразу закрывать. Просто входные параметры: требования, критерии качества, база знаний и тп будут разные в разные моменты времени. А Книберг просто говорит, что надо просто контролировать уровень и вводить корректирующее воздействие по факту.

    ОтветитьУдалить
  3. Что самое знаковое о чем говоорит книберг - это то, что как бы с этим тоже можно жить и его уровнем можно управлять.


    Лично я считаю что пилу допускать нельзя - пережили 3-4 пика пилы и начнут думать что этим можно управлять .
    А эта штуковина может съесть тебя в любой момент.
    Бороться , до последнего даже когда все хорошо.
    Победить может и не получится,но baseline будет как можно ниже.

    ОтветитьУдалить
  4. Угу, я с этого и начал пост: бороться нужно постоянно. Видимо не до конца, или не так, объяснил :) Абсолютно с тобой согласен насчет baseline. Но сама пилка никуда не денется: просто надо частоту зубьев уменьшать, чаще зачищая отходы жизнедеятельности :)

    ОтветитьУдалить

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объек

План "Б" или как прикольно провести субботний день

Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а" Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно ча

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после  вчерашнего выступления . Uncle Bob : " Flipping the Bit " Подробнее постараюсь перевести чуть позже, пока только это: Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :) Мантра: Сможете ли вы выполнить работу быстрее используя TDD? ДА Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА В любом случае? ДА Есть ли случаи, когда вам не нужно использовать TDD? НЕТ Представьте себе что вы на звездном корабле Enterprise ( Star track ) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы и