Getting Real, o princípio K.I.S.S. aplicado em metodologia
Faz pouco mais de 4 meses que comecei a utilizar Rails em alguns projetos, mas Java ainda é minha linguagem do coração, e algo que me surpreendeu muito foi a filosofia por trás do Rails, ele não é um framework matador de horda de dragões, e não é pra ser mesmo, seu próprio criador David Heinemeier Hansson não tem a intenção de adicionar um milhão de funcionalidades, e tem motivo pra isso, trabalha na 37signals, prercursora da metodologia Getting Real, uma verdadeira aula de como evitar a burocracia e extrair muita produtividade, considero o livro radical em alguns pontos, mas isso é questão de opinião, e é claro adequação à realidade do seu projeto.
E aqui cabe a pergunta, você não está fazendo coisas demais no seu projeto ?
Os frameworks hoje em dia parecem querer abraçar o mundo, querem estar em todos os tipos de projetos, seus criadores prometem funcionalidades novas e/ou extravagantes a cada dia, e nessa vontade de fazê-lo crescer, vai tornando-o apenas cada vez mais “gordo”, de difícil manutenção, e com isso nenhum projeto é ajudado. Sem contar a ausência de testes em muitos deles. Não quero dizer que Rails é o melhor de todos, estou citando apenas a filosofia por trás dele, há outros frameworks ótimos no mercado, tudo depende de pensar no que essencialmente o projeto precisa e com isso encontrar o framework correto.
Uma resposta para a enorme “gordura” de alguns frameworks é sempre: “Seu projeto tende a crescer, você vai precisar dos demais recursos oferecidos”. Sinceramente não gostaria de precisar usar tudo, não quero complexidade demais no projeto só para ganhar mais manutenção. Gosto da filosofia K.I.S.S. (Keep It Simple Stupid). O que o meu cliente vai ganhar com esta funcionalidade X ? Ela é realmente é necessária ? Quanto mais simples, menos manutenção, mais tempo você tem para funcionalidades novas e simples.
Vocês podem pensar que isso é preguiça mas não é, recentemente houve um caso interessante, eu precisava adicionar um editor de texto na aplicação, escolhi o excelente FckEditor, ele possui ótimas funcionalidades para um editor de texto em browser, a primeira coisa que fiz foi reduzir a quantidade de botões. Apresentei ao cliente, ele usou um pouco e disse “acho que o pessoal vai estranhar um pouco a princípio, tem como melhorar o layout ?”, mas o problema não era layout, observando como ele usou a ferramenta reduzi novamente a quantidade de botões para ter apenas o que ele realmente precisava e apresentei novamente. O resultado: “Puxa o layout melhorou mesmo, mais intuitivo”, ele nem reparou que a quantidade de botões foi diminuída, eu apenas apresentei o que ele precisava, e nem uma linha a mais. Se o seu cliente precisa de uma funcionalidade supérflua, que ele pediu por impulso, convença-o do contrário, ou ambos sofrerão com uma funcionalidade que talvez nem seja usada, está lá apenas para formentar a entropia.
É como o novato que lê um livro sobre padrões de projeto e acha que deve usar todos de uma vez, é necessário pensar no básico. Keep It Simple!
Refatorando Padrões » Blog Archive » Sem reinventar a roda, cache de páginas com EhCache e ServletFilter said,
May 3, 2007 @ 9:01 am
[...] Refatorando Padrões Programação orientada às melhores práticas « Refatorando Padrões home page « Getting Real, o princípio K.I.S.S. aplicado em metodologia [...]