Programador de Regras

Pessoal,

Um amigo meu fez um texto sobre os programadores, gostaria que vocês dessem uma opinião. Segue o texto:

Nunca fui jogador frequente de RPGs de mesa. Poucas as vezes que o joguei. Duas para ser mais exato. Sou extremamente fã desse tipo de jogo, tenho vários livros sobre assunto, li várias revistas sobre o tema, a ponto de conhecer bem (acho eu) a cultura dos jogadores do RPG. Um dos termos comumente conhecidos entre os jogadores é o “Advogado das Regras”. Um Advogado das Regras é o jogador que considera o jogo de RPG seja centrado nas regras, e não na diversão. Ele sempre vai procurar artíficios nos livros para construir personagens super-poderosos; aponta as regras que prejudiquem os inimigos e outros jogadores. Geralmente essas regras são torcidas ou com o texto levemente alterado/omitido de modo a validar o ponto de vista do jogador Advogado das Regras. Quando acuado faz a mesma coisa, utilizando-se das regras para se proteger. Em suma, o Advogado das Regras é um mal jogador de RPG. Ele não está lá pela diversão. Ele atrapalha e afugenta os outros jogadores. Afinal, quem se importa seum ragão pode fazer X ou pode fazer Y. A diversão não está nisso.

Ultimamente tem surgindo entre os programadores o equivalente no mundo da computação: os Programadores das Regras.

Mas deixe-me explicar primeiramente, como eles surgiram: Há vários anos, desde a década de 90, existe uma preocupação com a qualidade de software construída. É uma preocupação válida porque construir software é caro. Mantê-lo, realizando manutenções dos bugs encontrados, é muito mais caro. Então ao construí-lo com qualidade, mesmo gastando-se mais durante a construção, evita-se muita manutenção dispendiosa. Dessa busca por uma melhor qualidade muita coisa surgiu ou tornou-se prevalecente, mesmo que a primeira vista não esteja diretamente relacionada:
- A prevalência das linguagens com gerenciamento automático de memória: mesmo que elas tenham sido criadas anteriormente, elas popularizaram-se por causa dessa preocupação com qualidade (elimina-se muitos erros) e o aumento do poder computacional dos computadores.
- Os testes automatizados de software e todos os seus itens relacionados: Integração contínua, testes unitários, criar testes antes de programar (TDD).
- A metodologia ágil: busca a construção de software de maneira incremental e contínua, entregando somente aquilo que o cliente necessita. Quanto menos código escrito, menos erros incluídos.

Existem outras, e esse é apenas um breve resumo de cada assunto e de modo relacionado ao contexto desse texto. Eles são bem mais complexos do que isso. Enfim, tendo surgido vários assuntos relacionados com a qualidade de software, é natural que muitos textos e livros tenham sido escritos desses temas ou nas vertentes de “Como escrever código melhor” ou “Como ser um melhor programador”. E a maioria (se não a totalidade) dos programadores buscou esse conhecimento, novatos (como eu) ou não. Mesmo aqueles que não foram muito fundo no tema conhecem (mesmo que brevemente) os assuntos mais populares: Design Patterns, testes unitários, “Clean Code” etc.

Desses programadores, vários foram aqueles que não entenderam os assuntos e começaram aplicando-os incorretamente. O exemplo mais comum é aquele onde o sistema está cheio de classes com padrões de projeto, mesmo que não seja necessárias, apenas pelo fator “legal” ou pior, porque é assim que deve ser programado. Atenção ao último motivo, porque é onde se revela a álmaga do Programador das Regras: Existe um único jeito certo (muito raramente existem vários) de se programar algo. Sem contestação. É um jeito só e todos os outros são errados. E obviamente, o jeito certo é aquele defendido pelo Programador das Regras.

O Programador das Regras pega todas aquelas coisas e as torna obrigatórias. Qualquer software, por mísero que seja, que não seja construído utilizando todas aquelas técnicas legais que ele aprendeu não prestam.

Se você tentar programar algo, e o Programador das Regras avaliá-lo, que Deus tenha piedade. Ele começará a achar inúmeros problemas, dirá que de acordo com o livro X, citação da página 222, aquilo é incorreto. Você tentou corrigir? Se deu mal, porque a forma que o fez violou o que é dito no página 678 do livro Y. Então o Programador das Regras vai e implementa de acordo com que ele acha certo, considerando todo o vasto conhecimento dele e suas inúmeras certificações. Claro que você poderá encontrar algo que não esteja de acordo com os próprios livros que ele escreveu, mas ele se escapará com outra citação, em outra página, em talvez outro livro. O maior prazer de todo Programador das Regras é corrigir alguém usando uma citação transcrita literalmente de um livro. A primeira vista a citação até faz sentido, mas quando é feito uma reflexão por breves momentos, percebe-se que ela precisa ser torçida, ou em partes ignoradas, para que encaixe corretamente como uma crítica ao problema. É claro que isso é um trabalho de um Programador das Regras.

Que fique claro que esse texto não é uma tentativa de defesa para você “programar errado”. O problema é quando a dose do remédio é alta e ela se torna um veneno. Devemos valorizar menos um Programador das Regras e sim mais um Programador-Artesão. Mas, o que seria um Programador Artesão?

É aquele que através do seu ofício tenta entregar o melhor software possível (o grande objetivo!). O artesão sabe que para o cliente do seu trabalho, não importa que ele esteja usando a melhor técnica possível e sim se o produto é o melhor. O artesão sempre procura melhorar o seu conhecimento do ofício e a utilização das suas ferramentas. Mas o artesão sabe que ele pode ter somente as melhores ferramentas, mas nem sempre isso é garantia da melhor qualidade. Não só porque ele tem um ótimo martelo, que tudo deva ser pregado. Muitas vezes ele se vale de ferramentas improvisadas, que logo serão descartadas. Toma decisões que momentaneamente não podem ser compreendidas, ou porque ele sabe que o futuro algo pode ou não acontecer. Ele entende isso a motivação disso, sabe analisar os prós e contras de cada situação, de cada caminho que ele possa tomar.

Ele sabe que não o ofício dele não é ditado por regras. Não existem regras. Existem príncipios. E os príncipios podem ser reavaliados caso algum fato novo surja.
Tudo que importa no final é a qualidade do produto. Ele sabe que sua atividade não é feita seguindo os livros. Ele os utiliza, consulta como referência. Mas a ferramenta mais importante que ele tem é o próprio raciocínio. Ele pensa “Será que vale a pena fazer isso?”. As afirmações dos livros são refletidas, analisadas e aplicadas conforme cada caso.

Um Programador Artesão pensa por si só. Um Programador das Regras não pensa, ele é apenas reflexo dos outros.

No começo da carreira de um programador, o mundo é ditado por caminhos. Faça isso, faça assim, não faça dessa forma. Isso ajuda o programador a rapidamente aprender a programar, seguindo os passos dos mais experientes. Conforme o tempo vai passando ele vai entendo como esses caminhos foram construidos. E então ele desvirtua. Acredita que sabe tudo sobre caminhos e vira o Programador das Regras, onde somente são válidos aqueles caminhos. O Programador Artesão já entende o porquê de cada caminho e a utilidade deles para cada situação.

Que sejamos mais Programadores Artesões do que Programadores de Regras

Bem legal o texto.
Me lembrou de um vídeo que vi estes dias:

Acho que isso acontece quando se busca seguir os modelos dos projetos de sucesso.
Existe o risco e cria-se o medo de pensar diferente. De se seguir ou criar modelos diferentes.
Poucos estão dispostos a gastar tempo e dinheiro em algo que pode dar errado.
Pra não ter medo é necessário saber muito bem sobre os recursos disponíveis, o que quer (em prioridades) e o que deve ser feito.

Bom o texto, mas como o próprio autor diz: cuidado para não confundir com: “viu, isso tudo é bobagem, posso fazer como eu quiser.”

No mais, sim, existem aos montes os que não entendem os princípios e tentam executar as práticas. O resultado é péssimo, obviamente, e isto não é privilégio do mundo do software. Os que se agarram as práticas sem entendê-las (não sabendo o momento em que não se deve usá-las) contribuem para que haja resistência aos próprios princípios que as criaram.

A consequência disso pode ser bem pior do que simplesmente fazer a primeira coisa que vier a cabeça por complicar muito coisas que são naturalmente simples. Um design pattern (por exemplo), onde não é necessário degrada o código muito mais que alguns ifs aninhados.

Mas isso é algo que vai muito além de qualquer atividade, isso é do ser humano. Ninguém garante que nós mesmos já não tivemos, ou ainda temos, atitudes assim, mas com a convicção de estarmos certos. Afinal acreditamos estarmos certos até que nos provem que não.

sou a favor de um monte de regras que antigamente eu não concordava

muito mais facil entender códigos que parecem que foi você que programou…

regras que demorei a entender sua importancia: OO(sim!), MVC, Dependency Injection, Estruturas de dados (usava apenas arraylist).

concordo que nem todo software precisa usar sempre o mesmo padrão, por isso também entendo a útilidade da programação orientada a componentes, ou mesmo o programador que não usa frameworks…

infelizmente programador artesão bom é rarissimo, mas são os melhores.

falacia da autoridade.