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

Как мы пишем код

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

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

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

Возьмите за привычку поддерживать качество кодирования

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

Зачем проверять код

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

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

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

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

  1. Может ли член моей команды понять этот код без моего объяснения?
  2. Смогу ли я понять код, просто взглянув на него через 6-7 месяцев?
  3. Действительно ли я доволен качеством кода

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

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

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

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

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

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

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

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

Мы всегда должны оставлять мир в лучшем месте, чем мы нашли

Всегда будь суров к себе

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

Первоначально опубликовано на https://blog.smartcodehub.com 30 августа 2020 г.