Рефакторинг — это переосмысление вашего кода, всего в нем, чтобы сделать ваш код лучше. В этой серии статей о рефакторинге кода я покажу вам, почему, когда, что, где и как проводить рефакторинг, поскольку рефакторинг — это больше искусство, чем наука. В этой части я объясню, что делает код хорошим, основу, на которой я буду опираться позже в остальной части серии.
Что такое хороший код?
Основная цель рефакторинга — чистый код, лучший код или как бы вы его ни называли. Но что на самом деле составляет хороший код? Хороший код пахнет и пробуется. Если вы написали много кода, вы понимаете, что я имею в виду; Вы можете легко определить, является ли код хорошим или плохим с опытом. Но что, если вы новичок в кодировании, но все же хотите все делать правильно?
Мы можем суммировать аспекты хорошего кода с этими тремя принципами:
- Удобочитаемый
- растяжимый
- эффективное
читабельность
Если ваш код соответствует стандартным общеизвестным синтаксису, стилю и методам документирования, или, другими словами, когда вы и ваши коллеги-разработчики можете легко интерпретировать код с минимальной двусмысленностью, ваш код считается читаемым и, следовательно, поддерживаемым с точки зрения стиля. и внешний вид. Чтобы достичь этого, вы должны следовать стандарту кодирования. Вы можете использовать какой-то общедоступный стандарт или создать свой собственный, если хотите, но как бы вы ни выбрали, ваши коллеги должны найти ваш синтаксис, стиль, документацию по коду и комментарии прямо, ясно и не требуют, насколько это возможно, дальнейших объяснений. Я предпочитаю использовать общедоступный стандарт, поскольку он может сократить время обучения для новых людей, присоединившихся к моей команде разработчиков позже.
Читаемость и расширяемость перекрываются, когда вы используете базовые конструкции ваших языков программирования для того, для чего они были предназначены в максимально возможной степени, а для решения общеизвестных проблем вы используете общеизвестные шаблоны (шаблоны проектирования). Но что, если у вас возникла новая проблема? Или что, если вы только что создали лучшее решение для старой проблемы? Потрясающе! Другие программисты не смогут понять ваше новое решение на миллиард долларов, если вы не документируете его должным образом! Держите свой ум в лучшем виде и взлетайте так высоко, как вам нравится, но не забывайте уделять время тому, чтобы описать в своем коде, как и почему вы его сделали.
растяжимость
И читабельность, и расширяемость способствуют удобству сопровождения вашего кода и перекрываются в определенные моменты времени. Но чтобы усилить разницу, читаемый код можно поддерживать с точки зрения его стиля, а расширяемый код — с точки зрения его логики. Тот же аргумент применяется к шаблонам проектирования, поскольку они способствуют как удобочитаемости, так и расширяемости.
Ваш код расширяем, когда он следует некоторым повторно используемым, логичным, хорошо известным шаблонам, будь то определенные стандартные шаблоны проектирования или нормальный логический поток. Например, некоторые разработчики предпочитают использовать шаблон проектирования Singleton для работы с соединениями с базой данных. В качестве другого примера, большинство из нас будет использовать стандартный foreach для итерации по массиву, который является стандартным потоком. Можно использовать цикл for или даже цикл while при сходных обстоятельствах, но это довольно редко встречается в PHP, поэтому следует документировать, почему такие конструкции были необходимы, чтобы избежать путаницы.
Основными аспектами расширяемости являются разделение и инкапсуляция. Разделение означает, что ваш код (в основном функции / методы и классы) не должен зависеть или перекрывать друг друга; код должен быть настолько «чистым», насколько это возможно, с удалением любых перекрывающихся функций и других несвязанных сущностей. Если вы пишете процедурный код, ваши функции должны содержать только ту логику, которую подразумевают их имена; не заставляйте функции делать слишком много! При написании кода используйте подход «инструментарий» — небольшие базовые процедуры работают вместе для создания больших сложных систем.
Инкапсуляция является неотъемлемой частью развязки. Всякий раз, когда вы разъединяете компоненты, вы уже сделали некоторую инкапсуляцию. Чтобы инкапсулировать компоненты, продолжайте отделять их внутренние компоненты от глобальной области и заставлять все взаимодействия с ним происходить на уровне его интерфейса. Это модульный подход, который облегчает последующее удаление или обновление любой части вашей системы, в отличие от монолитного дизайна, который делает ваш код спагетти.
КПД
Вы должны помнить об эффективности с самой первой строки кода в любом проекте, поскольку узкие места, как известно, возникают из-за какого-то очень неразумного использования языковых конструкций, например, из-за вложения нескольких циклов и неразумного использования рекурсии, а также из-за некоторого неразумного использования логических шаблонов, например, не использовать кэширование и отправку / получение данных в / из потоков без надлежащей буферизации.
Эффективность важна, но не ставьте под угрозу первые два правила ради этого. Фактически, ухудшение читаемости и расширяемости может привести к снижению эффективности! В большинстве случаев эффективность прямо пропорциональна применению первых двух правил. Когда возникает исключительная ситуация, сделайте все возможное, чтобы убедиться, что у вас есть другие способы сохранить ваш код в хорошем состоянии.
Резюме
В этой статье я познакомил вас с тем, что делает код хорошим. Я ограничил обсуждение тремя основными аспектами: читабельность, расширяемость и эффективность, и описал, что каждый из них означает.
Теперь, когда вы знаете, что составляет хороший код, мы можем перейти к следующим частям серии. Во второй части я покажу вам некоторые вещи, на которые стоит обратить внимание при рефакторинге для лучшей читабельности.
Изображение через Fotolia