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

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

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

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

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

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

А если вы попали в проект, история которого насчитывает больше 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 under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.