engenharia de software

Há um tempo atrás eu criei um artigo sobre o que é e como utilizar o decorator pattern. Ele fazia parte de uma série de posts sobre design patterns que iniciei.

Dando continuidade a esta série, hoje vou mostrar um exemplo mais real do uso dele e que talvez explique melhor a sua utilidade. O post antigo mantém-se, porém este vai ilustrar um pouco melhor.

Bom, para relemebrar: o decorator pattern tem como intenção mudar ou adicionar comportamentos de um determinado objeto sem precisar modificar sua classe.

O exemplo utilizado aqui foi retirado "do mundo real" e adaptado para o post. Acontece que um usuário poderia marcar a ordem e quais compressões um determinado arquivo deveria sofrer. Entre as possibilidades, estavam o Gzip e o Bzip.

Existem maneiras e maneiras de se resolver este problema. A escolhida foi utilizando o Decorator para retornar o conteúdo do arquivo comprimido e seu nome final, já com as extensões .gz e .bz2 definidas.

Bem, é notável o crescimento das metodologias ágeis de desenvolvimento de software. Uma das práticas que me agrada muito, é a programação em pares (pair programming). É bem perceptível, a um longo prazo, a diferença que faz essa prática. Navegando pela internet, como um marujo sem rumo, encontrei um post falando sobre Remote Pair Programming. Parece meio estranho, porque o XP (eXtreme Programming) faz alusão a uma dupla programar em um único computador, com um único teclado e um único mouse.

Faz um tempo que quero escrever algo sobre engenharia de software, pois tenho aprendido muito disso nos últimos 6 meses, principalmente. Na verdade, tudo parte de observações e leituras que fiz por ai. Às vezes elas foram forçadas por professores ou espontâneas a ponto de eu apenas saber.

No post anterior Vimperator, comportamente do Vim no Firefox eu tinha mensionado que:

Parece radical, mas a produtividade aumenta, de certo modo. Não só na hora de programar e testar, sempre que edito arquivos no Vim, tento não usar o mouse. Claro que sempre vai ter alguma aplicação que vai te obrigar a usar o mouse, mas se pudermos evitar, melhor!

Eu continuo com esta idéia. Coisinha bonita é para cliente final. Desenvolvedores devem trabalhar com ferramentas que proporcionam o melhor uso do tempo possível, pois o bom profissional é aquele que esbanja do ócio, eis o fluxo:

• Concluir as atividades rapidamente com eficácia e eficiência está diretamente ligado ao ócio, pois se ele tivesse feito algo mal feito, estaria corrigindo os bugs e não vendo vídeos no youtube.
• Com tempo livre, o cérebro humano fica mais descansado e mais propício a receber insights/intuições para resolver problemas difíceis, que - e estes merecem - precisam de mais tempo e necessitam ser bem planejados.
• Resolvendo problemas de forma criativa - talvez até inovadora -, faz com que se evite problemas futuros. Logo, se poupa tempo. Se poupando tempo, voltamos a cláusula anterior.

Parece utópico, mas eu acredito nisso. Eu acho que é possível. Basta saber onde conseguir ganhar tempo em atividades, automatizando com scripts, programas e etc, o tempo é consequência.