предисловие
Что такое рефакторинг, который все считают плохим в ежедневной разработке проектов? В глазах многих разработчиков, которых я встречал, рефакторинг понимается как свержение предыдущего программного обеспечения, перепроектирование и создание чего-то точно такого же, как интерфейс! Я думаю, что это очень опасно иметь такой образ мышления.В современном обществе, где эффективность превыше всего, такая трата человеческих ресурсов неприемлема для общества и бизнеса.Давайте обсудим, что такое реальная реконструкция на этот раз? Перед официальным началом давайте посмотрим, как Бог понимает рефакторинг.
Глоссарий
Рефакторинг (существительное):Корректировка внутренней структуры программного обеспечения для улучшения его понимания и снижения стоимости его модификации без изменения наблюдаемого поведения программного обеспечения.
Рефакторинг (глагол):Используя серию методов реконструкции, отрегулируйте свою структуру без изменения наблюдательного поведения программного обеспечения.
В прошлом многие люди использовали термин рефакторинг для обозначения очистки кода. На самом деле, ключ к рефакторингуИспользуйте большое количество небольших шагов, которые поддерживают поведение программного обеспечения, шаг за шагом к крупномасштабным изменениям.. Каждый отдельный рефакторинг либо небольшой, либо состоит из нескольких небольших шагов. Поэтому, если кто-то говорит, что его код был недоступен в течение нескольких дней или более во время процесса рефакторинга, в основном вы можете быть уверены, что то, что он делает, не является рефакторингом.
зачем нужно
Улучшить дизайн программного обеспечения
Без рефакторинга внутренний дизайн программы со временем будет постепенно ухудшаться. Во многих технологических компаниях Китая скорость имеет решающее значение. Чтобы иметь возможность выходить в интернет раньше, компания вынуждена сокращать время разработки. Чтобы уйти с работы и уйти домой пораньше, разработчики уходят с работы меньше сверхурочно. Многие разработчики часто не до конца понимают дизайн архитектуры программы, когда они изменяют ошибки и код, просто временный патч, поэтому Чжан Сан изменил его сегодня, а Ли Си изменил его завтра, поэтому код постепенно терял свою собственную структуру. Со временем программистам становится все труднее понять первоначальный дизайн, читая код, поэтому код становится все более испорченным и быстрым, и, наконец, становится проектом, который никто не осмеливается трогать.
Увеличение скорости программирования
На ранней стадии проекта, когда сложность и коррупция кода еще не достигли пика, прогресс разработки вначале будет очень быстрым, что создаст у руководства компании иллюзию того, что реальная скорость разработки должна быть такой, и его всегда нужно поддерживать. Но когда разработка достигает определенной стадии, когда вы хотите добавить новую функцию, это займет намного больше времени, чем раньше, и разработчикам нужно больше времени подумать о том, как вставить новую функцию в существующую. базы, избегайте смущающего состояния воздействия на все тело, меняя одно место. Вся кодовая база проекта выглядит как патчи поверх патчей. Это похоже на археологию, чтобы выяснить, как работает вся система. Эти нагрузки продолжают замедлять скорость добавления новых функций, и в конечном итоге программисты не могут этого вынести. , он спросит: «А давайте сделаем новую версию и откажемся от текущего проекта, не так ли?».
Итак, насколько испорчен код проекта, который мы должны начать рефакторинг? В книге «Рефакторинг» предшественника Мартина Фаулера уже обобщено 24 возможности практического рефакторинга. Давайте проверим их одну за другой, чтобы увидеть, есть ли у нас какие-либо проблемы при написании кода, допущенные эти ошибки.
Когда проводить рефакторинг
1. Таинственное наименование
Хорошее имя может помочь читателю понять смысл кода с первого взгляда.Самая важная часть чистого кода — начать с хорошего имени. На самом деле, многие люди не хотят менять название программы, и считают, что это не стоит потраченного времени, но хорошее название может сэкономить много времени на догадки в будущем, поэтому, когда в проекте появляется загадочное имя , это начало рефакторинга. См. главу 2 «Осмысленное наименование чистого кода» для получения дополнительной информации о осмысленном именовании кода.
2. Дублирующийся код
В сознании отличных разработчиков практикуется принцип всего трех вещей, то есть когда кусок кода используется более чем в трех местах, пора приступать к рефакторингу.Три не является абсолютной величиной.Если быть точным, Если вы видите одну и ту же структуру кода более чем в одном месте, вам следует немедленно приступить к рефакторингу кода. Многим начинающим разработчикам нравится разрабатывать, копируя и вставляя код при написании кода, что создаст больше ненужных проблем для других в дальнейшем сопровождении и изменении кода.
3. Слишком долгая функция
Кто-то однажды сказал, что если функция имеет более 50 строк кода, вы должны начать думать о ее рефакторинге. Согласно моему прошлому опыту разработки, функции с меньшей степенью детализации будут жить дольше и лучше всего, и все они следуют принципу единственной функции. Когда функция слишком длинная, сложность будет выше и понимание будет сложнее, поэтому многие разработчики любят добавлять больше комментариев для объяснения программы в длинную функцию, это неправильный подход, слишком много комментариев Легче вмешиваться с чтением и пониманием кода. Поэтому, когда мы чувствуем, что нам нужно использовать аннотации для объяснения логики кода, мы должны абстрагировать контент, который необходимо аннотировать, записать его в отдельную функцию и дать ему интуитивно понятное и хорошее имя.
4. Слишком длинный список параметров
Когда я писал код на Angular1, мне часто приходилось внедрять множество зависимых объектов в контроллер, а в callback-функции нужно было передавать большое количество параметров, из-за чего у меня часто тряслись руки или последовательность была неправильной, что привело к некоторым ошибкам. Слишком длинные списки параметров часто сбивают с толку и легко допустить ошибку Мы можем объединить несколько параметров в один объект и уменьшить длинный список параметров за счет передачи объектов, чтобы код был более кратким и читабельным.
5. Глобальные данные
Использование глобальных данных в проекте может легко привести к загрязнению данных и конфликту. Во многих спецификациях кода использование глобальных данных явно запрещено, а глобальные данные могут быть изменены из любого места в кодовой базе, что чрезвычайно затрудняет устранение ошибок. В реальной разработке глобальные данные могут быть абстрактно инкапсулированы, а операции импорта вручную могут выполняться там, где данные используются.
6. Переменные данные
Для слаботипизированного языка разработки Js легко может возникнуть проблема переменных данных, после обновления данных в одном месте он не понимает, что другая часть ПО ожидает данные совсем другого типа данных, поэтому ошибка исправлена. , это случается в очень редких случаях, поэтому найти причину сбоя будет сложнее, поэтому сейчас Ts становится все популярнее в кругу front-end технологий.
7. Дивергентное изменение
В начале разработки программного обеспечения мы надеемся, что программное обеспечение можно легко модифицировать.Как только нам нужно его изменить, мы можем сразу же перейти к определенной точке в системе и модифицировать его только в этой позиции. Дивергентные изменения происходят, когда модуль часто изменяется в разных направлениях по разным причинам.
8. Децентрализованная модификация
Разбросанные модификации похожи на дивергентные изменения, но с точностью до наоборот. Если для каждого изменения вам приходится вносить много мелких изменений во многие разные классы, проблема, с которой вы сталкиваетесь, заключается в разбросанных изменениях, когда ваш код разбросан по нескольким местам, и вы не только их трудно найти, но и легко пропустить важное изменение. . В настоящее время вам необходимо инкапсулировать и абстрагировать или переместить некоторый код в тот же модуль, чтобы добиться централизованного изменения.
9. Комплекс крепления
Разработчики, принявшие объектно-ориентированное программирование, будут более или менее думать, что код должен иметь высокую связность, низкую связанность, открытость и замкнутость и т. д. при написании кода. Но иногда вы обнаружите, что функция взаимодействует с функциями или данными в другом модуле очень часто, гораздо лучше, чем доступ внутри модуля, в котором она находится.Это комплекс приложений кода. Мы можем переместить эту часть кода внутрь модуля, к которому осуществляется доступ, или мы можем абстрагировать его еще на один уровень и разложить функцию на несколько более мелких функций, которые размещены в разных местах.
10. Грязь данных
Когда я поддерживал чужой код, я часто видел одни и те же строки и одни и те же параметры во многих местах, разбросанных по каждому уголку кода, что затрудняло поддержку такого кода. Нам нужно только абстрагировать данные, разбросанные повсюду, извлечь их в отдельный объект, а затем получить доступ к данным, импортировав объект, что может помочь нам уменьшить много повторяющегося контента и сделать его модифицированным. Также больше не будет разрозненных изменений в код.
11. Паранойя базового типа
В некоторых проектах с поврежденным кодом паранойя базовых типов является очень распространенной проблемой.Например, цены могут быть представлены типами с плавающей запятой, а диапазоны координат могут быть инкапсулированы как объекты для отображения, но на самом деле они хранятся и отображаются как строки. Строки кажутся универсальным типом данных, и вполне возможно заменить этот код, ориентированный на тип, правильным типом для отображения.
12. Повторный переключатель
В коде, написанном новичком, при столкновении с условным суждением или ветвлением большое количество повторяющихся вложенных условий if и повторного переключения являются обычными способами решения проблемы. Проблема с этими дублирующими переключателями заключается в том, что если вы хотите добавить альтернативную ветвь, вам нужно найти все переключатели и изменить их один за другим. Для повторяющихся суждений о ветвях мы можем использовать多态для замены условных выражений, что делает код более элегантным.
13. Оператор цикла
В большом количестве бизнес-сценариев операторы цикла не нужны, и многие новички любят писать большое количество операторов цикла for, чтобы удовлетворить свои потребности. На самом деле мы можем использовать管道Замена циклов, таких как использование методов filter, map, forEach и других, поможет нам быстрее увидеть обрабатываемые элементы и их действия.
14. Резервные элементы
При разработке проекта, чтобы поддерживать изменения и способствовать повторному использованию кода, мы часто абстрагируем и инкапсулируем код, но в настоящее время часто трудно понять степень абстракции, что приводит к промежуточной инкапсуляции. Может быть, имя метода и код реализации выглядят одинаково, может быть, абстрактный класс — это просто простая функция и т. д., что приводит к избыточности кода. Мы можем освободить слишком абстрактный код путем слияния, тем самым уменьшив избыточность кода.
15. Расскажите об универсальности
Аналогичным образом, в чрезмерном кодексе произойдет множество особых обстоятельств, используемых для того, чтобы иметь дело с некоторыми особенно редкими или ненужными вещами, на самом деле эти особые ситуации будут только сложнее для поддержания и понимать, поэтому в начале Дизайн, рассмотрите рассмотрение, что если вы действительно используете его, оно того стоит. Если вы не можете использовать его, вы только проще, сделаете только код.
16. Временные поля
В проекте, написанном несколькими людьми, вы могли видеть, как другие определяют временное поле в коде, но это поле будет использоваться только в определенных случаях.Если код не входит в ветку, такое временное поле будет легко быть неправильно понятым. Мы можем абстрагировать эти временные поля в специальный класс, затем переместить эти поля и связанный с ними код в этот класс, а затем вызывать методы этого класса там, где это необходимо.
17. Слишком длинная цепочка сообщений
При использовании кода, написанного другими, для получения данных, когда мы смотрим на его логику, мы обнаруживаем, что объект, к которому вы обращаетесь, является другим объектом прокси, и когда другой объект запрашивает другой объект, появляется слишком длинная цепочка сообщений. если вы спешите исправить ошибку, этот код может свести вас с ума. Когда цепочка сообщений слишком длинная, мы можем абстрагироваться и переместить эти коды в класс, чтобы обрезать слишком длинную цепочку сообщений, чтобы сократить глубину кода и значительно улучшить читаемость кода.
18. Посредник
Одной из признаков объектно-ориентированного программирования является инкапсуляция, а инкапсуляция часто сопровождается делегированием. Но, возможно, вы видели, что половина функций интерфейса класса делегируется до других классов для реализации, что является чрезмерным использованием инкапсуляции. В это время мы должны удалить код посредника и взаимодействовать напрямую с объектом реального реализации.
19. Инсайдерская торговля
В реальной разработке многие люди реализуют высокую связность модулей, но после связности обязательно возрастет большой объем обмена данными между модулями, что увеличит связь между модулями. Если между двумя модулями всегда был частный обмен данными, то нам необходимо выяснить общие данные между двумя модулями, абстрагировать их как посредника данных между ними и поставить это поведение обмена на светлую сторону.
20. Негабаритные классы
Крупнейший источник раздутого кода — слишком большой класс. Классу нужно много чего делать, и естественно будет много полей, последует дублирование кода, код начнет барахлить и в конце концов умрет. Для такого большого класса нам необходимо использовать возможности абстракции для уточнения этих кодов, извлечения одного и того же бизнеса в соответствующий класс и извлечения общего содержимого в суперкласс.
21. Классы, которые делают одно и то же
В коде, который перебирался в нескольких версиях, есть много классов с одной и той же целью.Вообще говоря, кажется, что все делают одно и то же, с небольшими различиями, такими как некоторые параметры. Эти классы полны большого количества повторяющегося кода. Мы можем сделать параметры функции согласованными, изменив объявление функции, а затем объединить их. Если есть повторяющийся код, мы абстрагируем их в суперклассы, чтобы компенсировать это.
22. Чистые классы данных
У некоторых опытных программистов для удобства управления некоторые разрозненные данные будут помещаться в специальный чистый класс данных, чтобы этот класс имел много полей и использовал для доступа к этим данным функцию поля. Но эти классы чистых данных бесполезны, кроме как для доступа и чтения этих полей.Мы должны переместить поведение обработки данных из других мест в классы чистых данных.
23. Отклоненные завещания
При сопровождении некоторого кода наследования часто обнаруживается, что подкласс наследует родительский класс и получает все функции и данные родительского класса, но подкласс получает только значение от родительского класса, а другие функции родительского класса Сумма значение отвергается подклассом. Это означает, что дизайн системы наследования неверен Нам нужно создать новый родственный класс для этого подкласса, а затем запихнуть неиспользуемые функции и значения в этот родственный класс, чтобы родительский класс содержал то, что разделяют все подклассы.
24. Примечания
Отличный код, понятный. Но на самом деле большинство комментариев существует потому, что код очень плохой, поэтому приходится добавлять некоторые комментарии для облегчения дополнительных пояснений. Итак, когда вы чувствуете необходимость написать комментарии, попробуйте сначала провести рефакторинг кода, использовать приемы абстрагирования функций и изменения объявлений функций и постараться сделать все комментарии излишними.
Вышеизложенное — это теория о 24 неприятных запахах кода.В следующей статье мы официально начнем тренировку и практику!