Рефакторинг до или после корабля?

Question

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

У меня такой вопрос: дайте ETA для функции, вы бы написали код, пока функция не заработает и не будет завершена? Или вы заставили бы его работать как можно быстрее и рефакторинг для качества выпуска?

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

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

Answer 1

Я предпочитаю рефакторинг до и после доставки.

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

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

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

Редактировать 2: Что касается вопроса "как убедить моего менеджера в рефакторинге"(см. комментарии), вот некоторые ресурсы, которые могут помочь:

• Объяснение рефакторинга для менеджмента в InfoQ
• Оригинальная книга Мартина Фаулера Рефакторинг ( доступно в сети в полном объеме , кажется) имеет раздел под названием " Что я скажу своему менеджеру? ".На самом деле я рекомендую прочитать первые несколько глав книги в любом случае, поскольку они объясняют основные идеи рефакторинга более четко, чем все остальное, что я видел.

Answer 2

Проблема в том, что если у вас есть склонность к рефакторингу только после доставки, вы никогда не сделаете этого;)

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

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

Answer 3

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

Answer 4

Если вы делаете Test Driven Development. Часто вы пишете простейшую вещь, которая работает сначала, а затем рефакторинг, когда добавляется дополнительная функциональность (AKA Red, Green, Refactor).

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

Answer 5

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

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

Answer 6

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

Answer 7

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