Общие сведения о техническом долге
Термин технический долг относится к будущим затратам, которые неизбежно будут понесены вследствие того, что сейчас выбирается более простое решение, а не лучшие практики, которые бы потребовали больше времени.
Термин "технический долг" был выбран из соображений аналогии с финансовым долгом (задолженностью). Люди, которые имеют долги, часто принимают решения, которые кажутся подходящим или единственно возможным вариантом на момент решения, но в результате их ежемесячные процентные выплаты по долгу возрастают.
Чем больше накапливается процентов к уплате, тем труднее приходится им в будущем и тем хуже становятся доступные в дальнейшем варианты выбора. В случае финансовой задолженности со временем приходится одалживать деньги, чтобы уплатить начисленные проценты, и возникает эффект "снежного кома". Подобным образом и технический долг может накапливаться до такого уровня, когда разработчики тратят почти все свое время на устранение проблем и переделки (будь то плановые или внеплановые), вместо того, чтобы создавать ценность для предприятия.
Но как это происходит?
Самое частое объяснение — это сжатые сроки. Когда разработчики вынуждены быстро создавать код, они часто принимают сочетания клавиш. Например, вместо рефакторинга метода для включения в него новой функциональности метод копируют, чтобы создать его новую версию. Затем проводится тестирование только вновь написанного кода, но пропускается тестирование на уровне, необходимом, если бы вносились изменения в исходный метод, ведь он вызывается из других частей кода!
Теперь существует две копии одного и того же кода, которые придется обновлять в будущем, вместо одной, и возникает риск расхождения логики. Причин может быть множество. Например, разработчикам может не хватать технических навыков и зрелости, или же может отсутствовать конкретный владелец продукта или однозначное руководство.
В организации может вообще не быть стандартов написания кода. Тогда разработчики даже не будут знать, какой код они должны были бы писать. У разработчиков может не быть точно сформулированных требований к результату. Или же им могут выдаваться в последнюю минуту изменения требований.
Требуемые работы по рефакторингу могут откладываться. Тестирование качества кода, любое, автоматизированное или ручное, может вообще отсутствовать. В конечном итоге становится все труднее и труднее предоставлять пользователям полезный и эффективный продукт в приемлемые сроки и по приемлемой цене.
Технический долг — это одна из основных причин того, что проекты не укладываются в сроки.
Со временем он нарастает так же, как могут накапливаться и денежные долги. Часто встречаются следующие источники технического долга.
- Отсутствие стиля и стандартов написания кода.
- Отсутствие тестовых случаев для модульных тестов или их неудачное проектирование.
- Игнорирование или непонимание принципов объектно-ориентированной разработки.
- Монолитные классы и библиотеки кода.
- Неудачная концепция, ведущая к плохим выборам используемой технологии, архитектуры и подходов. (Например, когда в концепции учтены не все атрибуты системы, влияющие на поддержку, удобство взаимодействия пользователей с системой, масштабируемость и другие факторы.)
- Чрезмерное техническое усложнение кода, "переинжиниринг" (добавление или написание кода, который не обязателен, написание собственного кода, когда было бы достаточно существующих библиотек, или создание ненужных уровней или компонентов).
- Недостаточное комментирование и документирование.
- Написание не самодокументирующегося кода (в частности, использование имен классов, методов и переменных, которые не являются описательными и не указывают их предназначение).
- Выбор компромиссов ради удовлетворения "поджимающих" сроков.
- Оставление в кодовой базе неиспользуемого кода.
Примечание.
Со временем технический долг потребует "уплаты накопившейся задолженности". Если его не "уплатить", то сначала команда будет устранять проблемы, реализовывать новые функции и усовершенствования продукта все медленнее, а со временем это станет просто экономически нерациональным.
Мы видим, что технический долг создает целый ряд проблем во время разработки и сильно усложняет добавление в продукт конечной ценности для пользователей.
Наличие технического долга на проекте поглощает производительность труда, ухудшает моральный климат в командах разработчиков, делает код трудным для понимания и "хрупким", замедляет внесение изменений и последующую проверку этих изменений. Незапланированная работа часто препятствует своевременному выполнению запланированных работ.
В долгосрочной перспективе она также подрывает потенциал организации. Часто технический долг в организациях накапливается постепенно и незаметно. Сначала он невелик, но со временем разрастается. Каждый раз, когда вносится быстрая и грубая правка или тестирование пропускается, потому что изменения необходимо внести срочно, проблемы все растут и растут. Становится все дороже и дороже предоставлять поддержку, а рано или поздно неизбежно возникают и серьезные проблемы.
Со временем организация уже не может своевременно и экономически эффективно реагировать на нужды и запросы своих клиентов.
Автоматизированные измерения для мониторинга
Один из способов минимизации постоянного накопления технического долга — это применение автоматизированного тестирования и оценки.
В следующих демонстрациях мы ознакомимся с одним из распространенных средств, используемых для оценки долга: SonarCloud. (Первоначальной версией этого продукта был SonarQube, предназначенный для локального использования).
Доступны и другие средства, и мы также обсудим некоторые из них.
А затем, в ходе практического занятия, вы узнаете, как настроить свои Azure Pipelines для использования SonarCloud, как интерпретировать результаты анализа, и, наконец, как настроить профили качества для управления наборами правил, которыми руководствуется SonarCloud в ходе анализа ваших проектов.
Дополнительные сведения см. на веб-сайте SonarCloud (на английском языке).
Итак, приступим к рассмотрению.
Azure DevOps можно интегрировать с широким рядом существующих средств, используемых для проверки качества кода в ходе сборок.
Какие средства оценки качества кода вы используете сейчас (если используете вообще)?
Что вам нравится и что не нравится в этих средствах?