logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

Programando melhor: evite criticar o código alheio

Uma das situações comuns na vida de um escovador de bits é a necessidade de editar código escrito por outras pessoas. E essa é uma situação com a qual muitos programadores não estão preparados para lidar, pois envolve muito mais o lado pessoal do que o lado técnico. Mas, tecnicamente, verdade seja dita: é difícil ler e entender código dos outros. Pelo simples fato da linha de raciocínio ser diferente. É difícil, mas algo que precisamos aprender a lidar.

Todo programador segue uma linha de raciocínio para implementar uma funcionalidade em um software, linha essa que foi moldada com anos de programação. Independente de design patterns ou padrão de codificação, a forma de resolver problemas é algo muito pessoal. Tudo que o programador lê ou aprende sobre algoritmos é absorvido e empregado de formas diferentes. Patterns e standards ajudam a minimizar isso, mas não modificam a forma como as coisas são.

Criticar código dos outros, principalmente para seus colegas de trabalho, é chato e pode te causar problemas. A pessoa que escreveu o código pode ser quem senta do seu lado, e talvez ele não goste muito de ser criticado (alguém gosta?). Além disso, todo código escrito tem uma história, e no contexto dessa história tudo tem um bom motivo para ter sido feito daquela forma. Você não pode julgar cegamente algo só por aquilo que você está vendo.

Um bom motivo para um código aparentemente ruim é a inexperiência de quem escreveu. Você não pode exigir de um programador iniciante a mesma qualidade de algoritmo de alguém com dez anos de experiência. Você já foi iniciante um dia, e acredito que quando lê um código que você escreveu a alguns anos atrás chega a sentir vergonha. Mas é assim que funciona, as pessoas aprendem, ninguém começa sabendo. Além disso, se um programador iniciante foi colocado para fazer uma parte crítica do sistema, a culpa é de quem o alocou para essa tarefa.

Você nunca sabe a situação que levou à criação de um certo código. Talvez o código não tenha sido feito da melhor maneira possível porque era véspera de feriado e o programador queria ir embora. Justificável ou não, é um bom motivo. Se o programador ficou enrolando a semana inteira e resolveu fazer uma gambiarra às 17:30 de sexta é um problema dele com o gerente dele, não é um problema seu. Talvez o gerente inventou um prazo maluco sem consultar os programadores, o que é a coisa mais comum desse planeta. O fato é: você não sabe.

Nós somos pagos para resolver problemas, certo? Resolva os problemas e evite criar outros. Criticar código alheio só cria problemas, raramente resolve alguma coisa. Já conheci gente com bom conhecimento técnico mas que ninguém suportava, tudo devido à esse costume de criticar todo o código que aparecia pela frente. Espero que todo mundo saiba que só conhecimento técnico não resolve.

Na frase "código feio que está funcionando em produção", a parte que importa é a "...está funcionando em produção...". Pense bastante antes de refazer algo que está funcionando, e não critique o código. Fale em "reestruturação para facilitar a manutenção" e não em "refazer aquele troço nojento que eu não entendo". Afinal, como você pode refazer algo que não entende?


Em 06/12/2007 16:50, por Rodrigo Strauss


  
 
 
Comentários
Wanderley Caloni | website | e-mail | em 07/12/2007 | #
Você tocou em um ponto muito importante da programação que é: não estamos sozinhos. Quase nunca o código vai ser 100% nosso, e mesmo que seja, quase sempre o construímos em cima de algum framework, biblioteca ou modelo já inventado há milhões de anos.

E desse tópico importante, o mais importante que você disse foi: entender o código do outro. É muito fácil criticar um sistema operacional que você não conhece, uma linguagem de programação nova ou o código de um colega que não está mais entre nós; difícil é reconhecer que se estava errado, rever seus conceitos e entender o que incomoda no código, se é preconceito ou tem justificativa lógica (exemplo: isso pode dar problemas na condição X).

PS: que bom que você está voltando sua velha freqüência de postagens. Eu já estava achando que eu estava postando demais da conta =).
Marcelo | website | em 07/12/2007 | #
Rodrigo, antes de mais nada, parabens pelo site.
Deixa eu tirar uma duvida com vc... este eu blog foi desenvolvido por vc ou vc usou algo ja pronto?
Pois gosto do layout do seu blog e procuro por algo semelhante.
Obrigado.
Charles | website | em 07/12/2007 | #
Acredito que o maior motivo para se criticar o código alheio seja nada mais do que preguiça de tentar entende-lo. É mais cômodo criticar e tentar fazer com que fiquem com pena de mim por estar me sacrificando com um código tão ruim do que fazer um esforço maior para entender o mesmo.

É mais ou menos assim na política: O importante é ser do contra, tendo ou não algo melhor ou nem mesmo bem entendendo o que foi proposto.

"Justificável ou não, é um bom motivo" - Bela frase!
Rodrigo | website | em 08/12/2007 | #
Criticar o código alheio só é um problema quando o ambiente de trabalho não propicia o aprendizado mútuo e a evolução da equipe.

Onde trabalho todos tem a liberdade, e meio que a obrigação, de revisar o código dos outros e criticá-lo. Receber tanto um elogio quanto um crítica é sempre bem vindo, pois indica que as pessoas se importam com aquilo que está fazendo.

Trabalhar em projetos com programação em pares ou posse global do código cria o ambiente necessário para críticas servem levadas a sério e de maneira profissional.

Código tem que ser feito para ser lido por humanos e não máquinas, se ninguém reclama do compilador por que faria algum sentido não aceitar críticas de colegas de equipe?

O problema não é criticar, é trabalhar em um ambiente com uma cultura podre.
Rodrigo Strauss | website | em 08/12/2007 | #
Wanderley: já faz algum tempo que eu estou tentando me dedicar mais ao site. Acho que um post por semana, de tamanho médio ou pequeno é o ideal. E fugir do velho problema do "isso não é importante o suficiente para colocar no blog".

Marcelo: eu fiz tudo, o design (se é que dá pra chamar assim) e o engine do blog, todo em php.

Rodrigo: Nesse post eu tratei de críticas puras e simples e não de revisão de código. Falei que gente que vive reclamando do código alheio. Críticas são bem vindas quando esperadas e feitas na hora correta, fora isso acaba gerando problemas maiores.
Thiago Brito | website | e-mail | em 10/12/2007 | #
Acredito que criticar o código de um codigo de um colega ajuda a criar um ambiente de discussão e pode inclusive aumentar a qualidade de codigo e melhorar a padronização entre a equipe. Afinal, se qualquer codigo que o desenvolvedor digitar for aceito (estando bom ou ruim) sem critica ou dúvida nenhuma, pode acontecer o que é chamado de "zona de conforto", onde o desenvolvedor não melhora pq do "jeito que está agora está bom".

Acredito que críticas construtivas ajudam o desempenho da equipe como um todo. O que não pode (e é o que eu percebi no seu post) é o desenvolvedor que critica um código só por criticar, sem fazer qualquer julgamento em relação a ele. Isso realmente é um veneno para o relacionamento e para a equipe como um todo e ele deve ser tratado o mais breve possível.
Vinícius Godoy | website | em 26/12/2007 | #
Essa foi uma experiência interessante quando começamos a implementar o Extreme Programming na empresa onde trabalho. Nesse processo começamos trabalhando em duplas. Sim, existe um sujeito que codifica diferente de você te dando pitaco o tempo todo.

No início isso parece ruim, mas um código que agrada a dois é certamente melhor que um código que agrada a um programador só.

Depois, como se não bastasse, as duplas trocam de tempos em tempos. E pegamos um código feito por outra dupla. Agora o caos está completo. Ou a equipe se integra e faz algo que seja agradável a todos, ou a guerra irá começar.

Como todos valorizam seus empregos, a tendência é que o código fique igualmente bom e que aprendamos a valorizar as diferenças.

Em pouco tempo, você começa a se acostumar ao estilo dos seus colegas e ele aos seus. E o que passa a prevalecer é o estilo da equipe.
Wilson Barbosa | em 06/07/2013 | #
Tem uma palavrinha bacana para isso: Refatoração de codigo...

hauhahaahuahauah
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::