Рефакторинг Кода: Когда сделать что?
Я хотел бы указать, что нет такой вещи, как инициализация двойной скобки. Существует только обычный традиционный блок инициализации брекетов. Второй блок фигурных скобок не имеет ничего общего с инициализацией. Ответы говорят, что эти две фигурные скобки инициализируют что-то, но это не так.
Во-вторых, почти все ответы говорят о том, что это используется при создании анонимных внутренних классов. Я думаю, что люди, читающие эти ответы, получат впечатление, что это используется только при создании анонимных внутренних классов. Но он используется во всех классах. Чтение этих ответов - это какое-то новое особое будущее, посвященное анонимным классам, и я думаю, что это вводит в заблуждение.
. Идем дальше, этот вопрос говорит о ситуации, когда вторая открывающая скобка находится сразу после первого открытия скобки. Обычно в обычном классе есть некоторый код между двумя фигурными скобками, но это абсолютно одно и то же. Так что это вопрос размещения скобок. Поэтому я думаю, что мы не должны говорить, что это какая-то новая захватывающая вещь, потому что это то, что мы все знаем, но просто написано с некоторым кодом между скобками. Мы не должны создавать новую концепцию, называемую «инициализация двойной скобки».
Я не согласен с аргументом, что вы создаете слишком много анонимных классов. Вы не создаете их, потому что блок инициализации, но только потому, что вы их создаете. Они будут созданы, даже если вы не использовали две инициализации брекетов, чтобы эти проблемы возникали даже без инициализации ... Инициализация не является фактором, который создает инициализированный объект.
Кроме того, мы не должны говорить о проблеме, созданной используя эту несуществующую вещь «инициализацию двойной скобки» или даже обычную инициализацию одной скобки, поскольку описанные проблемы существуют только из-за создания анонимного класса, поэтому он не имеет ничего общего с исходным вопросом. Но все ответы дают читателям впечатление, что это не вина в создании анонимных классов, а эта злая (несуществующая) вещь, называемая «инициализация двойной скобки».
10 ответов
Реальное разоблачение мне было Рефакторинг: Улучшение Дизайна Существующего Кода :
С надлежащим обучением квалифицированный разработчик системы может взять плохой дизайн и переделать его в хорошо разработанный, устойчивый код. В этой книге Martin Fowler показывает Вам, где возможности для рефакторинга обычно могут находиться, и как пойти о переделке плохого дизайна в хороший.
Это помогло мне к эффективно, и систематически осуществляйте рефакторинг код. Также помогло мне много в обсуждениях с другими разработчиками, когда их holy code должен быть изменен...
Jeff Atwood сделал хорошее сообщение в блоге при рефакторинге и запахах кода , Вы могли бы хотеть проверить это.
код Рефакторинга в.NET занимает время к grok. Необходимо знать немного объектно-ориентированные принципы разработки (или методы проектирования ), чтобы к осуществляют рефакторинг эффективно и беспощадно .
Короче говоря, Вы осуществляете рефакторинг код, чтобы удалить запахи кода и делать изменения легче сделать. Кроме того, не переусердствуйте его.
Вот обзор на точке наклонной черты книги, названной Чистый Код .
книга по-видимому немного суха, но очень хороша.
Выезд Martin Fowler комментарии и книга по Рефакторинг
- Осуществляют рефакторинг Вас код, когда он вызывает проблемы. Любые проблемы сделают: производительность, scallabillity, интеграция, maintainance - что-либо, что заставляет Вас провести больше времени на нем, когда Вы должны. Это это не повреждается, не фиксирует его, даже если Вы не полагаете, что это чисто или до современных стандартов.
- не проводят слишком много времени, делая код прекрасным. Вы никогда не будете достигать совершенства, но Вы могли провести много времени, пытаясь сделать так. Помните закон убывающей доходности.
- Внутренняя часть проект только осуществляет рефакторинг код, когда Вы на самом деле работаете над функциональностью, которая зависит от него. Т.е. если у Вас есть пользовательская история для итеративных призывов к "изменению механизм загрузки" или "исправление ошибки в загрузке файла", Вы могли осуществить рефакторинг код загрузки файла. Однако, если Ваша пользовательская история о "подтяжке лица дизайна UI загрузки файла", не входят в бизнес-логику.
Работа Эффективно с Унаследованным кодом является одной из лучших книг, которые я видел на этом предмете.
не помещаются от заголовка книги - Вместо того, чтобы рассматривать Рефакторинг как формальное понятие (который имеет его место), эта книга имеет партии и много простых, "почему я не думал об этом" подсказки. Вещи как "проходят класс и удаляют любые методы, не непосредственно связанные с тем классом, и помещают их в различного".
, например, у Вас есть сетка и некоторый код для сохранения расположения той сетки в файл. Можно, вероятно, безопасно выгнать код сохранения расположения с квартиры к различному классу.
Я рекомендовал бы Доменный Управляемый Дизайн . Я думаю и YAGNI и принципы AlwaysRefactor равняются двум упрощенным. Возраст, который старый вопрос по проблеме, я осуществляю рефакторинг, "если (someArgument == someValue)" в функцию или оставляют его встроенным?
нет никакого ответа "да" или "нет". DDD советует для рефакторинга его, если тест представляет правило buisiness. Рефакторинг не (только) о повторном использовании, но и о ясно давании понять намерений.
Я просто получил копию Завершенного Кода, и нашел, что был раздел по этому.
, Хотя я буду все еще читать книгу принятого ответа, что Завершенный Код преподавал мне, существенно улучшил способ, которым я думаю о разработке классов.
Прежде сегодня, я не знал то, чем ADT был (абстрактный тип данных), и теперь я знаю, как разработать классы, придерживающиеся инкапсуляции.
Мое практическое правило - оставлять код не хуже, чем вы его нашли .
Идея состоит в том, чтобы работать к лучшему , не пытаясь достичь идеального результата или идти до конца.
Отдельные рефакторинги иногда имеют сомнительную пользу и - как крайний пример - действительно может быть спорным, является ли m_Pi лучшим именем, чем m_PI . Однако чаще всего один вариант более последователен и менее удивителен, даже если он не очевидно «лучше».
Одна ситуация, когда я регулярно обнаруживаю, что рефакторинг выполняется автоматически, - это перед реализацией функции в фрагменте кода.
Часто несколько TODO ждут, чтобы их накормили, некоторые несоответствия или иногда настраиваемые функции, которые в последнее время получили лучшую поддержку библиотеки. Внесение этих изменений до того, как я реализую фактический запрос функции, дает мне некоторое представление о коде, и я проверяю функциональность «до».
Еще один момент - после исправления ошибок. After, поэтому предварительное воспроизведение не затрагивается, а исправление ошибки и рефакторинг - это две отдельные фиксации.
Существует веб-страница, посвященная рефакторингу по адресу http://www.refactoring.com/ . В нем есть много ссылок на дополнительные ресурсы по теме рефакторинга кода, а также список рассылки для обсуждения вопросов, связанных с рефакторингом.
И последнее, но не менее важное: существует большой (и все еще растущий) каталог доступных рефакторингов, который выходит далеко за рамки что написано в (очень рекомендуемой) книге Мартина Фаулера по рефакторингу.