Технический долг накапливается с течением времени, и в какой-то момент может сделать приложение непригодным для поддержки. Это как бомба замедленного действия, которая, если ее не обезвредить вовремя, может привести к серьезным последствиям для клиентов и финансовому ущербу для организации.
Термин «технический» в названии зачастую вызывает ощущение, что сокращение технического долга является исключительной ответственностью разработчиков. Конечно, команда разработки играет ключевую роль в рефакторинге кода и сокращении технического долга. Но рефакторинг не всегда ограничивается только кодом. Многие другие группы сотрудников должны играть свои связанные роли, чтобы обеспечить рефакторинг и сокращение технического долга.
Давайте попробуем поговорить о том, какие группы или отдельные роли в организации должны объединяться для сокращения технического долга.
IT-руководство
В истинном духе одного из принципов Agile – «Постоянное внимание к техническому совершенству» – IT-руководству необходимо осознавать, что «идеальное» или «отличное» решение сегодня может не соответствовать будущим требованиям с точки зрения скорости или надежности и может не соответствовать ожиданиям клиентов. Подобные компромиссные технические решения должны постоянно пересматриваться и улучшаться.
Руководители IT-департаментов должны понять ценность затрат времени на то, чтобы сделать приложение устойчивым в долгосрочной перспективе. Они должны дать командам время и средства на рефакторинг существующего кода, чтобы сделать его лучше. Они должны предоставить своим операционным менеджерам и линейным руководителям полномочия для принятия необходимых решений по рефакторингу и улучшению существующих приложений.
Владелец продукта
Владелец продукта (Product Owner) играет ключевую роль в организации работы команды разработчиков. Он несет ответственность за сбор бизнес-требований и определение их приоритетов. При этом PO руководствуется в расстановке приоритетов соображениями ценности для бизнеса. Однако владельцу продукта следует не забывать, что приложение будет продолжать работать так, как ожидается, и предоставлять бизнес-ценность только в том случае, если оно построено на прочной основе.
Когда команда разработки проводит ревью существующей архитектуры и кода и определяет возможности для улучшения, им приходится учитывать усилия по рефакторингу наряду с требованиями приоритезации от PO. Через определенные промежутки времени владелец продукта должен предоставлять команде возможность проводить рефакторинг. Это может потребовать отмены приоритетов, обусловленных бизнес-требованиями. Но владелец продукта имеет средства управлять этим процессом и поддерживать осведомленность стейкхолдеров со стороны бизнеса.
Заинтересованные стороны бизнеса
Наряду с владельцем продукта стейкхолдеры играют свою роль в создании надежного приложения. Когда речь заходит об удовлетворении неотложных бизнес-требований, а не о том, чтобы сделать приложение более устойчивым, стейкхолдерам в долгосрочной перспективе следует зарезервировать время для работы с техническим долгом. В подходящий момент – скажем, в период спада – они должны быть готовы немного замедлиться и позволить потратить усилия на рефакторинг. Они должны понимать, что время и деньги, вложенные в рефакторинг, могут не показывать видимых изменений в функциональности, но помогут улучшить качество и производительность приложения. Они также должны осознавать, что не стоит строить функциональность поверх известных недостатков приложения.
Архитекторы
При рефакторинге кода разработчик может проявить улучшения в архитектуре приложения. Архитекторы должны признавать необходимость рефакторинга архитектуры. Они должны быть готовы вкладывать усилия в анализ влияния изменений и соответствующим образом реорганизовывать архитектуру.
При этом им следует убедиться, что изменения соответствуют общей архитектуре на уровне предприятия. В то же время, если они видят возможности для улучшения общей архитектуры, необходимо транслировать это сообществу архитекторов предприятия. Если это требует значительных изменений, то PO и стейкхолдеры со стороны бизнеса должны быть осведомлены о последствиях таких изменений.
Тестировщики
Каждое изменение кода должно быть протестировано перед развертыванием приложения. На основе кода или дизайна, прошедших через рефакторинг, инженеры по тестированию – как ручному, так и автоматизированному – должны быть готовы рефакторить тест-кейсы. Может возникнуть несколько вариантов: некоторые тест-кейсы становятся избыточными и больше не требуются; некоторые тест-кейсы придется обновить; могут потребоваться новые тестовые наборы для проверки веток кода, которые появятся после рефакторинга. При внедрении этих изменений тестировщики должны быть уверены, что они не утратили полноценность проверки исходной функциональности.
Следует отметить, что речь здесь идет об изменениях в тестовых кейсах или скриптах, возникающих в результате рефакторинга кода. Ревью и поддержание чистоты набора регрессионных тестов – это исключительно необходимые усилия при рефакторинге тест-кейсов и тестовых скриптов.
Команда эксплуатации
Иногда рефакторинг может определить более простые способы развертывания приложения. В таких случаях преимущества, полученные в ходе рефакторинга, могут быть реализованы не полностью, если не внести изменения в развертывание. Команда эксплуатации должна тесно сотрудничать с разработчиками, архитекторами и тестировщиками для выявления таких изменений и предоставления подходящей среды тестирования и развертывания переработанного кода.
Если организация станет зрелой в практиках DevOps, это сотрудничество будет укореняться в их подходе к работе. Однако если команды находятся на ранних стадиях принятия DevOps, руководство департаментов Dev и Ops должно облегчить совместную работу, чтобы извлечь выгоду из усилий по рефакторингу.
Технический долг – это широкий термин, охватывающий все этапы цикла разработки IT-решения. Это понятие не ограничено только кодом. IT и бизнес должны иметь комплексное end-to-end видение проблемы и периодически проводить рефакторинг приложения, чтобы уменьшить технический долг.
Оригинал статьи Developers Alone Cannot Reduce Technical Debt in a Silo, автор Равишанкар Н. (Ravishankar N.)