2. SUMÁRIO
• Definição
• Princípios
• Padrões de codificação
• QA Tools
• Profile
• Dicas gerais
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Let me cast some light in our path
3. O QUE É QUALIDADE?
Ou, como ela é percebida, visualizada, e/ou medida?
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
4. A QUALIDADE ESTÁ RELACIONADA À ÓTICA
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Analista
• Atende os requisitos
Infraestrutura
• Robusto
Programador
• Intuitivo / Fácil
leitura e manutenção
Empresa
• Lucrativo
Cliente
• Correto
Gestor
• Dentro do prazo
freepik.com
5. MAS O TRABALHO É TODO SEU
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Com grandes poderes, vêm grandes responsabilidades
freepik.com
6. COMO SE MEDE A QUALIDADE?
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Enquanto isso, na sala de review...
7. ANÁLISE ESTÁTICA & ANÁLISE DINÂMICA
Análise estática
• Baseada na estrutura
• Sem rodar o app
• Coleta de estatísticas
• Requer avaliação
ponderada
Análise dinâmica
• Baseada no comportamento
• Rodando o app
• Situações pré-programadas
• Rápida avaliação
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Static analysis & Dinamic analysis
http://feaforall.com/wp-content/uploads/2013/04/1.jpg
9. PRINCÍPIOS DE DESIGN DE
SOFTWARE
Diretrizes para se considerar ao / antes de codificar
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
10. PRINCÍPIOS DE DESIGN DE SOFTWARE
• Reuso de experiência;
• Recomendações do que deve ser feito;
• Recomendações do que deve ser evitado.
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
KISS YAGNI STUPIDDRY SOLID
11. KISS
• Preza pela simplicidade
• Fácil de entender e manter
• Menos suscetível a erros
• Parece simplista ou “chato”
• Simplificação de problemas
PRINCÍPIOS DE DESIGN DE SOFTWARE
“Uma solução simples é melhor que uma complexa, mesmo que ela pareça estúpida.”
“Faça de forma simples, mas não
mais simples que o necessário.”
M REC
12. DRY
• Reduzir a repetição de
informações
• Mitigar contradições
• Métodos e sub-rotinas
• Não inclui apenas código
• Fonte única de
conhecimento
– Geradores
– Automatizadores
Reduz o acomplamento
(coupling)
PRINCÍPIOS DE DESIGN DE SOFTWARE
“Cada parte do conhecimento deve ter uma origem única e sem ambiguidade.”
M REC
13. YAGNI
• Associado a XP
• Refatoração contínua
• Requisitos bem definidos
• Custo de implementação
– Barato agora e barato depois?
Deixe pra depois.
– Barato agora e caro depois?
Faça agora.
• Redução de bugs
PRINCÍPIOS DE DESIGN DE SOFTWARE
“Implemente quando você realmente precisar, e não quando acha que vai precisar.”
M REC
14. STUPID X SOLID
• Ambos definem um conjunto de princípios;
• STUPID: Evite problemas no seu código;
• SOLID: Boas práticas para melhorar seu
código.
PRINCÍPIOS DE DESIGN DE SOFTWARE
O que fazer e o não fazer quando estiver codificando
STUPID SOLID
15. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• Difíceis de testar;
• Escondem dependências;
• Tight coupling.
PRINCÍPIOS DE DESIGN DE SOFTWARE
Só pode haver um
16. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• Duplicação de código;
• Código de um módulo
utilizando código de outro;
• Dependências circulares;
• Dependências
descontroladas.
PRINCÍPIOS DE DESIGN DE SOFTWARE
Assim como o mar, onde uma única gota desencadeia uma reação sem proporções
http://martinfowler.com/ieeeSoftware/coupling.pdf
17. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• Singleton;
• Tight Coupling;
• Acúmulo de
responsabilidades.
PRINCÍPIOS DE DESIGN DE SOFTWARE
I find your lack of tests disturbing
18. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• 97% do tempo você estará
otimizando o lugar errado
do código;
• Prejudica a legibilidade;
• Aumenta a complexidade;
• Possibilidade de introdução
de bugs.
PRINCÍPIOS DE DESIGN DE SOFTWARE
Premature optimization is the root of all evil
19. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• Abreviações;
• Nomes não
contextualizados;
• Baixa legibilidade.
PRINCÍPIOS DE DESIGN DE SOFTWARE
fazABagacaToda($deonde = ‘comeco’);
20. STUPID
• Singleton
• Tight Coupling
• Untestability
• Premature Optimization
• Indescriptive Naming
• Duplication
• Mais tempo de
manutenção;
• Baixa corretude;
• Contradições.
PRINCÍPIOS DE DESIGN DE SOFTWARE
Qual devo usar? Util::limpaTexto() ou Texto::limpa()?
21. SOLID
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
PRINCÍPIOS DE DESIGN DE SOFTWARE
Olha pai, é um videocassete com tv, ou uma tv com videocassete?
• Classes, métodos e funções
com uma única
responsabilidade;
• Cuidado com God Classes.
22. SOLID
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
PRINCÍPIOS DE DESIGN DE SOFTWARE
Software entities should be open for extension, but closed for modifications
• Polimorfismo
– Tipos concretos
• Interfaces / Classes
abstratas
– Tipos abstratos
https://en.wikipedia.org/wiki/Subtyping
Pássaro
Pato Cuco Avestruz
23. Pássaro
Pato Cuco Avestruz
SOLID
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
PRINCÍPIOS DE DESIGN DE SOFTWARE
Objetos podem ser substituídos por seus subtipos sem alterar a corretude do programa
• Subtipo comportamental
– Precondições;
– Pós condições.
https://en.wikipedia.org/wiki/Subtyping
24. SOLID
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
PRINCÍPIOS DE DESIGN DE SOFTWARE
Várias interfaces específicas são melhores que uma interface geral
• Propósito bem definido;
• Implemente apenas os
métodos que irá utilizar;
• Diminui a acoplagem;
• Aumenta a coesão.
27. SOLID
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
PRINCÍPIOS DE DESIGN DE SOFTWARE
O que realmente importa é a necessidade, e não o comportamento
• Módulos de níveis não devem
apresentar dependência entre si,
ambos devem depender de
abstrações;
• Abstrações não devem depender de
detalhes;
• Detalhes devem depender da
abstração.
https://en.wikipedia.org/wiki/Dependency_inversion_principle
31. PADRÕES DE CODIFICAÇÃO
A resposta da velha pergunta: “Coloco a chave na frente ou embaixo?”
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
32. PADRÕES PHP-FIG
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
PSR: PHP Standard Recommendation
• PSR-1: Basic Code Standard
• PSR-2: Coding Style Guide
• PSR-3: Logger Interface
• PSR-4: Autoloading
Standard
• PSR-6: Caching Interface
• PSR-7: HTTP Message
Interface
33. PSR-1 & PSR-2
• Série de regras de
formatação de código
– Conteúdo de arquivos
– Funções
– Classes
– Métodos
– Namespaces
– Visibilidade
– Tamanho de linha
– Endentação
– Modificadores
– Estruturas
– ...
PADRÕES PHP-FIG
Base Code Standard & Coding Style Guide
No more!
49. PROFILING
- Não otimize agora.
- Ainda não!
- Agora sim, vamos lá.
- Mas antes disso, já rodou o profiler?
50. PROFILE
• Identificar bottlenecks
• Otimização direcionada
• Evita degradação de
performance
PROFILING
Tio, e agora, já posso começar a otimizar meu código?
http://weblogs.asp.net/craigshoemaker/asp-net-caching-and-performance
51. XDEBUG + $VIEWER
• Profile
• Code coverage
• Remote debugging
• Function trace
• Webgrind
– https://github.com/jokkedk/webgrind
• Xdebug trace explorer
– https://github.com/corretge/xdebug-trace-gui
• KCacheGrind
– https://kcachegrind.github.io/html/Home.html
PROFILING
X-debug ao resgate
Execução não recomendada em produção
57. DICAS #1
• Comentários
• Ler a documentação
• Projetos open source
• Responsabilidade única
• Entender o que está fazendo
• Utilizar frameworks
58. DICAS #2
• Conhecer suas tools
• Manter-se atualizado
• Reuniões de nivelamento
• Usar o bom senso
• Pensar antes de codificar
http://www.skorks.com/page/3/
INCLUIR VARIAÇÃO DO TEMPO?
Corretude: Correto processamento de entradas para originar saidas
Extensibilidade: Suporte ao crescimento e evolução do sistema
Manutenabilidade: Facilidade de manutenção do sistema
Reusabilidade: Reaproveitamento de módulos ou partes do sistema em outros sistemas
Code coverage é uma estatística de qto (totalidade e variações) do programa foram testadas durante a análise dinâmica
Temos também uma análise de profile, que é uma análise dinâmica que gera estatísticas que precisam ser analisadas
Corretude: Correto processamento de entradas para originar saidas
Extensibilidade: Suporte ao crescimento e evolução do sistema
Manutenabilidade: Facilidade de manutenção do sistema
Reusabilidade: Reaproveitamento de módulos ou partes do sistema em outros sistemas
Por ser recomendações, nem sempre são validos, mas devem ser levados em consideração para tomar decisões
Nivelamento por baixo – exemplo de arrumar um tanque em meio à guerra
A manutenção é local fácil, quando você duplica uma “solução” o bicho pega
----- Meeting Notes (09/03/16 20:09) -----
slackware
Inclui esquemas de banco, planos de testes, documentação e o build do sistema
Os geradores de código tornam a informação única, pois a origem será sempre a mesma
Um bom exemplo de duplicação de documentação é a utilização de um wiki/doc que ao invés de referenciar um item, ele o explica novamente.
Qdo há duplicação de conhecimento, alguém deve ser definida como autoridade de representação, o que está sempre correto
Exemplo: C++ header and class file, o header é utilizado pelo compilador como autoridade de validação
do the simplest thing that could possibly work
Não poupe tempo – minimo produto viável MVP
O problema é originado qdo o singleton é disponibilizado através de um getInstance()
Para diminuir o tight coupling usa-se: Interfaces, Callbacks, Listeners
Acarreta dificuldade de reutilização do código
Resumindo, é qdo vc precisa alterar um módulo acarretado por modificações em outro (pode não ser obvio, o que eh pior)
Deve-se preocupar com o compling em níveis mais altos do sistema
Geralmente causada por tight coupling, singletons e várias responsabilidades
Recomendado rodar profiles de código em um momento posterior
No principio utilizava-se polimorfismo para não atrapalhar a definição de programas que utilizavam o módulo (88, tipos concretos)
Qdo reformulado, for dito que seria necessário definir uma interface, que seria fechada para modificações,
que seria implementada conforme a necessidade, portanto, aberta para extensões. Com a utilização de interfaces, a implementação fica por conta
de quem vai estender (90, tipos abstratos)
Principio derivado do OCP, adicionando a verificação comportamental
Pós condição: o resultado de um fatorial sempre deve ser um inteiro maior ou igual a 1
Pré condição: o divisor de uma divisão deve ser diferente de zero
Exemplo do quadrado estendendo o retângulo, no quadrado, os setters sempre definem o mesmo valor pros dois itens. Um calculo de área, seria calculado de forma errada.
R: W:5, H10 => A50 / Q: W:5, H10 => A100
Coesão, deixa coisas similares juntas
Coesão, deixa coisas similares juntas
Coesão, deixa coisas similares juntas
We wish to avoid designs which are: Rigid (Hard to change due to dependencies. Especially since dependencies are transitive.)
Fragile (Changes cause unexpected bugs.)
Immobile (Difficult to reuse due to implicit dependence on current application code.)
Desgin rules: goto, eval, acomplagem
Design rules: goto, eval, acomplagem
Desgin rules: goto, eval, acomplagem
Bolas são arquivos
Tamanho é complexidade
Cor é indice de manutenabilidade
XHProf é uma ferramenta recomendada para produção
Execução não recomendada devido à quantidade de informações coletadas e gravadas em disco
Code coverage: (upper) Lista de funções que chamam a função selecionada, mesmo indiretamente
Treemap: área do retangulo é proporcional ao custo da função
Flatprofile: número médio de chamadas
http://phpdebugbar.com/
----- Meeting Notes (09/03/16 20:09) -----
programador limpo
codigo limpo
livro
design de pacotes