Sun 16 Nov, 2008
Checklist de Qualidade do Código Ruby On Rails - Parte 1
by Abraão CoelhoFiled under: Aprendendo Rails, Rails
Tags: good practices, Rails
Checklist de Qualidade do Código Ruby On Rails - Parte 1 (original)
Práticas que sua equipe de desenvolvimento precisa aderir
Na minha experiência, Ruby e Ruby On Rails têm sido um das mais difíceis combinações linguagem/framework para realmente dominar. Para alguém que cresceu com C, C++ & Java na maior parte de seu treinamento, Ruby tem uma forma bastante diferente (e melhor!) de design OO, e o framework Rails tem muitas opiniões a serem entendidas e lembradas. Por mais tempo que leve para dominá-las ao nível em que estou – e tenho certeza que ainda tenho um logo caminho – eu adoro e não irei voltar atrás.
Eu tenho uma leve suspeita que enquanto Ruby On Rails continuar crescendo em popularidade, existirão muitos desenvolvedores presos na mentalidade OO estilo Java, muitos desenvolvedores que estão apenas aprendendo; e isso é uma Coisa Muito Boa. É também uma coisa ruim, porque código ruim gera outros códigos ruins quando publicado e visto por outros.
Enquanto ThriveSmart contrata mais desenvolvedores – nem todos experts em Ruby ou Rails – cria-se uma necessidade crescente de se assegurar que o código e as estratégias de design mantenham um nível extremamente alto de qualidade através dos diferentes projetos. Meu bom amigo Dan e eu reunimos essa checklist que espera-se que todas as nossas equipes assinem em cada um de seus projetos. É uma lista em evolução, mas aqui está uma “imagem” atual.
Checklist de Qualidade Ruby On Rails
1. Cada action do controller chama apenas um método do model além do find ou new.
(Faça métodos .new ou .update customizados no modelo com todo o necessário.)
2. Somente uma ou duas variáveis de instância são compartilhadas entre cada controller e view.
3. Todos os nomes de models e variáveis são imediatamente óbvios (para um novo desenvolvedor) e tão curtos quanto possíveis sem usar abreviações.
4. Todos os “finds” customizados acessados em mais de um lugar no código usam named_scope ao invés de um método customizado.
5. Um .find ou .find_by_ nunca é chamado numa view ou view helper.
6. Há zero código customizado que duplica uma funcionalidade de uma função já existente no Rails.
7. O código tem sido agressivamente enxuto durante o desenvolvimento. (ver DRY)
8. Toda funcionalidade usada em um ou mais models foram transformadas em bibliotecas/módulos.
9. Toda lógica duplicada entre doisou mais aplicativos foram transformados em um “plugin gemificado”.
10. STI não é usado em qualquer/todo lugar.
11. Toda escolha de design deve “carregar” o design mais simples possível para a necessidade dos usuários no momento atual.
(Tentativas de adivinhar futuras funcionalidades não foram desenhadas na aplicação)
12. Cobertura de testes próxima de 100% no mais alto nível da aplicação: dentro e entre as actions do controller.
13. Todos os testes passam antes do código ser agregado [merged] ao repositório compartilhado.
14. Todos defeitos corrigidos em um produto em produção tem testes adicionados para prevenir regressão.
15. Todo plugin instalado teve seu código revisto.
Eu certifico que todo o acima é verdadeiro para o meu projeto.
[Nome Impresso] [Assinatura]
Explicações
A esperança é que cada item nessa checklist seja tão óbvio para o desenvolvedor Ruby On Rails que nem valha a pena mencionar - mas para o novo desenvolvedor Ruby On Rails, os ítems na lista são não-óbvios e necessitam alguma explicação: Então aqui estão:
———-
Bom pessoal, daqui em diante irei “explicar” (com a tradução) cada um deles e em seguida irei colocar os ítens restantes. Talvez hoje ainda coloque um ou dois ítens, depende mesmo de como for o trabalho que tenho que entregar amanhã =D
green card says:
Há alguma informação sobre este assunto em outras línguas?
Abraão Coelho says:
No título do artigo tem o link pro original, em inglês… Semestre tá acabando, logo continuo com essas traduções. Até lá só me resta sobreviver =)