Паттерны для SimpleDateFormat

Ссылка на все паттерны для SimpleDateFormat: http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html

Sonar + maven

Как подводные лодки исследуют морское дно и обнаруживают вражеские корабли с помощью такого прибора как сонар, так и opensource проект для анализа кода с идентичным названием Sonar позволяет, используя метрики, обнаружить недостатки в программе.

Установка Sonar

1. Загрузить последнюю версию Sonar тут и распаковать.
2. В settings.xml в maven (обычно лежат в $MAVEN_HOME/conf или ~/.m2) добавить новый профиль Sonar:

   
    sonar
    
     true
    
    
     
     
       jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
     
     com.mysql.jdbc.Driver
     sonar
     sonar
     
     
       http://localhost:9000
     
    
   
   

   Если в проекте используется БД, то прописываем соответствующие driverClassName, username и password.
   В любом случае необходимо прописать sonar.host.url.
3. Запускаем Sonar:
   $SONAR_PATH/bin/windows-x86-32/StartNTService.bat
4. А теперь можно проанализировать ваш проект, запустив
   mvn sonar:sonar

После этого ваш проект добавился к проектам, проанализированным с помощью Sonar.
Отчеты будут доступны по url, что вы прописали в sonar.host.url.

Вот так выглядит общая страница отчета по проекту:

• Показывает статистику по проекту, такую как количество строк, пакетов и тп.
• Количество комментариев и дубликатов.
• Соответветсвие стандартам по разным метрикам (в данном примере Rules compliance 81.8% ).
• Зависимости между пакетами.
• Уровень complexity (запутанности) кода.
• Результаты юнит-тестов и уровень покрытия кода

Каждый раздел можно посмотреть подробнее.

Например, покрытие тестами:

Или отчет complexity кода:

Сheckstyle (java) + maven

Для оценки соответствия кода заданным в команде стандартам могут использоваться разные утилиты, но чаще в моей практике использовалась Checkstyle
Часто Checkstyle используется для повышения качества кода в тех командах, где присутствует негармоничное соотношение джуниоров, интермидов и синиоров. Когда кода много в таких проектах, рефакторить его просто некому и некогда. Был в моей практике проект, где самая основная операция осуществлялась в одном методе с длиной порядка 1500 строк. Использовав эту утилиту, рефакторинг кода осуществился бы в принудительном порядке (например, параметры длина метода и code complexity).

Подключается плагин при помощи maven так:

 org.apache.maven.plugins
 maven-checkstyle-plugin
 2.6
 
  src/config/checkstyle.xml
  true
 
 
  
   package
   
    check
   
  
 

При этом обычно настраивают так, что при любом несоответствии стандартам билд ломается.

Основные элементы для настройки стиля:

1. Ограничения размеров
   • FileLength - ограничение на количество строк в файле:

   • LineLength - ограничение на длину строки для повышения читабельности кода:

   • MethodLength - ограничение на длину метода (ограничение, о котором говорилось выше):

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

2. Метрики
   Также очень полезно использовать ограничения по основным метрикам кода
   • BooleanExpressionComplexity - ограничение на количество условий в boolean выражении:

   • CyclomaticComplexity - ограничение вложенность for, if, switch и тп конструкций. Величина "запутанности" кода:

3. Дубликаты. Любителям copy+paste посвящается :)
   • StrictDuplicateCode - длина кода, который при дублировании должен быть отрефакторен:

4. Стандарты именования
   • В данном случае представлен пример именования методов, классов, переменных

5. И не забываем javadoc.
   • JavadocType - наличие javadock у классов, интерфейсов, enum:

   • JavadocMethod - наличие javadock у методов:

Coberture + maven

Пожалуй, уже некого убеждать о важности юнит-тестов в программировании, и многие используют каждый день такие инструменты как:

• cobertura
• emma
• clover

Данная статья является просто быстрым стартом использования cobertura под Maven. Во-первых, для создания отчета о покрытии кода юнит-тестами достаточно просто прописать в pom:

    
        
            
                org.codehaus.mojo
                cobertura-maven-plugin
                2.5.1
            
        
    

А для того чтобы билд фейлился, если покрытие ниже заданного (ниже в примере задано покрытие не меньше 75%) прописываем уже не в , а в :

 
    
        
            org.codehaus.mojo
            cobertura-maven-plugin
            2.5.1
            
                
                    75
                    75
                    true
                    75
                    75
                    75
                    75
                
            
            
                
                    
                        clean
                        check
                    
                
            
        
    

При этом можно некоторым важным пакетам повышать покрытие кода:

    
        75
        75
        true
        75
        75
        75
        75
        
            
                com.mobiletech.aker.parsers.*
                75
                100
            
        
    

а некоторые пакеты "убирать" из базы анализа:

    
        
            org.codehaus.mojo
            cobertura-maven-plugin
            2.5.1
            
                
                    
                        com.example.boringcode.*
                    
                    
                        com/example/dullcode/**/*.class
                    
                
            
        
    

А вот так выглядит сгенерированный отчет (по умолчанию генерируется в /site/coberture/):