Нельзя сказать, что долги — априори вредная вещь. Люди, компании и целые страны часто залезают в финансовые долги, чтобы обеспечить и ускорить прогресс — например, построить дом, нанять дополнительный персонал и закупить сырье, наладить инфраструктуру и повысить качество образования. Разумеется, долг всегда облагается процентами, и их нужно выплачивать уже для того, чтобы оставаться на плаву. Вы должны обрести финансовую устойчивость и выгодно вложить одолженные средства прежде, чем бремя процентов начнет перевешивать выгоду от инвестиций. Долг — это временный инструмент. Автор текста — Пип Джонс.
В Agile-методологиях изменения всячески приветствуются. Эта философия гордо отделяет себя от «Водопада» именно потому, что приемлет и даже стимулирует постоянные изменения в рабочем процессе, трактует постоянные изменения как одну из основных частей разработки, а не предпринимает безнадежных попыток «заблокироваться» от таких вариаций. Изменения в работе по ходу проекта бывают обусловлены как положительными факторами (обучение клиента, НИОКР, фокус-группы, изменения конъюнктуры рынка), так и реагированием на очевидные сложности и урезание бюджета. Поэтому обеспечение возможности изменений уже на этапе подготовки проекта — ключевое условие для последующего внедрения инноваций и создания идеального продукта.
Хорошо, Agile допускает значительные изменения в работе, но это же не означает, что такие изменения даются «даром»! Если то и дело переориентировать фрагмент кода для решения то одной, то другой, то третьей задачи, то рано или поздно этот код, возможно, потребуется полностью переделать. В лучшем случае понадобится выполнить рефакторинг, чтобы обеспечить работоспособность кода в обозримом будущем. Программный компонент, который изначально разрабатывался для обслуживания небольшого потока задач, может не выдержать резкого увеличения нагрузки. Чтобы этого не случилось, в таком коде можно реализовать специальные архитектурные аспекты, ограничивающие рост подобной нагрузки.
Последствия конкретного архитектурного решения несложно оценить, изучив те компромиссы, на которые приходится идти при определении приоритетности типичных «ценностных регуляторов» Agile — высокопроизводительности, надежности, масштабируемости, эффективности, безопасности, удобства использования и т. д. Между некоторыми из этих показателей возникают острейшие «конфликты интересов» — достаточно соотнести высокопроизводительность и эффективность. Представьте себе ситуацию: вы решили, что ваш спорткар обходится вам в копеечку и вызываете автомеханика, чтобы он переделал вам эту гоночную машину в семейный автомобиль-универсал. Для этого потребовались бы настолько радикальные изменения, которые просто нереализуемы на практике. Речь идет не о «доработке», а о полной пересборке. Конечно, пример утрированный, но вы понимаете, что проблемы именно такого рода возникают при внесении любых значительных изменений в программу.
Существуют и многие другие источники технического долга. Среди них следует назвать вечные дедлайны с выходом на рынок, а также очевидное желание клиента получить «видимый результат». Добавим сюда сложности, с которыми сталкивается разработчик, убеждая людей, что вот эта штука действительно нужна, а не сделана из любви к искусству. Неудивительно, что нам порой приходится принимать меры, лишь откладывающие, а не решающие проблему.
Многим из нас приходилось работать на хлопотных проектах, где на разработчика постоянно давит необходимость «хоть что-то доделать до релиза». В таких условиях совершенно некогда налаживать автоматизированное тестирование и настраивать систему развертывания. Наскоро дописываешь какую-нибудь фичу и просто сбрасываешь файлы на сервер. Кажется, что такой релиз — это небольшая победа малой кровью, но горькая правда в том, что в спешке мы проигнорировали самые надежные способы работы. Мы разработали платформу, на которой нет контроля версий, она не документирована, ее функционал невоспроизводим. Мы пошли по скользкой дорожке, на которой нас ожидают все новые серии дорогостоящих, чреватых ошибками релизов, выполняемых вручную. И выход только один — вернуться к началу и исправить ситуацию, любой ценой реализовав в нашем творении эти проверенные методы. Конечно, на этом этапе будет сложно модернизировать механизмы рабочих процессов, гораздо разумнее было сразу организовать их правильно, но это и есть проценты, которые приходится платить по долгам.
Итак, как же определить, влезли ли мы в технический долг и насколько?
Хороший вопрос! Дать на него полный ответ могут только разработчики, в первую очередь те, кто уверенно разбирается в проекте.
Чтобы отслеживать накапливающийся долг в принципиально новом проекте, необходимо наладить качественную двустороннюю коммуникацию между разработчиками и заказчиками. Вы должны гарантировать, что обе стороны одинаково понимают ценностные приоритеты проекта. Клиент должен постоянно информировать вас о том, какая дополнительная работа потребуется для полной реализации истории, в частности, обо всех планируемых интеграциях с функциями из других историй или о соответствии определенным стандартам качества. Работы, связанные с планируемыми интеграциями и рефакторингом, необходимо обсуждать регулярно — как для того, чтобы клиент понимал объемы «невидимой работы», требуемой для обеспечения модульности, так и для того, чтобы разработчики не забыли об этой работе!
Если система сильно фрагментирована, ее конструкция не была полностью спроектирована заранее, а выстраивалась в более «текучем», гибком ключе, то на интеграцию потребуется дополнительное время, а также не исключено, что придется заниматься незапланированным рефакторингом. Поэтому не откладывайте интеграцию системы до конца проекта, если только у вас нет целой команды гениальных мастеров по работе с API.
Если вы принимаетесь за доработку готовой платформы, которую требуется расширить или усовершенствовать, то первая команда разработчиков наверняка будет отлично представлять, насколько качественно и профессионально написана база кода. Правда, их суждения могут быть и необъективны — из-за гордости или из-за опасений раскрыть лишнюю информацию. Некоторые разработчики (обычно это сеньоры) готовы довольно откровенно обсуждать качество своего продукта — отчасти потому, что имеют более полную картину о его качествах, а также потому, что на собственном опыте знают, как отражается на добротности продукта качество командной работы. Поэтому они не ощущают себя полностью ответственными за недоделки и сознают, что каких-то из них было не избежать. Старшие разработчики обычно с готовностью рассказывают, как можно было бы улучшить код, если бы у них было на это больше времени или просто делают это задним числом. Кроме того, существуют отличные структурированные методы разбора полетов, способствующие свободному и честному описанию ситуации и оставляющие собеседника с чувством облегчения от того, что он расстался со сложным проектом.
Чтобы быстро проверить, насколько хорошо организована, документирована, проста в настройке и сборке конкретная база кода, бывает целесообразно просто озадачить ею свежую команду разработчиков. Если эти «рецензенты» достаточно опытны, они смогут сделать качественный обзор API и ключевых областей кода, выполнят своеобразную оценку рисков или комплексную проверку. Можно реализовать небольшое сквозное усовершенствование, которое послужит отправной точкой для дальнейшей оценки работ.
Поговорив с менеджером проекта или с клиентом, вы сможете получить представление о тех ценностных факторах, которые изначально лежали в основе разработки. Присутствовал ли в проекте жесткий дедлайн, может быть, был ограничен бюджет? Хорошо ли был спланирован проект? Много ли было изменений? Может быть, бюджет был сильно превышен? Может быть, кто-то перерабатывал, трудился в условиях стресса или конфликта? Возможно, в проекте было много проблем, багов, задержек? Насколько точно было рассчитано время, нужное для решения технической задачи? Все просто: чем сложнее была ситуация, в которой создавался код, тем больше в нем будет технического долга.
Такие дискуссии помогут вам составить общее впечатление о приложении: было ли оно наскоро склеено скотчем, или перед вами нарождается мощный масштабируемый механизм. Итак, было бы полезно в начале беседы обозначить направление, в котором вы собираетесь развивать программу — например, в сторону увеличения трафика, изменения демографических показателей пользователя или устройства, нового функционала.
Существует ряд индикаторов, помогающих понять, получал ли проект достаточные инвестиции, или дышал на ладан.
Автоматизация сборки, тестирования и релизов — сравнительно дорогое удовольствие. Настроить эти функции непросто, но очень скоро они начинают экономить вам время и деньги, которые бы тратились на ручной труд при разработке текущего проекта. Если сборка, тестирование и развертывание программы выполнялось вручную, очевидно, что бюджета едва хватало на разработку важнейших функций и проект существовал в долг.
Хороший признак — использование паттернов проектирования. Если в архитектуре легко просматриваются стандартные паттерны проектирования, например, наблюдатель, инверсия управления, фасады или шаблоны делегирования, а также архитектурные паттерны — многоуровневая архитектура, MVC или MVVM, то новый разработчик будет иметь огромный бонус для понимания базы кода, поскольку в ее структуре все будет разложено по полочкам, каждый элемент на своем месте. Программисту придется сосредоточиться только на функциональных модулях кода, а не на всей системе. Если же в системе не просматривается общая стройная организация, то там, несомненно, окажется масса заказного инфраструктурного кода, на понимание которого потребуется немало времени. Иногда такой «служебный скелет» бывает страшно спутан с функциональным кодом, из-за чего всю программу гораздо сложнее воспринимать, отлаживать и изменять.
Была ли у программистов хорошая экосистема? «Тест Джоэла» позволяет идентифицировать типичные проблемы, связанные с рабочей экосистемой и влияющие на качество кода. В частности, этот тест выявляет и некоторые типы технического долга. Важнейшими параметрами из этого списка являются контроль исходников, отслеживание ошибок и регулярность сборок — без этого маловероятно, что работа в команде шла организованно.
Итак, как же принимать решения, которые позволили бы снизить технический долг или справиться с неожиданно обнаруженным долгом?
Наиболее универсальная рекомендация — просто относитесь к техническому долгу так же, как и к финансовому. Инвестируете ли вы средства в приложение, заботитесь ли о его будущем, стимулируете ли команду работать только в соответствии с проверенными методами? Позволяете ли вы разработчикам тратить время на нефункциональные аспекты и «уборку», то есть на работу, не дающую прямого осязаемого результата? Если все это — про вас, то вы правильно подходите к процессу и не накапливаете технический долг. Игнорирование доводов разработчика о необходимости потратить время на вспомогательные дела — все равно, что игнорирование выписки по кредитной карте. Какое-то время это сходит с рук, но только какое-то время.
Критика ценностных приоритетов Agile-команды — хороший способ подтвердить вашу позицию, направленную на поддержку будущих разработок, опережение хакерских атак и стремление быть на переднем крае технологической эволюции, глобализации или локализации, готовность к интеграции и миграции. Установив доверительные отношения с одним или несколькими ключевыми разработчиками, вы будете понимать разницу между рациональным инвестированием в техническую инфраструктуру и спонсированием эгоистичных причуд.
Когда мы постфактум анализируем причины срыва задач, мы можем понять, не был ли такой срыв обусловлен неявными эффектами удешевления проекта. Начертите круговую диаграмму для оценки времени, необходимого для решения задачи или выполнения проекта, берите за основу данные системы отслеживания времени, ищите сквозные проблемы, которые приводят к «уплате процентов» — игнорирование изменений, случаи принципиальной недооценки, переключение задач, затягивание работы, т. д. Ищите периоды времени, которые неожиданно были потрачены на какие-то дела перед решением «реальной» задачи. Возможно, это время было потрачено на вспомогательные работы, связанные с устранением огрехов последней итерации — классический пример технического долга.
В конце концов, реальная проблема, провоцируемая техническим долгом, — это излишнее усложнение ваших задач. Поэтому единственный строгий способ оценки успешности вашего «погашения» — внимательно отслеживать эффективность работы и точность квотирования времени на решение технических задач. Если пределы погрешности при планировании работ снижаются и вам все реже приходится слышать «Надо бы уделить время на рефакторинг, но в моей квоте эта работа не учтена» — это значит, что вы уже научились погашать технический долг. Разумеется, практическая польза от распознавания и использования подобных тенденций при коммуникации ощущается в первую очередь с долгосрочными проектами, в которых накопилась объемная база данных. С другой стороны, в краткосрочных проектах, например в кампаниях, проблема технического долга практически отсутствует!
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.