Как убедить менеджера позволить вам выплатить технический долг?

В то время как самая последняя запись

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Просто основываясь на том, что вы написали, и о том, что ваш проект все еще находится в разработке, я бы предупредил вас, чтобы вы помнили поговорку "Лучше враг совершенства". (Я считаю, что это было придумано или, по крайней мере, популяризировано Майклом Лоппом.) Возможно, лучшее время в жизненном цикле Проекта для кода рефакторинга.

Ответ 3

Если менеджмент сочувствует, но они отказываются дать вам 2-3 недели для полного пересмотра, тогда компромисс будет заключаться в том, что вы исправляете ошибки в этих компонентах, пишите некоторые тесты и делаете некоторые рефинансирования, время улучшает код.

Вы могли бы просто сделать это, или вы могли бы попросить добавить 10% к оценкам ошибок/функций в тех областях, которые будут использоваться для этой цели.

Ответ 4

Основная статья из вашей ссылки уже имеет прекрасный ответ. Это описание технического долга очень хорошее:

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

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

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

Ответ 5

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

Непрерывное улучшение небольших кусков в конце концов будет творить чудеса.

Нет необходимости запрашивать разрешение.: -)

/Roger