Definindo Padrões e Boas Práticas ao iniciar um Projeto

Assuntos Gerais Agile
#1

Olá, amigos foristas!

Seguinte: estou começando um projeto novo, relativamente grande e complexo, onde, atualmente, trabalha uma equipe de 5 pessoas. Como é um produto da empresa, várias outras pessoas mexerão com esse sistema. Pessoas com mais ou menos experiência passarão por esse projeto. Dito isso, gostaria de estabelecer junto com a equipe algumas convenções/padrões para justamente evitar a arbitrariedade e diminuir um pouco do impacto da alta rotatividade de desenvolvedores no projeto. O projeto usará EJB, JPA, JSF (1.2 ou 2), Rich Faces ou Prime Faces, Facelets e alguns outros frameworks.
Tentei montar uma lista já de alguns itens. Gostaria de saber de vocês o que vocês acham certo manter ou tirar. O que é legal e o que é exagero.

----------- Legibilidade do código --------------

-Indentação do código (limitar número de colunas do código na IDE?);

-Código que contenha regra de negócio, relativamente complexa, deve ser comentado; (subjetivo, usar o bom senso)

-Evitar try/catch sem tratamento de exceção;

-if e else, mesmo com uma linha, abrir e fechar {}

  • Nomes de variáveis devem ser sugestivos (auto-explicativos)

  • Evitar código comentado. O SVN deve ser usado para guardar código antigo;

  • Evitar warnings;

  • Regras de negócio devem ser tratadas no BO. Não no DAO nem no ManagedBean;

  • Os métodos devem executar somente aquilo que se propõem a fazer; Exemplo: método ?salvar? não deve ter código de validação dentro dele;

  • Antes de criar um método utilitário ou um serviço, verificar se o mesmo já não existe no sistema ou em alguma biblioteca utilitária;

  • Se foi desenvolvido um método que pode ser usado por outras classes, colocá-lo num projeto Util.

  • variáveis que são lista, usar o ?list? antes do nome da variável. Ex: listUsuarios, listPapeis, listAtribuicoes.

------------------- Métodos ---------------------

  • Todos os métodos devem começar com palavras no infinitivo (ex: buscar, salvar, calcular…), exceto os que retornam boolean.

Métodos de busca: buscarPor… ou buscarTalEntidadePor…

Métodos que persistem objetos: salvar

Métodos que removem objetos: excluir/remover

Métodos que buscam objetos usando varios atributos (mais de 5), devem ter seu nome com buscarPorFiltro.

Não usar palavras em língua estrangeira nos nomes do método.

--------------- Desempenho/BD -----------------

  • Usar HQL nas consultas, evitar query nativa;

  • Listas sempre como lazy.

  • Evitar uso de laços aninhados (consultas no banco são mais rápidas);

  • Evitar uso abusivo da sessão;

  • Usar paginação real nas listagens;

#2

Legal.
Mas como você vai aferir se está realmente sendo posto em prática?

#3

[quote=raf4ever]Legal.
Mas como você vai aferir se está realmente sendo posto em prática?[/quote]

Impossível de garantir isso, da mesma maneira que não posso evitar que alguém implante uma bomba-relógio no sistema. Tenho que contar com a boa vontade da equipe.
O que você acha de revisão de código?

#4

Aliás… legibilidade e formatação do código até consigo garantir até um certo ponto na IDE.

#5

Existe um plugin do Eclipse chamada PMD que pode te ajudar com isso.
E não esqueça dos teste também.

#6

Existe um plugin do Eclipse chamada PMD que pode te ajudar com isso.
E não esqueça dos teste também.[/quote]
há também o Checkstyle e o FindBugs.

e a programação em par pode ajudar.

#7

Fala ae, Leandro

Eu acho esse ponto deve ser melhor analisado:

Imagina na hora de desenvolver aquele relatório cheios de detalhes onde tem N INNER JOINS. Em HQL ficaria um pouco complexo e certamente você não teria a otimização correta da consulta. Isso já aconteceu comigo.

Mas o restante está muito bem definido. O problema como sempre será humano e todos abraçarem a causa.

#8

Evitar query nativa == usar apenas quando necessário.

#9

Vc poderia criar uma lista com todas as boas praticas no começo do projeto em um Brainstorm.

Depois elabore alguma forma de ciclo PDCA. Não sei se vc vai trabalhar com sprints ou algum tipo de iteração mas vc pode a cada 15 dias convocar o time e perguntar o que esta sendo usado, o que esta ruim, etc. Um suporte de alguma ferramenta pode ser utilizado como analise de codigo, linhas de codigo/linhas de teste, cobertura de testes, resultados de teste de performance, etc. A lista de boas praticas é util para ser um guia mas se vc não consegue aplicar a pratica X pode significar que ela não é tão util como a Y que não era imaginada na epoca do guia.

Como no fim das contas vc quer que as pessoas trabalhem melhor e que o sistema não de dor de cabeça o melhor que vc pode fazer é perguntar pro time como estão as coisas. Se houver sinceridade vc pode descobrir que nos ultimos dias a coisa tem sido puxada e os testes unitarios estão ridiculos mas todos entendem que testes são importantes a longo prazo.

Só não burocratize demais. De repente alguem pode rejeitar um commit pq não segue padrões (vai la o cara e cria 90 classes anonimas para gerar um XML quando podia ter usado um Map<String,String> e o XStream) mas quando é algo gritante, mas no geral um bom time deve amadurecer com relação as praticas e apenas debatendo, tentando, se comprometendo com elas que vai pra frente, do contrario vira um .DOC que diz que cada metodo não pode ter mais de 5 linhas mas ninguem se importa com aquilo.

#10