Invente menos problemas!
O açucar União está com uma campanha publicitária chamada Viva Momentos de União, que possui mensagens que fazem alusão a situações de prazer e bem-estar, realçando a importancia da qualidade de vida e tudo mais. Não se preocupem, não vou escrever sobre açucar!
No projeto Lucidus os nossos sachês de açucar pro café são da União e cada um vem com uma mensagem, entre elas essa que eu achei brilhante:
Invente menos problemas.
E aí isso me remete, como desenvolvedor, ao nosso velho problema de querer sempre complicar as coisas. Há um bom tempo que estudo XP, mas foi somente nos últimos meses que tive a oportunidade de ver na prática como a coisa funciona. Desde que entrei para o projeto Lucidus meus conceitos sobre como desenvolver software mudaram muito, do meu ponto de vista para melhor, claro.
XP possui como um de seus valores a simplicidade. A idéia é implementar as coisas da forma mais simples possível, sem preocupar-se com o amanhã ou com tentar prever quais funcionalidades, métodos ou funções serão necessárias no futuro. É preocupar-se apenas em resolver o problema de agora de forma simples. Isso puxa(ou o inverso) uma das práticas do XP, o design incremental.
Quando estudei engenharia de software tradicional na universidade “aprendi” que o design deveria ser sempre feito antes da implementação. Então deveria-se planejar(o sistema, as classes, os patterns, a base de dados, os relacionamentos, etc) numa tentativa de prever o rumo que o projeto iria levar. Felizmente aprendi cedo de que isso na teoria é muito bonito, mas na prática não funciona. Quer queiram ou não, os projetos de software sempre sofrem mudanças na hora da implementação. Mudanças essas que podem ser drásticas a ponto de toda documentação/projeto que foi escrito não servir mais para nada, por não refletir a realidade do projeto.
Quando em XP dizemos que trabalhamos com design incremental do software, não estamos dizendo que não usamos patterns… Isso apenas quer dizer que decidimos que patterns utilizar na hora em que de fato precisarmos dele. O uso contínuo da refatoração nos leva aos patterns.
Há alguns anos atrás eu trabalhava(leia-se ganhava dinheiro) apenas com Java e, por coincidência ou não, muitas das pessoas com que trabalhei e empresas por onde passei possuiam essa mesma cabeça da engenharia de software tradicional e passavam meses projetando e montando o ambiente de trabalho antes de que qualquer linha de código útil fosse escrita.
Felizmente, mais uma vez, há 2 anos eu descobri o Ruby e o Rails. Descobri que as pessoas que trabalham com Ruby e Rails seguem fielmente a linha da simplicidade, dos princípios DRY e KISS. Descobri que Rails se encaixa como uma luva no XP. Então a frase do dia é:
Invente menos problemas. Use Rails!
12.01.2008 03:55 PM
January 12th, 2008 at 09:49 PM
Oi, Mergulhão.
Há algum tempo alguém, acho que foi o Marcelo Alvim, me fez notar um detalhe interessante sobre padrões de projetos. Em inglês, há duas palavras distintas para se referir a padrões.
A palavra pattern se refere, sobretudo, à padrões que são reconhecidos, que se repetem e representam exemplares de alguma coisa ou evento.
A palavra standard, por sua vez, tem mais a ver com uma normatização técnica criada por algum órgão para definir como deve ser executada uma ou mais atividades. Freqüentemente as normas criadas definem, por exemplo, critérios de qualidade. Aqui no Brasil, por exemplo, a ABNT é responsável pela definição de inúmeros padrões (normas técnicas).
Em inglês, quando alguém fala de design patterns, fica claro que se está tratando de reconhecimento de padrões. Ou seja, você faz algo no software, percebe um padrão e, como conseqüência, aplica um design pattern previamente conhecido.
Aqui no Brasil, essa distinção não fica clara, porque em português só há a palavra padrão para representar os dois significados mencioados acima. Muita gente interpreta, erroneamente, que padrões de projeto são normas de construção de software que precisam ser seguidas. Padrões não têm que ser seguidos, eles têm que ser reconhecidos no software. Quando são reconhecidos, podemos aplicá-los.
Design pattern é algo que está muito associado à refatoração. Você reconhece algo que está acontecendo no código, percebe que está parecendo um pattern conhecido e, eventualmente, refatora para que o código passe a ter aquele pattern.
Em resumo, design patterns não são building blocks de código. Não temos que construir software apenas compondo patterns. Nós os usamos quando eles são reconhecidos e não como bloquinhos que precisam ser colocados uns sobre os outros. É aí que muita gente acaba errando.
A propósito, excelente post! :-)
Grande abraço, Vinícius.
September 26th, 2008 at 06:20 PM
Infelizmente, o que normalmente acontece é que a galera fica procurando onde encaixar design patterns antes mesmo de escrever algum código…