Обычно, если вы работаете над программным проектом, особенно в его начале, качество кода – это не первое, на что вы обращаете внимание. Однако вопрос о том, как улучшить качество и эффективность кода, должен быть одной из главных проблем для разработчики java , руководитель технической группы, системный архитектор и даже руководитель проекта. Как улучшить качество кода Java?
Улучшение качества кода – это одна из вещей, которая требует хорошо разработанной стратегии и ее соблюдения на протяжении всего жизненного цикла проекта. Это только вопрос времени, когда это настигнет вас и вызовет проблемы, если вы просто оставите это без внимания. Вот почему гораздо лучше решить эту проблему заранее.
В Romexsoft мы обычно используем Java для наших проектов и всегда рассматриваем способы улучшения качества кода на Java. Мы делаем это, следуя методам улучшения качества программного обеспечения и используя Инструменты для улучшения качества кода Java , которые помогают нам не только улучшать наш код, но и нашу производительность.
В этой статье мы рассмотрим наиболее часто используемые методологии разработки и первоклассные инструменты, которые мы используем для создания лучшего кода. Цель состоит в том, чтобы рассмотреть общие подходы к качеству кода и помочь командам выбрать методологию и инструмент, которые сделают их процесс эффективным.
Что такое Методология разработки программного обеспечения?
Методология разработки программного обеспечения представляет собой набор шаблонов и правил, которые используются для структурирования, планирования и контроля процесса разработки программных решений. Чтобы эффективно управлять процессом разработки, руководитель проекта должен выбрать методологии разработки, наиболее подходящие для соответствующего проекта.
Итак, давайте рассмотрим некоторые из них, чтобы понять, почему существуют различные методологии и какие из них наиболее часто используются.
Парное программирование
Парное программирование – это проверенная методология, которая уменьшает количество ошибок в вашем коде. Это делается двумя разработчиками, которые совместно используют одно рабочее пространство (клавиатуру и экран), и это похоже на воспоминание из школы или университета – один разработчик кодирует, в то время как другой читает написанный код и обдумывает потенциальные проблемы. Разработчики обучают друг друга кодированию и могут меняться ролями во время сеанса.
Основным преимуществом парного программирования является обмен знаниями и повышение качества кода. Это также улучшает коммуникацию внутри команды.
Парное программирование – это не только код, но его можно использовать для командных строк операционной системы, работы с сервером БД, управления файлами, работы с облаком и многих других случаев.
Поэтому, если вы работаете над более сложными или критическими элементами, не стесняйтесь объединяться со своими коллегами и использовать эту методологию для предотвращения ошибок/проблем в вашем коде. Учитывая более высокую стоимость ошибок/проблем, которые будут обнаружены позже во время разработки или после выпуска, парное программирование экономит ваше время и деньги.
Учитывая общеизвестный факт, что “две головы лучше, чем одна”, дискуссия о парном программировании, похоже, утихла, и люди действительно практикуют его.
Соглашения о кодировании
Соглашения о кодировании – это набор руководящих принципов, которые разрабатываются командами разработчиков и включают рекомендации по стилю программирования, методам и методам для каждого аспекта кода, написанного в компании или определенном проекте. Эти соглашения обычно специфичны для каждого языка программирования и охватывают организацию файлов, отступы, комментарии, объявления, инструкции, пробелы, соглашения об именах, методы и принципы программирования, правила программирования, лучшие архитектурные практики и т.д. Главное преимущество определенных стандартов заключается в том, что каждый фрагмент кода выглядит и кажется знакомым. Это делает его более читабельным и помогает программистам понять код, написанный другим программистом.
Если стандарты кодирования будут соблюдаться и последовательно применяться на протяжении всего процесса разработки, в будущем будет легче поддерживать и расширять код, его рефакторинг и разрешать конфликты интеграции. Сам стандарт имеет гораздо меньшее значение, чем его соблюдение.
Соглашения о коде важны для программистов по ряду причин:
- 40 % – 80 % стоимости жизненного цикла программного обеспечения уходит на техническое обслуживание.
- Вряд ли какое-либо программное обеспечение поддерживается его автором на протяжении всей его жизни.
- Соглашения о коде улучшают читабельность программного обеспечения, позволяя программистам быстрее понимать новый код.
Честно говоря, я большой поклонник стандартов кодирования. Для меня имеет смысл потратить время на их обсуждение и споры, поскольку это ценный вклад в экономию вашего времени и усилий в будущем.
Начните с организации совещания о том, что должно быть в стандарте кодирования. Это должна быть только личная встреча, но не по электронной почте или через чат-системы. Обсудите правила, которые вы решили включить в соглашение о кодексе. Правила, которые согласованы большинством команды, должны быть приняты как “обязательные”, а другие правила могут рассматриваться как “необязательные”.
Руководящие принципы конвенции о кодексе должны часто пересматриваться. Правила могут быть перемещены из “обязательных” в “необязательные” и наоборот. Если некоторые из них работают не так, как ожидалось, их необходимо переработать или удалить из руководства.
Программистам настоятельно рекомендуется следовать этим рекомендациям во время кодирования, и их следует использовать как часть обзора кода, который является следующим в нашем списке.
Проверка кода
Следующая лучшая вещь для парного программирования – это обзор кода. Если вы не практикуете парное программирование, то рекомендуется рассмотреть, по крайней мере, обзор кода. Это легкий процесс, который следует применять как можно скорее после написания кода.
Некоторые из других вопросов, перечисленных ниже, не столь очевидны, но их стоит рассмотреть. Давайте продолжим.
Модульные тесты
Следующая методология, о которой мы поговорим, – это модульное тестирование. В зависимости от вашего опыта вы, возможно, слышали или не слышали что-то о модульных тестах, разработке на основе тестов или какой-либо другой методологии тестирования. Обычно эти методологии применяются в контексте крупных программных систем, а иногда и в контексте простых веб-сайтов.
В компьютерном программировании модульное тестирование – это процесс разработки программного обеспечения, в котором наименьшая проверяемая часть исходного кода, называемая модулем, тестируется индивидуально и независимо, чтобы проверить, работают ли они должным образом. Это поможет вам выявить сбои в алгоритмах и/или логике до выпуска кода.
Одно из преимуществ, которое вы получаете от создания модульных тестов, заключается в том, что ваша команда будет мотивирована на написание тестируемого кода. Поскольку модульное тестирование требует соответствующей структуры вашего кода, это означает, что код должен быть разделен на более мелкие, более целенаправленные функции. Каждый из которых отвечает за одну операцию с набором данных, а не за большие функции, выполняющие ряд различных операций.
Второе преимущество написания хорошо протестированного кода заключается в том, что вы можете предотвратить будущие сбои, когда небольшие изменения в существующем коде нарушают функциональность. Когда произойдет сбой, вам сообщат, что вы написали что-то не так.
На первый взгляд, тратить время на написание модульных тестов во время разработки выглядит как дополнительные расходы. Однако это сэкономит время, которое вы могли бы потратить на отладку. Это должен быть пошаговый процесс.
Конечно, вы не можете писать модульные тесты для каждой части вашего проекта, но вам нужно убедиться, что основные компоненты ведут себя так, как ожидалось. Когда проект расширится, вы можете просто запустить разработанные вами тесты, чтобы убедиться, что существующая функциональность не нарушается при внедрении новой функциональности.
Разработка на основе тестирования
Разработка на основе тестов (TDD), также называемая дизайном на основе тестов, представляет собой методологию разработки программного обеспечения, которая сочетает модульное тестирование, программирование и рефакторинг исходного кода. Обычно разработчики склонны пропускать архитектурный аспект разработки программного обеспечения и сразу переходить к кодированию. Они пытаются получить приблизительную реализацию и только после того, как у них есть рабочий прототип, они думают о написании тестов. Хотя этот подход может быть успешным, требуется много усилий, чтобы просто заставить его работать.
TDD – это одна из тех практик, которые способствуют повышению качества кода и уменьшению количества ошибок. Он был представлен как часть более широкой парадигмы разработки программного обеспечения, известной как Scrum и экстремальное программирование (XP), которые являются разновидностями методологии гибкой разработки программного обеспечения. TDD помогает создавать приложения высокого качества за меньшее время. Правильная реализация TDD требует, чтобы разработчики и тестировщики точно предвидели, как приложение и его функции будут использоваться в реальном мире.
Когда он запускается как часть непрерывного цикла интеграции с частыми автоматизированными сборками и тестами, практикуется модульное тестирование на стероидах. Для того чтобы применить эту методологию, разработчикам необходима специальная подготовка и коучинг.
В моем понимании TDD, перед кодированием вам нужно знать (по крайней мере) отправную точку. Прежде всего, вам нужно подумать об объектах и их поведении, чтобы решить данную проблему. При выполнении TDD вы начинаете с теста и с вашего видения мечты о том, как будет выглядеть тест.
Непрерывная Интеграция
Непрерывная интеграция (CI) – это практика разработки, которая требует, чтобы разработчики несколько раз в день интегрировали код в общий репозиторий (SVN, Subversion или Git). Каждая регистрация проверяется с помощью автоматических тестов. Хотя автоматизированные тесты не являются строго частью CI, они обычно ожидаются. Такой подход позволяет разработчикам обнаруживать проблемы раньше и, как следствие, решать их быстрее.
Это ценная практика сама по себе. Вам следует сосредоточиться на настройке простого процесса непрерывной интеграции как можно раньше. Существует множество инструментов, которые могут помочь вам настроить этот процесс, и наиболее известными из них являются Дженкинс , Бамбук , и |/Teamcity . Они позволяют автоматизировать развертывание программного обеспечения и сосредоточиться на создании продукта.
Демонстрационная сессия
Демонстрационное совещание по обзору обычно проходит ближе к концу спринта. Цель этой встречи – показать другим членам команды, клиентам и заинтересованным сторонам результаты работы команды, достигнутые в течение спринта.
Возможно, не сразу видно, почему это приводит к улучшению кода, но это произойдет. Регулярно показывая исходный код, разработчики должны поддерживать его в состоянии выпуска. Благодаря регулярным демонстрационным встречам у вас будет хорошо организованный процесс получения отзывов. И это даст вам лучшее понимание того, что было сделано правильно, и укажет, когда что-то пошло не в том направлении.
Теперь давайте пойдем дальше и проверим, есть ли некоторые рекомендуемые инструменты для улучшения качества кода, чтобы отшлифовать процесс.
Инструменты для улучшения качества кода Java
Нет разработчика, который никогда не ошибался.
Обычно компилятор улавливает синтаксические и арифметические проблемы и выводит трассировку стека. Но все еще могут быть некоторые проблемы, которые компилятор не улавливает. Это могут быть неправильно реализованные требования, неправильные алгоритмы, плохая структура кода или какие-то потенциальные проблемы, о которых сообщество знает по опыту.
Единственный способ выявить такие ошибки – попросить какого-нибудь старшего разработчика просмотреть ваш код. Такой подход не является панацеей и мало что меняет. С каждым новым разработчиком в команде у вас должна быть дополнительная пара глаз, которые будут смотреть на его/ее код. Но, к счастью, есть много инструментов, которые могут помочь вам контролировать качество кода , включая Checkstyle, PMD, FindBugs, SonarQube, и т.д. Все они обычно используются для анализа качества и построения некоторых полезных отчетов. Очень часто эти отчеты публикуются серверами непрерывной интеграции, такими как Jenkins.
Вот список инструментов статического анализа кода Java, которые мы используем в RomexSoft в большинстве наших проектов. Давайте рассмотрим каждый из них.
Стиль проверки
Обзоры кода необходимы для качества кода, но обычно никто в команде не хочет просматривать десятки тысяч строк кода. Но проблемы, связанные с ручным анализом кода, могут быть автоматизированы с помощью анализаторов исходного кода, таких как Checkstyle .
Checkstyle – это бесплатный инструмент статического анализа кода с открытым исходным кодом, используемый при разработке программного обеспечения для проверки соответствия кода Java установленным вами соглашениям о кодировании. Это автоматизирует важную, но скучную задачу проверки кода Java. Это один из самых популярных инструментов, используемых для автоматизации процесса проверки кода.
Checkstyle поставляется с предопределенными правилами, которые помогают поддерживать стандарты кода. Эти правила являются хорошей отправной точкой, но они не учитывают требования, предъявляемые к конкретному проекту. Хитрость для успешного автоматического анализа кода заключается в том, чтобы объединить встроенные правила с пользовательскими, поскольку существует множество руководств с инструкциями.
Checkstyle можно использовать в качестве плагина Eclipse или как часть встроенной системы, такой как Муравей , Мавен или Gradle для проверки кода и создания отчетов о нарушениях стандартов кодирования.
ПМД
PMD – это инструмент статического анализа кода, который способен автоматически обнаруживать широкий спектр потенциальных ошибок и небезопасный или неоптимизированный код. Он проверяет исходный код Java и ищет потенциальные проблемы, такие как возможные ошибки, мертвый код, неоптимальный код, чрезмерно сложные выражения и дублированный код.
В то время как другие инструменты, такие как Checkstyle, могут проверить, соблюдаются ли соглашения и стандарты кодирования, PMD больше фокусируется на упреждающем обнаружении дефектов. Он поставляется с богатым и легко настраиваемым набором правил, которые вы можете легко настроить и выбрать, какие конкретные правила следует использовать для данного проекта.
Так же, как и Checkstyle, PMD можно использовать с Затмение , |/ИДЕЯ IntelliJ , Мавен , Грейдл или |/Дженкинс .
Вот несколько случаев плохой практики, с которыми сталкивается PMD:
- Пустые блоки try/catch/finally/switch.
- Пустые операторы if/while.
- Мертвый код.
- Случаи с прямой реализацией вместо интерфейса.
- Слишком сложные методы.
- Классы с измерениями высокой цикломатической сложности.
- Ненужные операторы “если” для циклов, которые могут быть циклами “в то время как”.
- Неиспользуемые локальные переменные, параметры и частные методы.
- Переопределите метод hashcode() без метода equals().
- Расточительное использование строки/буфера строк.
- Дублированный код – копирование/вставка кода может означать ошибки копирования/вставки и, таким образом, привести к снижению ремонтопригодности.
Найди жучков
FindBugs – это инструмент качества Java-кода с открытым исходным кодом, в чем-то похожий на Checkstyle и PMD, но с совершенно другим фокусом. FindBugs не касается стандартов форматирования или кодирования, но лишь незначительно интересуется лучшими практиками.
Фактически, он концентрируется на обнаружении потенциальных ошибок и проблем с производительностью и очень хорошо справляется с обнаружением множества распространенных труднодоступных ошибок кодирования, включая проблемы синхронизации потоков, разыменование нулевого указателя, бесконечные рекурсивные циклы, неправильное использование методов API и т.д. FindBugs работает с байт-кодом Java, а не с исходным кодом. Действительно, он способен обнаруживать совершенно другой набор проблем с относительно высокой степенью точности по сравнению с PMD или Checkstyle. Как таковой, он может быть полезным дополнением к вашему набору инструментов статического анализа.
FindBugs в основном используется для выявления сотен серьезных дефектов в крупных приложениях, которые классифицируются на четыре ранга:
- самый страшный
- страшный
- тревожный
- вызывающий озабоченность
Давайте подробнее рассмотрим некоторые случаи ошибок.
Бесконечный рекурсивный цикл
Здесь метод result value() называется рекурсивным внутри самого себя.
Исключение Нулевого указателя
Ошибка поиска проверяет код оператора, который наверняка вызовет исключение NullPointerException.
Приведенный ниже код представляет собой относительно простую ошибку. Если переменная ‘obj’ будет содержать значение null, а переменная ‘str’ имеет некоторый экземпляр, это, несомненно, приведет к исключению NullPointerException.
Метод, возвращаемое значение которого не следует игнорировать
Строка является неизменяемым объектом. Таким образом, игнорирование возвращаемого значения метода будет сообщено как ошибка.
Подозрительное сравнение равных()
Метод вызывает equals(объект) по ссылкам разных типов классов без общих подклассов.
Объекты разных классов всегда должны сравниваться как неравные, поэтому сравнение !str.equals(значение) всегда будет возвращать значение false.
Хэш равен несоответствию
Класс, который переопределяет equals(объект), но не переопределяет hashCode() и использует встроенную реализацию hashCode() из java.lang. Объект, скорее всего, нарушит инвариант, согласно которому равные объекты должны иметь одинаковые хэш-коды.
Класс не переопределяет равные в суперклассе
Вот пример: дочерний класс, который расширяет родительский класс (который определяет метод equals), добавляет новые поля, но не переопределяет сам метод equals. Таким образом, равенство в экземплярах дочернего класса будет использовать унаследованный метод equals и, как следствие, будет игнорировать идентификатор дочернего класса и вновь добавленные поля.
Подводя итог, Firebug распространяется как отдельное приложение с графическим интерфейсом, но также доступны плагины для Eclipse, NetBeans, IntelliJ IDEA, Gradle, Maven и Jenkins. Дополнительные наборы правил могут быть подключены к FindBugs, чтобы увеличить набор выполняемых проверок.
Гидролокатор
SonarQube – это платформа с открытым исходным кодом, которая была первоначально запущена в 2007 году и используется разработчиками для управления качеством исходного кода. Sonar был разработан для поддержки глобальной стратегии непрерывного улучшения качества кода в компании и, следовательно, может использоваться в качестве общей центральной системы управления качеством. Это делает возможным управление качеством кода для любого разработчика в команде. В результате в последние годы она стала мировым лидером в области непрерывной проверки систем управления качеством кода.
В настоящее время Sonar поддерживает широкий спектр языков, включая Java, C/C++, C#, PHP, Flex, Groovy, JavaScript, Python и PL/SQL (некоторые из них с помощью дополнительных плагинов). И Sonar очень полезен, поскольку он предлагает полностью автоматизированные инструменты анализа и хорошо интегрируется с Maven, Ant, Gradle и инструментами непрерывной интеграции.
Sonar использует FindBugs, Checkstyle и PMD для сбора и анализа исходного кода на наличие ошибок, плохого кода и возможного нарушения правил стиля кода. Он исследует и оценивает различные аспекты вашего исходного кода, от незначительных деталей стиля, потенциальных ошибок и дефектов кода до критических ошибок проектирования, недостаточного охвата тестированием и избыточной сложности. В конце концов, Сонар выдает значения показателей и статистику, выявляя проблемные области в источнике, которые требуют проверки или улучшения.
Вот список некоторых функций Sonarqube:
- Это показывает не только то, что не так. Он также предлагает инструменты управления качеством, которые помогут вам все исправить.
- SonarQube устраняет не только ошибки, но и правила кодирования, покрытие тестов, дублирование кода, сложность и архитектуру, предоставляя все подробности на панели мониторинга.
- Это дает вам представление о качестве вашего кода в определенный момент времени, а также о тенденциях отставания и опережающих показателях качества.
- Он предоставляет вам показатели качества кода, которые помогут вам принять правильное решение.
- Существуют показатели качества кода, которые показывают ваш прогресс и показывают, становитесь ли вы лучше или хуже.
SonarQube – это веб-приложение, которое может быть установлено автономно или внутри существующий Веб-приложение Java. Показатели качества кода можно получить, запустив mvn sonar:sonar в вашем проекте.
Ваш pom.xml файлу потребуется ссылка на этот плагин, потому что он не является плагином maven по умолчанию.
Кроме того, Sonar предоставляет расширенную отчетность с помощью нескольких представлений, которые показывают определенные показатели (вы можете настроить, какие из них вы хотите видеть) для всех проектов. И что самое важное, он не только предоставляет показатели и статистику о вашем коде, но и преобразует эти неописуемые значения в реальные бизнес-ценности, такие как риск и технический долг.
Время для выводов
За годы работы над различными проектами по разработке программного обеспечения мы накопили собственный опыт улучшения хорошего кода. И вот что мы рекомендуем делать в течение всего процесса, чтобы улучшить качество кода:
- Следуйте руководству по стилю языка программирования.
- Придерживайтесь ТВЕРДЫХ принципов в своем дизайне.
- Дайте описательные имена методам и переменным.
- Не переоценивайте дизайн.
- Используйте шаблоны проектирования.
- Не изобретайте велосипед и не используйте сторонние фреймворки.
- Используйте эффективные структуры данных и алгоритмы.
- Создавайте модульные тесты.
- Документируйте все аспекты вашего проекта.
- Храните все элементы вашего проекта в системе контроля версий.
Выполнив все эти пункты и используя инструменты анализа качества кода в сочетании с методологией разработки в своей повседневной практике программирования, вы в конечном итоге создадите более читаемый, более тщательно протестированный, с большей вероятностью корректно выполняемый и намного более простой в пересмотре код. Вы также избавите себя, свою команду и своих клиентов от множества головных болей, времени и, следовательно, денег.
Если это то, что вы хотели бы испытать в рамках всего процесса разработки, не стесняйтесь обращаться в Romexsoft. Мы знаем, как отправлять качественный код и предоставлять нашим клиентам лучший опыт.
Написано Romexsoft 13 сентября 2017 года Первоначально опубликовано в блоге Romexsoft/| 11 Лучших практик и инструментов для улучшения качества кода Java
Автор: Юрий Бондаренко
Оригинал: “https://dev.to/serhiykozlov/11-best-practices-and-tools-to-improve-the-java-code-quality-l0j”