rails checklist

Todas as funcionalidades utilizadas em dois ou mais models devem ser transformadas em uma library ou module (biblioteca ou módulo).

Talvez a grande vantagem de Ruby sobre linguagens similares a Java são mixins(modules). Não ignore isso - aproveite isso ao máximo.
No OO estilo-Java, pra conseguir funcionalidade compartilhada entre classes, você geralmente tem que fazer subclasses. Este não é o caso. Em ruby você pode embutir (com mixins) funcionalidades de vários modules diferentes em qualquer classe ou objeto - até em tempo de execução. Entenda modules bem, e utilize-os para compartilhar código duplicado entre models (e controllers)!


Toda a lógica duplicada entre duas ou mais aplicações deve ser transformada em um plugin gemificado.

Agora que plugins podem ser gemificados, não existe mais razão para não fazer plugins. Eles são fáceis de fazer, e agora muito fáceis de *reusar e gerenciar nos seus diversos deployments*.
Ao contrário de outros frameworks, os plugins do Ruby on Rails são extremamente leves e fáceis de escrever. Vale a pena fazer um plugin, mesmo que seja apenas um module de 5, 6 linhas.
E provavelmente ele torna seu código fácil de migrar, se você mudar para outros frameworks Ruby, como Merb.


STI nunca é usado. Nunca.

*Eu já vi muitas aplicações rails*. Nunca vi uma onde usar STI (Single Table Inheritance) *era a decisão correta*. Nunca. Eu vejo isso mais frequentemente quando alguém é novato, e acha STI maravilhoso pra compartilhar código.
Mas em rails, é muito fácil adicionar colunas a tabelas e compartilhar código entre model sem STI.
Ao invés disso, você deveria gerar models diferentes, e usar um ou dois modules para qualquer *lógica correta* entre eles. Use partials comuns para compartilhar código de views. Se você utilizar STI, vai conectar para sempre os dois models de um modo que é muito difícil de ser desfeito - uma migração de dados nunca é divertida.
Associações polimórficas, entretanto, são encorajadas!


Qualquer decisão de projeto deve ser o mais simples possível para as necessidades atuais dos usuários. Nenhuma funcionalidade futura foi desenvolvido na aplicação.

Outra fora de dizer isso é O Modo Rails (The Rails Way). E esse paradigma é tanto para os Gerentes de Projeto quanto para os Desenvolvedores - *mas ambos têm a responsabilidade de certificarem-se que isso está sendo cumprido*.
Apesar de que o Capítulo 4 de Caindo na Real (Getting Real) explicar isso melhor do que eu jamais poderia - para resumir. Se você tentar adivinhar as coisas, ao invés de ater-se aos fatos, algumas dessas advinhações estarão, invariavelmente, erradas. *Some might be right, but any designing and development that are for wrong guesses make things more complex, harder to fix, and harder to improve.*
Ao invés disso, faça o código pra o que você sabe que é verdadeiro, lance logo, analise os usuários e faça iterações rapidamente. Esse é um dos maiores benefícios de aplicações web sobre aplicações desktop - então aproveite essa vantagem.