O título desse post é o título do capítulo 10 do livro “Getting Real“, da empresa americana 37signals.
A 37signals é uma empresa americana sediada em Chicago, focada em desenvolvimento de aplicações web de produtividade para empresas e para uso pessoal. Seu carro chefe é o Basecamp, solução de gestão de projetos e a partir desse produto ele lançaram o framework Rails para Ruby, criando assim o Ruby on Rails, sobre o qual temos falado com alguma frequência aqui no tecblog.
O Getting Real ou, em português, Caindo na Real é um livro escrito pelos donos da 37signals e fala sobre sua filosofia de desenvolvimento de aplicações web. O livro fala sobre tudo que envolve o desenvolvimento de uma aplicação web, desde sua concepção até a manutenção pós-lançamento.
Ele pode ser lido na íntegra em inglês, em português, ou em vários outros idiomas. Você ainda pode comprar um PDF, ou mesmo uma cópia física desse livro.
Esse livro é leitura (e releitura) obrigatória para qualquer pessoa que queira fazer uma aplicação web de qualidade.
Abaixo vou colocar o capítulo que emprestou o título para esse post para ilustrar um pouco do conteúdo desse livro.
Menos Software
Mantenha seu código o mais simples possível
É bastante razoável pensar que um software com o dobro de código seria apenas duas vezes mais complexo. Mas na verdade, à medida que se aumenta a quantidade de código, a complexidade do software tende a crescer exponencialmente. Cada pequena adição, cada nova interdependência, cada nova preferência amplia o efeito cascata. Adicione código desenfreadamente à sua aplicação, e antes que você perceba, você terá criado uma grande e desgovernada bola de neve.
A melhor maneira de se enfrentar a complexidade é com menos código. Menos software significa menos funcionalidades, menos código, menos desperdício.
A chave está em repensar qualquer problema difícil que venha a necessitar de uma grande quantidade de componentes para ser solucionado em um problema mais fácil, que requeira muito menos. Você pode acabar não solucionando exatamente o mesmo problema, mas tudo bem. Resolver 80% do problema original despendendo 20% do esforço é uma vitória e tanto. O problema original raramente é tão crítico de forma a realmente merecer cinco vezes mais esforço em sua solução.
Menos software é a melhor maneira para aposentar a sua bola de cristal. Em vez de tentar prever problemas futuros, lide apenas com os problemas de hoje. Por quê? A maioria dos medos que você tem a respeito do futuro raramente tornam-se reais. Não perca seu tempo tentando solucionar estes problemas-fantasma.
Desde o início, desenvolvemos nossos produtos ao redor do conceito de pouco software. Sempre que possível, simplificamos os problemas mais difíceis. E descobrimos que a solução para problemas mais simples não é somente mais fácil de implementar e suportar, como também de entender e usar. É tudo parte de uma estratégia para diferenciar-se dos competidores: em vez de focar-se em produtos que fazem mais, construímos produtos que fazem menos.
- Menos software é mais fácil de gerenciar.
- Menos software reduz a quantidade de código e isso significa menor carga de trabalho de manutenção (e uma equipe mais feliz).
- Menos software reduz os custos de mudança, de forma que você pode adaptar-se rapidamente. Você pode mudar de idéia sem ter que mudar milhões de linhas de código.
- Menos software resulta em menos bugs.
- Menos software significa menos suporte.
A escolha de quais funcionalidades incluir ou omitir também tem muito a ver com a quantidade de software. Não tenha medo de dizer “não” a solicitações de funcionalidades difíceis de serem implementadas. A menos que elas sejam absolutamente essenciais, economize tempo, esforço e muita confusão deixando-as de fora.
Vá devagar, também. Quando surgir uma nova idéia, não tome nenhuma ação por uma semana, e ao final veja se a idéia ainda parece tão brilhante. O tempo extra em “banho maria” geralmente ajudará seu cérebro a pensar em uma solução mais simples.
Encoraje programadores a pensar em contra-propostas
O que se deseja ouvir é: “A maneira como você sugeriu levará 12 horas para ser implementada. Mas há um jeito de fazer que vai levar só uma hora. Não vai fazer x, mas vai fazer y.”. Deixe o software dizer “não”. Encoraje os programadores a lutarem pelo que eles pensam ser a melhor maneira.Também busque por alternativas a ter que escrever mais software. Seria possível mudar um fluxo de telas de modo que elas sugiram uma rota alternativa para os usuários que não requeira mudanças no modelo do software? Por exemplo, seria possível sugerir que as pessoas façam upload de imagens de um tamanho específico, em vez de ter que manipular as imagens no lado do servidor?
Para cada nova funcionalidade de sua aplicação, pergunte-se se não existe uma maneira de se produzir o mesmo resultado e que não requeira tanto software. Escreva apenas o código que precise, e nada mais. Sua aplicação acabará bem mais magra e saudável.
NÃO existe código mais flexível do que NENHUM código!
O “segredo” do bom projeto de software não estava em saber o que codificar; estava em saber o que NÃO codificar. Estava em saber o que deixar de fora! Estava em perceber quais os pontos que necessitariam de mais flexibilidade e quais não, e então deixar espaço para futuras mudanças, em vez de tentar expandir mais e mais o design.
—Brad Appleton, engenheiro de software
(de There is No CODE that is more flexible than NO Code!)
Complexidade não aumenta linearmente com o tamanho
A regra mais importante da engenharia de software é também a menos conhecida: a complexidade não cresce linearmente com o tamanho. .. Um programa de 2000 linhas requer mais do dobro do esforço de desenvolvimento que um programa com a metade do seu tamanho.