Ответ 1

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

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

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

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

Ответ 2

Встреча на высшем уровне

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

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

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

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

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

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

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

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

Тестирование устройств

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

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

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

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

Scrum Backlog

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

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

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

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

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

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

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

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

Рефакторинг

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

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

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

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

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

P.S. Если кто-то жалуется на то, что кто-то "тратит время", написав несколько модульных тестов при исправлении одного дефекта, покажите им

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

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

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

Дрю