Esse mês deixei a DTS Consulting, empresa pela qual prestava serviços ao HSBC Bank Brasil desde o ano passado. Não, não …. não vou me aposentar. Aliás, a tão sonhada aposentadoria está cada vez mais longe, e na verdade, todo ano precisa ser postergada … hehe…

Gostaria de agradecer à todo o pessoal da DTS e do HSBC que aguentaram bravamente as minhas lamúrias por todos esses meses à fio, e que apesar de toda minha chatice, nunca desistiram de mim!!!
Para vocês todos , apenas posso desejar muito sucesso !!!… hehe…

Desde a semana passada faço parte da equipe de integração da Global Village Telecom – GVT, através da eWave do Brasil. Tenho muito ainda para apreender, e vi na GVT uma oportunidade para trabalhar com tecnologias e ferramentas ainda desconhecidas para mim. Em alguns projetos, estão sendo desenvolvidas algumas idéias do SCRUM, o que deixa o trabalho um pouco mais dinâmico. E nem preciso dizer, que tenho uma certa simpatia por metodologias ágeis !!!

Acho que muita coisa está por vir, nos próximos sprints, vamos ver o que acontece… hehe…

Ouvir outras opniões, principalmente àquelas totalmente contrárias as suas é muito importante, seja para que você reforçe seus ideais ou simplesmente para que você reveja seus conceitos. Geralmente, quando tenho “absoluta certeza” de algo, procuro por uma segunda opnião, um outro ponto de vista. Isso porque, em TI, ter certeza absoluta sobre alguma coisa, me assusta.

Mas sinceramente, algumas coisas não tenho mais paciência pra escutar. Não sei se estou ficando velho. Não sei se estou ficando muito rabujento. Talvez sejam ambas as coisas. Quando se está a algum tempo “fazendo programas”, você acaba apreedendo muita coisa boa, mas principalmente, acaba identificando tudo aquilo que NÃO SE DEVE FAZER em desenvolvimento de software.
Vou descrever abaixo algumas frases clássicas que provavelmente você já ouviu em alguma reunião, tech-talk ou de algum gerente “espertão”.

1. Programador não é pago pra pensar, é pago pra programar. Essa já perdeu a graça. Sério. Se seu gerente ainda acha que programação é simplesmente um processo mecânico e repetitivo, diga a ele para contratar um milhão de macacos para fazer o trabalho. Bem mais barato.
   Por favor, não importa qual o nome que as empresas dão a ele: desenvolvedor, programador, analista-programador, mas esse cara deve ser capaz de identificar requisitos e implementar soluções. E muito mais que isso, deve ter noções de arquitetura de software, deve conhecer as tecnologias e ferramentas que utiliza, se preocupar com requisitos não-funcionais, escalabilidade, etc. Não é necessário ser um “super-homem” auto-didata, mas precisa ter flexibilidade suficiente para participar de reuniões com o cliente e ter conhecimento técnico para implementar uma solução. E de qualquer forma, em desenvolvimento de software, code monkeys nunca foram uma opção.

2. Programador deve apenas codificar o que está especificado.
   Se a empresa que você trabalha tem um “analista” que pensa no que precisa ser feito, escreve um monte de diagramas numa linguagem de modelagem (a.k.a UML) e depois passa para um “programador” que apenas codifica em linguagem executável o que foi especificado, acho que seria interessante seu gerente dar uma olhada nisso aqui. E se esta abordagem fosse realmente eficiente/eficaz, os relatorios do Standish Group não estariam desse jeito.
   Programador não baixa a cabeça e sai codificando. Programador deve saber o “porque” está implementando algo. Deve saber o contexto do problema e saber quais as necessidades dos stakeholders. Programador avalia soluções. Sugere melhorias. Critica requisitos de negócio. Ao contrário do que pregam muitas consultorias por aí, BONS PROGRAMADORES SEMPRE SERÃO FUNDAMENTAIS.
   

3. Mas é apenas uma “alteraçãozínha” !!!
   Pelo amor de Deus, não existe uma “alteraçãozinha” em TI. Por melhor que seja o design de suas classes. Por mais bem escrito que sejam seus componentes. Por mais simples que seja o seu ambiente de desenvolvimento, uma “alteraçãozinha” sempre irá envolver esforços de programação, testes e build para produção. Quanto a isso, independente das metodologia, frameworks ou ferramentas empregadas, não se pode fazer mágica.
   Se você trabalha num ambiente um pouco mais ágil (a.k.a SCRUM), é bem provável que você irá conseguir responder mais rapidamente a mudanças de requisitos, e o tratamento de alterações de código fonte serão mais tranquilas. Mas se você trabalha numa empresa que possui milhares de fases de desenvolvimento, artefatos, papelada e burocracia, a alteração de um “label” em produção pode se tornar uma tarefa sofrível.
   

4. Está pronto, só falta testar !!!
   Essa é clássica. Se você tem algum trecho de código que não foi coberto por testes… bem… você tem apenas código fonte.

   - Pronto, terminei !!!
   - Que bom !!! Posso ver como ficou ?!
   - Não.. não…não testei isso ainda..!!!
   - Humm ?!
   
   Qualquer framework, componente ou serviço que se preze, deve ser no mínimo, verificável. E isso não aprendi na faculdade. Foi a tia Perivalda que me ensinou, a muito tempo atrás, nas aulas práticas de ciências: se um experimento não pode ser verificável, então é apenas um modelo teórico.
   Qualquer alteração num sistema, deve ser acompanhado por no mínimo, um caso de testes. É fundamental que este mesmo sistema, tenha um conjunto de testes unitários e teste integrados que me permitam dizer se algo está errado.
   A muito tempo deixei de acreditar naqueles que dizem que os testes são outra “fase” do processo e que programador não se envolve com testes, apenas codifica. Programadores escrevem testes, e ponto final. TDD, por exemplo, é uma ótima abordagem que permite o desenvolvimento de sistemas “testáveis” e vericáveis.

   Por ora, essas são algumas das pérolas da programação que me vêm à memória. E mesmo que esse post tenha ficado com cara de “desabafo”, é bem possível que ainda escreva uma continuação para ele…

Passamos a maior parte do tempo desenvolvendo programas que devem ser, além de compatíveis com a arquitetura atual do sistema, estar preparados para futuras alterações. Geralmente somos levados a acreditar que, como programadores, nossas implementações devem ser “genéricas” e “atemporais”.
Essa busca pelo “genérico” não é incomum entre arquitetos e programadores. Kevlin Henney já falou a respeito desse comportamento:

A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.
Kevlin Henney

Acho que essa cultura de generalização exagerada pode criar problemas quando programadores perdem o foco no contexto do sistema, nos interesses dos stakeholders e passam em se preocupar em produzir frameworks e componentes genéricos.

Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.
Kevlin Henney

Thus, the real goal for all architect is to make sure the final architecture, resulting from the design and code written, solves the stakeholders concerns. I have nothing if only nice code and a great design that does not solve the stakeholders needs.The architect needs to learn how to get out of the design/coding swirl without losing eye-contact, and start developing the solution with the problem in mind.
William Martinez Pomares

A maioria dos esforços para tornar implementações genéricas, acabam inserindo complexidade desnecessária ao código fonte, pois as decisões são feitas para resolver, problemas que na maioria das vezes acabam não se concretizando no futuro.
Frameworks genéricos, ou frameworks de referência geralmente se tornam um problema de arquitetura de sistemas. As boas arquiteturas são estabelecidas dentro de um cenário espefício. Cada projeto tem característias e necessidades únicas, que podem ser resolvidas com frameworks mais apropriados para àquela situação. Mas na prática, o que acaba acontecendo, é que após um projeto bem sucedido, muitos programadores tem a impressão que o mesmo framework pode ser utilizado para qualquer outro projeto futuro. E então, a máxima torna-se verdadeira: pra quem só tem um martelo, todo problema é prego.

Claro, que práticas que já obtiveram sucesso num projeto, podem eventualmente ser aplicadas em outras situações. Contudo, isso não pode se tornar uma regra. Achar que algumas tecnologias podem ser aplicadas em todos os projetos, é ilusão. Mas tem muita gente que ainda acredita em soluções genéricas, compra meias tamanho único e fica na eterna busca pela bala de prata para seus problemas.

Além do mais, o cliente não compra arquitetura. O cliente paga por uma solução, que as vezes, é software. O cliente não está preocupado com o número de camadas da aplicação ou se ela foi desenvolvida com struts ou mentawai, muito menos com o design de suas classes. O cliente espera que o sistema ajude a resolver seus problemas e venha de encontro aos seus anseios.
Apesar da arquitetura de sistemas estar mais relacionada à escolha e aplicação de tecnologias, creio que seja fundamental que arquitetos e programadores sempre mantenham foco nos interesses e objetivos dos principais stakeholders dos projetos.

E antes de sair tentando reusar objetos e generalizar componentes, pergunte a si mesmo: “O que realmente precisa ser feito ?”