Брэм Коэн, автор BitTorrent, писал: "То, что мог бы написать любой идиот, обычно имеет качество написанного идиотом". И действительно, несмотря на постоянное пополнение рядов программистов, качеством кода могут похвастаться не все.
Отличительные признаки хорошего кода:
Другие важные характеристики качественного кода – это документированность, наличие комментариев и лаконичность. Совокупность этих признаков позволяет считать код чистым и красивым – таким, каким он и должен быть.
Качество кода напрямую влияет на жизнь продукта после релиза. Если код плохой, то его приходится регулярно исправлять и на этапе создания программы, и после ее релиза. Несомненно, приложение может быть хорошим и востребованным, однако нестабильность работы значительно снижает удовлетворенность пользователей. Если же код хороший, то в дальнейшем даже не участвовавшие в написании кода программисты могут быстро внести правки.
Источник: Cyanide and Happiness
Все действия, заданные кодом, должны быть последовательными и логичными. Это упрощает работу с ним, позволяя отследить цепочку размышлений разработчика и понять, как должны функционировать процессы программы. Линеаризация состоит из нескольких этапов: выделить главную ветвь алгоритма, вынести ее на наименьший уровень вложенности и рекурсивно повторить с подветвями. Должно получиться что-то такое:
Стоит избегать многочисленных повторов, если их можно объединить одной функцией. Если некоторые части кода не используются, стоит подумать об их удалении, чтобы не усложнять понимание. Не стоит изобретать велосипеды и загромождать ими код. Многие задачи, которые стоят перед программистами, уже давно решены; стоит просто поискать получше.
Комментарии нужны не всегда, однако иногда они необходимы, чтобы специфицировать контракт класса или метода, документировать библиотеку или просто пояснить код. В любом случае, их не должно их быть и слишком много. Они должны объяснять, что и почему делает программа, а не как у нее это выходит.
Иногда перенос блоков кода в комментарии объясняется благими намерениями программистов: мало ли, кому он может понадобиться в будущем. Например, это происходит, когда часть программы полностью переписывается, но перечеркивать проделанную работу жалко – вот она и пылится в комментариях месяцами. Если часть кода можно убрать, то это нужно сделать.
Разработчик должен не только писать код, но и проверять его функциональность. Регулярное тестирование программы – один из важных факторов ее качества. Если затянуть с этим процессом, то код будет слишком длинным, и поиск багов займет куда больше времени, чем мог бы.
Несомненно, стремление к качественной и продуктивной работе похвально. Однако переработки приводят к выгоранию, а следование эталонам лишает возможности найти более простое и красивое решение. Следовательно, нужно работать со свежей головой и позволять себе отступать от шаблонного понимания того, как правильно писать код. Так разработчик сможет оптимизировать форму и содержание кода и сократить время работы с ним в будущем.
Не стоит относиться к ошибкам с ненавистью и яростно бороться с каждой мелочью. Конечно, от багов необходимо избавляться, но этот процесс должен идти на пользу и программе, и программисту. Это позволяет учиться избегать однотипных ошибок в будущем и относиться к коду более внимательно, поэтому стоит запастись терпением и принять эту часть работы с ПО.
В начале создания кода мы продумываем его архитектуру – структурные элементы, интерфейсы, их взаимодействие и общий архитектурный стиль. Иногда это происходит быстро, но при работе над большими и сложными проектами мы углубляемся в процесс и уделяем внимание всем деталям. Важно, чтобы разработанной архитектуры придерживались все, кто работает над программой. Это позволит выстроить четкую и красивую систему, с которой будет просто и приятно работать.
Можно закинуть вещи в шкаф одной большой кучей и поплотнее его закрыть, чтобы ничего не вывалилось, а можно аккуратно разложить все по полочкам. Результат один: вещи внутри, шкаф закрыт. Однако снова доставать и перекладывать вещи будет удобнее во втором случае. Так же и с кодом: если возникает необходимость, мы переписываем его более аккуратным способом, не меняя функционал. Это положительно сказывается на его понимании и снижает количество потенциальных проблем.
Код наших младших разработчиков проходит через проверку более опытными специалистами. Это позволяет посмотреть на выполненную работу свежим взглядом, найти зоны роста и, конечно, отладить код. Нередко старшие разработчики анализируют код друг друга, чтобы еще и поделиться опытом. Бывают и ситуации, когда junior-разработчики свежим взглядом смотрят на код опытных коллег и вносят удачные правки. Такая совместная работа позволяет повысить качество и читаемость кода.
Это автоматическая проверка кода, для которой не требуется выполнение программы. Преимущество статического анализа заключается в том, что он не требует временных затрат людей и отмечает ошибки, которые человек мог пропустить при code review. Благодаря этому мы удваиваем пользу от проверки кода и делаем его более совершенным.
Если вы хотите сэкономить деньги и время, которые потратили бы на работу над ошибками после релиза приложения, уделите вниманию качеству кода. Мы в Azoft не понаслышке знаем о том, что такое хороший код, и будем рады показать вам это на живом примере. Пишите на [email protected] или оставьте контакты в форме внизу страницы. Мы будем рады сотрудничать с вами!
Все
Технологии
Ликбез
Места
HowTo
Стартапы
Новости
Сервисы
Приложения
