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

5 основных ошибок, которые допускают команды разработчиков

  1. Отсутствие стандартов для проекта, таких как соглашения об именах для CSS, переменных JavaScript и изображений, папок и URL-адресов.
  2. Не рецензирование с коллегами
  3. Прыжки во фреймворк, не зная, что этот фреймворк решает
  4. Не думать о масштабируемости
  5. Не думать об обслуживании во время кодирования

1. Отсутствие стандартов, которым нужно следовать в проекте

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

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

2. Отсутствие рецензирования с коллегами

Когда у вас есть контрольный список с набором стандартов, вы готовы провести обзор в соответствии с этими рекомендациями.

При написании кода мы в основном концентрируемся на завершении кода. В спешке у нас есть шансы пропустить стандарты в некоторых местах. Доставка кода без их исправления будет преследовать нас во время обслуживания.

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

3. Прыгать во фреймворк, не зная, что этот фреймворк решает

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

Если мы посмотрим на веб-разработку, JavaScript является основой для каждого фреймворка, такого как Angular, React, Vue и т. д. Если мы знаем JavaScript, мы можем кодировать на нем без особых усилий. Но каждый из примеров решает большую проблему. Например, Angular больше ориентирован на компоненты и двустороннюю привязку переменных, тогда как React больше ориентирован на компоненты и одностороннюю привязку переменных.

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

4. Не думать о масштабируемости

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

Потому что кодирование без учета масштабируемости приведет к повторному написанию кода позже.

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

Перед началом кодирования просмотрите все свое приложение и спланируйте, какие элементы повторяются, и сделайте их компонентами. Если вы считаете, что одна логика/функция повторяется, сделайте ее сервисом.

5. Не думать об обслуживании во время написания кода

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

Мораль истории

  • Перечислите свои требования к разработке продукта и изучите различные доступные платформы, рассмотрите преимущества платформы и выберите ту, которая соответствует вашим требованиям к продукту.
  • Определите стандарты продукта в начале, и все в команде должны им следовать.
  • Полностью изучите продукт и спланируйте масштабирование продукта в будущем. Принципы SOLID помогут вам
  • Планируйте структуру папок, схему и код БД таким образом, чтобы сэкономить время обслуживания (поставьте себя на место другого разработчика).
  • Принимайте последовательные экспертные оценки со стандартами в качестве контрольного списка

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