Важные концепции, которые помогают писать лучший и простой код

Типичное сохранение между двумя программистами,

Dev1: «Привет, я почти завершил изменения для этой функции. Я взял тот старый за образец и разработал этот »
Dev2:« Отлично! Затем давайте запустим и протестируем это на вашем локальном компьютере »
Dev1: * Создает локальный проект и запускает его *
Программа: * Не работает для сборки *
Dev2:
«Ой, что здесь не так?»
Dev1: «Я не уверен. Думаю, я все сделал правильно »
Разработчик2:« Дай-ка я посмотрю… .. Даже, я не уверен, что не так. Давай спросим кого-нибудь »

Dev1, Dev2 вызывают Dev3.

Dev3: * изучает код *
Dev3: «Я не понимаю, что здесь не так. Кажется, все правильно. "

На протяжении всего разговора мы видим одну общую черту.

Неопределенность! Неуверенность в том, что происходит.

Путаница! Не совсем понимаю, как все сочетается.

Почему это происходит?

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

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

Принцип DRY

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

Поэтому, когда кто-то говорит, что ваш код НЕ СУХОЙ, это не означает, что вы окунули свою IDE в бассейн с водой (я знаю, что это плохая шутка), но они имеют в виду, что вы повторяете одно и то же снова и снова.

Написание СУХОГО кода в конечном итоге приводит к меньшему количеству кода. Таким образом, меньше кода означает меньше сложности для понимания. В конечном итоге это приводит к простоте обслуживания кода.

У каждого программиста есть собственное определение меньшего количества кода. Некоторые программисты устанавливают 150 строк в качестве порогового значения для класса, чтобы гарантировать простоту, у других - 200 строк, и это значение постоянно меняется от человека к человеку.

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

Написание СУХОГО кода

Простой способ сделать ваш код СУХИМ - сначала определить повторяющийся код. Но дело не только в коде, но также в логике и поведении. Если вы чувствуете, что какая-то логика или функция или операция повторяется, но меняются только входные данные, вы всегда можете извлечь ее как функцию и вызвать функции с соответствующими входными параметрами в качестве параметров.

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

Помещая дублированный код в функцию, мы фактически реорганизуем наш код. Рефакторинг - это не что иное, как изменение кода без изменения его поведения.

Принцип KISS

Аббревиатура KISS расшифровывается как Keep It Simple Silly или Keep It Simple Stupid. Думаю, уже понятно, о чем идет речь. Код вашего приложения должен быть простым и понятным. Простое означает разные вещи для разных людей. Чтобы не усложнять, вы должны убедиться, что ваш код не слишком запутан и сложен, но его легко читать. Для этого нам нужно знать, когда код становится сложным для понимания другим человеком.

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

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

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

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

Спасибо, что прочитали эту статью! Не стесняйтесь делиться своими комментариями / мыслями.

Давайте вместе сделаем программирование увлекательным! Подпишитесь, чтобы получить больше контента!

Присоединяйтесь к FAUN: Веб-сайт 💻 | Подкаст 🎙️ | Twitter 🐦 | Facebook 👥 | Instagram 📷 | Группа Facebook 🗣️ | Группа Linkedin 💬 | Slack 📱 | Cloud Native Новости 📰 | Еще .

Если этот пост был полезен, нажмите несколько раз кнопку хлопка 👏 ниже, чтобы выразить поддержку автору 👇