Пишите лучший код с этими 6 принципами
Чтобы быть хорошим инженером-программистом, нужно не только писать код, но и решать проблемы наиболее эффективным и действенным образом. Этого можно достичь с помощью алгоритмов, модульного тестирования и пространственно-временного анализа сложности. Существует также набор проверенных и проверенных временем принципов, которые разрабатывались годами для совершенствования искусства и науки разработки программных приложений. Эти принципы служат руководством к лучшему и чистому коду, который легче отлаживать и понимать.
Вот наш список самых важных принципов разработки программного обеспечения.
СУХОЙ (не повторяйся)
Этот принцип восходит к книге Энди Ханта и Дэйва Томаса «Программист-прагматик», которые определили его как:
Каждая часть знания должна иметь единственное, недвусмысленное и авторитетное представление в системе.
Это означает, что каждая часть данных должна иметь единую контрольную точку или единый источник истины (SSOT), так что изменение отдельной части этих данных не требует изменения логически несвязанных элементов. Это потому, что все вхождения этих данных относятся к одному месту. Это отличается от кода, который требует изменения каждого экземпляра, скажем переменной, всякий раз, когда вы изменяете один ее экземпляр в исходном коде. Код, не подчиняющийся принципу DRY, называется WET, что означает «писать все дважды», «нам нравится печатать», «писать каждый раз» или «тратить время впустую»! Применение DRY к коду снижает избыточность и упрощает последующее управление.
Поцелуй (Keep It Simple Stupid)
Согласно Словарю современного американского сленга и нетрадиционного английского языка Routledge, этот принцип был разработан ВМС США в 1960 году. Они отметили, что большинство систем работают лучше всего, если они просты и понятны, в отличие от сложных и сложных. . Опыт показал, что сложность вызывает ошибки, потому что есть больше (ненужных) частей, которые нужно отслеживать, и меньше инженеров могут понять, как они соединяются. KISS делает ваш код чище и снижает вероятность появления ошибок. Такой код также легче отлаживать и поддерживать.
ЯГНИ (Вам это не понадобится)
YAGNI исходит из методологии разработки программного обеспечения под названием Extreme Programming (XP). Кто может лучше дать определение этому, чем соучредитель XP Рон Джеффрис, который сказал:
Всегда внедряйте вещи, когда они вам действительно нужны, а не тогда, когда вы просто предвидите, что они вам нужны.
Разработчики нередко добавляют функции в свои приложения в ожидании потенциальной необходимости. Возможность удалить комментарий может показаться соблазнительной для некоторых, но сейчас становится вполне стандартной практикой полностью исключить возможность его удаления. Например, такие платформы, как Youtube и LinkedIn, не позволяют удалять свои комментарии. Избегание ненужных функций - хорошая практика в разработке программного обеспечения. Однако бывают случаи, когда предвидение будущего использования или потребности в функции может оказаться полезным.
ТВЕРДЫЙ
Он состоит из принципов дизайна, которые впервые появились в статье Роберта Мартина 2000 года, озаглавленной Принципы дизайна и шаблоны дизайна. Это:
- Принцип единой ответственности: Каждый класс, метод или модуль должен иметь единственную ответственность, так что только одна часть приложения должна иметь возможность влиять на класс, если эта часть будет изменена. Это имеет смысл в реальной жизни. Ваша спальня не предназначена для душа, и ваш душ не предназначен для сна. Классы и методы можно рассматривать как комнаты с отдельными целями и обязанностями. Это делает ваш код более организованным и понятным.
- Принцип открытости-закрытости: это означает открыт для расширения и закрыт для изменения.
Открытость для расширения означает, что существующий код должен разрабатываться с возможностью построения на его основе, без необходимости начинать с нуля. Нам не нужно изменять существующий код, чтобы добавить к нему функции или возможности.
Закрыто на изменение означает, что после того, как существующий код заработает, мы должны стараться не вносить в него ненужные изменения. Причина в том, что он может открыть банку с червями, заставив нас также изменить весь код, связанный с ним, без нашего ведома. Чтобы не тратить на себя больше работы, чем необходимо, в идеале следует оставить существующий код в покое.
Имейте в виду, что часто есть очень веские причины для рефакторинга кода, которые могут быть неуклюжими или трудными для выполнения. Если рефакторинг может обеспечить ясность или улучшить производительность, следует делать исключения из этого принципа.
- Принцип подстановки Лискова: это означает, что ваши подклассы должны вести себя так же, как и класс, от которого они наследуются. Другими словами, вы должны иметь возможность заменить родительский класс дочерним и ожидать того же базового поведения. Например, предположим, что у вас есть класс vehicle со свойством wheels и методом drive ().
class Vehicle {
wheels: 4;
drive(){
System.out.println("Vroom!!!");
}
}
class Sedan extends Vehicle {
occupants: 4;
}
class Bicycle extends Vehicle {
occupants: 1;
}
Согласно принципу подстановки Лискова, вы должны иметь возможность заменять родительский объект дочерним объектом и наоборот, и код должен вести себя таким же образом. Здесь, хотя объект Седан можно заменить объектом Автомобиль, вы не можете сделать то же самое для объекта Велосипед. Велосипед, хотя и является транспортным средством, не должен иметь опции «привод» и не имеет четырех колес. Мой класс транспортного средства нужно было бы изменить, чтобы он был более общим. Мы можем исправить это следующим образом.
class Vehicle {
Vehicle (chosenBrand, chosenModel, numSeats){
brand: chosenBrand;
model: chosenModel
occupants: numSeats;
}
}
class Sedan extends Vehicle {
drive(){
console.log("Vroom");
}
class Bicycle extends Vehicle {
const numWheels = 2;
....
}
- Принцип разделения интерфейса. Лучше всего его определяет сам Мартин:
Многие клиентские интерфейсы лучше, чем один интерфейс общего назначения.
Более практично иметь отдельные интерфейсы, которые обрабатывают отдельные задачи, чем один, который обрабатывает множество. Например, в приложении лучше иметь отдельные вкладки, посвященные отдельным вопросам, например «Настройки», чем вкладку, посвященную несвязанным вопросам.
- Принцип инверсии зависимостей: модули высокого уровня не должны зависеть от модулей низкого уровня. Взаимодействие между двумя модулями следует рассматривать как абстрактное взаимодействие между ними, а не как конкретное.
Разделение проблем
Это относится к факту возложения отдельной ответственности на каждую функцию, класс или компонент. Часто возникает соблазн поручить одной функции выполнять несколько задач, однако лучше разделить труд между специализированными функциями или компонентами. Предположим, вы разрабатываете погодное приложение, вместо единственной функции, которая генерирует прогноз погоды на данный день, было бы разумнее иметь функцию, которая вычисляет температуру, ту, которая возвращает влажность. , и еще один, который определяет дату. Это делает код более чистым, который легче читать и устранять неполадки.
Я хочу отметить, что, хотя это может показаться идентичным «принципу единой ответственности», это не так. Единая ответственность говорит о том, что каждый класс или функция должны иметь свою собственную ответственность. Разделение проблем говорит о том, что вы должны разбить эту единственную ответственность на более мелкие части, каждая из которых несет свою ответственность. В нашем примере с погодным приложением у вас может быть одна функция, которая берет на себя единственную ответственность за создание погоды. В идеале вам нужно иметь отдельную функцию для даты / времени, одну для влажности и т. Д. Это разделение задач. Следовательно, его можно рассматривать как подмножество принципа единой ответственности.
Возможность повторного использования кода
Одним из преимуществ разделения ответственности является возможность повторного использования кода. Поскольку каждый метод был написан для решения отдельной задачи, теперь его можно будет повторно использовать в будущем для аналогичных целей. Итак, в нашем погодном приложении нашу функцию вычисления даты можно повторно использовать в другой части нашего кода, которая также может требовать дату.
Это лишь некоторые из принципов разработки программного обеспечения, которые настоятельно рекомендуется учитывать разработчикам при разработке приложений. Они позволяют код, который легче читать, отлаживать и поддерживать в течение длительных периодов времени. По ссылкам ниже можно найти дополнительные ресурсы по этой теме.
Спасибо за прочтение! Приступаю к кодированию! :)
