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

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

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

149 голосов | спросил Desolate Planet 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 02:32:36 +0300000000amSat, 05 Feb 2011 02:32:36 +030011 2011, 02:32:36

17 ответов


178

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

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

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

ответил jmort253 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 05:04:35 +0300000000amSat, 05 Feb 2011 05:04:35 +030011 2011, 05:04:35
47

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

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

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

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

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

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

ответил Bernard Dy 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 06:28:17 +0300000000amSat, 05 Feb 2011 06:28:17 +030011 2011, 06:28:17
40

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

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

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

  • Оценки новых функций намного выше, чем они должны быть. Или вообще невозможно.
  • Плохой код порождает более плохие коды
  • Список ошибок растет, даже если разработчики всегда исправляют их.
  • Члены команды уходят (это само по себе может показать, что существует проблема, описанная в этот отличный ответ )
ответил Nicole 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 03:21:05 +0300000000amSat, 05 Feb 2011 03:21:05 +030011 2011, 03:21:05
30

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

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

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

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

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

ответил Karl Bielefeldt 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 07:37:33 +0300000000amSat, 05 Feb 2011 07:37:33 +030011 2011, 07:37:33
20

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

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

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

ответил Péter Török 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 02:39:29 +0300000000amSat, 05 Feb 2011 02:39:29 +030011 2011, 02:39:29
12

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

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

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

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

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

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

ответил biziclop 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 03:21:22 +0300000000amSat, 05 Feb 2011 03:21:22 +030011 2011, 03:21:22
12

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

Или они идут вниз, быстро .

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

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

ответил Orbling 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 03:50:45 +0300000000amSat, 05 Feb 2011 03:50:45 +030011 2011, 03:50:45
12

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

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

ответил EricSchaefer 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 10:49:45 +0300000000amSat, 05 Feb 2011 10:49:45 +030011 2011, 10:49:45
7

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

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

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

ответил mindcrime 23 +04002011-10-23T02:15:07+04:00312011bEurope/MoscowSun, 23 Oct 2011 02:15:07 +0400 2011, 02:15:07
6

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

  

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

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

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

ответил BЈовић 23 FriEurope/Moscow2011-12-23T14:09:52+04:00Europe/Moscow12bEurope/MoscowFri, 23 Dec 2011 14:09:52 +0400 2011, 14:09:52
4

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

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

  

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

Как клиент, который бы вы сами покупали?

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

ответил jasonk 22 Mayam12 2012, 02:00:47
3

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

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

ответил JB King 5 FebruaryEurope/MoscowbSat, 05 Feb 2011 02:41:52 +0300000000amSat, 05 Feb 2011 02:41:52 +030011 2011, 02:41:52
2

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

Вот почему:

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

Итак, лучший способ продвижения вперед:

  1. Когда они дадут вам новую задачу, попробуйте реализовать ее как можно лучше в заданное время
  2. Напишите это в первый раз. Если вам нужно изменить его впоследствии, вы сделали ошибку в первый раз, и любое изменение всегда будет неправильным направлением - и это возможность обучения программистов при совершении ошибок.
  3. Не запрашивайте дополнительное время для этого, вы не получите его, есть сроки, которые вы знаете.
ответил tp1 22 +04002011-10-22T21:37:58+04:00312011bEurope/MoscowSat, 22 Oct 2011 21:37:58 +0400 2011, 21:37:58
1

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

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

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

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

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

ответил James Anderson 22 AM000000100000001231 2014, 10:41:12
1

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

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

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

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

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

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

Удачи!

ответил Matt Cashatt 11 22014vEurope/Moscow11bEurope/MoscowTue, 11 Nov 2014 20:59:22 +0300 2014, 20:59:22
1

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

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

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

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

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

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

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

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

ответил Jay Elston 2 +03002015-10-02T22:07:21+03:00312015bEurope/MoscowFri, 02 Oct 2015 22:07:21 +0300 2015, 22:07:21
0

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

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

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

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

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

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

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

При возникновении проблемы с конкретным модулем:

  1. Напишите набор тестов, демонстрирующих проблему , которые также могут завершиться неудачно без рефакторинга
  2. Рефакторинг как часть разработки, указывающий, что тесты все еще не работают.
ответил Steve Barnes 8 PMpSat, 08 Apr 2017 12:21:14 +030021Saturday 2017, 12:21:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132