Принципы кодирования

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

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

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

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

Как они помогают следовать этим принципам?

Свобода публикации компонентов из любой кодовой базы означает, что больше кода используется и используется повторно — в соответствии с принципом DRY. Это также означает, что вы не создаете полную систему проектирования с компонентами пользовательского интерфейса, которые никогда не будете использовать — вместо этого каждый компонент собирается и публикуется только тогда, когда это необходимо — в соответствии с принципом YAGNI.

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

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

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

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

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

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

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

- Каждый юнит должен иметь только ограниченные знания о других юнитах: только юниты, «тесно» относящиеся к текущему юниту.

- Каждый юнит должен разговаривать только со своими друзьями; не разговаривай с незнакомцами.

- Поговорите только со своими непосредственными друзьями.

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

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

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

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

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

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

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

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

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

Заходите на наш сайт чтобы прочитать другие стать!