• 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
• 9 anos de experiência em desenvolvimento e arquitetura de sistemas de informação • Atualmente trabalha com desenvolvimento, consultoria e treinamentos de TI
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.
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”.
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 “.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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
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
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
opensanca
ikumatadokoro
murabayashi
afilina
tkikuc
akikogoto
kakao
krpk1900
ivargrimstad
hideg
maaretp
paigeccino
tammielis
kneath
eileencodes
bkeepers
smashingmag
danielanewman
soudai
sstephenson
tammyeverts
jnunemaker
bluesmoon
![org.springframework.[...].SpringValidatorAdapter • Padrão estrutural Adapter](https://files.speakerdeck.com/presentations/072c796fff1846198666d539ea56af8b/slide_63.jpg){kind=link}
![org.springframework.[...].BeanDefinitionVisitor • Padrão de comportamento Visitor](https://files.speakerdeck.com/presentations/072c796fff1846198666d539ea56af8b/slide_64.jpg){kind=link}
![org.springframework.[...].NoOpScope • Padrão de comportamento Null Object](https://files.speakerdeck.com/presentations/072c796fff1846198666d539ea56af8b/slide_65.jpg){kind=link}
