5 способов повышения качества кода
Немногие программисты задумываются над улучшением качества кода. Действительно, это не так просто, если за плечами несколько успешных проектов и целая очередь из заказчиков и потенциальных работодателей. Или опыта нет вовсе, а главная цель — чтобы работало. Но всё же подумайте, удовлетворяет ли ваш код следующим критериям:
- его можно прочитать один раз и понять;
- он содержит минимум ошибок и потенциальных уязвимостей;
- соответствует стандартам языка и основным принципам построения;
- делает в точности то, что от него хочет клиент или заказчик.
Эти критерии позволяют отделить качественный код от просто работающего. Код, который делает разницу между разработчиком и кодером. Чтобы понять все аспекты его создания, достаточно прочитать всего 2 книги:
А пока вы выискиваете на это время, позвольте тезисно рассказать о 5 основных заповедях создания превосходного кода:
Использование линтера
Линтер – утилита для проверки код на соответствие стандартам и спецификациям языка. К примеру, для Python он существует в виде пакета Pylint, для JavaScript – ESHint, для Java – FindBugs и т.д.
Для любого популярного языка и среды разработки вы без труда подыщете линтер с гибкими настройками. Вам не составит труда отключить «принципиальный» пункт, но в остальном ваш код будет выполнен профессионально. К сожалению, линтеры не часто используются разработчиками. Причина – самоуверенность, помноженная на лень. Никто не хочет добавлять лишние шаги в процесс выпуска, тем более, если стандартный компилятор не выявил ничего криминального.
На практике же стиль кода и стандарты языка часто являются основой для создания надёжного кода, который легко читается и правится, а главное – работает. А ведь именно это - цель разработки.
Контроль разработки
Несмотря на существование систем непрерывной интеграции и развертывания, большинство начинающих программистов игнорирует автоматизацию разработки. Что ещё хуже, вместо использования инструментов, вроде Bamboo или Jenkins, они отдают предпочтение бумажному блокноту или простой таблице в Excel.
В результате вы можете перепрыгивать определённые этапы, в частности, проверку упомянутым линтером. Экономия времени и средств получается незначительная по сравнению с использованием систем непрерывной интеграции, а вероятность пропуска ошибки куда выше.
Создание чёткого кода
На GeekBrains неоднократно выходили статьи с рекомендациями по оформлению качественного кода. Они сводятся к 4 основным пунктам:
- Умеренное комментирование.
- Правильные имена.
- Ограничение объёма блоков.
- Чёткая структура кода.
Комментарии не должны пояснять отдельные строки и тем более имена. Комментарии – это сообщение другому разработчику, что происходит во всей программе или отдельном блоке. Это возможность временно отключить часть функциональности. Это заметка для себя во время разработки. Но это не инструмент перевода написанного кода в человеческий язык.
А вот названия функций и переменных должны делать конкретную строку кода понятной для других разработчиков. При этом длина должна укладываться в разумные пределы: в зависимости от языка предел составляет 15-25 символов. Если ваше имя больше – потратьте ещё 30 секунд на обдумывание.
Следить также следует за длиной функций и циклов. К примеру, Google C++ Style Guide рекомендует ограничение в 40 строк, всё, что больше – лучше разбить на более мелкие части. Цифра здесь – ориентир, главное – сохранить читаемость кода. Если разбиение 100 строк кода на 5 логических блоков пойдёт только во вред – лучше оставить как есть.
В структуре кода главное сохранять иерархию и, как с функциями, при возможности не перегружать отдельные блоки и файлы функционалом. Например, в Java полезно придерживаться правила «один класс за файл», а потом группировать их по смыслу. Аналогичного принципа дробления на «кирпичи» придерживайтесь и в других языках.
Тестирование кода
В начале мы задали условие, что качественный код должен выполнять все требования заказчика, а также сохранять рабочее состояние при всех условиях. Для того чтобы проверить это на практике, необходимо использовать специальные тесты. Как и в случае с линтерами, новички игнорируют потребность в них, ограничиваясь методом «научного тыка». Такие проверки неэффективны и подсознательно обходят все проблемные места.
Вне узкопрофильной разработки ПО, где у каждого программиста своя функция, за создание тестов отвечает тот же, кто пишет код. На практике эффективно разрабатывать рабочую программу и тест одновременно. Благодаря этому вы контролируете работоспособность каждого участка кода, а не всей программы в целом.
Не стоит обходить вниманием модули автоматизированной проверки, позволяющие найти любые конфликты. Несмотря на простоту алгоритма «подключил и проверил», рассчитаны они на продвинутую аудиторию со сложными продуктами. Большинство из них требует настройки или осуществляет тестирование перебором всевозможных вариантов, что не слишком показательно для заказчика. Поэтому для начала лучше научиться создавать свои.
Обзор кода
Финальная стадия проверки качества кода, которая даже не входит в системы непрерывной интеграции. Алгоритм простой:
- Перечитываете свежесозданный код целиком. Если ни разу не задумались над выполняемым действием – первый этап проверки пройден.
- Передаёте код ментору, соседу или старшему по должности коллеге. Наверняка у них нет ни времени, ни желания разбираться с чужим кодом, так что эти комментарии покажут читаемость. Главное, чтобы его обзор не ограничился вашими комментариями.
- Передаёте код руководителю или заказчику. Если у него возникают уточняющие вопросы по именам или алгоритмам – это повод всерьёз задуматься о качестве кода.
Для тех, кто обучается на курсах или самостоятельно по книгам, рекомендуем найти на форуме «друга по проверке» со схожими познаниями. Проверяя друг друга, тренируясь задавать правильные вопросы и отвечая на них, вы будете обучаться программированию быстрее, а код делать надёжнее и чище. Ведь это именно то, к чему должен стремиться каждый разработчик.
Вы следите за качеством своего кода?