Как написать хороший код: 6 советов для начинающих программистов

Качество кода — важный критерий при оценке разработчика.

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

Я программирую почти 10 лет, из них 4 года занимаюсь корпоративной разработкой. Мой самый масштабный проект связан с кэшбэком в приложении Т⁠-⁠Банка. Я руковожу командой, которая делает внутреннюю платформу для менеджерского сопровождения спецпредложений и партнеров.

В основном пишу на Java, но иногда готовлю небольшие проекты на Kotlin, Scala и на TypeScript. Чаще работа связана с бэкендом, поэтому советы в материале пригодятся в первую очередь бэкендерам.

На оценку кода влияет много критериев, но их можно условно разделить на две категории:

1. Общепринятые — те, которых стараются придерживаться все разработчики. Это соответствие требованиям, заданным создателями языка программирования. Например, в Java названия методов должны быть глаголами.
2. Локальные — критерии качества, установленные отдельной командой разработчиков на уровне собственно небольшой команды, отдела или компании. Допустим, в команде не принимают код без комментариев.

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

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

1. Роберт Мартин «Чистый код» — легко читается, конспект есть на «Хабре». По мнению Мартина, хороший код решает конкретную задачу и в него просто вносить изменения. Автор советует относиться к написанию кода как к созданию книги: готовить черновик и редактировать его, делая понятным для читателя. И не бояться удалять «мертвый код», который нигде не используется.
2. Стив Макконнелл «Совершенный код». Рекомендую, если хочется почитать что⁠-⁠то объемное. Эта большая и тяжелая книга заставляет задуматься о том, как ты программируешь, и активнее совершенствовать код.
3. «Паттерны объектно-ориентированного программирования». Полезная книга, которая рассказывает про организацию кода. Ее авторов — разработчиков Эриха Гамму, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса — прозвали «бандой четырех».

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

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

Хороший программист стремится к порядку и разбивает данные на логические части — модули. Наименее ресурсозатратный подход — дробить код по принципу «один блок — одно действие». Тогда компоненты программы не зависят друг от друга, их легче менять и использовать снова. Кроме того, такой код быстрее и удобнее отлаживать: вам не придется тратить много времени на тестирование и поиск нужной информации.

Оформление кода определяется кодстайлом — специальными правилами написания программы. Они нужны, чтобы код выглядел опрятно и легко читался. Так его проще дорабатывать и поддерживать.

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

• run — метод, который запускает новый поток;
• getBackground — функция для получения цвета фона объекта.

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

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

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

Чтобы быстро найти дублирующийся код, пригодятся два способа:

1. Код⁠-⁠ревью — когда код проверяет не автор, а другие разработчики из того же проекта. Это стимулирует команду делиться лучшими практиками и придумывать новые решения, которые сделают код эффективнее. Кроме того, в результате обычно повышается читаемость кода. Подробнее о код-ревью можно прочитать на «Хабре».
2. Специальные инструменты. Современные IDE умеют находить и подсвечивать дублирующийся код. При правильной настройке приложение автоматически выявит повторяющийся метод и заменит дубли. Также есть различные инструменты для анализа кода, например платформа SonarQube. Их можно встроить в пайплайн сборки кода и автоматизировать проверку на дубли.

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

Вместе с тем оптимизация требует времени и делает код сложнее. Последнее затрудняет поддержку: другим программистам придется дольше вникать в код, а после — тратить больше времени на его доработку.

Грамотная оптимизация предполагает баланс между повышением производительности и усложнением кода. Разумеется, в процессе могут возникнуть ошибки — от этого никто не застрахован. Чтобы облегчить себе работу, сначала посмотрите код целиком и оцените, проверьте структуру, наименования разных частей. То, что не соответствует стандарту, потенциально может привести к багам, а следовательно, это и нужно править.

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

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

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

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

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

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

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

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

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