Рефакторинг - и должен быть - постоянный процесс. Недостаточно просто удовлетворить требования с работающей и протестированной реализацией, которая все еще немного неполна.
«Сделайте так, чтобы это работало, а затем заставьте это работать лучше» .
Я не могу вспомнить, где я читал эту цитату, но это ключ к правильному применению рефакторинга, и я считаю это непрофессиональным, чтобы поступить иначе.
Непрерывный рефакторинг подобен вытиранию разливов во время приготовления пищи и чистке посуды после еды. Целевой рефакторинг - это все равно что найти грязную кухню, но есть время, чтобы вымыть грязный стакан или два. Вы бы предпочли жить с постоянно грязной кухней, или вы предпочитаете содержать вещи в чистоте на ходу?
Вы заставляете код работать, а затем реорганизуете свой код, чтобы обеспечить наилучшую реализацию, которую вы можете использовать. Если вы делаете что-то знакомое, может случиться так, что вы впервые реализуете лучший код, однако для того, чтобы быть уверенным, нужно потратить некоторое время на то, чтобы дважды проверить свою работу. Если это выглядит так, как будто вы могли бы улучшить свой код, то вы попытаетесь провести рефакторинг, чтобы убедиться, что ваш код, по крайней мере, настолько прост и чист, насколько вы можете это сделать. Это означает, что вы сокращаете объем технического долга, который оставляете позади, и облегчаете чтение и рефакторинг в следующий раз, когда необходимо разобраться с кодом. Это основное значение, лежащее в основе мантры TDD «Red-Green-Refactor», за исключением того, что, когда в TDD вы производите рефакторинг, главным образом, для устранения дублирования, необходимо также рассмотреть другие элементы, которые могут быть реорганизованы, такие как большие классы, длинные методы,
Если вы столкнулись с серьезным изменением дизайна, то, возможно, вы можете отложить его на некоторое время, особенно если у вас очень мало времени в расписании. Это, однако, при условии, что функциональность вашего кода не будет скомпрометирована, а также при условии, что реализация продолжит соответствовать требованиям. Такая ситуация должна быть редкостью, и вы можете помочь гарантировать, что она будет еще реже, если вы будете постоянно проводить рефакторинг. Тем не менее, еще более важно то, что вы не можете рисковать, оставляя свои основные изменения слишком долго, в противном случае вы в конечном итоге создадите еще большую рабочую нагрузку, которая может быть либо более дорогостоящей для устранения, либо может привести к еще более дорогостоящей провал проекта.
У меня складывается впечатление, что многие люди путают определения Рефакторинг и Реинжиниринг . Эти два термина описывают стратегии для управления очень разными ситуациями. Если вы хотите провести реинжиниринг, вы берете на себя обязательство внести радикальные изменения, которые изменят поведение системы. Это сделает недействительными некоторые тесты, а также потребует новых тестов. Когда вы выполняете рефакторинг, вы гарантируете, что ваша система продолжает вести себя точнотак же, как это было до изменения, однако вы также гарантируете, что ваш код будет иметь долговечность и что его будет легче поддерживать с течением времени. Вы не «балуете» свой код, черт побери, вы придерживаетесь профессионального стандарта чистого кода, который снизит риск сбоев и гарантирует, что ваш код остается приятным для работы, и профессионального стандарта ,
Возвращаясь к аналогии с разбитыми окнами, если вы разбили окно, вы должны немедленно его починить. Если вы не заметили, что окно разбито, то вам нужно решить стоимость, если вы оставите окно разбитым. Теперь повторите предыдущие два предложения, но замените окно на Ошибка, В конечном итоге вам нужна другая стратегия. Если вы создали ошибку в коде, вы исправили ее сразу, или вы увидите, что изменения потребуют внесения изменений, и вы примете коммерческое решение относительно того, когда будет лучше решить проблему. Таким образом, вы не рефакторинг для устранения проблемы, вы рефакторинг, чтобы убедиться, что легче найти и исправить проблемы. Мне все равно, насколько удивительным вы считаете свой код, сложные системы всегда будут иметь проблемы, с которыми нужно будет справляться с течением времени. В этом и заключается весь технический долг, и поэтому рефакторинг должен быть непрерывным процессом, пока вы реализуете свой код , а не быть оставленным в течение некоторого произвольного будущего времени.
Короче говоря, ответ, что в редких случаях может быть приемлемо отложить серьезные изменения в коде, чтобы сделать крайний срок, однако не следует считать обычной практикой рассматривать рефакторинг как упражнение, независимое от вашей ежедневной работы по реализации, и, конечно, никогда не использовался в качестве оправдания командами, не знакомыми с базой кода, как вариант, позволяющий избежать того, чтобы их реализация была настолько скудной и чистой, насколько это возможно при определенных обстоятельствах.