понедельник, 16 августа 2010 г.

6/97: Прежде, чем вы приступите к рефакторингу

Это перевод Before You Refactor. Автор: Rajith Attapattu.

Из "97-ми вещей, которые должен знать каждый программист".

В какой-то момент любой программист сталкивается с необходимостью улучшить свой код - рефакторингом. Но прежде чем вы приступите к этому, пожалуйста, подумайте о следующих вещах, потому что они помогут вам и другим сэкономить кучу времени (и страданий):
  • Наилучший способ к реструктуризации кода начинается с взятия существующей базы кода и тестов, написанных для неё. Это поможет вам понять сильные и слабые стороны существующего кода, так что вы сможете гарантировать, что вы сохраните сильные стороны, избегая ошибок, приводящим к слабым сторонам. Все мы думаем, что сможем написать лучше, чем существующая система... пока в итоге мы не окажемся с чем-то не лучшим (или даже худшим), чем предыдущая инкарнация, потому что мы не учились на ошибках старой системы.
  • Избегайте искушения переписывания с нуля. Лучше всего использовать повторно так много кода, как это возможно. Не важно, что этот код уродлив - он уже был протестирован, проанализирован, и т.п. Выкидывание старого кода (особенно, если он побывал в релизных версиях) означает, что вы выкидываете месяцы (или даже года) проверенного, закалённого боями кода, который может содержать в себе обходные пути или исправления, о которых вы даже не подозреваете. Если вы не примете это во внимание, то ваш новый код может в итоге демонстрировать те же самые загадочные баги, что уже были когда-то исправлены в старом коде. Вы выкинете в мусорку много времени, усилий и полученного знания за всё это время.
  • Много последовательных изменений лучше, чем одно массивное изменение. Последовательные изменения позволяют вам просто измерять их влияние на систему - к примеру, через тесты. Вам будет не смешно, когда вы увидите сотни красных отметок в тестах после одного большого изменения. Это может привести к разочарованию, которое может привести к неверным решениям. С другой стороны, вы легко справитесь с парочкой проваленных тестов.
  • После каждой итерации - убедитесь, что все тесты проходят. Добавьте новые тесты, если существующие не покрывают ваши изменения. Не выкидывайте тесты от старого кода без внимательного изучения. С первого взгляда, некоторые тесты могут казаться неприменимыми к вашему новому дизайну, но будет очень мудро покопаться в причинах, почему этот тест был изначально добавлен и что он должен проверять.
  • Личные предпочтения и эго не должны стоять у вас на пути. Если что-то не сломалось - зачем это чинить? Если стиль или структура кода не соответствуют вашим личным предпочтениям - то это не должно быть причиной для реструктуризации. Если вы думаете, что вы можете написать этот код лучше, чем предыдущий программист - это тоже не достаточная причина.
  • Новые технологии - это не достаточная причина для рефакторинга. Одна из наихудших причин для рефакторинга - это если существующий код не следует всем этим новым клёвым технологиям и веяниям сегодняшнего дня, и мы верим, что новый язык или библиотека могут сделать наш код более элегантным. Если только анализ стоимости и выгоды не покажет вам, что эти новые вещи приведут к значительным улучшениям в функциональности, управляемости или продуктивности, то лучше бы вам оставить всё как есть.
  • Не забывайте, что люди делают ошибки. Реструктуризация не гарантирует, что новый код всегда будет лучше старого (или хотя бы так же хорош как он). Я видел и был частью нескольких неудачных попыток реструктуризации. Это не было красиво, но это было человечно.

1 комментарий:

  1. Вот с искушением переписывания с нуля иногда бывает трудно бороться :)

    ОтветитьУдалить

Можно использовать некоторые HTML-теги, например:

<b>Жирный</b>
<i>Курсив</i>
<a href="http://www.example.com/">Ссылка</a>

Вам необязательно регистрироваться для комментирования - для этого просто выберите из списка "Анонимный" (для анонимного комментария) или "Имя/URL" (для указания вашего имени и ссылки на сайт). Все прочие варианты потребуют от вас входа в вашу учётку (поддерживается OpenID).

Пожалуйста, по возможности используйте "Имя/URL" вместо "Анонимный". URL можно просто не указывать.

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