DevKucher;

Принципы разработки, которым должен следовать каждый разработчик

Изображение на обложке для Принципы разработки, которым должен следовать каждый разработчик

Что делает тебя хорошим разработчиком?

Если вы зададите 10 людям этот вопрос, вы обязательно получите 10 разных ответов. Хотя ответы могут быть изложены в разных словах, они вероятно, будут передавать одно и то же значение. Лично для меня хороший программист - это тот, кто способен понять проблему, придумать жизнеспособное решение, быть способным представить это решение конечному пользователю и работать в команде для достижения этой конечной цели.

Но как управлять огромным кодом с большим количеством разработчиков?

Предполагается, что каждый участвующий участник будет писать код, который будет чистым и поддерживаемым. Но, как это сделать? Вам нужно следовать определенным принципам разработки. Так как эти принципы облегчают вашу жизнь и жизнь других.

Принцип единственной ответственности

Когда вы начнете писать код, в течение длительного периода времени ваш код станет неуклюжим. У вас будут классы/модули, которые выполняют несколько функций. В итоге получатся классы с сотнями и тысячами строк кода.

Этот принцип говорит о том, что каждый класс или модуль в программе должен иметь только определенную функциональность. Другими словами, класс или модуль в программе должен отвечать только за задачи, касающиеся одной конкретной функции. Это поможет вам сохранить ваши модули минимальными и чистыми.

Source: [Mukesh Yadav](http://blogs.innovationm.com/solid-single-responsibility-principle/)

"Чистый" код лучше "умного" кода

Когда вы пишете программы вы склонны демонстрировать насколько вы умны, тем, как вы пишете код. Этот умный код был бы больше похож на загадку, чем на реальный кусок понятного кода. Читатель должен быть очень умен, чтобы понять, что делает ваш умный кусок кода. Написание кода такого типа никогда не будет полезным для вас. На самом деле никого не волнует, насколько умный ваш код, если он понятен и прост для всех.

Примером такого умного кода может быть вложенность теринарных операторов вместо обычной if-else конструкции.

let a = 10;
let b = 3;
let c = 25;

return a > b ? a : b; // нормально

return a > b ? (a > c ? a : c) : b > c ? b : c; // плохо

// нормально
if (a > b) {
  return a > c ? a : c;
} else {
  return b > c ? b : c;
}

Закон Деметры

Когда модули становятся взаимозависимыми друг от друга, они становятся тесно связанными. Это означает, что один класс будет иметь много зависимостей от других модулей. Тесная связь снижает гибкость и возможность повторного использования кода.

Закон Деметры был впервые введен Яном Холландом в 1987 году в Северо-Восточном университете. Этот принцип можно обобщить следующим образом:

  • Каждый модуль должен обладать ограниченным знанием о других модулях. То есть знать о модулях, которые имеют «непосредственное» отношение к этому модулю.

  • Каждый модуль должен взаимодействовать только с известными ему модулями «друзьями», не взаимодействовать с незнакомцами.

  • Общайся только со своими близкими "друзьями".

Аналогия из жизни: Если Вы хотите, чтобы собака побежала, глупо командовать её лапами, лучше отдать команду собаке, а она уже разберётся со своими лапами сама.

Этот принцип позволяет вам иметь независимые классы и код, которые более слабо связаны, так как зависимостей меньше. Любые сделанные изменения должны отражаться только на непосредственных друзьях.

YAGNI (You aren't gonna need it) - Тебе это не нужно

Мы склонны планировать заранее и готовиться к жизни. Но это не очень применимо в программировании. Этот принцип говорит о том, что люди пишут код, который им никогда не понадобится в будущем.

Другими словами, идея YAGNI - в том, что вам никогда не следует разрабатывать функциональность, которая вам может понадобиться в будущем. Скорее всего, вам это не понадобится, и вы попросту потеряете время.

Вы можете рассматривать это как конкретное применение принципа KISS как ответ тем, кто серьезно относится к принципу DRY. Неопытные программисты часто делают все возможное, чтобы избежать создания кода WET, написав максимально абстрактный и общий код. Но слишком много абстракции заканчивается раздутым кодом, который невозможно поддерживать.

Хитрость заключается в том, чтобы абстрагировать код только тогда, когда вы видите код, который нуждается в абстракции. То естье применяйте принцип DRY к коду, который, по вашему мнению, вы могли бы писать снова и снова в будущем.

Проще говоря - живи настоящим, а не будущим.

Source: [monkeyuser.com](https://www.monkeyuser.com/assets/images/2019/123-yagni.png)

Заключение

«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям ». Мартин Фаулер

Как говорится в цитате, написание чистого, понятного кода в наши дни является обязательным требованием. Вы не можете написать чистый код в одночасье. Это требует практики и практики. Вы должны медленно менять подход к проблеме и находить решения в чистом виде. Этот переход не будет мгновенным, скорее всего он займет несколько месяцев и несколько проектов.

Поскольку программирование является групповой задачей, успех вашего проекта во многом зависит от вашей команды. Следовательно, крайне необходимо, чтобы люди писали код, который их коллеги могут легко понять и поддерживать.

Надеюсь, вы чему-то научились из этого. Какой у вас опыт плохого программирования? Упомяните их в комментариях.

Удачной разработки!

Ресурсы