Практика кодирования, за которую вы будете любить себя в будущем

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

Мартин Голдинг

Вот 6 методов кодирования, которые я принял за последние 10 лет, чтобы гарантировать, что у моего будущего я будет меньше грехов прощать.

1. Стандартизировать форматирование кода

Любая кодовая база читается намного больше, чем написано. Код с постоянным форматированием легко читается и понятен каждому в команде. Стандартное форматирование гарантирует, что ваш глаз и ваше подсознание могут беспрепятственно искать переменные, фигурные скобки, функции и т. Д. Голанг отлично справляется со своей задачей, предоставляя gofmtкоманду в стандартной библиотеке. На этом закончились все обсуждения форматирования, которые так часто встречаются в обзорах кода в сообществе Golang.

2. Не следуйте принципу СУХОЙ вслепую

СУХОЙ (не повторяй себя) — почти мантра для разработчиков. Но если применять без разбора, это приводит к абстрактному коду, который трудно читать и понимать. Это также останавливает различные части кода, чтобы развить их в полном объеме. Не следуйте принципу СУХОЙ вслепую. 

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

3. Отладка кода через логи

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

Слишком много регистрации == нет регистрации .

4. Остерегайтесь преждевременных оптимизаций

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

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

5. Не усложняйте свою кодовую базу ненужными функциями

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

6. Настройте конвейер CI / CD в начале жизненного цикла разработки.

Даже если это шоу «один-два человека», конвейер CI / CD уменьшает накладные расходы на запоминание (и выполнение) сборки и развертывания конкретной кодовой базы. Распространенным предположением является то, что конвейеры CI / CD важны только в командах, которые ежедневно внедряют много кода в производство. По моему опыту, конвейеры CI / CD еще более важны для баз кода, которые редко затрагиваются, потому что вы не помните, как и где был развернут код. Это особенно верно, если вы обновляете код только один раз в год. Кроме того, наличие конвейера CI / CD гарантирует, что у вас есть контролируемый версией скрипт, который точно скажет вам, о чем вы думали X месяцев назад. 

Добавить комментарий

Войти с помощью: