Код рефакторинга: когда делать что?

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

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

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

Есть ли какие-то ресурсы, которые могли бы помочь в принятии такого решения?

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

Ответ 1

Настоящим открытием для меня было Рефакторинг: улучшение дизайна существующего кода:

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

Рефакторинг http://ecx.images-amazon.com/images/I/519XT0DER6L._SL160_PIlitb-dp-arrow,TopRight,21,-23_SH30_OU01_AA115_.jpg

Это помогло мне эффективно и систематически реорганизовать код. Также это очень помогло мне в обсуждениях с другими разработчиками, когда их holy code нужно изменить...

Ответ 2

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

Рефакторинг кода в .NET занимает некоторое время. Вам необходимо знать некоторые объектно-ориентированные принципы дизайна (или методы проектирования), чтобы рефакторинг эффективно и беспощадно.

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

Ответ 3

Вот обзор косой черты книги под названием Clean Code.

Книга, по-видимому, немного сухая, но очень хорошая.

Ответ 4

Отъезд комментарии от Мартина Фаулера и книга Рефакторинг

Ответ 5

Перегруппируйте код, когда он вызывает проблемы. Любые проблемы будут: производительность, масштабируемость, интеграция, поддержка - все, что заставляет вас тратить больше времени на это, когда вам нужно. Это не сломано, не исправляйте это, даже если вы не считаете, что оно чистое или соответствует современным стандартам.
Не тратьте слишком много времени, чтобы сделать код идеальным. Вы никогда не достигнете совершенства, но вы могли бы потратить много времени, пытаясь это сделать. Запомните закон уменьшения прибыли.
Внутри проекта переопределяют код только тогда, когда вы фактически работаете над функциональностью, которая зависит от нее. То есть если у вас есть история пользователей для итерационных вызовов для "изменения механизма загрузки" или "исправления ошибки при загрузке файла", вы можете повторно разложить код загрузки файла. Однако, если ваш рассказ пользователя о "обновлении дизайна пользовательского интерфейса загрузки файлов" не входит в бизнес-логику.

Ответ 6

Я бы рекомендовал Domain Driven Design. Я думаю, что принципы YAGNI и AlwaysRefactor являются двумя упрощенными. Возрастный вопрос по этой проблеме заключается в том, что я реорганизую "if (someArgument == someValue)" в функцию или оставляю ее встроенной?

Нет ответа "да" или "нет". DDD рекомендует реорганизовать его, если тест представляет правило buisiness. Рефакторинг не является (только) о повторном использовании, а о том, чтобы сделать намерения ясными.

Ответ 7

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

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

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

Ответ 8

Мое правило - оставить код в худшей форме, чем вы его нашли.

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

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

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

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

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

Ответ 9

Я только что получил копию кода Complete и обнаружил, что есть раздел об этом.

Хотя я все еще буду читать принятую книгу ответов, то, что Code Complete научил меня, значительно улучшил то, как я думаю о разработке классов.

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

Ответ 10

Там есть веб-страница, посвященная рефакторингу http://www.refactoring.com/. Он содержит много ссылок на дополнительные ресурсы по теме кода рефакторинга, а также список рассылки для обсуждения проблем, связанных с рефакторингом.

Наконец, существует большой (и все еще растущий) каталог рефакторинга, который выходит далеко за рамки того, что написано в (очень рекомендуемой) книге Рефакторинга Мартином Фаулером.