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

С тех пор, как я начал использовать .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.

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

Ответ 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/. Он содержит много ссылок на дополнительные ресурсы по теме кода рефакторинга, а также список рассылки для обсуждения проблем, связанных с рефакторингом.

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