Обзор литературы за последнее время

1. "Экстремальное программирование" Кент Бек
   
   Отличное руководство для тех, кто хочет перейти на на такую методологию разработки как экстремальное программирование. Рассмотрены условия перехода, основные моменты методологии, сложности и преимущества. Для затравки - основные тезисы экстремального программирования:
   • Игра в планирование(planning game)
   • Небольшие версии(small releases)
   • Метафора(metaphor)
   • Простой дизайн(simple design)
   • Тестирование(testing)
   • Переработка(refactoring)
   • Программирование парами(pair programming)
   • Коллективное владение(collective ownership)
   • Непрерывная интеграция(continuous integration)
   • 40-часовая неделя(40-hour week)
   • Заказчик на месте разработки(on?site customer)
   • Стандарты кодирования(coding standards).
   Из недостатков - в книге не отделены особенности ЭП от других agile методологий.
2. "Гибкие методологии разработки" Б. Вольфсон
   
   В книге представлены основные положения всех agile методик, есть выдержки из манифеста о гибкой разработке, также представлены особенности всех известных разновидностей данной методике, где на первое место выходит scrum и экстремальное программирование.
3. "Экстремальное программирование: разработка через тестирование" Кент Бек
   
   И снова от Кента Бэка отличная книга о test driven development. Тут четко, послеовательно, шаг за щагом приводят тебя к необходимости тестов в целом и перед началом работы над задачей в частности. Из классики (c)

   TDD заключается в следующем:
   1. Быстро создать новый тест.
   2. Запустить все тесты и обнаружить, что новый тест не выполняется.
   3. Внести небольшие изменения.
   4. Снова запустить все тесты и на этот раз зафиксировать, что все они успешно срабатывают.
   5. Провести рефакторинг (refactoring) для устранения дублирования.
   

4. "Паттерны проектирования" Э. Фримен, Э. Фримен, К. Сьерра, Б. Бейтс
   
   О паттернах сейчас знают все, но, тем не менее, не все их применяют. Наверное, все начинали знакомство с ними по знаменитой книге банды четырех, но сколько потребовалось усилий, чтобы запомнить где нужно применять фасад и что такое паттерн обозреватель?
   
   Данная книга легко и ненавязчиво, а, главное, на очень доступных примерах объясняет суть большинства самых употребляемых паттернов. Так что до знакомства со справочником от банды четырех рекомендовала бы эту книгу.
5. "SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) (Certification Press)" Katherine Sierra Книга будет полезна не только, готовящимся к SCJP, но и всем людям которые хотят знать инструмент, повседневно используемый в работе, в совершенстве.

После прочтения некоторых книг хочется выделить авторов-создателей толковой, полезной и легкочитаемой технической литературы. На первом месте, безусловно, для меня Стив Макконел, с его кодом, оценками продуктов, UML. А в этом списке выделились Кэти Сиера и Кент Бек.

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 у методов: