Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.
Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Qual foi o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.
Tenho dedicado os últimos anos a ministrar treinamentos, sejam pela eGenial ou para equipes em empresas. No ano passado participei de treinamentos com mais de 100 pessoas e só no começo deste ano foram mais quase 100.
Treinar tanta gente é uma experiência fantástica pois em nenhum emprego eu poderia ver o fonte de tantas pessoas, conhecer tantos problemas diferentes e aprender com os erros dos outros e propor soluções antes mesmo de aconteçam comigo.
Mas uma coisa tem me assustado muito: NOMES. Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.
Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Qual foi o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.
Então, o primeiro fator que considero para desenvolver OO corretamente é como você deve nomear e simular o mundo real através do seu código.
Mas como nomear corretamente as coisas?
A funcionalidade do Rails que acho mais fantástica é a preocupação de manter a característica do Ruby de ser legível. Temos métodos como validates_presence_of ou has_and_belongs_to_many ao invés de apenas vpo ou has_blg. Esta preocupação fica mais clara ainda se pensarmos nas tabelas, models e controllers.
Tabelas no Rails praticamente só servem para persistir objetos (reparem: objetos no plural) por isso elas são nomeadas no plural (customers, transactions, teachers, etc) enquanto a classe (class é um esqueleto para um objeto) e como ela criará um objeto por vez ela é nomeada no singular (Customer, Transaction, Teacher).
Métodos são operações que o objeto pode realizar, logo devem ser ações como calculate, find, sum enquanto propriedades/atributos são características do objeto que consequentemente devem ser nomeadas como tal. Seus accessors devem ter nomes de propriedades como name, age, value e etc. Se existe uma variável que é um verbo/ação então simplesmente seu código está errado e não tem significado como um objeto.
Já sabemos como nomear tabelas, classes e como a prática do Rails é muito boa para manter o código legível. Mas o que são controllers?
Um controller é uma forma de expor ao mundo os seus objetos do sistema e ao pensar como organizar seu controllers você deve ter isto em mente (por isto o Rails é REST e não apenas para expor uma API qualquer). Suas actions do controller devem ser ações mesmo, ações que vão ser executadas em seus objetos para poder mostrá-los ao mundo.
Se você tem uma action chamada “calculos” o nome simplesmente está errado, isto não é uma ação. Se você pensar em um controller como expositor de seus models com views então o método “calculos” está até no local errado, ele deveria estar dentro do model de BankAccount por exemplo e o controller apenas obtém o valor retornado pela ação calculate de um objeto da classe BankAccount. Neste exemplo a preocupação com nomes nos ajuda a colocar os métodos nos locais corretos criando uma boa arquitetura.
Código deve ser legível mesmo quando o sistema se tornar legado.
Qualquer sistema se torna legado, mesmo ele sendo escrito em Rails 3.0beta hoje, daqui a uma semana ele é legado e você não se lembrará de boa parte do que foi escrito lá.
Um desenvolvedor é um escritor e seu código (principalmente em Ruby) são frases que dizem o que deve acontecer. Se você não nomear seus métodos, objetos e variáveis da forma correta mais cedo ou mais tarde nem mesmo você entenderá um código que escreveu (experiência própria) quanto mais outro desenvolvedor.
Outro fator que destrói a legibilidade são os resumos. Um helper como options_for_select que cria options para um select do html poderia ser resumido para opt_select ou has_many poderia ser h_many. Mas estes resumos são extremamente prejudiciais e tornam o fonte impossível de ler futuramente.
Então sempre escreva o fonte como um manual e pensando em outra pessoa que venha a le-lo ao invés de pensar em você mesmo. Isto evitará o problema acima e mesmo daqui a 1 ano você voltará no código e entenderá tudo na primeira leitura.
Por que escrever fonte em Português é péssimo?
Nos treinamentos percebo que muita gente tenta escrever código Ruby em Português. O grande problema disto é que você terá algo assim: Pessoa.find_all_by_nome. Se você pensar em seu código como um simulador do mundo real que apenas contem instruções de como as coisas devem acontecer está óbvio que o seu simulador está “manco”.
Pessoa.find_all_by_nome não diz nada nem em Português e nem em Inglês. Logo é uma falha de arquitetura, e principalmente em Ruby, seu código acabou de perder a legibilidade da linguagem, que o Rails mantém e você acabou de destruir.
Como é impossível escrever tudo em Português então evite escrever qualquer coisa em Português. Desta forma você não terá um simulador “manco” que não descreve nada em linguagem nenhuma. Claro, termo técnico ou da regra de negócio como CPF, CNPJ e outros devem ser mantidos em Português ou na linguagem que for mas outras coisas como enturmação em uma rede social de alunos deveria ser representado como membership. Caso contrário você terá uma bizarrice como está:
class Estudante < ActiveRecord::Base has_and_belongs_to_many :enturmacoes end
ao invés de
class Student < ActiveRecord::Base has_and_belongs_to_many :memberships end
Evitando este tipo de arquitetura ruim: Estudante.first.enturmacoes.all(:conditions=>…). Ao ler esta frase (isto deveria ser uma frase) não existe nenhum significado em Português e nem em idioma algum, logo você tem um erro de nomenclatura e seu simulador do mundo real está manco, não representa a realidade e mais cedo ou mais tarde você estará dando manutenção em um sistema que apenas você entende.
Por favor não me venha dizer que é patriota e que o idioma do seu país é Português. Se você pensa assim deveria escrever class em japonês ao invés de Inglês já que o Ruby é uma linguagem Japonesa. Seu código é escrito para os outros e a única garantia que qualquer pessoa entenderá é escrevendo-o semanticamente correto e como a linguagem de programação já é em Inglês escreva-o em Inglês.
Também não existe problema algum se seu Inglês não é fluente. Tenha um dicionário a mão e tudo estará resolvido.
Conclusão
Não tenho vergonha em dizer que escrevi vários sistemas de 4 ou 5 anos atrás que por não ter seguido uma boa arquitetura o código é terrível e de difícil leitura. E pensando em arquitetura que me apaixonei por Ruby e consequentemente Rails, com eles é simples escrever um código que será fácil de ler mesmo daqui a 3 anos.
É sua obrigação fazer o código funcionar mas também é sua obrigação subdividir seus arquivos em pastas que fazem sentido, criar classes, templates e escrever código semanticamente correto, como um livro. Isto tudo é arquitetura do projeto e não apenas frescura, é preocupação com manutenção futura.
Esta regra o ajudará a identificar o que são método, o que são variáveis, objetos e onde colocar estas coisas.
Então pense 2 ou 3 vezes antes de escrever um método ou classe e não tenha vergonha em gastar mais horas do seu dia pensando em como organizar seus models e controllers do que escrevendo dezenas de linhas de código.
). Quase morri de rir assistindo à trívia.
. Estou morrendo de saudades da minha esposa e agora volto para casa. 
