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

158

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

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

Пустынная планета
источник
5
"работа с разработчиками" "сообщить об этом руководству" О чем вы спрашиваете? Разработчики или менеджеры? Какое поведение вы хотите изменить?
S.Lott
45
Технический долг подобен финансовому долгу - в конечном итоге гораздо проще просто не накапливать его. Оплачивайте все свои технические счета раз в неделю.
Лоуренс Дол
7
Майк> Я думаю, что вы живете в гораздо менее строгом мире, так как сроки и ограниченные бюджеты доминируют в мире, в котором я живу. Если программное обеспечение плохо адаптируется к будущим потребностям и требует много работы для исправления, тогда руководство часто больше озабочено игнорированием это и продолжайте прибегать к особенностям. Сейчас многие компаньоны, с которыми я работал, создали временные таблицы, поэтому разработчикам нужно записывать свою работу, и, если время не вкладывается в то, где руководство видит потенциальный бизнес, вы тратите свое время.
Пустынная планета
4
Я думаю, вы могли бы сказать, что это проблема краткосрочных выгод по сравнению с долгосрочными. Если команда разработчиков привела систему в порядок таким образом, что внедрение новых функций заняло не один день, а один день, это незамедлительное преимущество. Если руководство увидит, что вы пытаетесь улучшить код и идете вразрез с тем, что они хотят, вы становитесь бунтовщиком в их глазах. Я действительно не знаю, что является лучшим решением, но кажется, что это такая распространенная проблема, и я видел, что это делает с командами.
Пустынная планета
3
Скотт> Чтобы ответить на вопрос, я бы хотел изменить отношение руководства. Разработчики знают код и имеют непосредственный опыт относительно того, какой код должен быть улучшен, чтобы сделать вещи проще. На предыдущей работе, когда мы выпустили новую версию приложения, количество ошибок продолжало расти ужасными темпами. Я изо всех сил старался внедрить тестовые стратегии, но это часто кажется безнадежным делом.
Пустынная планета

Ответы:

191

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

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

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

jmort253
источник
30
мой опыт в целом соответствует этому. Технический долг очищается по мере добавления новых функций. Иногда оценки для определенных «связанных» исправлений / функций дополняются, чтобы включать очистку этих вещей.
Кен Хендерсон
4
+1 Ты точно разделяешь мои чувства ... кроме того, что ты выразил себя гораздо более дипломатично;)
Майкл Браун
7
Хороший ответ. Мне еще предстоит увидеть бизнес, который с радостью подпишет проект «рефакторинг», который не принесет пользы клиенту, а только приведёт в порядок код. Рефакторинг-как-вы-го.
JBRWilkinson
7
«Когда я встретился с моим боссом, чтобы обсудить это, он сказал, что я должен включить рефакторинг во все мои оценки». - Это мое отношение и позиция многих разработчиков в командах, в которых я работал. Однако, когда эти 9–5 разработчиков, как мы их называем, обеспокоены своими обзорами и повышением заработной платы, они не собираются создавать для себя больше работы. Они будут следовать тому, что думает руководство, в конце концов, это тот, кто им платит.
Пустынная планета
8
@ jmort253: есть одна (небольшая) проблема с этой, в остальном, отличной политикой -> невозможно провести значительные изменения (т. е. изменить базу данных, как сказано в OP). Те должны быть четко решены.
Матье М.
48

Как сказал Ганди, когда его спросили, сработает ли его тактика с кем-то вроде Гитлера. Он сказал: «Это будет трудно». Но я думаю, что есть справедливый аргумент, что ответ на самом деле «Нет». К сожалению, я не думаю, что вы пытаетесь сделать, можно сделать. Дело не в том, что я пытаюсь быть пессимистичным, скорее, я пытаюсь быть честным.

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

Мне кажется, мне нравится то, что Ренесис сказал в своем ответе, потому что он один из немногих, кто понимает, что менеджмент думает совсем не так, как инженер. И я думаю, что все мы видели прогресс в том, что компании становятся ориентированными на даты и более управляемыми проектами, в отличие от клиентов и качества. Под этим я подразумеваю типичные компании, а не настоящие компании, у которых хватит смелости сказать «это будет сделано, когда это будет сделано» (например, Apple Computer или id Software - и да, я понимаю, что иногда люди не свободны принять такой подход).

Но вот в чем дело: компании, которые выбирают подход, основанный на качестве, ... что вы заметили в них? Правильно, ими руководят инженеры, а не продавцы, маркетологи, менеджеры проектов или бухгалтеры. Подумайте о HP, Apple, ID, Google, Microsoft и IBM. Все началось и стало успешным благодаря инженерам, а не продавцам, хотя продавцы, безусловно, сыграли свою роль, и я уверен, что многие будут спорить о том, связана ли Microsoft с качеством :). И из тех, которые пошли вниз, ушли от руководству инженером. В этом заявлении есть целый ряд аргументов, поскольку существует множество технических компаний, которые в конечном итоге потерпели неудачу из-за неспособности адаптироваться к изменяющимся временам и управлять собственным ростом. Я не рассматриваю лидерство на основе инженерных разработок как причину этих неудач, для меня это s вопрос навыков и деловой хватки, которые не зависят от того, кто является разработчиком или бухгалтером. Тем не менее, я думаю, в целом, что в разработке есть преданность строгости подотчетности и дисциплины, которая приносит пользу компаниям, где инжиниринг является компонентом.

Серьезно, оглянись вокруг. ИТ-лидерство крайне не хватает. Фокус всегда на стоимости и времени, и редко на качестве, если это достаточно хорошо. ИТ-лидеры редко отчитываются перед генеральным директором, теперь это всегда финансовый директор. ИТ-специалисты зацикливаются на поддержке производства и все в большей степени обязаны руководителям проектов, которые сосредоточены на меньших, более легко усваиваемых и измеримых кусках, а не на существенных изменениях революционной ценности (не то, чтобы это обязательно было неправильно; разделяй и властвуй - это хорошо, но видение должен быть там для общей картины).

Извините, что так долго занимал этот пост, но, в конце концов, я думаю, что ваш вопрос о том, как заставить руководство заботиться о техническом долге, часто лучше решить, найдя правильного лидера, чем меняя существующего. По словам Ренесиса, объяснение технического долга стандартным мыслителям означает изменение фокуса на деньги и затраты, и я думаю, что при переводе многое теряется; даже если вы преуспели в этом, это будет иметь значение, только если его купит главный лидер компании. Убедить вашего менеджера среднего звена поступить правильно, вероятно, только уволят его.

Бернард Ди
источник
43

Первое, что нужно сделать, это изменить формулировку. Называя его «техническим долгом», у руководства возникает идея, что его разрешение - это своего рода инвестиция, хотя на самом деле это больше похоже на вирус. (Я как Дейв Рэмси из технического долга.)

Разрешение на то, чтобы оно оставалось неоплаченным, сопряжено с огромными затратами, которые невозможно увидеть или легко определить количественно.

Перечислите следующие проблемы для управления:

  • Оценки новых функций намного выше, чем они должны быть. Или вообще невозможно.
  • Плохой код порождает больше плохого кода
  • Список ошибок растет, даже если разработчики всегда их исправляют
  • Члены команды уходят (само это может показать, что есть проблема, как объяснено в этом превосходном ответе )
Николь
источник
7
+1, хотя я думаю, что последний пункт должен быть «Хорошие / лучшие члены команды уходят»
Кен Хендерсон,
12
Bit технический долг является инвестицией иногда. Если вы участвуете в гонке с другой компанией, и тот, кто запускает первый, получает рынок для себя, тогда имеет смысл сделать ярлыки в коде, чтобы ускорить запуск. Никто не будет заботиться о том, что у вас есть идеальный код, если у вас нулевые клиенты.
Quant_dev
3
@quant_dev, если вы видите это как дихотомию между «более быстрым» и «идеальным кодом», тогда, конечно, вы будете думать таким образом. Нет причин, по которым ярлыки не могут быть технически обоснованными, и в этом случае они не считаются техническими долгами.
Николь
2
@Renesis "Нет причин, почему ярлыки не могут быть технически обоснованными" - это просто неправда.
Quant_Dev
3
И иногда это вовсе не технический долг, это просто беспорядок: sites.google.com/site/unclebobconsultingllc/…
TrueWill
30

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

Один из способов, которым я продолжаю оказывать давление, - это когда меня просят о смете, и можно было бы сэкономить время, если бы мне не приходилось сталкиваться с конкретными техническими проблемами задолженности, я включаю это в свою смету . Например, « Эта ошибка займет у меня 2-3 дня, чтобы отследить ее, но если бы мы уже исправили эти 2 другие ошибки с« низким приоритетом », которые были в очереди навсегда, это, вероятно, заняло бы меньше одного». Часто, ответ будет идти вперед и исправить эти другие, пока вы на это.

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

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

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

Карл Билефельдт
источник
20

Вы можете попробовать аналогию с кредитной картой. Спросите их: «Вы чувствуете себя комфортно, оставляя выписки по своей кредитной карте неоплаченными в течение длительного периода времени?

Менеджеры понимают затраты и выгоды, но (обычно) не технические термины, используемые нами, разработчиками. Термин «технический долг» уже был придуман, чтобы помочь преодолеть этот коммуникационный барьер, но вам, возможно, придется сформулировать его более четко. Большинство менеджеров очень хорошо знают (часто из собственного опыта), что просроченные платежи по кредитным картам растут с ужасной процентной ставкой, поэтому больно оставлять их неоплаченными. Это может помочь им понять серьезность проблемы, связанной с энтропией программного обеспечения.

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

Петер Тёрёк
источник
12

Никто не даст денег за замену чего-то, что работает чем-то другим, что (при любой удаче) также работает.

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

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

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

Никакая убедительность не изменит эту ситуацию, и если вы введете обязательный стандарт качества кода, ваши девять-пять разработчиков найдут способ работы системы, в то время как ваши преданные разработчики неизбежно будут раздражены всей процедурой (которая не не нацелены на них, но нельзя сказать, что разработчик X должен подчиняться правилам, а Y может делать все, что он захочет).

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

biziclop
источник
5
+1 Но эти 9-5 разработчиков, ну, вы хотите вращающуюся дверь для них, в идеале с какой-то формой ускорителя.
Orbling
3
@ Орблинг: +1. Если им все равно, они действительно должны работать где-то еще. Здорово, что разработчики приходят к вам с "У меня только что была эта идея ...".
quick_now
3
@ Orbling В определенных областях развития они могут быть полезны. Я вовсе не фанат «снобизма разработчиков», но вы должны найти нишу для каждого, чтобы они были полезны. Худшее, что вы можете сделать, это предположить, что все такие же, как вы.
biziclop
Лично я считаю, что индустрия сильно перегружена. Там, где я базируюсь, большинство программных вакансий получают около 300 кандидатов, подающих заявку в эти дни. При таком уровне конкуренции работодатель может позволить себе нанимать работодателей, которые делают все возможное и лучше среднего.
Orbling
«Сверните обновления в рефакторинг, чтобы предложить ощутимые преимущества (точки продажи)», - вот что я продолжаю слышать от нашего главного архитектора, поэтому мне придется повторить это.
Марио Т. Ланца
12

Дело в том, что во многих компаниях, особенно с учетом текущей экономической ситуации, каждый час должен оплачиваться кому-то.

Или они быстро падают .

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

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

Orbling
источник
12

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

Я не рассматриваю рефакторинг как задачу, отдельную от реализации функций. Это неотъемлемая часть этого.

EricSchaefer
источник
5
Я не могу не согласиться: «Технический долг подобен финансовому долгу - в конечном итоге гораздо проще просто не накапливать его. Оплачивайте все свои технические счета раз в неделю»
Лоуренс Дол
7

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

Проанализируйте, сколько времени разработчики вынуждены тратить, чтобы помочь службе поддержки в решении производственных проблем, а затем расскажите, что исправление некачественного старого кода могло бы: A. уменьшить количество проблем с поддержкой, B. облегчить службе поддержки решение проблем, не переходя в разработку, и C. сократить время, затрачиваемое разработчиками на вопросы производства, когда они возникают. Поместите это в доллары, сэкономленные тем, что разработчики не были связаны работой поддержки. Также отметьте, что каждый час, потраченный разработчиком на поддержку, является «двойным ударом», потому что вы платите не только разработчику за поддержку, но и снижаете издержки, связанные с тем, что мог бы сделать этот разработчик (добавление новых функций и т. Д. .)

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

Mindcrime
источник
6

После этого объяснения технического долга ваше руководство должно быть убеждено погасить его:

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

Кухня - это ваш код, еда - ваш продукт, а еда - ваш продукт.

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

BЈовић
источник
4

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

Давайте перефразируем это, чтобы позиционировать себя как клиента. Старая добрая ролевая игра.

Предположим, вы купили холодильник. И вы могли бы купить холодильник за 1000 долларов, который нормально работал у Acme Corp. Или холодильник за 2000 долларов у Acme Deluxe Fridges, который выглядел одинаково снаружи и имел те же технические характеристики, но имел более низкие затраты на обслуживание из-за более чистой внутренней архитектуры.

Как покупатель, что бы вы сами купили?

И что инженеры Acme Deluxe считают лучшим ответом?

jasonk
источник
3
Мне трудно определить вашу позицию по этому вопросу. Я думаю, что ваш ответ «это зависит от того, что хочет клиент». Проблема в том, что не каждый покупатель понимает, что недорогой холодильник будет вытекать из-за утечки, неприятного мусора из морозильной секции, издавать громкие звуки и в конечном итоге перестанет работать через 5 лет, в то время как другой будет работать ровно и тихо в течение 20 лет. и не подлежит замене, пока владельцы не сочтут его неподходящим для перепродажи в обмен на новую модель. Тем не менее, мне нравится вопрос, который вы задали. Это заставляет задуматься. +1
jmort253
Первая строка - «Это должен быть очень убедительный аргумент [], что я не мог использовать эти деньги сейчас, чтобы сделать что-то более важное для меня». Честно говоря, я использую пример с холодильником, мне все равно, что происходит внутри моего холодильника. Я просто хочу результата. (холодная еда по разумной цене). Честно говоря, мне все равно, что инженеры-холодильники считают, что это лучший продукт внутри страны. Я мог бы посоветоваться с ними, но на самом деле это не их решение.
Джейсон
3

« Технический долг » может быть непростым делом для представления руководству, поскольку они могут не видеть в этом необходимости. Вопрос может быть сформулирован так: есть ли в компании чемпион, чтобы заявить: «Послушайте, мы тратим здесь X% времени на работу над техническим долгом. Дайте нам 3 месяца, чтобы показать вам, что это работает хорошо», или что-то в этом роде. аналогичный. Там есть требование автономии, но есть и временные рамки, так как в противном случае руководство может задаться вопросом, как долго, пока они не увидят некоторые результаты, что является довольно опасной территорией.

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

JB King
источник
Я полностью согласен с этим и нахожу это все больше и больше. Недавно я собрал список дефектов, которые были вновь открыты, потому что не было установлено правильное исправление или дефекты подобного характера. Надеюсь, разработчики вложили в это время. Иногда они делают, иногда нет, но этот вид данных является полезной основой для того, чтобы показать руководству, как нездоровый продукт влияет на их бизнес.
Пустынная планета
2
На моем нынешнем рабочем месте сверхурочные распределяются по неправильным причинам. Если бы время было потрачено на поддержание работоспособности приложения, а не на проблемы с пожаротушением, деньги были бы сэкономлены на сверхурочной работе, и разработчики были бы более уполномочены, а не сожжены и раздражены руководством.
Пустынная планета
Но руководство (в большинстве случаев правильно!) Видит это так. У меня есть magimix 1980-х, который все еще работает, и вы говорите мне заменить его только потому, что он старый и цвет немодный!
Джеймс Андерсон
2

Вы должны просто перестать жаловаться на это.

Вот почему:

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

Так что лучший путь вперед - это:

  1. Когда вам дадут новое задание, постарайтесь выполнить его как можно лучше в данный момент времени.
  2. Напишите это отлично с первого раза. Если вам нужно изменить его впоследствии, вы допустили ошибку в первый раз, и любое изменение всегда идет в неправильном направлении - и это возможность обучения для программистов, когда вы делаете ошибки.
  3. Не просите дополнительное время для этого, вы не получите его, есть сроки, которые вы знаете.
ТР1
источник
3
Я в основном согласен, за исключением того, что хорошо известно, что даже дрянное программное обеспечение имеет тенденцию выживать гораздо дольше, чем ожидают его создатели. Но вы правы, лучше не жаловаться. Вместо этого, если вы видите некоторый ре-факторинг ограниченного масштаба, который поможет понятности кода, возможно, стоит пойти дальше и вносить изменения БЕЗ РАЗРЕШЕНИЯ во время обслуживания / исправления ошибок (и подвергаться риску при этом).
Анджело
@ Анджело - Не лучше ли высказать свои опасения, чем позволить команде страдать в тишине? Я видел, как эта проблема влияет на моральный дух команды, а также на количество времени / денег, потраченных на сверхурочную работу. Я не рассматриваю это как "стон" как таковой. Вы просто указываете на риски проекта, и если ваши идеи могут ускорить сроки поставки и упростить процессы, то почему бы хотя бы не попытаться высказать свои опасения? Если это пропадает мимо ушей, то, по крайней мере, вы знаете, где вы стоите.
Пустынная Планета
2
Вы должны громко жаловаться на это , в противном случае вы виноваты в том, что код других людей сломался («Вы знали, что это беспорядок, и никому не сказали?»). Встать и встать "Эй, босс, это дерьмо рано или поздно поразит поклонника", жизненно важно для поддержания работоспособности команды разработчиков.
Алекс
1

Я так понимаю, вы никогда не участвовали в проекте по переписыванию / замене или даже обновлению существующей системы.

Это одни из самых сложных проектов, которые можно успешно завершить. Вот некоторые проблемы, с которыми вы столкнетесь:

  1. Деловые правила теряются во времени.
  2. Документация и реализация полностью не синхронизированы.
  3. То, что вы видите как ошибку, пользователи видят как функцию.
  4. И наоборот, многие «особенности» будут рассматриваться пользователями как дефекты.
  5. Вы не будете принимать участие пользователей - они будут рассматривать ваши «факты» как «ботаников, задающих глупые вопросы», они будут расценивать усилия по тестированию как пустую трата времени, они будут настаивать на добавлении новых функций, таким образом, удлинение проекта приведет к уже отставать от графика.
  6. Скорее всего, исходный код не соответствует 100% с запущенным исполняемым файлом.
  7. Пока ваш отдел возится с разработкой рефакторинга, бизнес на самом деле хочет, чтобы это не было сделано.
  8. Скорее всего, ваш ре-факторинг будет включать в себя «более чистые улучшенные интерфейсы», что приведет к перетаскиванию других проектов в трясину поздних поставок и неудачных испытаний.
  9. После того, как проект будет завершен (более 50% этих усилий потерпят неудачу полностью), вы потеряете всю кредитоспособность - вам нужно будет перейти в другую компанию в другом городе, чтобы найти кого-то, кто тоже готов выслушать вас.
  10. Если проект «удастся», то все будут помнить, какой это был кошмар - вы .......

Я призываю вас избегать любых проектов переписывания / рефакторинга, таких как чума, они могут быть одними из самых удручающих в любой профессиональной карьере.

Есть много мудрости во фразе «Если это не сломано, не исправляйте это».

Джеймс Андерсон
источник
1
«Я так понимаю, вы никогда не были вовлечены в проект по переписыванию / замене или даже обновлению существующей системы», - неправильно, 7 лет.
Пустынная планета
1
Я полностью согласен с тем, что полное переписывание часто является катастрофой. Но у меня есть три примера за последние 8 лет моей карьеры. Одним из них был длинный улов, который привел к тому, что мы смогли лучше поддерживать продукт, но не обеспечил никакой ценности для бизнеса; другой был короткий переписать, который был полным успехом; третьим было решение не переписывать, что в конечном итоге убило компанию. Выбери свой яд.
Том Харрисон-младший
1

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

Вчера вечером я смотрел шоу в национальном парке Йосемити, и было отмечено, что с 1940 по конец 1990-х годов не выросло ни одного нового дерева секвойи. Было обнаружено, что причина была в том, что существовала строгая политика, запрещающая сжигание лесных пожаров, и что сосновые шишки секвойи нуждались в тепле от огня, чтобы открывать и выпускать свои семена.

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

Сейчас я работаю над проектом, в котором есть веские основания для перестройки: устаревшее программное обеспечение было написано исключительно с использованием веб-форм .NET. Практически вся бизнес-логика сочетается с логикой представления тегов HTML / server и не может быть расширена в другие приложения, когда бизнес вырос.

Управление стоит за задачей, потому что они имеют достаточное количество доверия к своим разработчикам, что, как я понимаю, является редкой роскошью.

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

Удачи!

Мэтт Кашатт
источник
1
как это отвечает на вопрос: «Как вы сообщите об этом руководству, чтобы они заинтересовались решением технических долгов?»
комнат
1
@gnat: Как большинство «ответов» отвечают на этот вопрос напрямую? См., Например, ответы Джеймса Андерсона, tp1 или любые ответы сверху с наибольшим количеством голосов. Но чтобы ответить на ваш вопрос, я привел альтернативную аналогию, которую ОП может использовать. Сдается мне, что вы просто не согласны с моим мнением по этому вопросу. Это нормально, но нет причин понижать голос.
Мэтт Кашатт
1
согласно моему прочтению, верхний ответ, на который вы ссылаетесь, напрямую связан с заданным ответом, основываясь на соответствующем опыте «Когда я встретился с моим начальником, чтобы обсудить это ...» Что касается вашего мнения, я скорее склонен согласиться с этим, но я голосую на о качестве контента, а не о том, поддерживаю ли я определенное мнение или не согласен. Модель голосования «Вопросы и ответы» по стеку довольно плоха, когда (неправильно) используется для опросов общественного мнения
комнат
1
Тогда я рекомендую прочитать это снова. Описание разговора с начальником о методе покрытия технического долга путем добавления оценок для будущей работы не дает ответа на вопрос: «Как вы сообщите об этом руководству, чтобы заинтересовать их в решении технического долга?» или. Тем не менее, я не голосовал против ответа, потому что он добавил к разговору. Таким образом, все, что вам удалось сделать, это приглушить мнение по этому вопросу, с которым вы согласны без какой-либо существенной причины. «Программисты» должны быть тем местом, где мы можем поговорить. Не все двоично.
Мэтт Кашатт
1

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

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

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

Я предлагаю вам обсудить эту стратегию со своими менеджерами (и, если возможно, теми, кто принимает решения о том, куда тратятся деньги).

Общий подход к созданию и управлению дорожной картой прост, но он требует поддержки вашей команды управления. Сначала определите цель. Определите элементы технического долга и разработайте целевую системную архитектуру, которая сокращает элементы вашего технического долга. Помните, это не обязательно должно быть идеально, просто работоспособно и лучше, чем вы есть на данный момент. Примите во внимание программное обеспечение, средства разработки, аппаратные платформы, основные новые функции, которые могут быть добавлены в систему. Сделайте анализ затрат. Если у вас есть желаемая архитектура, каковы ощутимые преимущества от проведения рефакторинга? (Преимущества включают сокращение времени тестирования, более надежные программные продукты, более предсказуемые циклы разработки и т. Д.) Если вы сможете показать достаточно преимуществ для проведения рефакторинга, вы можете получить поддержку управления.

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

Дорожные карты действительно полезны, и, возможно, 13-й вопрос по тесту Джоэла должен звучать так: «Есть ли у вас дорожная карта?»

Вот видео первого часа недавнего сеанса дорожной карты Red Hat Linux .

Джей Элстон
источник
1

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

Ключевые факторы в достижении соглашения:

  • Существующий код был в более не поддерживаемой цепочке инструментов (MicroPower Pascal), которая работала только на почти неподдерживаемой платформе разработки (PDP11-23).
  • Поиск разработчиков, которые могли бы работать с инструментами и целями, становился практически невозможным.
  • Целевое оборудование больше не было доступно, если требовались запасные части, а производитель все больше отказывался предоставлять услуги по ремонту.
  • Проблемы в коде приводили к легко идентифицируемой неудовлетворенности клиентов и прямым затратам на обслуживание.
  • Добавление новых функций или даже исправление ошибок становилось практически невозможным из-за ограничений целевого оборудования, что приводило к необходимости реорганизации других областей, чтобы освободить место при решении проблем.
  • С 8-часовым временем сборки разработка и тестирование любых изменений были дорогостоящими.

В отчете подробно изложены проблемы с оценками текущих затрат и предложены 3 варианта:

  1. Заморозить, где мы были, возможно, даже не исправлены ошибки в ближайшем будущем.
  2. Оптимизируйте код только для пространства, безотносительно к удобству сопровождения, указывая, что любой, кто пытается сохранить оптимизированный код, должен быть умнее, чем тот, кто занимался оптимизацией.
  3. Внедрите, с проверяемостью и ремонтопригодностью в качестве основных факторов, в широко распространенном отраслевом стандарте (ANSI C), на новом недорогом оборудовании COTS (PC-104), с несколькими поставщиками, имеющимися у себя дома. разработана интерфейсная карта, позволяющая ей работать с оставшимся существующим оборудованием. Добавление ограниченного набора новых функций в рамках разработки, таких как энергонезависимое хранилище, сторожевой таймер для автоматического перезапуска в случае сбоя, когда некоторые устройства выходили из строя несколько раз в день, и для сброса требовался сервисный вызов в размере 40 фунтов стерлингов , лучшая диагностика в процессе.

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

Для случаев с менее значительным техническим долгом я склонен принять то, что я называю партизанским рефакторингом:

Когда есть проблема с определенным модулем:

  1. Напишите набор тестов, которые демонстрируют проблему, которая также может быть неудачной без рефакторинга
  2. Refactor как часть разработки указывает на то, что тесты по-прежнему не проходят.
Стив Барнс
источник