Qualidade de Código

Opentalks da qual Samuel Grigolato e Flávio Souza abordaram sobre Qualidade de Código!

Transcript

1. Qualidade de código Nem tudo é o que parece ser
2. Flavio Souza • Formado em Engenharia de Computação pela UNIARA • Mestre em Ciência da Computação pela USP São Carlos (Área: Sistemas Distribuídos e Programação Concorrente) • Doutorando em Ciência da Computação pela USP São Carlos (Área: Sistemas Embarcados Críticos) • Trabalho com desenvolvimento de sistemas
3. Samuel Grigolato • Bacharel em Ciências da Computação pela UNIP • 9 anos de experiência em desenvolvimento e arquitetura de sistemas de informação • Atualmente trabalha com desenvolvimento, consultoria e treinamentos de TI
4. • Agenda
5. Qualidade Qualidade é um conceito relativo. Diversos aspectos são levados em conta. Ex: No caso de um automóvel, fatores como conforto, segurança, desempenho, beleza e custo têm relação com a qualidade. • Qualidade está fortemente relacionada à conformidade com os requisitos. • Qualidade diz respeito à satisfação do cliente.
6. Qualidade de Software Existem muitas definições para qualidade propostas na literatura, sob diferentes pontos de vista Da mesma forma que a Qualidade, a Qualidade de software é um termo que pode ter diferentes interpretações
7. Qualidade de Software Peters (2002): “Qualidade de software é avaliada em termos de atributos de alto nível chamados fatores, que são medidos em relação a atributos de baixo nível chamados de critérios” . Sanders (1994): “Um produto de software apresenta qualidade dependendo do grau de satisfação das necessidades dos clientes sob todos os aspectos do produto”.
8. Qualidade de Software Pressman: “Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais” ISO9126 (1994): “Qualidade é a totalidade de características e critérios de um produto ou serviço que exercem suas habilidades para satisfazer às necessidades declaradas ou envolvidas “.
9. Qualidade de Software vs Qualidade de Código Confundir a qualidade de software com código, é de fato fácil. Mas é necessário distingui-los para entendermos as diferentes preocupações. • Para clientes ou usuários finais, software é o que pode fazer a diferença para a vida ou um negócios e de maneira funcional. • Já o código é um aspecto oculto ou homólogo ao software.
10. Qualidade de Código Já olhou para um código macarrônico e teve a impressão de que estava olhando para um programa estruturado? • Quantas vezes que analisou um código tão acoplado que uma pequena alteração causaria um colapso estrutural com a retirada de uma carta da base de um castelo de cartas? • Escrever código é mais fácil do que lê-lo.
11. Qualidade de Código Sendo um desenvolvedor, estamos constantemente buscando um equilíbrio entre a velocidade e qualidade. Existem diversas formas de implementar um mesmo código, consequentemente há muitas opiniões sobre o que faz bem o software. Quando existe uma pressão para a velocidade, a qualidade do seu código é afetada. O problema só é sensivelmente apreciado quando há a necessidade de adaptar este código a novas features.
12. Mas o que exatamente é a qualidade do código? A qualidade do código tão é subjetiva, devido a diversidade e complexidade projeto e o nível de experiência do desenvolvedor.(É por isso que a indústria não tem métricas padrão para medir a qualidade do código.) Qualidade de código - Métrica
13. Qualidade de Código Por não existem formas quantitativos para medir a qualidade do código, no entanto existem algumas atributos qualitativos que discutem a qualidade de código:
14. Qualidade de Código Funcional: Em última instancia destina-se a um propósito. Se o código não satisfaz as necessidades para as quais foram originalmente codificados, consequentemente não é bom.
15. Qualidade de Código Compreensível e legibilidade: Código deve ser fácil de entender independente do nível do desenvolvedor. • No contexto de projeto, qualquer desenvolvedor deve capaz de identificar os principais pacotes. • Em um nível de módulo, o entendimento sobre as responsabilidades e dependências devem ser claras • Já em um nível de função/método, você deve ser capaz de raciocinar sobre a entrada, saída e lógica.
16. Qualidade de Código (Compreensível e legibilidade)
17. Qualidade de Código Testável: Código deve ser escrito de modo que é facilmente testável. Código testável tende a ser menores, com interfaces bem definidas, baixo acoplamento a outras partes do sistema, consequentemente tem menos efeitos colaterais, e tende a ser menos mutável. • Em outras palavras, o código testável é melhor código projetado.
18. Qualidade de Código Manutenibilidade: Por mais bem escrito que seja um código, erros serão encontrados. A facilidade (ou dificuldade) de manutenção a um código está relacionada com a sua legibilidade, adaptabilidade, e simplicidade. • A necessidade de ampliar ou reutilizar códigos em outros lugares é comum. O bom código é modificado com uma quantidade mínima de esforço e sem causar efeitos secundários desagradáveis. • É muito mais fácil corrigir defeitos de um código compreensível e testável do que está a tornar o código sem defeitos testável.
19. Qualidade de Código Eficiente: Código deve fazer uso eficiente dos recursos do sistema (memória, CPU, conexão de rede, etc.). A otimização deste atributo é a raiz de muitos males, tiver-se de escolher entre o código compreensível e eficiente quase sempre escolher o código compreensível. "premature optimization is the root of all evil" - Donald Knuth
20. Referências de Livros Existem alguns livros que auxiliam o desenvolvimento de padrões, técnicas, conceitos e boas práticas de programação: • C/C++ - Effective C++ • C# - Programming C# 5.0 • Java - Effective Java Programming Language Guide • Python - Effective Python: 59 Specific Ways to Write Better Python • Ruby - ruby under a microscope
21. Quer saber o que o custo de um erro de software é? Depende de quão tarde você encontrá-lo.
22. Quer saber o que o custo de um erro de software é? Depende de quão tarde você encontrá-lo.
23. Custo Vs. Tempo
24. O esforço gasto por organizações de software com retrabalho pode variar em média entre 40% e 50% do esforço total do desenvolvimento de um projeto
25. Através da análise de 63 projetos, BOEHM apresentou o custo relativo da correção de defeitos encontrados em cada uma das atividades de desenvolvimento O esforço com retrabalho é reduzido em média para 10% a 20% do esforço total de desenvolvimento.
26. Correção Vs. Tempo
27. A Mariner 1 foi a primeira aeronava dos EUA a ser enviar para Vênus. Devido a um erro de software a Mariner 1 saiu do trajeto planejado e a decisão do oficial de segurança da NASA foi em emitir o comando de auto-destruição após 290 segundos da decolagem. No relatório devido a omissão de um hífen em instruções do programa na edição de dados, resultou em sinais de orientação incorretos sendo enviado para a nave espacial. Exemplo 1: NASA - Mariner 1 O custo para o foguete teria sido mais de US $ 18 milhões na época.
28. Em 2009 houve três recalls da Toyota, todos estavam relacionados com o acelerador do carro.Em do mesmo ano, as concessionários Toyota foram instruídos atualizar os computadores de bordo desses carros. A Toyota terminou o recall com mais de 9 milhões de carros em todo o mundo, mas o problema não mecânico. Os carros tinham um erro de software que causou um atraso no sistema aceleração. Exemplo 2: Recall Toyota Devido a campanha e obrigações legais, o recall foi estimado em US$ 3 bilhões.
29. Em agosto de 2012 Knight Capital Group Inc., devido a um erro de software a compania solicitou mais de 4 milhões em ações em menos de uma hora, o que deveriam ter sido distribuída ao longo de um período de dias. O problema foi devido a uma alteração de código, resultando a perda de 75% em dois dias após o software defeituoso Exemplo 3: Bolsa de Valores O bug de software causou mais de US$ 440 milhões em perdas, o que é 4x o que a empresa obteve em 2011.
30. De olho no código… (1)
31. Técnica: programação em par A programação em par é uma das mais conhecidas práticas da Extreme Programming (XP) é uma metodologia de desenvolvimento de software ágil e seus objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas. A programação em par é o trabalho de dois desenvolvedores em uma único computador, sendo um piloto, que conduz o desenvolvimento, implementa o código, e o co-piloto, que revisa e ajuda o piloto a tomar decisão no desenvolvimento da atividade.
32. Técnica: programação em par Melhora a disciplina: pares são mais propensos a fazerem a coisa certa e são menos propensos a fazerem pausas longas. Maior qualidade: o trabalho é feito e revisado constantemente por duas pessoas. As soluções são mais simples e com menos erros. Fluxo de trabalho: a atenção e foco no trabalho são mais fortes. Um ajuda o outro a manter o foco no trabalho e criar um fluxo contínuo de produção. Este fluxo é mais resistente a interrupções: enquanto um lida com a interrupção o outro continua trabalhando.
33. Técnica: programação em par Melhora a moral: trabalhar coletivamente traz mais satisfação e reconhecimento. As amizades são fortalecidas e novos laços de amizade são criados. Propriedade coletiva: trabalhando em par, e rotacionando periodicamente os pares, todos ganham um conhecimento integral de todas as partes de um projeto. Mentoring: um par mais experiente ensina um par menos experiente a aprender durante do projeto. A troca de conhecimento é mais eficiente e rápida. Menos interrupções: as pessoas são mais relutantes em interromper um par do que interromper alguém sozinho.
34. Técnica: programação em par Multi-disciplinaridade: a troca de experiência entre os pares proporciona a formação de um perfil multi-disciplinar. Isso significa que, além da competência técnica que domina, cada integrante do par pode aprender sobre outras competências e ter acesso a outros conhecimentos. Auto-gerenciamento: quanto mais as pessoas trabalharem em par, e rotacionarem os pares, mais auto-organizadas e auto-gerenciadas as equipes serão. União do time: as pessoas se conhecem melhor quando trabalham em par e ficam mais unidas, criando entrosamento e sinergia no trabalho.
35. Técnica: programação em par (Dicas) Baseada em Turnos - deve mudar de posição de tempos em tempos, o codificador (piloto) torna-se o revisor(co-piloto) e vice-versa. Testador(Codificador) - A técnica consiste em, utilizar TDD com "pareamento". Um desenvolvedor escreve um teste que falha, então o outro desenvolvedor assume a codificação e deve fazer com que o teste passe escrevendo o mínimo de código possível.
36. Técnica: programação em par Existe a polêmica de que a programação em par é mais cara, pois dobra as despesas de desenvolvimento de código e as necessidades de mão de obra são críticos. IBM afirma que gasta cerca de US$ 250 Milhões em reparação e correções a cada 30 mil problemas relatados por clientes (US$ 8.000 para cada defeito)
37. http://collaboration.csc.ncsu.edu/laurie/ Papers/XPSardinia.PDF Um experimento executado na Universidade de Utah investigou a economia da programação em pares com seus alunos do último ano de Eng. Software.
38. No primeiro programa os pares gastaram 15% mais tempo com relação aos programadores individuais
39. O código produzido pelos pares apresentou 15% menos defeitos com relação aos programadores individuais.
40. Se um programa de 50.000 linhas de código (LOC) for desenvolvido por um grupo de programadores individuais e um outro de programadores pares, ambos a uma taxa de 50 LOC/hora, os indivíduos irão desenvolver este código em 1000 horas sendo assim os pares precisaram de 1150 horas.
41. No entanto os programadores individuais injetaram 100 defeitos por mil linhas de código.
42. Estatisticamente, as equipes em par relataram que ficaram mais confiantes com os seus programas do que quando eles programaram sozinhos
43. os pares apresentaram programas com qualidade superior e com menos linha de código com relação aos códigos produzidos pelos programadores individuáis.
44. Técnica:revisão de código Revisão de código, é o ato sistemático de verificação do código produzido por outro programador.
45. A revisão de código é responsável por 60% da identificação de bugs ou defeitos. https://kev.inburke.com/kevin/the-best -ways-to-find-bugs-in-your-code/
46. Veja como revisão de código economizar US$ 200 Mil de uma empresa
47. Revisão de código (Na prática)
48. Revisão de código (Na prática)
49. Revisão de código (Na prática)
50. Revisão de código (Na prática)
51. De olho no código… (2)
52. De olho no código… (3)
53. Técnica: análise estática de código (Sonar)
54. O que é? • Análises efetuadas sem executar o software • Testes automatizados não são exemplos • Eficaz na aplicação de padrões de codificação • Como ele é executado?
55. Encontre o conjunto correto de regras Cada projeto e time possui necessidades específicas que devem refletir na composição do perfil de regras Alguns exemplos de regras: - Floating point numbers should not be tested for equality - "for" loop stop conditions should be invariant - "@Deprecated" code should not be used - Sections of code should not be "commented out" Fonte: https://sonarqube.com/coding_rules
56. Encontre a “fronteira de qualidade” correta Cada projeto (ou cada categoria de projeto) deve possuir seu próprio conjunto de limitadores Indicadores: • % de cobertura de código por testes automatizados • Novas violações de segurança ou bug • Razão entre novo código e quantidade de violações de débito técnico
57. //NOSONAR • Permite indicar pontos onde não há solução • Pode ser abusado • Não deve ser usado para esconder débito técnico • Regra: "NOSONAR" should not be used to switch off issues • Controle os falsos positivos no próprio servidor do Sonar
58. Controle de duplicação de código • Usar com parcimônia • Muitas vezes a duplicação não representa um problema
59. Controle de comentários • Análise estática pode ajudar a controlar a escrita de comentários • “Obviamente”, nenhum tratamento semântico é feito
60. De olho no código… (4)
61. Vida real: uma olhada no código-fonte do Spring Framework
62. Uma olhada no código do Spring Framework • Projetos open source tendem a possuir código com qualidade ◦ Seleção natural ◦ Revisão por padrão Exemplos: • https://github.com/spring-projects/spring-framework/pull/1078 • https://github.com/spring-projects/spring-framework/pull/1128
63. org.springframework.beans.factory.config.Scope • Padrão de construção Strategy • Padrão de construção Abstract Factory
64. org.springframework.[...].SpringValidatorAdapter • Padrão estrutural Adapter
65. org.springframework.[...].BeanDefinitionVisitor • Padrão de comportamento Visitor
66. org.springframework.[...].NoOpScope • Padrão de comportamento Null Object
67. De olho no código… (5)
68. Obrigado ! Duvidas ?
69. Contatos flavioluiz.ssouza samuel.grigolato flavioluiz.souza samuel.grigolato flaviossouza samuel-grigolato-67465b43 @flaviolsouza @samuelgrigolato