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

Question

Хотя самая свежая запись в блоге Coding Horror - не первый раз, когда я слышал об этой концепции, я не мог не применить ее в своем собственном проекте, когда читал ее. ,

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Тогда не нужно спрашивать разрешения. : -)

/ Roger

Answer 5

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

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

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

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