Привет, коллеги. Так уж вышло, что писать хороший код - не такое тривиальное занятие, тем более, что мало кто вообще использует какое-то общее определение "хорошего кода". Тем не менее, есть несколько несложных приёмов, выполняя которые можно существенно улучшить себя. Это и обсудим.
Не буду углубляться в подходы; лишь обозначение методики и краткое описание преимуществ и особенностей.
Чек-лист
Любая разработка - это набор действий, которые надо выполнить. Иногда, мы держим их в голове и выполняем последовательно. Тут проблема заключается в том, что попытка всё делать сразу неизбежно приводит к тому, что что-то да и забывается, упускается из виду, кажется неважным сейчас и остаётся не сделанным потом.
И тут на помощь приходит список дел или, как его называют, чек-лист. Просто пишем то, что надо сделать в нужном порядке и просто идём по нему. Шансы пропустить что-то важное сильно сокращаются. Хотя, безусловно, тут потребуется потратить некоторое количество времени и усилий, чтобы создать по-настоящему рабочий чек-лист. Для простых задач (вроде похода в магазин) достаточно одной итерации; для чего-то более сложного (скажем, написать плагин для почтового сервера, шифрующий отправляемые сообщения) - понадобится подумать, что же в этот список должно попасть.
Может потребоваться несколько итераций, прежде чем список будет соответствовать потребностей. Но тут есть прямая закономерность: чем длинней список, тем больше вероятность, что без него результат вышел бы сильно хуже.
Контроль версий, автоматизация, командная строка
Если не используете Git - самое время начать (можно выбрать и другую систему контроля версий; важно, чтобы была возможность переключаться между версиями кода).
То же про автоматизацию: сборка, тестирование, создание выходных артефактов (CI/CD). Если кода ещё очень мало и тестов вообще нет - используйте заглушки; автоматизируйте сборку. Можете использовать Jenkins или встроенные сервисы репозиториев. Тут главное начать; контроль версий вместе с автоматизацией обеспечат вас всегда готовым (даже если и сырым) продуктом.
Не нравятся предложенные инструменты - найдите и освойте те, что понравятся. И да, все действия крайне желательно выполнять из командной строки (я, например, работаю под Linux и мне привычен bash, но и для Windows есть как WSL, Cygwin Terminal, так и cmd или PowerShell). Командная строка позволяет сильно автоматизировать процесс (кликанье мышкой по кнопкам в открывшемся окне автоматизировать возможно, но сильно сложней).
Хорошей идеей будет написать некоторый скрипт, который бы автоматически подготавливал все артефакты для нового проекта.
Данный список "чего бы ещё неплохо было бы иметь" можно сильно расширить разными средами (скажем, для тестирования и готового результата), контейнерами и много чем другим, но не всегда это требуется.
Инструменты контроля качества кода
Сообщения (предупреждения) компилятора, линтеры, статические анализаторы, защитники стиля и форматирования кода позволяют уже на начальном этапе избежать довольно значительного количества ошибок. И если статические анализаторы кода - штука весьма неоднозначная (не то, чтобы очень часто используется), то всё остальное присутствует в открытом доступе. Но тут всё зависит от языка разработки.
Ну и да, если есть ошибки (или даже предупреждения), то крайне желательно от них избавляться. Даже если всё работает. Даже если, порой, придётся принудительно пропустить проверку какой-то строки, потому что сложно найти нужную ошибку среди сотни других уведомлений.
Если приходится работать с обширной кодовой базой, то лучше проверять ошибки и устранять их по частям (сперва, например библиотека 1, потом компонент 2 и так далее). Когда очередной объект проверен - повысить приоритет с "предупреждение" до "ошибка".
Кто-то мог бы посоветовать инструменты типа Chat GPT или Copilot, однако я пока что к такому инструментарию отношусь с настороженностью: сгенерированный код далеко не всегда хорош и работает верно, а исправлять ошибки бывает довольно тяжело. Впрочем, со временем это может измениться в лучшую сторону.
Качество кода
Увы, следить за качеством кода придётся всегда. Если этого не делать, то маленькие проекты, после превращения в большие, перестают поддерживаться и даже небольшие изменения требуют колоссальных усилий, чтобы внести правки и ничего не сломать при этом. Тесты немного помогают, но лишь немного, а достаточно низкое качество продукта гарантированно отправляет его на свалку.
Другой крайностью является прокрастинация через перфекционизм, когда желание создать наилучший возможный результат приводит к бесконечным переделкам и затягиваниям сроков, что, в конечном итоге, нередко приводит к тому, что продукт так и не доживает до завершения. Лучшее - враг хорошего (а, порой, и просто приемлемого).
Думаю, качество кода - вполне управляемый параметр, если пользоваться инструментарием и методиками, описанными выше.
Ещё один немаловажный момент, связанный с кодом, сводится к простому утверждению:
Мы больше читаем код, нежели пишем
Надеюсь, намёк понятен? Если нет, то проясню: код следует изначально быть оптимизированным для чтения, иными словами, написание кода - это не просто написание кода, а написание кода, который легко "уместить в голове", а прочитав - понять, о чём речь (забываем про глобальные переменные, многочисленные модули с вынесенным функционалом с невнятными названиями методами): увидел код - прочёл - понял.
Ну, неужто вы думали, что эволюционировать в инженера-программиста будет просто?
Далее
Хотел бы я сказать, что этого достаточно, но, разумеется, это не так.
Подытожим: чек-лист, инструментарий поддержки приложения, инструменты совершенствования качества кода и написание качественного кода. Самое сложно - написание качественного и понятного кода.
А вот и продолжение темы.
