Распространенное заблуждение

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

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

Это заставило меня опасаться рефакторинга.

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

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

Есть много причин для рефакторинга фрагмента кода. Вот некоторые из них:

Легкие изменения

Лучшая цитата о рефакторинге, которую я когда-либо читал:

«Сделайте изменение простым, а затем внесите легкое изменение»

- Кент Бек

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

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

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

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

Изменения требований к существующей функциональности

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

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

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

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

Сначала функциональность, потом рефакторинг

'Что' делает код и 'как' код делает это часто можно рассматривать как два разных проблемы, над которыми можно работать отдельно. 'what' - функциональность кода, а 'как' - дизайн кода. .

Часто бывает очень полезно сосредоточить все свои усилия на правильной работе. Сначала вас не волнует дизайн, потому что вы уверены, что ваши навыки рефакторинга помогут вам получить лучший дизайн послесловия. Когда «то, что ваш код делает» (функциональность) уже решено, вы можете думать о как (дизайне) .

Предварительный дизайн

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

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

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

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

Читаемость

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

Заключение

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

Полезная книга, которая поможет вам улучшить свои навыки рефакторинга, - Рефакторинг Мартина Фаулера.