Não Culpe o Código Alheio


Você fez entrevista numa grande empresa e foi contratado como Desenvolvedor Senior.

No primeiro dia que lhe dão acesso ao código para corrigir uma pequena falha, você olha o código e pensa:

Mas que P#$@[Piiiiii] é essa?!

Unsplash image

O código é uma bagunça.

Não há divisão lógica entre camadas.

A equipe diz que o código é Orientado a Objetos, mas não há verdadeiros Objetos.

Tudo parece ser global, pois não parece haver nenhum tipo de Encapsulamento.

E agora?

Normalmente, o primeiro sentimento é culpar o último programador que trabalhou no código.

Você pensa:

“Eu não faria assim!”

“O que estavam pensando quando codificaram isso aqui?”

“Será que alguém aqui sabe o que é normalização das tabelas, padronização do código, separação de camadas, responsabilidade única…?”

Culpar é fácil.

Culpar sem nem ao menos saber o histórico do projeto, as motivações envolvidas e os responsáveis pelo projeto é ainda mais fácil.

Mas, não cometa essa injustiça.

Não pense que somente o último programador é o total responsável por toda essa bagunça, pois tem grandes chances dele apenas ter seguindo ordens!

Sim, é verdade.

Claro que isso não exime os programadores da culpa.

Você também é culpado

Se você constrói algo, também é responsabilidade sua que seja feito da forma correta.

Se você não concorda com a atitude de seus superiores, procure outro emprego.

É isso aí! Esse é o correto a se fazer.

Mas infelizmente a vida não é fácil. E para a maioria das pessoas, a vida pode ser extremamente difícil.

Procurar outro emprego demanda tempo. Então a maioria “vai levando a vida”. Vai “empurrando pra frente” até onde der pra chegar. E essa atitude impacta diretamente nos projetos que essas pessoas estão envolvidas.

Muitas vezes esses programadores até tentam fazer o certo, mas gerentes de projetos inexperientes dizem para fazer de outra maneira:

Mais rápido, mais barato, mais… sem lógica! Mais um projeto que irá fracassar.

E isso é extremamente desmotivamente.

Então, quando tudo já está uma bagunça e você não tem voz de decisão para fazer o certo… nada mais importa.

E assim o código vira uma bagunça.

Conclusão

Quando chegar numa nova empresa, assuma o código.

Diga que precisa de um tempo para entender tudo.

Não aponte culpados. Ao invés disso, mostre à empresa algumas soluções.

E quando alguém apontar um erro no código, não diga que a culpa não é sua só porque o código já estava ali antes de você chegar.

Se você assumiu o código, agora ele é seu.

Até logo.

Posts Relacionados

  • Mais Performance usando Argumentos "const" para Interfaces

  • Herança de Formulário é para Iniciantes

  • Eliminando Métodos Privados

  • Classes Aninhadas

  • API Unit: Tudo num só lugar

  • Injeção de Dependência sem XML, Atributos/Anotações ou Frameworks

  • Nomeando Classes em Libraries

  • Versionando e Organizando seus Pacotes

  • Xavier Package

  • Inter-process Communication