Plano de Projeto

SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
Procedimento para revisão de fonte
 As OS para revisão de fontes serão enviadas para a fila Java com o serviço DES-REVISÃO DE
FONTES, sendo um item para o serviço anterior e outro para DES-COMPILAÇÃO.
 Revisores: Gualberto, Rodrigo, Leandro, Héliton e Cristian.
 Telas de complexidade baixa ou pequenas correções de erros não há necessidade de revisão
de fontes.
 Telas que possuem um orçamento acima de 60 horas devem ser revisadas antes, com uma
verificação em 50% concluída.
 Para telas acima 120 horas e complexidade alta deverá ser revisada em partes ou módulos
de forma que facilite a revisão.
 Todas as telas dos programadores iniciantes deverão ser revisadas.
 A revisão de fonte será monitorada pelo gerente de projetos.
 Este documento poderá ser atualizado pelos membros da equipe, desde que haja consenso,
devido suas necessidades.
Revisão de fonte Java
1) Os nomes de classes, variáveis e métodos estão refletindo a realidade do que elas representam?
Os nomes devem ser grandes o bastante para expressar de maneira adequada o que ele
representa
Evite nomes muito grandes ou muitos curtos.
Evite abreviações desnecessárias.
2) O escopo das variáveis estão bem definidos, como segue:
Variáveis que estão como atributos de classe precisam realmente ser atributos de classe?
Variáveis locais estão inicializadas de maneira correta e não estão sendo reaproveitadas para
valores que não representem seu nome?
3) O código está limpo sem excesso de comentários ou trechos de código comentados?
Script de revisão Java e Flex
Versão 1.0
1/6
SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
4) Existem uma linha em branco sempre que o código muda de "assunto" (evite código”linguição”!)
5) Os métodos possuem um número de linhas adequado? Nem muito grande nem muito pequeno?
6) Os métodos privados excessivamente pequenos e que são usados em poucos lugares, não
devem ser usados, pois podem deixar uma leitura de difícil entendimento.
7) Os métodos públicos devem ser evitados sempre que possível. Apenas os métodos que
representam a interface pública de uma classe devem ser públicos.
8)
Evite
métodos
GETTER/SETTER
desnecessários.
Apenas
atributos
que
configuram
o
comportamento da classe devem possuir SETTER e apenas atributos que possam realmente ser
usados pelo código chamador devem ter um GETTER definido.
9) Classes que possuem um nível de configuração complicado devem usar classes auxiliares de
configurações e métodos de construção (Build) apropriados.
8) EVITE CÓDIGO REPETIDO. Ao invés de copiar e colar grandes blocos de código crie classes
auxiliares (Helpper) e isole a funcionalidade para reaproveitamento sempre que possível.
10) Evite excesso de flags e booleanos de controle, eles são complicados de manter.
11) As classes de EJB que usam métodos transacionais possuem código de ROLL-BACK adequado?
12) As conexões e sessões JAPE estão sendo abertas e fechadas adequadamente?
13) Métodos que usam transação manual estão usando as técnicas e classes adequadas ?
14) As consultas feitas de maneira nativa (SQL nativo) estão usando o NativeSQL ?
15) A passagem de parâmetros para o NativeSQL está usando NamedParameters ?
16) As consultas embarcadas (SQL) muito longas estão sendo escritas em arquivo separado
(.SQL)?
17) A sintaxe SQL usada está considerando os dois BDs suportados pelo sistema? As macros do
JAPE podem ajudar?
18) As consultas que são usadas dentro de loops estão usando NativeSQL configurado de tal forma
que o Statement seja reaproveitado?
19) A solução criou muitas classes? São realmente necessárias tantas classes ou interfaces?
20) O nível de complexidade do código está aceitável ? Quando você olhar pra esse código daqui a
seis meses, você vai entender o que ele faz?
Script de revisão Java e Flex
Versão 1.0
2/6
SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
21) Listeners de entidade são executados sempre que houver mudanças na entidade independente
de onde elas ocorreram, portanto deve-se tomar cuidado para que a regra imposta no listener
possa ser executada sem problemas em todos os casos.
22) Está passando parâmetros para listeners usando JapeSessionContext ou JapeSession? Prefira
JapeSession.
23) Prefira trabalhar com null ao invés de strings vazios.
24) Nunca confie no banco de dados, o que é verdade em uma base não é verdade em outra.
25) NUNCA, JAMAIS, criar atributos de classes em EJBs do tipo Stateless (com excessão de
SessionContext) ou em classes de Servlets.
26) Padrão de fontes:
* Sempre usar o formatador de fontes do Eclipse usando o nosso padrão.
* Sempre usar o CTRL-O para organizar os imports.
* Não deixar trechos de código comentados sem necessidade.
27) Utilizar bem os comentários: coloque-os em trechos mais complexos e retire-os de trechos
óbvios.
28) Não deixar objetos sem referência e não reaproveitar referências de objetos.
Por exemplo:
Object obj1 = new Object();
Object obj2 = new Object();
obj1 = obj2;
29) Não programar no estilo procedural em uma linguagem orientada a objetos.
30) Não criar classes gigantes que façam tudo. Sempre que possível quebrar em tarefas menores e
preferencialmente que possam vir a ser reutilizadas.
31) Geralmente nomes de métodos possuem verbos e nomes de variáveis e atributos são
substantivos.
32) Não capturar exceções específicas, a não ser que elas tenham um tratamento diferenciado.
33) Não colocar as constantes em uma classe ou interface separada, elas devem ser colocadas em
classes cujo contexto faça sentido.
Script de revisão Java e Flex
Versão 1.0
3/6
SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
34) Evitar lançar exceções nos construtores de classes.
35) Se foi criado um serviço, verificar o request e o response.
No request deve-se ter atenção a parâmetros requeridos (Evitando NPE).
No response deve-se tomar cuidado com a estrutura para que não fique extensa.
36) Observar nos códigos se não foi feita duplicação de códigos que já existam em Helpers ou
Utils.
37) Evitar estruturas complexas Java ou Flex (como ENUM) desnecessariamente só para dizer que
a Sun não criou atoa.
38) Evitar códigos performáticos por demais e inatendíveis por de menos. Por exemplo, foi criado
um código muito problemático para ganho de performance, mas a sua manutenção ou
entendimento é incompreensível.
39) Todas as rotinas "genéricas" estão separadas em métodos?
Eventualmente um trecho de código pode ser reutilizado no futuro (mesmo que não esteja
sendo atualmente). Por isso, é uma boa prática separá-lo em um método da classe ou
mesmo um método utilitário.
40) A persistência é executada através do Jape? Persistência manual (direto pelo jdbc) deve ser
evitada.
41) Há utilização de componentes/métodos depreciados?
42) Manipulação de XML é feita com ajuda do XMLUtils?
Utilizar os métodos da classe XMLUtils para evitar verificações de nullPoiter excessivas.
Revisão de fonte Flex
1) Atributos privados de classe devem começar com
_
2) Atentar para as chamadas de serviço, pois elas são assíncronas.
3) Evitar arquivos .mxml grandes, pois fica difícil a leitura. Além disso, o Flex Builder tem
dificuldade em parsear e algumas funcionalidades param de funcionar (syntax highlighting e code
assist).
4) Applications e Modules devem ser colocados diretamente na pasta
Script de revisão Java e Flex
Versão 1.0
src do projeto.
4/6
SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
5) Componentes visuais, mesmo que implementados em .as, devem ser possíveis/fáceis de serem
utilizados no .mxml.
6) Dê preferência aos nossos componentes (SanTree, SanPopUp, DefaultSankhyaApplication,
ConfigurableDataGrid) ao invés dos equivalentes nativos do Flex.
7) Constantes devem ser const e não var. Além disso, devem ser nomeadas em caixa alta.
8) Evitar o uso de [Bindable], pois na maioria das vezes não funcionam como esperado.
9) Sempre que for criar um componente novo, fazer um post explicativo no blog.
10) Observar a utilização de 'this' dentro de closure, pois ele não se refere à classe externa.
11) Evitar aninhamento de closures.
12) Evitar carregar campos desnecessários no DBDataSet.
13)
Remover
imports
desnecessários
nas
classes,
pois
o
Flex
Builder
não
faz
isso
automaticamente.
14) Imagens e outros recursos devem ser colocados em pastas 'assets'.
15) Dados numéricos não assumem valor null e sim NaN (Not a Number).
16) Quando for utilizado regex, verificar se os flags (g, i, etc.) foram utilizados corretamente.
17) Verificar NPE em componentes como ViewStack, TabNavigator e Accordion, cujos filhos são
construídos de maneira "lazing".
18) Evitar que o conteúdo fique "grudado" no container, definindo paddings no container.
19) Antes de acessar uma propriedade de um objeto dinâmico, utilizar o método hasOwnProperty
para certificar-se que o objeto possui tal propriedade.
20) O DataSet recebe critérios estáticos através de Critéria provider?
21) A aplicação anula o método DefaultSankhyaApplication.loadByPk corretamente?
Carga inicial do DataSet deve ser feita por este método, pois o ambiente tentará carregar
um registro através deste mecanismo. Para resolver o problema da sincronização entre a
carga de metadados do dataset e a carga de dados, utilizar a classe utilitária
"PKCriteriaLoader" que faz a sincronização pelo método "refreshDataset".
22) Controle de acesso é feito pelo DefaultSankhyaApplication?
23) As colunas do Datagrid são criadas manualmente (quando não é Dynaform)?
Script de revisão Java e Flex
Versão 1.0
5/6
SCRIPT PARA REVISÃO DE FONTES JAVA E FLEX
Data: 08/11/2010
Versão: 1.0
ASSUNTO: Script de Revisão de fontes
24) O layout da tela compreende todos os componentes padrões (quando não é Dynaform):
PersonalizedFilter, GridConfig, GridPrinter, etc.?
25) Duplo click do grid coloca o DoubleFacePanel em modo formulário?
26) Controle de acesso está sendo respeitado (quando não é Dynaform)?
27) Os pop up’s criados pela aplicação usam SanPopUp?
Script de revisão Java e Flex
Versão 1.0
6/6