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

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

1- Обновление пакетов:

Обычная задача ежедневной работы разработчика — установка пакетов и библиотек для поддержки часто используемых функций. Если вы работаете над интерфейсным проектом, вы можете использовать npm, менеджеры пакетов yarn и pip, composer и т. д. для серверных проектов.

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

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

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

НЕ обновляйте сразу все пакеты проектов.

Что делать?

  • Начните с наименее используемого пакета/библиотеки в проекте. Обновите до последней версии и протестируйте конкретную функцию, использующую пакет.
  • ВАЖНО: зафиксируйте изменения с правильным сообщением о версии. Например: Обновите плагин XXX до версии x.x.x.
  • Выберите следующий пакет, обновите его и снова протестируйте приложение.
  • Повторите этот процесс для каждого пакета.
  • Будьте особенно осторожны при обновлении пакетов, которые наиболее широко используются в проекте.

2- Украсить/украсить файлы проекта:

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

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

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

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

Что делать?

  • НЕ запускайте prettier/beautify для всего проекта.
  • Вы можете работать с 3–4 файлами одновременно. Украшайте только те файлы, над которыми вы сейчас работаете.
  • Вы можете настроить редактор таким образом, чтобы он преобразовывал код при каждом сохранении.
  • Продолжайте фиксировать предварительно обработанные файлы в системе контроля версий после того, как убедитесь, что изменения работают нормально.

3- Рефакторинг:

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

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

Рефакторинг кода — это процесс реструктуризации существующего «компьютерного кода — изменение факторинга — без изменения его внешнего поведения».

– Википедия

Что делать?

IMO, вам будет легче выполнять рефакторинг, если ваша кодовая база имеет хорошее тестовое покрытие. Выполнение рефакторинга может легко испортить код в нескольких местах. Вы можете попытаться сохранить свой код СУХИМ (не повторяйтесь), фактически не проверяя все крайние случаи. Следовательно, автоматизированное тестирование помогает.

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

Вы собираетесь рефакторить код или переделывать код?

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

Удачного кодирования!!! 🙂