Código Ruim é Viral

Certo dia um desenvolvedor começou a trabalhar numa empresa e no seu primeiro dia, enquanto configurava seu ambiente, tirou do bolso um pendrive. Lá continha todo o código antigo que ele escreveu na empresa anterior, para poder codificar mais rapido, ele mesmo afirmou.


Apesar do fato de isso ser ilegal e antiético, é também estúpido.
Código que não é ativamente mantido e refatorado se degenera rapidamente. Então ao invés dele melhorar e aprender novas e melhoras formas de fazer as coisas, na verdade piora com o tempo.


Atalhos acabam sabotando projetos de software.
Cada vez mais desenvolvedores acabam escrevendo código ruim e construindo péssimos produtos de software. Nós gostaríamos de culpar os gerentes e as empresas que nos forçam a trabalhar em cada vez mais apertados cronogramas.


"Eu adoraria fazer testes automatizados ou TDD, mas eles não nos dão tempo para isso."


Testes automatizados e TDD são parte da codificação. Quando você entrega um software, ou mesmo um pedaço de código, você está assinando aquela entrega, afirmando que funciona. Testes automatizados e TDD não são opcionais para a empresa, são opcionais para você.

Se você é confiante de que está entregando código de qualidade sem testes, então talvez eles não são necessários. Mas não empurre esta decisão para o (geralmente não-técnico) gerente. Ele pode não oferecer explicitamente a você tempo para "testes automatizados" mas ele com certeza espera que a coisa funcione.

"Eu sei que isso é uma gambiarra, mas eles falaram que a gente precisa disso funcionando agora, e que depois a gente pode voltar a mexer nisso."

Se esta é a mentalidade na sua empresa, quantas vezes você realmente voltou em algum código para refatorar e melhorar? Correria e gambiarra só trazem mais correria e gambiarra. Quanto mais você corre, e pula bons designs e práticas de qualidade, pior seu código vai ficar. Você vai introduzir mais defeitos e mais complexidade desnecessária. Isso vai atrasar seu cronograma ainda mais, resultando em ... mais correria. É um círculo vicioso que nós como desenvolvedores não apenas participamos, como também somos a causa por produzir código ruim.

"Este código não é tão importante, então não precisa ter um bom design."

O que aconteceria se este código não funcione corretamente? Se a resposta é "pouca coisa", então você provavelmente deveria ir trabalhar com outra coisa. Se a resposta é "coisa pra caramba" (geralmente é) então faça direito.


Escrever código ruim é viral.

• Se você escreve código ruim em certas partes do código, vai se tornar um hábito e vai começar a se espalhar em todo o resto do código do sistema
• É a síndrome da janela quebrada: se algumas partes do código estão pobremente escritas, haverá menor ímpeto para escrever código bom em outras partes.
• Sua base de código-fonte é o principal manual de treinamento para novos desenvolvedores no seu time. Se eles estão aprendendo a partir de código ruim, é assim que eles vão codificar também.
• Deixar programadores ruins no seu time pode na verdade ter um impacto negativo na produtividade. Profissionais mais diligentes vão gastar tempo arrumando código ruim, e outros programadores vão acabar se contaminando, como numa epidemia, com código ruim.

Se o código é importante o suficiente para ser escrito, então é importante o suficiente para ser escrito corretamente.
Como tem o código ruim se espalhado pelo seu time? Você tem sido infectado? Possui algum remédio natural para sugerir?


Fonte: codeanthem - bad code is viral