1. Removendo o cheiro ruim
do seu código
Luís Otávio Cobucci Oblonczyk
22 de Outubro de 2011
6° SoLiSC

2. Luís Otávio Cobucci Oblonczyk
●
Desenvolvedor PHP na Softnex Tecnologia
●
Orientador no Senac TI
●
Doido por PHP desde 2003
●
Perfeccionista ao extremo =P
@lcobucci
http://about.me/lcobucci

3. Prepare-se

4. Você verá agora uma imagem
forte, porém real...
Ela representa o seu
código, sim você viu
direito, é o SEU código
aqui!

6. Sim, essa é a real visão do seu código,
e só você não percebeu isso ainda

7. Sim, essa é a real visão do seu código,
e só você não percebeu isso ainda
E não adianta querer
colocar uma telinha
bonitinha, porque lá
no fundo você sabe
como ele realmente é

8. Mas fique tranquilo, você tem
salvação (e seu código também)

9. Mas fique tranquilo, você tem
salvação (e seu código também)
Se você não está convencido,
vou argumentar um pouco

10. Vida do código ruim
●
Nasce difícil de entender
●
Cada manutenção gera uma (ou mais) falhas
●
Baixa produtividade devido a confusão absurda
existente
●
Surgem novos colaboradores na esperança de
que com mais gente tenha mais produtividade
●
Pressão na equipe
●
Mais falhas são criadas

11. Vida do código ruim
● Equipe revoltada propõe solução: jogar tudo no lixo e
começar novamente
● Divisão da equipe, os melhores vão modelar o novo
código enquanto os outros sofrem pra manter o
antigo
● Muito tempo se passa até que o novo entra no lugar
do antigo, muitas pessoas não estão nem mais na
empresa.
● Os colaboradores atuais exigem refazer o sistema
porque o código está uma porcaria novamente.

12. Alguém se identificou?

13. Mandamentos do código limpo
●
Nunca terás ciúmes do código que você criar
●
Não possuirás misericórdia para com código de
seus colegas
●
Matarás TODO e QUALQUER princípio de
código sujo

14. Verdadeiro programador
de código limpo

15. Porque apenas funcionar
não é suficiente!

16. Blz, como posso melhorar?

17. Escolha nomes decentes!

18. Nomenclatura
●
Use nomes que possuem algum sentido
●
Evite abreviações
●
Evite passar informações incorretas
●
Use nomes pronunciáveis
●
Cuidado ao misturar idiomas
●
Não dê dois (ou mais) sentidos para a mesma
palavra

19. Nomenclatura – Classes
●
Nomes das classes devem ser substantivos,
NUNCA verbos
●
A classe deve receber o nome do elemento que
ela representa na vida real

20. Nomenclatura – Métodos
●
Nomes dos devem SEMPRE conter verbos
●
Caso programar em português, os verbos
devem ser utilizados no modo imperativo
(calculaJuros(), cancelaCompra(), ...)

21. Nomenclatura – Interfaces
●
Interfaces adicionam comportamentos aos
objetos, portanto normalmente são nomeadas
como adjetivos (Clickable, Draggable,
Resizeable, …) ou substantivos (Iterator,
SplObserver, SplSubject)
●
Não há absolutamente NENHUMA necessidade
de colocar o prefixo “I” em uma interface

22. Criando métodos e funções

23. Métodos e funções
●
Devem ser PEQUENOS (no máximo 20 linhas)
●
Devem fazer apenas UMA tarefa
●
Cuidado com a complexidade ciclomática dos
métodos e funções (quantidade de caminhos
possíveis na execução)
●
Caso existam muitos parâmetros, considere
agrupar os parâmetros com o mesmo contexto
em um objeto
●
NÃO REPITA CÓDIGO!!

24. Lidando com comentários

25. Comentários
●
Comentários normalmente compensam um
código mal feito
●
Evite sempre o comentário que você pode
substituir por uma variável ou método/função
bem nomeada
●
if ($item->getStatus() == 3)

26. Comentários
●
Comentários normalmente compensam um
código mal feito
●
Evite sempre o comentário que você pode
substituir por uma variável ou método/função
bem nomeada
●
if ($item->getStatus() == 3) // verifica se está
cancelado

27. Comentários
●
Comentários normalmente compensam um
código mal feito
●
Evite sempre o comentário que você pode
substituir por uma variável ou método/função
bem nomeada
●
if ($item->getStatus() == 3) // verifica se está
cancelado
●
if ($item->estahCancelado())

28. Comentários
●
Comentários após fechar chaves são ruídos
desnecessários
●
Código comentado é inútil, portanto deve ser
exterminado da face da terra
●
Sempre que sentir necessidade de comentar
pode ter certeza que algo de errado não
está certo!

29. Utilize coding standards

30. Code Style
●
Unifica a forma que o código é escrito na
empresa, assim TODOS entendem o código de
forma prática e rápida
●
Você deve escolher um padrão de formatação
de código e combinar com a equipe TODA para
adotar este padrão

31. Gerenciando erros

32. Tratamento de erros
●
Prefira exceptions do que retornar mensagens
ou códigos de erros
●
Crie as exceptions necessárias para o
tratamento de erros das suas tarefas
●
Evite tratar a classe base de exception
●
O tratamento de exceptions é uma tarefa,
portanto no método que tratá-las não deve
haver nenhuma tarefa após o(s) catch(s)

33. Classes

34. Criando classes
●
Classes devem ser PEQUENAS
●
Mantenha os atributos encapsulados
●
Classes devem possuir apenas UMA
responsabilidade, ou seja deve estar inserida em
somente um contexto
●
Busque sempre a alta coesão, e
consequentemente baixo acoplamento
●
Utilize injeção de dependências
●
Crie testes automatizados!

35. Refatoração é OBRIGAÇÃO!

36. Refatoração
“Refatoração (do inglês Refactoring) é o processo
de modificar um sistema de software para
melhorar a estrutura interna do código sem alterar
seu comportamento externo.
(…)
Outra consequência é a melhora no entendimento
do código, o que facilita a manutenção e evita a
inclusão de defeitos.”
http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o

37. Refatoração
●
Devem SEMPRE existir testes de unidade para
podermos realizar uma refatoração correta
(sem eles não temos como afirmar que o
comportamento realmente não foi alterado).

38. Técnicas de refatoração
●
Extração de método
●
Extração de classe
●
Extração de variável local
●
Renomear classe/método/atributo
●
Encapsular atributo
●
Subir nível na hierarquia (para classe pai)
●
Descer nível na hierarquia (para classe filha)
●
Mover método/atributo (para outra classe)

39. Detonando TUDO!

40. <?php
namespace LcobucciUtilsMath;
use LcobucciUtilsLogFileLogger;
class Calculator
{
private $logger;
public function __construct()
{
$this->logger = new FileLogger();
}
public function div($x, $y)
{
$this->logger->log(
'div',
array($x, $y),
$y == 0 ? false : $x / $y
);
return $y == 0 ? false : $x / $y;
}
}

41. <?php
namespace LcobucciUtilsMath;
use LcobucciUtilsLogFileLogger;
class Calculator
{
private $logger;
public function __construct(FileLogger $logger)
{
$this->logger = $logger;
}
public function div($x, $y)
{
$this->logger->log(
'div',
array($x, $y),
$y == 0 ? false : $x / $y
);
return $y == 0 ? false : $x / $y;
}
}

42. <?php
namespace LcobucciUtilsMath;
use LcobucciUtilsLogFileLogger;
class Calculator
{
private $logger;
public function __construct(FileLogger $logger)
{
$this->logger = $logger;
}
public function divide($dividend, $divisor)
{
$this->logger->log(
'div',
array($dividend, $divisor),
$divisor == 0 ? false : $dividend / $divisor
);
return $divisor == 0 ? false : $dividend / $divisor;
}
}

43. <?php
namespace LcobucciUtilsMath;
use LcobucciUtilsLogFileLogger;
class Calculator
{
private $logger;
public function __construct(FileLogger $logger)
{
$this->logger = $logger;
}
public function divide($dividend, $divisor)
{
if ($divisor == 0) {
throw new InvalidArgumentException('Divisor can`t be ZERO');
}
$this->logger->log(
'div',
array($dividend, $divisor),
$dividend / $divisor
);
return $dividend / $divisor;
}
}

44. <?php
namespace LcobucciUtilsMath;
use LcobucciUtilsLogFileLogger;
class Calculator
{
private $logger;
public function __construct(FileLogger $logger)
{
$this->logger = $logger;
}
public function divide($dividend, $divisor)
{
if ($divisor == 0) {
throw new InvalidArgumentException('Divisor can`t be ZERO');
}
$result = $dividend / $divisor;
$this->logger->log('div', array($dividend, $divisor), $result);
return $result;
}
}

45. Dúvidas???

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