Как удержать одно "я" от подавляющего желания переписать все?

Ответ 1

Я большой поклонник создания списков!

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

Надеюсь, за относительно короткий промежуток времени у вас будет одна из двух вещей:

• Очень длинный список, который полностью избавляет вас от необходимости переписывать что-либо еще раз.
• Список, который на самом деле не так уж длинный, так почему бы не побаловать себя и не переписать?!

Ответ 2

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

Ответ 3

Самый незабываемый проект такого рода для меня произошел около 4 лет назад, когда меня вызвали в удаленный офис, чтобы "помочь" с проектом, который должен был быть представлен в течение 1 недели для крупной презентации клиенту и еще не работал вообще. Проект был в основном отключен от Индии, а ИМО - неудача управления проектами привела к тому, что тонна кода спагетти была слишком фрагментирована, чтобы нормально работать в ее нынешней форме.

После полного обзора дня я высказал свое мнение руководству о том, что проекту просто нужен оптовый рефакторинг и реорганизация, или он никогда не будет работать должным образом. Результатом этого обсуждения было 6 дней 20 часов работы /4 часа сна, 2 из которых я фактически провел спать на диване в лобби отеля из-за потерянного времени, когда возвращался в отель.

Основные улучшения кода:

• Применение стандартов именования
• Перемещено в исходное управление
• Разработка процесса сборки
• Документация отдельных компонентов

Большая часть исходного кода была оставлена ​​на месте, но просто перемещена и реорганизована/реорганизована, чтобы сделать ее устойчивой в долгосрочной перспективе. Была ли адская неделя? Конечно. Это сделало проект более успешным? Да.

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

Ответ 4

Как сдерживать себя от подавляющего желания переписывать все?

Стань старым *

Как это случилось со мной, я постепенно потерял желание переписать все. Почему?

• Как только вы это сделали несколько раз, вы поймете, что вы часто оказываетесь хуже, чем вы начали.
• Даже если вы являетесь божественным подарком для программирования, и ваш блестящий переписан не вводит никаких новых ошибок, вы просто не заметите или не реализуете около 30% мелких функций/ошибок, которые на что опираются. Это будет стоить вам месяцев при фиксации.
• Ничто не разрушает ваше иррациональное изобилие, как время. Часто это печальная потеря, но в этом случае это победа.

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

Ответ 5

Импульс для перезаписи является праведным, если:

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

Хороший стартер по решению больших рефакторингов на небольших этапах sourcemaking.com:

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

Ответ 9

• перечитать "Рефакторинг".
• Возьмите лист бумаги и укажите "Плохие запахи". (для каждого запаха в BadSmells() {
  print smell.name,
  }
• Добавить комментарии к коду, включая элементы из списка.
  while (odorPersists()) {
• Работайте по списку, с лазерным фокусированием на один запах за раз.
  }

Ответ 10

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

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

- Я делаю только то, что нужно делать с ними, но проблема документирована и будет исправлена ​​вовремя.

- Это не значит, что нужно обрабатывать небольшие разбитые окна; небольшие вопросы всегда должны быть зафиксированы на контакте ИМХО.

Ответ 11

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

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

Ответ 12

Я никогда не работал в какой-либо особенно быстрой, поэтому я делаю это:

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

2) Существует разумное исправление без серьезной перезаписи. Примените исправление, запустите тесты, проверьте его, отметьте ошибку как исправленную.

3) Теперь поднимите новую ошибку/проблему (запрос расширения), изложив предлагаемый переписать и как он улучшит код (более простой? более ремонтопригодный? уменьшает связь? влияет на производительность или использование ресурсов?). Назначьте это себе, CC, кому интересно этот бит кода.

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

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

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

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

Ответ 13

Joel имеет статью об этом:

Там тонкая причина, по которой программисты всегда хотят выбросить код и начать все заново. Причина в том, что они считают, что старый код беспорядок. И вот интересное замечание: они, вероятно, ошибаются.

Ответ 14

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

Ответ 15

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

Ответ 16

Не думайте, что вы ДОЛЖНЫ остановить себя от этого. В основном, если вы ЧУВСТВУЕТЕ для большой перезаписи, это в основном правильное. Я безумно не согласен с Джоэлом Спольским в этом вопросе...

Хотя это одно из немногих мест, где я не согласен с ним...;)

Ответ 17

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

Ответ 18

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

Если у вас все еще есть желание переписать его, у вас будет несколько тестов, чтобы узнать, что ваш код перезаписывания теперь терпит неудачу;)

Ответ 19

Рефакторинг только в том случае, если ваш босс/компания на самом деле его поощряет, иначе вы в конечном итоге сделаете частые дополнительные время, чтобы довести код до совершенства... Пока кто-то менее преданный не коснется его снова.

Ответ 20

Исходное предположение: вы уже "совершаете раннее, совершаете часто".

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

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

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