Removendo o cheiro ruim do seu código - SoLiSC 2011

Removendo o cheiro ruim
do seu código
Luís Otávio Cobucci Oblonczyk

22 de Outubro de 2011
6° SoLiSC

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

Você verá agora uma imagem
forte, porém real...

Ela representa o seu
código, sim você viu
direito, é o SEU código
aqui!

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

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 é

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

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

Se você não está convencido,
vou argumentar um pouco

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

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.

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

Verdadeiro programador
de código limpo

Porque apenas funcionar
não é suficiente!

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

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

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

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

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!!

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)

Comentários
●
código mal feito
●
bem nomeada
●
if ($item->getStatus() == 3) // verifica se está
cancelado

Comentários
●
código mal feito
●
bem nomeada
●
if ($item->getStatus() == 3) // verifica se está
cancelado
●
if ($item->estahCancelado())

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!

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

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)

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!

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

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).

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)

<?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;
}
}

<?php
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;
}
}

<?php


class Calculator
{
private $logger;

{
}

public function divide($dividend, $divisor)
{
$this->logger->log(
'div',
array($dividend, $divisor),
$divisor == 0 ? false : $dividend / $divisor
);

return $divisor == 0 ? false : $dividend / $divisor;
}
}

<?php


class Calculator
{
private $logger;
{
}

{
if ($divisor == 0) {
throw new InvalidArgumentException('Divisor can`t be ZERO');
}
$this->logger->log(
'div',
array($dividend, $divisor),
$dividend / $divisor
);

return $dividend / $divisor;
}
}

<?php

class Calculator
{
private $logger;
{
}

{
if ($divisor == 0) {
throw new InvalidArgumentException('Divisor can`t be ZERO');
}

$result = $dividend / $divisor;
$this->logger->log('div', array($dividend, $divisor), $result);

return $result;
}
}

Obrigado!

Eu por aí: http://about.me/lcobucci
Slides: http://slideshare.net/lcobucci

Avalie essa palestra: http://joind.in/3948

Removendo o cheiro ruim do seu código - SoLiSC 2011

Mais conteúdo relacionado

Mais procurados

Semelhante a Removendo o cheiro ruim do seu código - SoLiSC 2011

Removendo o cheiro ruim do seu código - SoLiSC 2011