Na nossa vida é importante nos preocuparmos com nossa saúde, e DEVEMOS fazer o mesmo com a saúde dos nossos softwares. Você verá aqui as principais ferramentas para medir qualidade e encontrar alguns tumores nos seus projetos!

1. Qualidade em Projetos PHP
Luís Otávio Cobucci Oblonczyk
19 de Novembro de 2011
PHPSC Conference 2011

2. Luís Otávio Cobucci Oblonczyk
● Desenvolvedor PHP na Softnex Tecnologia
● Orientador no Senac TI
● Doido por PHP desde 2003
● Perfeccionista ao extremo =Po
● Futuro PHP 5.3 ZCE? (teste em dezembro!)
@lcobucci
http://about.me/lcobucci

3. No trabalho, devemos lidar com várias coisas...

4. Algumas nos deixam felizes...

5. Outras nem tanto...

6. Alguns precisam de combustível...

7. Outros de diversão...

8. Para trabalhar com bom humor...

9. Mas tudo tem limite!

10. Funcionando!!!

11. Mas será que apenas funcionar é suficiente?

12. Não!!!
É preciso ter qualidade

13. Qualidade
“Qualidade é um conceito subjetivo que está
relacionado diretamente às percepções de cada
indivíduo.
Diversos fatores como cultura, modelos
mentais, tipo de produto ou serviço prestado,
necessidades e expectativas influenciam
diretamente nesta definição.”
http://pt.wikipedia.org/wiki/Qualidade

14. Atributos de qualificação de
software
●
Funcionalidade (oferece funcionalidades necessárias)
●
Usabilidade (é fácil de utilizar)
●
Confiabilidade (informações geradas são confiáveis)
●
Performance (tempo de resposta de gente)
●
Suportabilidade (é fácil de dar manutenção no código)

15. A vida de um software sem
qualidade
●
Devido a um fato sobrenatural seu código para de
funcionar
●
A correção dos bugs é simples, o problema é encontrá-
los
●
Ao corrigir uma coisa, outras três param de funcionar
●
“O sistema estava funcionando até você usá-lo”

17. “You can't control what you can't measure”
DeMarco, Tom

19. O software é um tumor...

20. E para mantermos ele com saúde

21. Precisamos utilizar as ferramentas corretas...

22. PHPUnit
●
Possibilita a criação de testes de unidade de forma
simples e precisa
●
Mostra o local exato dos problemas
●
Facilita as manutenções (diminui a possibilidade de
uma correção danificar outras funcionalidades)
●
Métricas: número de testes (com falha ou não),
número de métodos testados, cobertura de testes
http://www.phpunit.de/manual/current/en/index.html

23. Atenção: testes podem mentir...

24. Atenção: testes podem mentir...

25. Mutagenesis
●
Verifica se seus testes estão “falando a verdade”
●
Basicamente ele “muda” seu código em tempo de
execução e roda seus testes de unidade, se os testes
permanecerem funcionando muito provavelmente
existem testes mal feitos.
https://github.com/zenovich/runkit
https://github.com/padraic/mutagenesis

26. PHPLoc
●
Provê uma visão geral do projeto
●
Métricas: quanto código existe no projeto (lines of
code) e como está organizado (número de
namespaces, classes, métodos, funções, constantes)
https://github.com/sebastianbergmann/phploc

28. PHP CodeSniffer
●
Varre seu projeto buscando violações de coding
standards
●
Métricas: número de violações encontradas, quais
partes devem ser corrigidas
http://pear.php.net/package/PHP_CodeSniffer

30. PHPCPD
●
Busca duplicações de códigos em seu projeto
●
Métricas: número e locais das duplicações
https://github.com/sebastianbergmann/phpcpd

32. PHPMD
●
Varre seu código buscando possíveis falhas
●
Mostra os locais que deveriam ser refatorados devido
à: variáveis que não são utilizadas, classes/métodos
muito complexos ou muito grandes, nomenclaturas
confusas em variáveis e métodos
http://phpmd.org

33. ●
Avoid short names
●
Class has too many methods
●
Avoid unused local variables
●
Overall complexity
●
Number of dependencies

34. DocBlox
●
Gera documentação de API a partir dos comentários
no código
●
Criação incremental
●
Compatível com PHP 5.3
●
Gera diagrama com as classes (precisa do graphviz)
●
Mais rápido e mais leve que o PHP Documentor
http://www.docblox-project.org/

36. Como juntar isso tudo?

37. Automatizando

38. Phing
●
“PHing Is Not GNU make; it's a PHP project build
system or build tool based on Apache Ant. “
●
Ferramenta de automatização de tarefas
●
Com o Phing é possível definir o processo de
build dos projetos
http://www.phing.info

39. Build?

40. Software build
●
“In the field of computer software, the term
software build refers either to the process of
converting source code files into standalone
software artifact(s) that can be run on a
computer, or the result of doing so.”
●
Processo de converter o código-fonte em um ou
mais artefatos, ou o resultado deste processo
http://en.wikipedia.org/wiki/Software_build

41. Porque usar o Phing?
●
Simples de configurar
●
Possui tarefas para as principais ferramentas
●
É extensível
●
É feito em PHP

42. Então é uma lista de tarefas?

43. Phing
●
Em cada projeto você define as etapas do build
em um arquivo XML
●
As etapas podem depender ou executar outras
etapas
●
Podem ser definidas propriedades no arquivo
XML ou em um arquivo externo

44. <?xml version="1.0" encoding="UTF-8"?>
<project name="ProjectName" default="build" basedir="." />

45. <?xml version="1.0" encoding="UTF-8"?>
<project name="ProjectName" default="build" basedir="." >
<target name="build" />
</project>

46. <?xml version="1.0" encoding="UTF-8"?>
<project name="ProjectName" default="build" basedir="." >
<property name="buildDir" value="${project.basedir}/build" />
<property name="reportsDir" value="${buildDir}/reports" />
<property name="docDir" value="${buildDir}/doc" />
<target name="clean">
<delete dir="${buildDir}" includeemptydirs="true" failonerror="true" />
<mkdir dir="${buildDir}" />
<mkdir dir="${reportsDir}" />
<mkdir dir="${docDir}" />
<exec command="chmod -R 777 ${buildDir}" />
</target>
<target name="phpunit"><echo msg="Testes de unidade"/></target>
<target name="phpmd" ><echo msg="Verificação de erros"/></target>
<target name="build" depends="clean">
<phingcall target="phpunit" />
<phingcall target="phpmd" />
</target>
</project>

48. Phing
●
É possível ainda:
●
SSH/SCP
●
Phar/Tar/Zip
●
Pear/Pear2
●
SVN/Git
●
Patch
●
Ftp (upload)
E mais: http://www.phing.info/docs/guide/stable/

49. Socorro, por onde começo?

50. Prepare-se psicologicamente!

51. Próximos passos?
●
Crie testes de unidade aos poucos sem mudar o
código
●
Utilizando o PMD verifique os pontos mais
críticos de otimização
●
Comece a refatoração!
●
Para as novas funcionalidades SEMPRE crie
testes, de preferencia seguindo as premissas do
TDD
●
Instale um servidor de Integração Contínua

52. Integração Continua
●
De forma bem rudimentar é a “automatização da
automatização”
●
Executa seu script de build automaticamente
logo após todo commit realizado no servidor de
controle de versionamento (ideal)
●
Mantém registrados os builds passados para
comparação de informação
●
Possui visualização em gráfico para execução de
testes de unidade, violações PMD, CPD e de Code
Standards

54. Dúvidas???

55. Obrigado!
Eu por aí: http://about.me/lcobucci
Slides: http://slideshare.net/lcobucci
Avalie essa palestra: http://joind.in/4496