terça-feira, 16 de setembro de 2008

Criatividade & Produtividade, cada caso tem sua hora

Ao se deparar com um problema no desenvolvimento de um sistema, qual a melhor e mais sustentável maneira para se encontrar uma solução? Buscar na literatura ou colocar os miolos para funcionar e desenvolver sua própria solução?


Olha só o que diz Leonardo Kenji:


Criatividade e Design Patterns September 15, 2008 1:16 pm

Ninguém pode negar que os Design Patterns, ou “padrões de projeto” ou “padrões de desenho”, formalizados no famoso livro do GoF (gang of four - a turma dos quatro, ou Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) foi uma mudança muito significativa em toda a indústria de software. A proposta era simples: uma vez estudadas diversas práticas de programação de “bons programadores”, eram identificadas algumas técnicas de design inteligentes que sempre apareciam mais ou menos de forma parecida para resolver problemas parecidos. Cada padrão era estudado e, voilá, junte vários destes e classifique-os e você tem um manual de “boas maneiras” para o desenvolvimento de software.

O benefício imediato, óbvio, é que ao se deparar com um problema de design, o desenvolvedor não precisa pensar numa solução do zero. Basta ir no compêndio de design patterns e procurar qual design resolve que tipo de problema.
Outro benefício indireto, mas igualmente importante, é trazer uma série de nomes para determinadas estruturas mentais, que facilitam a comunicação entre desenvolvedores. Ninguém precisa ficar explicando o que é um singleton se todo mundo já sabe o que é. Ganha-se tempo e leva-se a discussão um nível acima. E daí você pode ter ferramentas que automatizam a geração destes códigos, discussões acerca das vantagens e desvantagens de cada pattern, e etc.

Hoje em dia, existem patterns para praticamente todas as áreas específicas do desenvolvimento de software. É uma forma de reuso do conhecimento. Mas como tudo na vida, nem tudo é perfeito. Alguns anos atrás, eu estava conversando com um economista e falando dessa coisa de design patterns, e o cara mostrou uma cara de espanto, e falou: “que engraçado… em algumas situações na economia, pedimos para o aluno nunca procurar as soluções prontas, mas sempre tentar encontrar a solução por ele mesmo primeiro, para só depois recorrer à literatura… assim incentivamos a criatividade dos alunos e forçamos eles a pensarem…” Pode parecer improdutivo, e de fato, na engenharia de software, é uma bela vantagem ter na manga uma série de soluções prontas que “funcionam comprovadamente” e não perder tempo reinventando a roda.
Mas do ponto de vista criativo, assumir que os design patterns estão sempre certos, ou que são sempre a solução, também é uma faca de dois legumes. A postura do inovador deve ser sempre questionadora.
Haveria maneira melhor de resolver este problema? Este design pattern é realmente o mais adequado para a minha demanda? Quais são os fatores que poderiam levar este design a uma possível desvantagem? Quais tipos de problema poderiam advir do uso desta solução?
Se seu negócio é prazo, ficar pensando demais é perder tempo. Mas se seu negócio é inovar e criar soluções que sejam vantajosas diante do que é praticado em toda a indústria, nem sempre seguir o que existe pode ser a vantagem. E no fim das contas, espírito crítico nunca faz mal a ninguém.
--