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…