POJO без лишних слов

Нашел тут очень интересную штуку, называется Lombok.
Особенно интересно - интеграция с Eclipse.
Если коротко, то это плагин к компилятору, который на этапе генерации кода вставляет геттеры/сеттеры для указанных полей, что позволяет не держать их в исходном коде. Не секрет, что в 90% случаев геттеры и сеттеры используются только для доступа к полям (fields) и не содержат бизнес-логики.
В качестве примера, для pure java надо писать так:

class Book{
private String title;
private String author;
private int pageNumber;
public String getTitle(){
return title;
}
public String getAuthor(){
return author;
}
public int getPageNumber(){
return pageNumber;
}
public void setTitle(String title){
this.title = title;
}
public void setAuthor(String author){
this.author = author;
}
public void setPageNumber(int pageNumber){
this.pageNumber = pageNumber;
}
}
а с lombok достаточно написать:
class Book{
@Getter @Setter private String title;
@Getter @Setter private String author;
@Getter @Setter private int pageNumber;
}
По компактности и выразительности кода - почти Groovy :)

Информация по использованию - после скачивания надо будет запустить полученный jar и интегрировать его в Eclipse (там графический инсталлятор, так что все интуитивно понятно). Интегрировать с Eclipse не обязательно, но добавит немного приятности.
Необходимо также чтобы при компиляции lombok.jar был в classpath проекта (для Eclipse его надо добавить к библиотекам проекта). В режиме исполнения (runtime) ломбок не нужен.

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

Да и кстати, возможности не ограничиваются геттерами/сеттерами - есть еще несколько интересных возможностей. Более подробно рассмотренные в примерах на сайте.

Методика разработки

Методика разработки это по сути то, с чего начинается любой проект. В данном случае, я не имею в виду процессы, типа RUP или XP или еще какой P, а скорее конфигурацию проекта.
Цель этого текста не дать какой-то рецепт, а скорее структурировать собственные знания.
Да, и следует иметь в виду что все это написано в контексте разработки web-приложений на java.
Каждый раз начиная новый проект приходится отвечать на вопросы:

1. Будет ли это одномодульный или многомодульный проект?
2. Каким образом будет осуществляться взаимодействие между участниками?
3. Какова область ответственности каждого участника?
4. Какие средства стоит использовать для сборки, тестирования и прочего?
   

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

"Мелкое приложение"
Как следует из названия шаблон предназначен для небольших приложений, как правило, разрабатываемых одним автором. Как определить масштаб приложения каждый выбирает индивидуально, конечно. Я бы определил по числу используемых сущностей, в данном случае, не более 5-6. Что характерно, при таком определении количество пользователей (а значит и нагрузка) и/или размер базы могут быть весьма и весьма не маленькими.
1. Модульность - проект одномодульный во избежание излишнего усложнения, тем более для одного разработчика. Понятие модуля, обычно, соответствует понятию проект в средах разработки. Во всяком случае, для Eclipse это тождественные понятия. Но даже в случае коллективной работы сложностей не должно быть, если:
2. Средства коллективной разработки - subversion. Конечно и вопрос звучит несколько шире и существуют и другие системы контроля версий, помимо subversion, но в данном контексте, думаю, этого достаточно.
3. Область ответственности - т.к. разработчик скорее всего один, то он несет ответственность за приложение. Если для каких-то целей привлекаются дополнительные участники, например, web-дизайнер, то в этом случае четко должна быть определена их зона ответственности. Для дизайнера соответственно это будет внешнее оформление приложения: шаблоны, графические элементы и пр.
4. Вспомогательные средства
4.1 Сборка - в данном случае уместно использовать Аnt, как относительно простое, надежное и независимое от IDE средство.
4.2 Тестирование - JUnit, а также его различные расширения в зависимости от особенностей проекта и требованиям к качеству.
В общем-то и все. Можно использовать еще много разных средств для улучшения качества кода, поиска ошибок, но, как мне кажется достаточный уровень для разработки достигнут.

Ждем вдохновения и новые шаблоны проектов.