Качество кода: бесконечный цикл рецензирования

Давным-давно

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

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

В любом случае, я получил свой проект обратно и, бум, 75%. Я был сбит с толку. Я смотрел код, и все комментарии были положительными. Итак, я иду к своему профессору, и он говорит: «Ваше приложение сделало все возможное и сделало все, что должно было, и даже больше! Но ваш код плохой ». Я спрашиваю "Каким образом?" и он упоминает: «У вас плохое качество кода». Когда я спросил, как я могу повысить качество кода, он дал мне развернутый ответ, и я сломал ответ, и я пишу об этом в этом блоге.

Заказ в кодовой комнате

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

Почему это плохо отформатировано? Что ж, вы, наверное, догадались. Если нет, позвольте мне сказать вам. Импорт, который у вас есть в начале файла, станет более читабельным, если вы разместите его по порядку. Не обязательно должен быть в алфавитном порядке, но импорт с одними и теми же пакетами должен быть вместе. ЕСЛИ есть некоторая путаница, посмотрите на пример ниже:

Здесь мы видим больший порядок в импорте. Каждый раз, когда я хотел бы проверить пакеты с помощью java, они упорядочены друг под другом и так далее. Поначалу это может показаться сложной задачей, но на самом деле это очень просто. Что касается меня, я использую IntelliJ IDEA для разработки Java, и вот как я настроил свои настройки:

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

Единственное место, где не стоит пытаться найти значение X

Итак, мы закончили форматирование импорта правильно, и теперь пора приступить к кодированию! Конечно, все, что я собираюсь сказать, я делал виновным. При написании кода очень важно сделать его максимально понятным и читаемым для следующего человека, который его неизбежно увидит. ПЕРЕМЕННАЯ. ИМЕНА.

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

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

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

В кодировке допустимы только буквы i и j! И только внутри петель! Если вы можете сказать мне, что ДЕЙСТВИТЕЛЬНО обозначает каждая переменная, вы - абсолютная легенда. Я не думаю, что мне нужно объяснять, почему это также неприемлемый способ написания кода. Рецензенты или ваши коллеги не должны пытаться расшифровать эту древнюю мистическую функцию, которая имеет наглость называть себя классом.

Теперь давайте посмотрим на правильное соглашение об именах:

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

Но он работает на моей машине!

Тестирование. Тестирование. Тестирование. Подождите… ТЕСТИРОВАНИЕ! Единственный способ узнать, что ваш код действительно пуленепробиваемый [или насколько возможно] - это тестирование. Есть много сценариев, когда вы пишете фрагмент кода, загружаете приложение, и все в порядке, Дори, Боб - ваш дядя! В тот момент, когда кто-то другой пытается запустить его на своей машине или, не дай бог, вы пытаетесь развернуть, код начинает рассыпаться, как несвежее овсяное печенье с изюмом. Причина, по которой это случается иногда, заключается в том, что:

  • В вашей среде могут быть разные настройки (например, переменные пути)
  • В вашей среде IDE могут быть исправлены некоторые проблемы, возникающие в коде с помощью некоторых параметров, установленных в среде IDE.

Прелесть чего-то вроде Java в том, что вы можете «написать один раз, запустить везде». Так что убедитесь, что он работает везде!

Добро пожаловать на борт! Выяснить код

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

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

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

Ты будешь судим

Вы знаете, что лучше, чем два глаза, смотрящие на ваш код. Четыре. Даже шесть. Я не говорю о том, чтобы ваш код проверял паук [заранее прошу прощения за то, что вы написали эту шутку]. Иногда мы думаем, что наш код надежен, но это не всегда так. Что-то очень полезное - это принудительное рецензирование. Вы можете сделать это, установив минимальное количество утверждающих, если вы используете программное обеспечение для контроля версий, такое как GitLab или GitHub.

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

Заключение: прочтите, затем прочтите еще раз

Обращайтесь со своим кодом так же, как с групповыми чатами друзей в WhatsApp:

  • Напечатайте его так, чтобы каждый мог его понять, сделайте его читаемым для всей вашей аудитории.
  • То, как вы говорите о важных вещах, никто не поймет по-испански, если все будут говорить только по-английски. Если только они не сделают все возможное, чтобы выяснить, что вы имели в виду, говоря это. Так что просто пообещайте мне, что вы не назовете одну из своих переменных potato 🥔. Потому что тогда вашим товарищам по команде придется «искать», что означает эта переменная.
  • Точно так же вы строите планы, которые подходят для всей группы и чтобы каждый мог присоединиться к ним и хорошо провести время, сделайте так, чтобы ваш код мог запускаться кем угодно, и они хорошо проводили время, выполняя его.
  • Когда вы строите с ними планы, вы указываете место, время и кто может присоединиться. Не делайте так, чтобы в ваших планах с друзьями было больше документации, чем ваш код. Документ. Ваш. Код. Пожалуйста.
  • И последнее, но не менее важное: будьте готовы получать отзывы. Примите эту обратную связь, обработайте ее и работайте над улучшением.

А теперь идите и напишите возвышенный код! Возьми? Возвышенный? Ладно, по крайней мере, попробовала ...