Qualidade no desenvolvimento de softwre

Notas do Editor

• #5: Considerar que é relativamente fácil gerar código. Aprender uma linguagem é fácil. Escrever um código para resolver um problema é fácil.
• #6: Porém desenvolver um software que possa evoluir sem problemas para o time, sem perda de qualidade é bem diferente e muito mais complicado.
• #7: Para entendermos melhor essa afirmação vamos pensar juntos o que é desenvolvimento de software? É possível comparar o processo de desenvolvimento de software com o processo de construção civil?
• #8: Afinal de contas temos as mesmas etapas, planejamento, arquitetura, construção, entrega e depois manutenção. Porém existem dois pontos importantes que fazem toda a diferença.
• #9: E se quisermos uma piscina na cobertura? E se for necessário mais um andar?
• #11: Em contra partida é perfeitamente natural que um software sofra alterações durante seu desenvolvimento.
• #12: Outra grande diferença....
• #14: O custo de desenvolvimento seria igual ao da primeira vez? Não seria mais rápido desenvolver e ainda por cima ele não seria melhor que a primeira versão?
• #15: No início de um projeto, o cliente e nós, não sabemos exatamente o que será o software. Porem ao longo do tempo ambos vão aprendendo e construindo um produto alinhado as necessidades e este conhecimento adquirido não é perdido.
• #16: Vamos além, imaginem um time de desenvolvedores de uma startup. Sua única preocupação é um único projeto. Após um ano de projeto é feito uma retrospectiva do ano e constatou-se que o índice de atraso nas entregas foi baixo, o cliente está satisfeito e ainda por cima percebe-se que o software evoluiu muito, mas ainda falta funcionalidades a serem desenvolvidas.
• #19: Ao final do segundo ano é realizada a mesma retrospectiva e constatou-se que o índice de atraso nas entregas aumentou, consequentemente o índice de satisfação do cliente diminuiu e percebeu-se que foram desenvolvidas poucas funcionalidades e muitas correções
• #20: Os diretores da empresa, ao olharem os números, percebem que existe um problema de produtividade, afinal foi entregue muito menos do que se planejou. Mediante a pressão que o cliente coloca a empresa resolve contratar mais programadores, afinal de contas temos um problema de produtividade.
• #22: apesar de termos uma leve impressão de aumento de produtividade, percebe-se não é verdade e o que estava confuso ficou pior ainda.
• #23: Mediante ao CAOS estabelecido, o time e a direção da empresa realizam uma reflexão mais profunda e encontra-se um culpado: Código Legado. O time aponta que está cada vez mais difícil de desenvolver algo em meio ao código existente, que não é possível alterar o código que outro programador criou pois não o código não é compreensível e que uma alteração no código cria problemas em outros pontos do software que ninguém prevê.
• #24: Neste momento a reflexão feita pelo time indica, metaforicamente, que a cozinha ficou bagunçada demais para trabalhar e o time perdeu produtividade pois cada vez fica mais difícil alterar o software no meio da desorganização que o código está
• #25: Percebendo-se que não vai ser possível vencer o CAOS estabelecido, pelo código legado, surge uma ideia: Vamos refazer tudo! Contrata-se desenvolvedores especializados, um dream team, para fazer um novo software
• #26: e os programadores antigos trabalham no legado. Resultado quando menos percebe-se acabou o dinheiro da empresa!
• #27: Analisando o cenário descrito, será que o grande culpado foi o código legado? O que realmente houve? Desenvolvimento de software não é aprendizado? Porque o time não evoluiu e consequentemente o código não evoluiu?
• #28: Será que na verdade o time deixou de ser produtivo porque não adotou certos padrões de qualidade no código?
• #29: Comparando com uma equipe de F1 no momento de pitstop, a equipe é rápida porque não tem qualidade? Ou são rápidos porque tem qualidade? Ainda comparando, e se fossemos um lenhador que recebe um machado novo, no início da sua carreira, poderíamos afirmar que teríamos uma produtividade muito alta. Porém se nunca preocupássemos em afiar o machado chegaríamos a um ponto de que por mais talento e experiência adquiridos estaríamos cortando arvores com um taco e não um machado. 
• #30: Na verdade o código é o resultado do trabalho de um desenvolvedor de software, assim poderíamos dar uma nota para o nosso código!
• #32: Acontece que, precisamos descobrir qual grau de qualidade conseguimos ser mais produtivos, pois se ficar buscando a perfeição talvez se perca produtividade também. Então como podemos constantemente melhorar nossa qualidade e consequentemente nossa produtividade? Como podemos ser melhores programadores?
• #33: Para responder essas perguntas, relembrem-se que desenvolvimento de software é aprendizado então times altamente PRODUTIVOS são formados por pessoas que querem APRENDER constantemente!
• #34: Devemos estar sempre apreendendo e melhorando nossa técnica de programação e para isso precisamos constantemente refatorar nosso código! Ou seja precisamos constantemente alterar um código que está em funcionamento para torna-lo mais legível, eficiente e elegante. Mas para fazermos isso precisamos garantir que o código permaneça funcionando, não podemos modificar o comportamento mas sim sua estrutura
• #35: E neste cenário é impossível realizar re-fatoramento sem utilizar testes unitários. Escrever testes que garantam o comportamento unitário do nosso código é fundamental para a evolução de um bom código. Além de testes devemos estar de olhos abertos para a qualidade do código que escrevemos, evitando bad small’s no código e por consequência criando dívida técnica. 
• #37: Qual a finalidade do código? Está bem escrito? É fácil entender as coisas?
• #38: Há agora melhorou um pouco mais ainda assim ... Fica complicado de ler! Comentários?
• #39: Números mágicos, métodos longos, nomes ruins ......
• #40: Refatorar ......
• #43: Mas muito além de refactoring um código limpo implica em diversas outras boas práticas e técnicas devem ser aplicadas pelo programador, entre elas TDD, DDD, Princípios SOLID para orientação a objetos, padrões de projeto, padrões de arquitetura de software, princípios de engenharia de software e muito conhecimento sobre o negócio da sua aplicação. Ou seja, código limpo, legível e sustentável está ligado com muitas outras técnicas que o programador deve dominar
• #44: Portanto um profissional acima da média, deve ter
• #45: deve ter iniciativa (rafatorar),
• #46: código coletivo
• #47: não da a resposta, faz a pergunta (coaching).
• #48: , aprende para compartilhar (não enterra o ouro),
• #49: busca a excelência
• #51: é focado (Pomodoro)
• #53: Assim podemos concluir que desenvolvimento de software é aprendizado e assim devemos estar constantemente APRENDENDO coisas novas. Diariamente deveríamos nos perguntar
• #57: E para evoluirmos como profissionais precisamos traçar um objetivo para nossas carreiras
• #63: Porque assim você sempre estará ....