Статьи

Улучшите качество вашего программного обеспечения за 6 шагов

Ваши клиенты продолжают жаловаться на ошибки в вашем программном приложении? Требуется ли вам слишком много времени для внедрения новых функций? Если вы ответили « да» , то у вас, вероятно, есть проблемы с качеством вашего программного приложения. Вот 6 практических шагов, которые вы могли бы выполнить, чтобы улучшить его качество.

Прекратить создавать новые проблемы качества

Независимо от того, что происходило в прошлом, теперь вы несете ответственность за то, чтобы не вносить никаких новых проблем с качеством в исходный код, который вы пишете.

Шаг № 1: Установите SonarLint

Как разработчик, установите SonarLint в вашей любимой IDE (например, Eclipse), и вы будете удивлены, обнаружив, что он будет определять проблемы качества в вашем коде во время набора текста, давая вам подробные инструкции о том, что именно вы сделали неправильно, а также, что было бы правильным способом исправить это.

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

Шаг № 2: Настройте качественные ворота в SonarQube

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

Где вы проводите большую часть своего времени?

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

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

Шаг № 3: Рефакторинг часто меняющихся файлов

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


git log —format = format: —name-only |
egrep -v ‘^ $’ | сортировать | uniq -c | sort -r> commits_per_file.txt

Эта команда напечатает список отсортированных файлов из вашей кодовой базы, причем наиболее часто изменяемые (то есть имеющие наибольшее количество коммитов) будут отображаться первыми, как показано ниже:

Commits  File

230      gr/kolaxis/Utils.java
220      gr/kolaxis/UserManager.java
210      gr/kolaxis/UserTemplate.java

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

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

Шаг № 4: Сосредоточьте свои тесты на часто меняющихся кодах

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

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

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

Шаг № 5: Не трогайте старый код!

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

Я лично узнал, что исправление старого кода может привести к дефектам, о которых я не задумывался. Поэтому, если ваш старый код не поврежден, не исправляйте его! Единственным исключением из правила является случай «мертвого кода»; это код, который был зафиксирован когда-то в прошлом (во время разработки функции), но никогда не использовался. Если вы уверены, что фрагмент кода не вызывается, тогда удалите его! Удаление «мертвого кода» облегчит каждому разработчику навигацию по базе кода, а также сократит общее время сборки вашего программного приложения, что сэкономит драгоценное время вашей команды разработчиков.

Кто трогает твой код?

Сколько разработчиков касаются кода данного компонента в вашем программном приложении?

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


«Число мелких участников тесно связано с ошибками как до, так и после релиза …»

где второстепенный участник — разработчик с коммитом менее 5% в компоненте.

С другой стороны, если у вас есть один разработчик, который выполнил большинство коммитов в компоненте (также называемом владельцем компонента), то ожидается, что качество будет лучше. Как заявлено Microsoft в том же исследовании:


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

Шаг № 6: Обратите внимание на мелких участников

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

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

Как незначительный участник компонента, вы должны всегда консультироваться с основным вкладчиком (в идеале его владельцем), прежде чем вносить в него какие-либо изменения.

Дальнейшее чтение

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