PrincÃpios do Rails
Rails é baseado em uma série de princÃpios, práticas e filosofias. A maioria já existia, mas foi a partir da popularização do Rails que esses conceitos foram alavancados e passaram a ser conhecidos também em outras comunidades de desenvolvedores.
Isso nos leva à conclusão de que, perdurando ou não, Rails cumpriu seu papel: quebrar paradigmas, contribuir para uma geração de desenvolvedores mais competentes e valorizar o pragmatismo ao invés da burocracia e lentidão do mundo corporativo.
Conheça abaixo alguns princÃpios do Rails e do desenvolvimento ágil em geral:
Don’t Repeat Yourself – DRY (Não se repita)
Talvez o princÃpio mais famoso do Rails, diz que você não deve repetir trabalho em sua aplicação, seja código, seja configuração ou qualquer outro aspecto. Quando você começa a copiar e colar coisas em vários lugares, é um forte sinal de que algo está errado. Hora de refatorar.
Convention over Configuration (Convenção sobre configuração)
Outro ponto chave no framework. Como David Hansson diz, flexibilidade é superestimada, convenções são libertadoras.
O benefÃcio desse princÃpio no Rails é que, desde que siga as convenções do framework, o desenvolvedor fica livre de todo o trabalho “chato” de configuração (quem não conhece as milhares de linhas de XML dos frameworks Java?) e pode se concentrar no que importa: a solução do problema.
Tiny Controllers, Fat Models (Controllers magros, modelos gordos)
Uma prática um pouco especÃfica do Rails, com sua estrutura MVC, mas acho interessante mencionar também. Essa prática força a reeducação dos desenvolvedores e estimula o saudável hábito de restringir tudo o que é referente ao domÃnio do problema aos modelos. Controllers devem ser responsáveis apenas pelo controle de fluxo na aplicação.
Keep It Simple, Stupid! – KISS (Mantenha simples, estúpido!)
Esse princÃpio, com raÃzes militares, estabelece que a simplicidade deve ser um objetivo chave de todo projeto e qualquer complexidade adicional deve ser evitada ou eliminada.
Baseia-se fortemente na Navalha de Occam e na célebre frase de Einstein: “tudo deve ser o mais simples possÃvel, mas não simplificado”.
Leia mais: http://en.wikipedia.org/wiki/KISS_principle.
You Ain’t Gonna Need It (Você não vai precisar disso)
Estabelece que uma funcionalidade não deve ser adicionada ao produto até que esta seja totalmente necessária.
Todo desenvolvedor de software tem os momentos “Nossa, seria muito legal se a aplicação fizesse …” e então horas e horas são gastas em algo que não é necessário e que pode causar problemas depois.
Leia mais: http://en.wikipedia.org/wiki/You_Ain’t_Gonna_Need_It
Desenvolvimento iterativo e incremental
Acredito que todos já conhecem. O desenvolvimento iterativo e incremental é base das metodologias ágeis e traz inúmeras vantagens. Rails foi retirado de um produto desenvolvido num processo ágil. A agilidade corre nas veias desse framework.
Leia mais: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Build Less (Desenvolva menos)
Um resultado de todos esses princÃpios, práticas e filosofia é o conceito de fazer menos software. Isso não significa fazer algo pela metade nem fazer de qualquer maneira, significa fazer o essencial e muito bem feito.
A empresa sÃmbolo disso é a 37signals. O livro “Getting Real” tem um capÃtulo inteiro dedicado ao assunto, vale a pela conferir.
Nenhum comentário até agora