Maykel S. Braz
http://about.me/maykelsantosbraz
POTENCIALIZANDO A
QUALIDADE DE CÓDIGO
Padrões, princípios e ferramentas
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
O QUE É QUALIDADE?
Ou, como ela é percebida, visualizada, e/ou medida?
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
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
MAS O TRABALHO É TODO SEU
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Com grandes poderes, vêm grandes responsabilidades
freepik.com
COMO SE MEDE A QUALIDADE?
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Enquanto isso, na sala de review...
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
Extensibilidade
(Extensibility)
Corretude
(Correctness)
Reusabilidade
(Reusability)
Manutenabilidade
(Maintainability)
QUALIDADE
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
Qualidade
PRINCÍPIOS DE DESIGN DE
SOFTWARE
Diretrizes para se considerar ao / antes de codificar
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
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
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
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
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
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
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
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
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
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
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’);
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()?
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.
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
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
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.
INTERFACE SEGREGATION
PRINCÍPIOS DE DESIGN DE SOFTWARE >> SOLID
INTERFACE SEGREGATION
PRINCÍPIOS DE DESIGN DE SOFTWARE >> SOLID
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
DEPENDENCY INVERSION
PRINCÍPIOS DE DESIGN DE SOFTWARE >> SOLID
DEPENDENCY INVERSION
PRINCÍPIOS DE DESIGN DE SOFTWARE >> SOLID
DEPENDENCY INVERSION
PADRÕES DE CODIFICAÇÃO
A resposta da velha pergunta: “Coloco a chave na frente ou embaixo?”
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
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
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!
PSR FORMATER
Editor/IDE Suporte URL
Netbeans Config
https://github.com/bobsta
63/netbeans-psr-
formatting
Eclipse Nativo -
PHPStorm Nativo -
Sublime Config
https://github.com/phpfmt
/sublime-phpfmt
Zend Studio Nativo/Config
https://github.com/netojo
aobatista/PSR-2
QA TOOLS
Gestão da qualidade
PHPQA
POTENCIALIZANDO A QUALIDADE DE CÓDIGO
The PHP Quality Assurance Toolchain
PHPUnit
+
vfsStream
PHPLoc Behat
PHP_Depend
PHP
Mess Detector
PHP_CodeSniffer
PHP Copy/Paste
Detector
PHPDoxPHPMetrics
PHP DEPEND
• Métricas do código
– Indicadores de qualidade
– Refatoração
QA TOOLS >> PHPQA
https://pdepend.org/
Output é complicado e
maçante
PHP MESS DETECTOR
• Bugs
• Código subotimizado
• Expressões
supercomplicadas
• Código não utilizado
• Regras de design
• Regras de nomenclatura
QA TOOLS >> PHPQA
https://phpmd.org/
PHP_CODESNIFFER
• Violação de regras de
codificação
– PHP
– Javascript
– CSS
QA TOOLS >> PHPQA
http://pear.php.net/PHP_CodeSniffer
PHP COPY/PASTE DETECTOR
• Duplicidade de código
QA TOOLS >> PHPQA
https://github.com/sebastianbergmann/phpcpd
PHPDOX
• Documentação de API
• Info de fontes externas
QA TOOLS >> PHPQA
http://phpdox.de/
PHPUnit
PHPMD
PHPCS
PHPDox
PHPLOC
GIT
PHPDOX
QA TOOLS >> PHPQA
http://phpdox.de/
PHPDOX
QA TOOLS >> PHPQA
http://phpdox.de/
PHPMETRICS
• Métricas de código
– Indicadores de qualidade
• Geração de relatórios
– Qualidade
– Complexidade
– Manutenabilidade
QA TOOLS >> PHPQA
http://www.phpmetrics.org/
QA TOOLS >> PHPQA >> PHPMETRICS
INTEGRAÇÃO CONTÍNUA
• Incorporação no build
– Testes unitários
– Documentação
– Análise estática
• Aumento legibilidade
• Clareza
– Helicopter view
– Quality Gate
– Technical debt
QA TOOLS >> CI
Colocando tudo no mesmo balaio e melhorando a legibilidade
Jenkins
PHPQA
Sonar Qube
SONAR QUBE
QA TOOLS
https://nemo.sonarqube.org/
SONAR QUBE
QA TOOLS
PROFILING
- Não otimize agora.
- Ainda não!
- Agora sim, vamos lá.
- Mas antes disso, já rodou o profiler?
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
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
KCACHEGRIND
PROFILING >> XDEBUG
https://kcachegrind.github.io/html/Home.html
SYMFONY WEBDEBUG TOOLBAR
PROFILING
ZEND Z-RAY
PROFILING
LARAVEL DEBUGBAR
PROFILING
https://github.com/barryvdh/laravel-debugbar
DICAS GERAIS
DICAS #1
• Comentários
• Ler a documentação
• Projetos open source
• Responsabilidade única
• Entender o que está fazendo
• Utilizar frameworks
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/
PERGUNTAS?
DC Comics
maykelsb@yahoo.com.br
about.me/maykelsantosbraz
Contato
REFERÊNCIAS
 http://principles-wiki.net/
 https://en.wikipedia.org/wiki/KISS_principle
 https://effectivesoftwaredesign.com/2013/02/07/on-
developer-wisdom-and-software-quality-attributes/
 www.cin.ufpe.br/~if718/referencias/qualidade.ppt
 http://www.artima.com/intv/dry.html
 http://c2.com/cgi/wiki?DontRepeatYourself
 http://seiti.eti.br/kiss-yagni-e-dry/
 https://www.youtube.com/watch?v=LnPl04fYtcs
 http://williamdurand.fr/2013/07/30/from-stupid-to-
solid-code/
 http://misko.hevery.com/2008/08/17/singletons-are-
pathological-liars/
 http://programmers.stackexchange.com/questions/403
73/so-singletons-are-bad-then-what
 http://martinfowler.com/ieeeSoftware/coupling.pdf
 https://sourcemaking.com/refactoring/smells
 https://speakerdeck.com/miccheng/continuous-
integration-for-php-with-jenkins-and-sonar
 http://simpleprogrammer.com/2012/05/27/types-
of-duplication-in-code/
 http://c2.com/cgi/wiki
 http://www.oodesign.com/liskov-s-substitution-
principle.html
 http://noviciateinitiate.blogspot.com.br/2014/01/t
he-solid-principles-of-design-part-4.html
 https://en.wikipedia.org/wiki/Dependency_inversio
n_principle
 http://aspiringcraftsman.com/2008/12/28/examini
ng-dependency-inversion/
 http://martinfowler.com/articles/dipInTheWild.html
 https://www.42lines.net/2012/07/06/clean-code-
reducing-wtfs-per-minute/
 http://pt.slideshare.net/nethisip13/quality-control-
45498380
 https://www.42lines.net/2012/07/06/clean-code-
reducing-wtfs-per-minute/
 http://erichogue.ca/2011/03/linux/profiling-a-php-
application/
POTENCIALIZANDO A QUALIDADE DE CÓDIGO

Potencializando a qualidade de código

  • 1.
    Maykel S. Braz http://about.me/maykelsantosbraz POTENCIALIZANDOA QUALIDADE DE CÓDIGO Padrões, princípios e ferramentas
  • 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 MEDEA 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
  • 8.
  • 9.
    PRINCÍPIOS DE DESIGNDE SOFTWARE Diretrizes para se considerar ao / antes de codificar POTENCIALIZANDO A QUALIDADE DE CÓDIGO
  • 10.
    PRINCÍPIOS DE DESIGNDE 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 pelasimplicidade • 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 arepetiçã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 aXP • 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 • TightCoupling • 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 • TightCoupling • 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 • TightCoupling • 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 • TightCoupling • 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 • TightCoupling • 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 • TightCoupling • 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.
  • 25.
    INTERFACE SEGREGATION PRINCÍPIOS DEDESIGN DE SOFTWARE >> SOLID
  • 26.
    INTERFACE SEGREGATION PRINCÍPIOS DEDESIGN DE SOFTWARE >> SOLID
  • 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
  • 28.
    DEPENDENCY INVERSION PRINCÍPIOS DEDESIGN DE SOFTWARE >> SOLID
  • 29.
    DEPENDENCY INVERSION PRINCÍPIOS DEDESIGN DE SOFTWARE >> SOLID
  • 30.
  • 31.
    PADRÕES DE CODIFICAÇÃO Aresposta da velha pergunta: “Coloco a chave na frente ou embaixo?” POTENCIALIZANDO A QUALIDADE DE CÓDIGO
  • 32.
    PADRÕES PHP-FIG POTENCIALIZANDO AQUALIDADE 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!
  • 34.
    PSR FORMATER Editor/IDE SuporteURL Netbeans Config https://github.com/bobsta 63/netbeans-psr- formatting Eclipse Nativo - PHPStorm Nativo - Sublime Config https://github.com/phpfmt /sublime-phpfmt Zend Studio Nativo/Config https://github.com/netojo aobatista/PSR-2
  • 35.
  • 36.
    PHPQA POTENCIALIZANDO A QUALIDADEDE CÓDIGO The PHP Quality Assurance Toolchain PHPUnit + vfsStream PHPLoc Behat PHP_Depend PHP Mess Detector PHP_CodeSniffer PHP Copy/Paste Detector PHPDoxPHPMetrics
  • 37.
    PHP DEPEND • Métricasdo código – Indicadores de qualidade – Refatoração QA TOOLS >> PHPQA https://pdepend.org/ Output é complicado e maçante
  • 38.
    PHP MESS DETECTOR •Bugs • Código subotimizado • Expressões supercomplicadas • Código não utilizado • Regras de design • Regras de nomenclatura QA TOOLS >> PHPQA https://phpmd.org/
  • 39.
    PHP_CODESNIFFER • Violação deregras de codificação – PHP – Javascript – CSS QA TOOLS >> PHPQA http://pear.php.net/PHP_CodeSniffer
  • 40.
    PHP COPY/PASTE DETECTOR •Duplicidade de código QA TOOLS >> PHPQA https://github.com/sebastianbergmann/phpcpd
  • 41.
    PHPDOX • Documentação deAPI • Info de fontes externas QA TOOLS >> PHPQA http://phpdox.de/ PHPUnit PHPMD PHPCS PHPDox PHPLOC GIT
  • 42.
    PHPDOX QA TOOLS >>PHPQA http://phpdox.de/
  • 43.
    PHPDOX QA TOOLS >>PHPQA http://phpdox.de/
  • 44.
    PHPMETRICS • Métricas decódigo – Indicadores de qualidade • Geração de relatórios – Qualidade – Complexidade – Manutenabilidade QA TOOLS >> PHPQA http://www.phpmetrics.org/
  • 45.
    QA TOOLS >>PHPQA >> PHPMETRICS
  • 46.
    INTEGRAÇÃO CONTÍNUA • Incorporaçãono build – Testes unitários – Documentação – Análise estática • Aumento legibilidade • Clareza – Helicopter view – Quality Gate – Technical debt QA TOOLS >> CI Colocando tudo no mesmo balaio e melhorando a legibilidade Jenkins PHPQA Sonar Qube
  • 47.
  • 48.
  • 49.
    PROFILING - Não otimizeagora. - 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
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
  • 57.
    DICAS #1 • Comentários •Ler a documentação • Projetos open source • Responsabilidade única • Entender o que está fazendo • Utilizar frameworks
  • 58.
    DICAS #2 • Conhecersuas tools • Manter-se atualizado • Reuniões de nivelamento • Usar o bom senso • Pensar antes de codificar http://www.skorks.com/page/3/
  • 59.
  • 60.
    REFERÊNCIAS  http://principles-wiki.net/  https://en.wikipedia.org/wiki/KISS_principle https://effectivesoftwaredesign.com/2013/02/07/on- developer-wisdom-and-software-quality-attributes/  www.cin.ufpe.br/~if718/referencias/qualidade.ppt  http://www.artima.com/intv/dry.html  http://c2.com/cgi/wiki?DontRepeatYourself  http://seiti.eti.br/kiss-yagni-e-dry/  https://www.youtube.com/watch?v=LnPl04fYtcs  http://williamdurand.fr/2013/07/30/from-stupid-to- solid-code/  http://misko.hevery.com/2008/08/17/singletons-are- pathological-liars/  http://programmers.stackexchange.com/questions/403 73/so-singletons-are-bad-then-what  http://martinfowler.com/ieeeSoftware/coupling.pdf  https://sourcemaking.com/refactoring/smells  https://speakerdeck.com/miccheng/continuous- integration-for-php-with-jenkins-and-sonar  http://simpleprogrammer.com/2012/05/27/types- of-duplication-in-code/  http://c2.com/cgi/wiki  http://www.oodesign.com/liskov-s-substitution- principle.html  http://noviciateinitiate.blogspot.com.br/2014/01/t he-solid-principles-of-design-part-4.html  https://en.wikipedia.org/wiki/Dependency_inversio n_principle  http://aspiringcraftsman.com/2008/12/28/examini ng-dependency-inversion/  http://martinfowler.com/articles/dipInTheWild.html  https://www.42lines.net/2012/07/06/clean-code- reducing-wtfs-per-minute/  http://pt.slideshare.net/nethisip13/quality-control- 45498380  https://www.42lines.net/2012/07/06/clean-code- reducing-wtfs-per-minute/  http://erichogue.ca/2011/03/linux/profiling-a-php- application/ POTENCIALIZANDO A QUALIDADE DE CÓDIGO

Notas do Editor

  • #7 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
  • #8 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
  • #9 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
  • #11 Por ser recomendações, nem sempre são validos, mas devem ser levados em consideração para tomar decisões
  • #12 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
  • #13 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
  • #14 do the simplest thing that could possibly work Não poupe tempo – minimo produto viável MVP
  • #16 O problema é originado qdo o singleton é disponibilizado através de um getInstance()
  • #17 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
  • #18 Geralmente causada por tight coupling, singletons e várias responsabilidades
  • #19 Recomendado rodar profiles de código em um momento posterior
  • #23 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)
  • #24 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
  • #25 Coesão, deixa coisas similares juntas
  • #26 Coesão, deixa coisas similares juntas
  • #27 Coesão, deixa coisas similares juntas
  • #28 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.)
  • #39 Desgin rules: goto, eval, acomplagem
  • #40 Design rules: goto, eval, acomplagem
  • #41 Desgin rules: goto, eval, acomplagem
  • #45 Bolas são arquivos Tamanho é complexidade Cor é indice de manutenabilidade
  • #53 XHProf é uma ferramenta recomendada para produção Execução não recomendada devido à quantidade de informações coletadas e gravadas em disco
  • #54 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
  • #57 http://phpdebugbar.com/
  • #61  ----- Meeting Notes (09/03/16 20:09) ----- programador limpo codigo limpo livro design de pacotes