Наш код отстой, и я бессилен его исправить.Помощь![закрыто]

StackOverflow https://stackoverflow.com/questions/3618581

Вопрос

Наш код — отстой.Собственно, позвольте мне это уточнить.Наш старый код отстой.Его сложно отлаживать, и он полон абстракций, которые мало кто понимает или даже помнит.Буквально вчера я потратил час на отладку в области, в которой работал. в течение года И обнаружил, что думаю: «Вау, это действительно больно». Это не чья -то вина - я уверен, что все имело смысл изначально.Хуже всего то, что обычно это просто работает... при условии, что вы не просите его сделать что-либо за пределами его зоны комфорта.

Наш новый код довольно хорош.Я думаю, что мы делаем там много хорошего.Он понятен, последователен и (надеюсь) удобен в сопровождении.У нас есть сервер Hudson, работающий для непрерывной интеграции, и у нас есть начальный набор модульных тестов.Проблема в том, что наше руководство сосредоточено на написании Нового Кодекса.Нет времени уделять Старому Коду (или даже старому Новому Коду) заботу и внимание, в которых он так отчаянно нуждается.В любой момент наш бэклог Scrum (для шести разработчиков) содержит около 140 элементов и около дюжины дефектов.И эти цифры не сильно меняются.Мы добавляем вещи так быстро, как только можем их сжечь.

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

  • Что я могу сделать, чтобы задачи обслуживания и рефакторинга получили достаточно высокий приоритет для выполнения?
  • Применяете ли вы какие-либо стратегии, специфичные для C++, чтобы предотвратить столь быстрое гниение нового кода?
Это было полезно?

Решение

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

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

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

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

Другие советы

Вставать встречи

Я мог бы пойти к своему механику, и у нас есть небольшая встреча с постоянной встречей:

Я говорю ему, что я хочу, чтобы мои колеса выровнены, мои шины вращаются, и мое масло изменилось. Я упоминаю, что «о, кстати, мои тормоза чувствовали немного мягкого на пути. Могут [он] взглянуть на них? Как скоро я верну свою машину, потому что мне нужно вернуться к работе?»

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

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

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

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

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

Мой механик был просто прямо и честен со мной. Вы прямо и честны с вашим управлением? Или вы избегаете рассказывать им вещи, которые они не хотят слышать?

Установка тестирования

Я бы не коснулся линии кода, которую я не понял, и я бы не проверил новую линейку кода, которую я не тщательно проверил. (По крайней мере, не намеренно.)

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

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

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

Scrum backlog.

Лично я думаю, что термин «Scrum Backlog» - это неправильно. Список вещей, который нужно сделать, это просто список - список покупок, если вы будете. У меня был список, когда я пошел на механик. Моя всплывающая встреча с механиком была на самом деле больше встреча планирования спринта.

Заседание планирования спринта - это переговоры. Если ваше управление временное бокс без того переговоров, они ничего не управляют. Они просто пытаются взимать 10 фунтов дерьма в мешок на 5 фунтов, и это ваша ответственность, чтобы сказать им так.

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

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

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

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

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

Если вы не можете написать те тесты подразделения, потому что вы преодолеете слишком много функций, Чья это ответственность?

Рефакторинг

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

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

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

Обязательство + ответственность = сила

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

PS Если кто-то жалуется на голове «тратить время», написание нескольких модульных испытаний при исправлении одного дефекта, показать им Это видео на 80:20 правило и фунт «дефекты кластеров» в их мозги.

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

Это также старый код, который имеет дефекты ShowStopper? Если так, откуда они исходят? Старый код не имеет дефектов «ShowStopper», он просто поближен и ближе к остановке. В конце концов, это старый код - у него должны быть те же старые дефекты и те же старые ограничения, а не вещи, которые нужно смотреть сразу. Дефекты ShowStopper являются новыми дефектами кода. Похоже, в старом коде есть активное развитие.

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

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

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

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

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

Не важно, просто пытаясь быть честным. Сделайте глубокий вдох. Замедлять. Вы похоже, вам это нужно. Посмотри на то, что вы написали здесь. Это ничего не говорит. Вы говорите о рефакторе, Scrums, ShowStoppers, Defuls, Старый код, новый код. Что значит кто-нибудь из этого? Это все дрогнуло.

А как насчет «Новых инициатив против устаревших систем»? «Необходимо реформировать ранний код цикла Sprint с точки зрения новейшего понимания и т. Д.» Фактически ли выступители «ранние компоненты нынешних предпринимательских инициатив на предприятии были выпущены, но испытывают проблемы, и нет в бюджете из-за нового развития».

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

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

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

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

Некоторые случайные вещи, которые могут помочь...

  • Поговорите об этом со своей командой.Поделитесь своим опытом и своими опасениями, избегая при этом фразы «чувак, ваш старый код — отстой» (по очевидным причинам), и посмотрите, каков консенсус.Вы, вероятно, не одиноки.
  • Забудьте о своих менеджерах.Не подвергайте их такому уровню детализации — им не нужно думать о новом или новом.старый код и, вероятно, не поймут, если они это сделают.Это проблема, которую ваша команда должна решить и, при необходимости, сообщить о ней вашему ОП.
  • Будьте готовы к тому, что вы сможете выбросить вещи.Часть этого старого кода, вероятно, относится к функциям, которые больше не используются или вообще не были приняты пользователями.Чтобы это работало на вас, вам действительно нужно подняться на уровень выше и подумать о том, где код действительно обеспечивает ценность для пользователя или бизнеса, а где — ценность для пользователя или бизнеса.где это просто комок грязи, по которому ни у кого не хватает смелости принять решение.Кто посмеет, тот победит.
  • Расслабьте свой взгляд на архитектурную последовательность.Всегда есть способ подключиться к работающей системе с новым кодом, и это может позволить вам медленно перейти к более новому, более разумному подходу, сохраняя при этом старый достаточно долго, чтобы не сломать существующие вещи.

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

Надеюсь, это поможет.

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

Также было бы осторожно документировать части вашего «старого кода», которые наиболее трудно понять. Это также были бы частями вашего «старого кода», что вы должны сначала рефакторинг, как только вы получите одобрение.

Что-то попробовать: Группировать свой класс - сказать - худшие 10%, лучшие 10%, а остальные. Доставьте списки к вашему управлению, говоря: «Я предсказывая большинство ошибок в течение следующего квартала, будет найдена в первом наборе». На основе длины, цикломатическая сложность, Проверьте тестовое покрытие - какие бы инструменты для вас удобны инструменты. Тогда садись назад и посмотрите - и будь прав. Теперь у вас есть доверие, некоторые рычаги, когда вы говорите: «Я хотел бы инвестировать некоторые ресурсы в создании нашего плохого кода лучше, чтобы уменьшить затраты на эксплуатацию ошибок и обслуживание - и я знаю, где инвестировать эту энергию, см.?»

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

  • Нет комментариев или документации
  • Меньше ориентирован на объект
  • плохие переменные / имена функций
  • ...

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

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

Надеюсь, это помогло.

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

Кроме того, подходов, упомянутых выше, которые хороши, вы также можете попробовать это:

Для сохранения будущего кода очистить

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

Для очистки старого кода:

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

Вы также можете захотеть рассмотреть возможность получения владельца продукта и Scrummaster для захвата отдельной скорости для старого кода VS New Code и использовать это соответственно.

Если есть желаемая новая функция, и вы можете определить неповрежденную Hunk код, который находится в пути, то, возможно, вы сможете получить благословение управления для замены старого кода новым кодом, имеющим желаемую новую функцию. Когда я сделал это, мне пришлось писать несколько уродливой прокладки, чтобы встретить старые интерфейсы со стороны программного обеспечения, которого я не собирался прикоснуться. И тестовый жгут, который может осуществлять существующий код и управлять новым кодом, чтобы убедиться, что новый код, как видно через Shim Player, может обмануть остальную часть приложения, думая, что ничего не изменилось. Переработая порцию, которую мы переработали, мы смогли показать огромные преимущества производительности, совместимость с желаемым новым оборудованием, снижением каждого из потребностей нашего полевого сайта для экспертизы при администрировании пространства для приложения - и новый код было гораздо больше удовольствия. Эта последняя точка зрения не имеет значения для пользователей, но другие преимущества от переработки были достаточно привлекательны, чтобы «продавать» пользователей на заслуги несколько болезненной конверсии базы данных.

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

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

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

Дрю

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top