Всё, что должен знать разработчик ПО о качестве кода



Книга Всё, что должен знать разработчик ПО о качестве кода

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

Понятие качества кода 

Под качеством кода понимаются его характерные признаки и свойства. Они могут отличаться в зависимости от конкретных бизнес-задач организации и потребностей команды. И хотя у нас нет точного перечня контрольных показателей, тем не менее существует несколько общих критериев, отличающих хороший код от плохого.  

Критерии хорошего кода 

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

Диалог на картинке:

— Имей в виду, что я самоучка, поэтому, возможно, код “грязноват”.

— Посмотрим, уверена, что с ним все в порядке. Вот это да… Как будто я в доме, который построил ребенок, имея под рукой только маленький топорик и картинку с изображением. А еще напоминает рецепт салата, написанного корпоративным юристом с помощью автозамены в телефоне, знающей только формулы Excel. Похоже, что кто-то записывал разговор семейной пары, спорящей в Ikea, и вносил случайные поправки, пока не скомпилировал его без ошибок.

— Так, я все понял  —  иду читать руководство по стилю.

Примечательно, что разным программистам или командам свойственна субъективная трактовка всех этих критериев. Одному код покажется простым и понятным, а другой сочтет его запутанным и, следовательно, сложным в обслуживании. В связи с этим целесообразно обозначить определенные параметры, на которые можно будет ориентироваться. 

Документация, стандарты оформления кода и руководства по стилю 

Как говорил Дамиан Конуэй: “Документация подобна любовному посланию, адресованному самому себе в будущем”. Через комментарии или пометки в коде вы объясняете своему будущему прототипу, почему когда-то написали код именно таким образом или почему коллега-разработчик принял определенное решение в конкретный момент времени. Более того, опираясь на них, другие участники команды смогут понять логику принимаемых вами решений. 

Стандарты оформления кода также позволяют обеспечить его единообразие в процессе командной работы. Кроме того, они упрощают его использование и обслуживание. Уильям Мур описывает их как “последовательность процессов для конкретного языка программирования, подразумевающую соблюдение формата кода, методов и различных процедур”. 

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

Многие компании, такие как Google, Microsoft и WebKit, опубликовали свои стилевые рекомендации онлайн. На их основе вы можете создавать собственные аналоги. Помимо этого, есть множество руководств по конкретным языкам программирования. Alexander Van Tol, пишущий статьи для RealPython, предлагает несколько отличных ресурсов для программистов Python, включая советы по стилю и линтеры. 

Значимость ревью кода 

Ревью кода играют важную роль, способствуя повышению его качества и раннему выявлению проблем с возможностью их скорейшего исправления. Они также обеспечивают целостность и надежность создаваемого ПО. Для компаний, разделяющих принципы DevOps, такие проверки давно стали обычным делом и включаются в рабочий процесс на самых ранних стадиях. Чем раньше вы обнаружите ошибки, тем быстрее, легче и дешевле их получится устранить.

В течение 10 недель с июня по июль 2020 года компания SmartBear Software проводила всемирное онлайн-исследование, в котором приняли участие свыше 740 разработчиков ПО, тестировщиков, IT-специалистов, операторов и бизнес-лидеров из 20 различных производственных сфер. 92% респондентов назвали повышение качества ПО наиважнейшим преимуществом ревью кода. В число остальных вошли:

  • обмен знаниями внутри команды (81%);
  • возможность обучения менее опытных разработчиков (67%);
  • следование стандартам и соглашениям оформления кода (59%);
  • усиление сотрудничества (54%);
  • сокращение временных/денежных затрат на проект (31%);
  • внутренний аудит (26%);
  • возможность соответствовать нормативным стандартам (25%);
  • возможность формировать ожидания (24%);
  • повышение степени удовлетворенности/удержания клиента (19%);
  • повышение мобильности кода (17%);
  • повышение конкурентоспособности (16%);
  • сертификация ИСО/производства (10%).

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

Более того, свыше 80% опрошенных разработчиков отметили, что удовлетворенность процессами проверки кода напрямую связана с уверенностью в общем качестве готовых программных продуктов. 

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

Примерно 63% опрошенных по крайней мере каждую неделю участвуют в той или иной форме ревью. Если говорить о частоте и применяемом подходе, то 27% респондентов ежедневно проводят подобную проверку с привлечением соответствующих инструментов, а 19%  —  еженедельно.  

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

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

Инструменты для проверки качества кода 

Многие разработчики, уже использующие GitHub для обслуживания своих репозиториев Git, имеют опыт работы с пул-реквестами и форками для проведения ревью кода. Кроме того, в нашем распоряжении большое разнообразие других инструментов, позволяющих командам автоматизировать процесс. 

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

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

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

Рефакторинг кода 

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

Уменьшение технического долга 

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

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

Заключение 

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

45   0  
    Ничего не найдено.

Добавить ответ:
Отменить.