/Desenvolvimento

voltar
/Desenvolvimento

Como um código horrível é escrito por pessoas perfeitamente saudáveis

PorPaul M. Jones em

De Christian Maioli Mackeprang, o seguinte:

O código legado pode ser desagradável, mas eu tenho programado por 15 anos e apenas algumas vezes vi algo assim. Os autores criaram seu próprio framework, e foi uma tempestade perfeita de antipadrões.

E, no entanto, não foi a qualidade deplorável do código que despertou meu interesse e me levou a escrever este artigo. O que eu descobri, após alguns meses trabalhando lá, foi que os autores eram realmente um grupo experiente de desenvolvedores seniores com boas habilidades técnicas. O que poderia levar uma equipe de desenvolvedores competentes a produzir e realmente entregar algo assim?

Eu não acredito necessariamente em tudo isso, mas vale a pena pensar em:

  • Dar uma importância excessiva às estimativas: “Seus desenvolvedores podem optar por prometer demais e, em seguida, pular trabalhos importantes, como pensar em problemas arquitetônicos ou como automatizar tarefas, a fim de cumprir um prazo não realista”.
  • Não dar importância ao conhecimento do projeto: “Se você estiver em um grande projeto e houver módulos para os quais você não tem um expert e ninguém para perguntar sobre ele, isso é uma grande bandeira vermelha”.
  • Concentrar-se em métricas pobres, como “issues fechadas” ou “commits por dia”: “Quando uma medida se torna um alvo, ela deixa de ser uma boa medida (Lei de Goodhart)”.
  • Supor que um bom processo corrija pessoas ruins: “[Corrija sua contratação.] Talento compensa qualquer outra ineficiência em sua equipe”.
  • Ignorar práticas comprovadas, tais como revisões de código e teste unitários: “Resgatar o uso de ferramentas como IDEs modernos, controle de versão e inspeção de código irá ajudá-lo tremendamente”.
  • Contratar desenvolvedores sem habilidades de “pessoas”: “Não importa que a outra pessoa possa estar a dez mil milhas de distância. Uma chamada no Skype pode transformar uma longa maratona de codificação em uma correção de cinco minutos”.

Conclusão? “O que você não pode assumir é que apenas porque você se inscreveu para aplicar Agile ou outra ferramenta, que nada mais importa e as coisas se resolverão”.

***

Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6654

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

 

Deixe um comentário! 0

0 comentário

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

leia mais
Este projeto é mantido pelas empresas:
Este projeto é apoiado pelas empresas: