Clean Code         ’Desenvolvendo como um Profissional Agil André Faria            Bruno Lui @andrefaria           @bruno_...
André Faria GomesCIO na Bluesoft+10 de Anos de Desenvolvimento de SoftwareBlack Belt Lean 6 SigmaInstrutor da Adaptworks  ...
Bruno Lui             Desenvolvedor na Bluesoft+5 Anos no Desenvolvimento de Software              @brunolui              ...
Então você quer serum desenvolvedor de     software   profissional?
Quer que as mãesapontem para você edigam a seus filhospara que sejam como       você?
Cuidado com oque você Pede!
Profissionalismo ésem dúvida digno   de honra e  orgulho, mas    também é responsabilidade.
Você não pode se orgulhar de algo pelo qual não se responsabiliza...
É muito mais fácil ser umlargado... Não se responsabilizar pelo trabalho e pela carreira....
Quando umnão-profissional faz uma besteira, seuempregador limpa a     bagunça...
Quando um profissional faz uma besteira, ele   limpa a bagunça!
O que você faz para escrever  software sem defeitos?
Você se responsabiliza pelos defeitos                             que cria?
Escrever testes é essencial paragarantir que seu software funciona...
Como você pode dizerque é responsável se  não os escreve?
“Toda a linha de código que você escreve deve estar testada, e         Ponto Final!”                Uncle Bob
Código escrito porprofissionais pode seralterado sem custos    exorbitantes!
Em outras palavras,    você também é   responsável pelaestrutura do código que       escreve!
Sua carreira é sua    responsabilidade!   Leia     Treine  Vá a conferênciasNão é responsabilidade do seu empregador
Sua empresa te ajuda       com isso? Ótimo! Estão tefazendo um favor.
Mas aresponsabilidade ainda é sua!
Também não é responsabilidade do seuempregador te dar “tempo” para você estudar...
“Você recebe por 40horas para resolveros problemas da sua  empresa não os      seus...”           Uncle Bob
Faça as contas....
Sua semana tem 168 horas.
Dê à seuempregador40, e à suacarreira 20
Sobram 108
+ 56 para dormir  48
+ 52 para ...  60
Só não desperdice...
Durante essas 20 horas você deveestar fazendo algo  que gosta, queaumente ainda maisa sua paixão pelo     que faz.
Esse é o grande    segredo!
Além disso,   o desenvolvedorprofissional de verdade se preocupa com o código que escreve...
...desenvolve somente códigolimpo e não consegue mais   escrever código ruim.
Ninguém gosta de encontrar     um código ruim !
Raiva
Perda de Tempo
Frustração
Dor
Você fica P...
Mas afinal, o que é umcódigo limpo?
O que é um código limpo ?SimplesDiretoEficienteSem duplicidadeEleganteFeito com cuidado
N om   es       nific ati voss   igEscolhemos nomespara tudo, entãodevemos fazerisso bem feito
O nome deve dizer...- Por que existe;- O que faz;- Como é usado;
Use nomes que revelem sua intenção
int d;       // daysSe um nome de classe ou método requer umcomentário, ele não está revelando sua intenção
Faça distinções      significativasa1?       a2?int d?
for (int j=0; j < 34; j++) {     s += (t[j]*4)/5;}Nomes com apenas uma letra ou numéricos    são difíceis de serem encontr...
Use nome           s fáceis deencontrar
Use nome            spronunciáv           eis
private Timestamp genDMYHS()        Pronuncie seu códigoprivate Timestamp generateTimestamp()
e pa  lavrasEvit       não    são que      palavras
Não economize palavras“Use várias palavras para que o método ou variávelsejam facilmente entendidos e possam transmitir se...
Evite palavras que podemser variáveis ou palavras reservadas em outras      plataformas     Evite desinformação
Evite dar nomes como“listaDeLancamentos”, o tiponão precisa estar no nome     (notação húngara)      Evite desinformação
Evite trocadilhos, escrevaexatamente o que você        quer dizer     Evite desinformação
prát icas  B oasNomes de classes devem sersubstantivos e não devem conter verbosNomes de métodos devem conter verbos
Class es        odos           M ét
Devem ser pequenos “A primeira regra dos métodos é que eles devem ser pequenos.     Asegunda regra é que eles devem ser   ...
método <= 20 linhas linha <= 100 caracteresclasse = 200 a 500 linhas
e    éto  dos “M         s d evem fun çõe           uma         apenasfaz er              certa          faz ê-la cois a, ...
efin ir o           é dO  difícil           uma           ape  nas       é “ que            co isa”
Tentar extrair um novo método deum outro, e dar um nome ao trechoextraído é uma maneira de identificar
ParâmetrosMétodos com muitos parâmetros devem serevitados e possuírem uma boa justificativa paraexistirem.Pois confundem e...
Cuidado com os   efeitos colaterais.Eles são mentiras contadas pelo método,quando diz que fará uma coisa, mas faz         ...
public boolean checkPassword (String password) {      String passwordStatus = crypto.decrypt(password);      if (passwordS...
CQS - Command Query SeparationMétodos devem fazer algo ou retornar algo, mas nãoas duas coisas. Isso gera confusão, além d...
DRY - Don’t Repeat YourselfPreste atenção no código repetido. Evite duplicidadesreaproveitando seus métodos.
Para saber se otamanho da classe é  o ideal, devemos   analisar suas responsabilidades.
Princípio da única da responsabilidade (SRP)O princípio diz que umaclasse deve ter uma, eapenas uma razão para        mudar.
Tentar identificar responsabilidades  ajuda a melhorarnosso código e criarmelhores abstrações  Esse é um dos  conceitos ma...
Coesão  Classes devem conter poucas variáveis.           Cada método deve manipular             uma ou mais variáveis. Qua...
Comentários
Comentários pode                 m ser mentirosos                 e       trazer   desinformação,mesmo sem inte           ...
Ele não recebem“man  utenção”, sendo   que quanto maisvelhos maior a chance de e starem errados.
Come ntários não vão esconder o   código ruim  Geralmente você comenta para que se faça entender.     Quando pensar em com...
// check if the employee is eligible for benefitsif ((employee.flags == 100) && (employee.age > 65))           Explique-se...
Closing brace commentstry {        String nada;        while (i = 3) {             i++;             ...     } // end while...
utras                            ça v ocê olhar para o“Qualquer c omentário que fa                         que            ...
Comentários podem ser úteis...                      Aviso de                 consequências que                  um trecho ...
Com entários podem ser úteis...   Mostrar a intenção  por trás de uma decisão   tomada, e não só pela        informação.
Nunca deixecódigo comentado!  Quando alguém vê um código                             decomentado, não tem coragem         ...
mataçãoFo   r
“Formatação é importante, pois se      trata de Comunicação.”   Boa Comunicação é essencial para os      desenvolvedores p...
A legibilidade do seu código teráprofundo efeito em todas as mudanças que serão feitas eseu estilo e disciplina sobrevivem...
Métodos com conceitos relacionados devem       ficar verticalmente próximos
A ordem dos métodos cria um fluxo deleitura melhorando a legibilidade do código
Uma boa   identação   do código ajuda a visualizar  todo o escopo, torna mais fácil e rápida a identificação de situações ...
Essa identação não deve ser maior do que 2,      para compreensão fácil e rápida                        if (a > 0) {      ...
Espaçamento  public getSum(int one,int two,double number){      double sum=number+(one*two);  }Dê espaços entre operadores...
tam entoT ra   de erros
Tratar erros é responsabilidade dodesenvolvedor, as coisas podem dar errado enós temos que garantir que nosso código tem  ...
Use exceptio ns ao invés de retornar c ódigos de erro              Quem faz a chamada deve           verificar se há erros...
Forneça o contexto    na exception     Crie mensagens  informativas para os  erros, mencione o que aconteceu, o que estava...
Separe as regras de negócio de erros ou               outras situações.try {    MealExpenses expenses = expensesDao.getMea...
Não retorne null    Prefira retornar  Special case objects  ou vazio no caso de        coleções
Não passe null Evite passar null para  seus métodos, isso     pode gerar as        famosas  NullPointerExceptions
Testesunitários
As Três Leis do TDD
As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.
As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.2 - Você não pode escrever mai...
As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.2 - Você não pode escrever mai...
1   conceito por testeSepare um teste que esteja    testando mais de umconceito em outros testes.Facilite o entendimento  ...
Te  stesF.I.R .S.T
Fast    Os testes devem ser        rápidos para executar,       pois quando são lentos       a frequência de execução     ...
Testes não podem depender uns dos outros, pois se um  falha os outros também          falharamIndependent
R epeatable        Ao executa-los mais de uma vez, devem         sempre retornar o mesmo resultado
Self-Validating  Devem possuir respostas  booleanas, sem precisar de  interpretação para saber o          resultado.
T imely  Os testes devem ser escritos antes do código. Após o código será mais   difícil fazer o teste.
O código do teste é tão importante quanto o  código da produçãoO teste precisa sofrer alterações da mesma  forma que o cód...
Quanto mais sujo o  teste mais difícil darmanutenção, e menor aflexibilidade para alterá-lo.
“Se você deixar  seus testesapodrecerem, seu código também  apodrecerá”
Fique atentoaos Maus  cheiros
- Comentários pobres, obsoletos e redundantes- Código comentado- Testes que requerem mais de um passo- Muitos parâmetros o...
- Duplicação- Inconsistência- Intenção obscura- Variáveis e funções inexpressivas- Despadronização- Números mágicos- Desen...
ConclusãoClean code não foi escrito para ser uma lista de regrasVocê não se torna um bom programador aprendendouma lista d...
“Você é responsável pelo código que escreve”
Referências
Muito Obrigado! @andrefaria                            @bruno_luihttp://blog.andrefaria.com              http://brunolui.c...
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Clean Code - Desenvolvendo como um Profissional Ágil
Upcoming SlideShare
Loading in...5
×

Clean Code - Desenvolvendo como um Profissional Ágil

5,248
-1

Published on

Apresentação realizada com o @andrefaria no Agile Brazil 2012.

Nos livros Clean Code e Clean CodeR, Robert Martin descreveu o que significa ser um desenvolvedor de software profissional, como ele deve se comportar, e como deve escrever código. Nessa palestra gostaríamos de apresentar um pouco sobre o que temos aprendido utilizando as técnicas de Clean Code e como você pode, a partir delas, tornar sua equipe mais ágil, melhorar a qualidade e produtividade e tornar sua aplicação flexível para obter respostas rápidas às solicitações do mercado.

Published in: Technology
3 Comments
21 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,248
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
181
Comments
3
Likes
21
Embeds 0
No embeds

No notes for slide

Clean Code - Desenvolvendo como um Profissional Ágil

  1. 1. Clean Code ’Desenvolvendo como um Profissional Agil André Faria Bruno Lui @andrefaria @bruno_lui
  2. 2. André Faria GomesCIO na Bluesoft+10 de Anos de Desenvolvimento de SoftwareBlack Belt Lean 6 SigmaInstrutor da Adaptworks @andrefaria http://blog.andrefaria.com http://blog.bluesoft.com.br
  3. 3. Bruno Lui Desenvolvedor na Bluesoft+5 Anos no Desenvolvimento de Software @brunolui http://brunolui.com
  4. 4. Então você quer serum desenvolvedor de software profissional?
  5. 5. Quer que as mãesapontem para você edigam a seus filhospara que sejam como você?
  6. 6. Cuidado com oque você Pede!
  7. 7. Profissionalismo ésem dúvida digno de honra e orgulho, mas também é responsabilidade.
  8. 8. Você não pode se orgulhar de algo pelo qual não se responsabiliza...
  9. 9. É muito mais fácil ser umlargado... Não se responsabilizar pelo trabalho e pela carreira....
  10. 10. Quando umnão-profissional faz uma besteira, seuempregador limpa a bagunça...
  11. 11. Quando um profissional faz uma besteira, ele limpa a bagunça!
  12. 12. O que você faz para escrever software sem defeitos?
  13. 13. Você se responsabiliza pelos defeitos que cria?
  14. 14. Escrever testes é essencial paragarantir que seu software funciona...
  15. 15. Como você pode dizerque é responsável se não os escreve?
  16. 16. “Toda a linha de código que você escreve deve estar testada, e Ponto Final!” Uncle Bob
  17. 17. Código escrito porprofissionais pode seralterado sem custos exorbitantes!
  18. 18. Em outras palavras, você também é responsável pelaestrutura do código que escreve!
  19. 19. Sua carreira é sua responsabilidade! Leia Treine Vá a conferênciasNão é responsabilidade do seu empregador
  20. 20. Sua empresa te ajuda com isso? Ótimo! Estão tefazendo um favor.
  21. 21. Mas aresponsabilidade ainda é sua!
  22. 22. Também não é responsabilidade do seuempregador te dar “tempo” para você estudar...
  23. 23. “Você recebe por 40horas para resolveros problemas da sua empresa não os seus...” Uncle Bob
  24. 24. Faça as contas....
  25. 25. Sua semana tem 168 horas.
  26. 26. Dê à seuempregador40, e à suacarreira 20
  27. 27. Sobram 108
  28. 28. + 56 para dormir 48
  29. 29. + 52 para ... 60
  30. 30. Só não desperdice...
  31. 31. Durante essas 20 horas você deveestar fazendo algo que gosta, queaumente ainda maisa sua paixão pelo que faz.
  32. 32. Esse é o grande segredo!
  33. 33. Além disso, o desenvolvedorprofissional de verdade se preocupa com o código que escreve...
  34. 34. ...desenvolve somente códigolimpo e não consegue mais escrever código ruim.
  35. 35. Ninguém gosta de encontrar um código ruim !
  36. 36. Raiva
  37. 37. Perda de Tempo
  38. 38. Frustração
  39. 39. Dor
  40. 40. Você fica P...
  41. 41. Mas afinal, o que é umcódigo limpo?
  42. 42. O que é um código limpo ?SimplesDiretoEficienteSem duplicidadeEleganteFeito com cuidado
  43. 43. N om es nific ati voss igEscolhemos nomespara tudo, entãodevemos fazerisso bem feito
  44. 44. O nome deve dizer...- Por que existe;- O que faz;- Como é usado;
  45. 45. Use nomes que revelem sua intenção
  46. 46. int d; // daysSe um nome de classe ou método requer umcomentário, ele não está revelando sua intenção
  47. 47. Faça distinções significativasa1? a2?int d?
  48. 48. for (int j=0; j < 34; j++) { s += (t[j]*4)/5;}Nomes com apenas uma letra ou numéricos são difíceis de serem encontrados e entendidos dentro do código.
  49. 49. Use nome s fáceis deencontrar
  50. 50. Use nome spronunciáv eis
  51. 51. private Timestamp genDMYHS() Pronuncie seu códigoprivate Timestamp generateTimestamp()
  52. 52. e pa lavrasEvit não são que palavras
  53. 53. Não economize palavras“Use várias palavras para que o método ou variávelsejam facilmente entendidos e possam transmitir seu propósito”
  54. 54. Evite palavras que podemser variáveis ou palavras reservadas em outras plataformas Evite desinformação
  55. 55. Evite dar nomes como“listaDeLancamentos”, o tiponão precisa estar no nome (notação húngara) Evite desinformação
  56. 56. Evite trocadilhos, escrevaexatamente o que você quer dizer Evite desinformação
  57. 57. prát icas B oasNomes de classes devem sersubstantivos e não devem conter verbosNomes de métodos devem conter verbos
  58. 58. Class es odos M ét
  59. 59. Devem ser pequenos “A primeira regra dos métodos é que eles devem ser pequenos. Asegunda regra é que eles devem ser menores ainda.” Uncle Bob Classes menores são mais fáceis de ler e entender o que estão fazendo.
  60. 60. método <= 20 linhas linha <= 100 caracteresclasse = 200 a 500 linhas
  61. 61. e éto dos “M s d evem fun çõe uma apenasfaz er certa faz ê-la cois a, azê -la.” ent e f e s om
  62. 62. efin ir o é dO difícil uma ape nas é “ que co isa”
  63. 63. Tentar extrair um novo método deum outro, e dar um nome ao trechoextraído é uma maneira de identificar
  64. 64. ParâmetrosMétodos com muitos parâmetros devem serevitados e possuírem uma boa justificativa paraexistirem.Pois confundem e complicam o entendimento,além de dificultar os testes.
  65. 65. Cuidado com os efeitos colaterais.Eles são mentiras contadas pelo método,quando diz que fará uma coisa, mas faz outras “escondidas”.
  66. 66. public boolean checkPassword (String password) { String passwordStatus = crypto.decrypt(password); if (passwordStatus.equals(“OK”)) { Session.initialize(); return true; } return false; }
  67. 67. CQS - Command Query SeparationMétodos devem fazer algo ou retornar algo, mas nãoas duas coisas. Isso gera confusão, além de atribuirmais de uma responsabilidade.
  68. 68. DRY - Don’t Repeat YourselfPreste atenção no código repetido. Evite duplicidadesreaproveitando seus métodos.
  69. 69. Para saber se otamanho da classe é o ideal, devemos analisar suas responsabilidades.
  70. 70. Princípio da única da responsabilidade (SRP)O princípio diz que umaclasse deve ter uma, eapenas uma razão para mudar.
  71. 71. Tentar identificar responsabilidades ajuda a melhorarnosso código e criarmelhores abstrações Esse é um dos conceitos maisimportantes em OO
  72. 72. Coesão Classes devem conter poucas variáveis. Cada método deve manipular uma ou mais variáveis. Quanto mais variáveis ummétodo manipula, mais coeso ele é para a classe. Quando há coesão, significa que métodos e variáveis são co-dependentes.
  73. 73. Comentários
  74. 74. Comentários pode m ser mentirosos e trazer desinformação,mesmo sem inte nção;
  75. 75. Ele não recebem“man utenção”, sendo que quanto maisvelhos maior a chance de e starem errados.
  76. 76. Come ntários não vão esconder o código ruim Geralmente você comenta para que se faça entender. Quando pensar em comentar, é sinal que seu código deve ser refatorado.
  77. 77. // check if the employee is eligible for benefitsif ((employee.flags == 100) && (employee.age > 65)) Explique-se no código! if (employee.isEligibleForBenefits())
  78. 78. Closing brace commentstry { String nada; while (i = 3) { i++; ... } // end while} // end if
  79. 79. utras ça v ocê olhar para o“Qualquer c omentário que fa que lo, não vale os bitspartes do cód igo para entendê-consome”. Uncle Bob
  80. 80. Comentários podem ser úteis... Aviso de consequências que um trecho de código pode vir a causar
  81. 81. Com entários podem ser úteis... Mostrar a intenção por trás de uma decisão tomada, e não só pela informação.
  82. 82. Nunca deixecódigo comentado! Quando alguém vê um código decomentado, não tem coragem umapagá-lo. Vão pensar que há motivo para estar ali.
  83. 83. mataçãoFo r
  84. 84. “Formatação é importante, pois se trata de Comunicação.” Boa Comunicação é essencial para os desenvolvedores profissionais
  85. 85. A legibilidade do seu código teráprofundo efeito em todas as mudanças que serão feitas eseu estilo e disciplina sobrevivemesmo se o código original for alterado
  86. 86. Métodos com conceitos relacionados devem ficar verticalmente próximos
  87. 87. A ordem dos métodos cria um fluxo deleitura melhorando a legibilidade do código
  88. 88. Uma boa identação do código ajuda a visualizar todo o escopo, torna mais fácil e rápida a identificação de situações e regras relevantes.
  89. 89. Essa identação não deve ser maior do que 2, para compreensão fácil e rápida if (a > 0) { if (b > 1) { if (c > 2) { if (d > 3) { if (e > 4) {
  90. 90. Espaçamento public getSum(int one,int two,double number){ double sum=number+(one*two); }Dê espaços entre operadores, parâmetros e vírgulas. public getSum (int one, int two, double number) { double sum = number + (one * two); }
  91. 91. tam entoT ra de erros
  92. 92. Tratar erros é responsabilidade dodesenvolvedor, as coisas podem dar errado enós temos que garantir que nosso código tem um tratamento para cada situação
  93. 93. Use exceptio ns ao invés de retornar c ódigos de erro Quem faz a chamada deve verificar se há erros no retorno do método, e isso pode ser facilmente esquecido.
  94. 94. Forneça o contexto na exception Crie mensagens informativas para os erros, mencione o que aconteceu, o que estava tentando fazer, e por que o erro ocorreu.
  95. 95. Separe as regras de negócio de erros ou outras situações.try { MealExpenses expenses = expensesDao.getMeals(); total += expenses.getTotal();} catch (MealExceptionNotFound e) { total += expenses.getMealPerDiem();}
  96. 96. Não retorne null Prefira retornar Special case objects ou vazio no caso de coleções
  97. 97. Não passe null Evite passar null para seus métodos, isso pode gerar as famosas NullPointerExceptions
  98. 98. Testesunitários
  99. 99. As Três Leis do TDD
  100. 100. As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.
  101. 101. As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.2 - Você não pode escrever maistestes do que seja suficiente parafalhar.
  102. 102. As Três Leis do TDD1 - Você não pode escrever o códigoaté que tenha criado um testefalhando.2 - Você não pode escrever maistestes do que seja suficiente parafalhar.3 - Você não pode escrever maiscódigo do que o suficiente parapassar o teste que esta falhando.
  103. 103. 1 conceito por testeSepare um teste que esteja testando mais de umconceito em outros testes.Facilite o entendimento de cada teste.
  104. 104. Te stesF.I.R .S.T
  105. 105. Fast Os testes devem ser rápidos para executar, pois quando são lentos a frequência de execução diminui.
  106. 106. Testes não podem depender uns dos outros, pois se um falha os outros também falharamIndependent
  107. 107. R epeatable Ao executa-los mais de uma vez, devem sempre retornar o mesmo resultado
  108. 108. Self-Validating Devem possuir respostas booleanas, sem precisar de interpretação para saber o resultado.
  109. 109. T imely Os testes devem ser escritos antes do código. Após o código será mais difícil fazer o teste.
  110. 110. O código do teste é tão importante quanto o código da produçãoO teste precisa sofrer alterações da mesma forma que o código.
  111. 111. Quanto mais sujo o teste mais difícil darmanutenção, e menor aflexibilidade para alterá-lo.
  112. 112. “Se você deixar seus testesapodrecerem, seu código também apodrecerá”
  113. 113. Fique atentoaos Maus cheiros
  114. 114. - Comentários pobres, obsoletos e redundantes- Código comentado- Testes que requerem mais de um passo- Muitos parâmetros ou parâmetros boolean- Métodos mortos ou que fazem muita coisa- Responsabilidades fora do contexto- Nomes pequenos e inexpressivos
  115. 115. - Duplicação- Inconsistência- Intenção obscura- Variáveis e funções inexpressivas- Despadronização- Números mágicos- Desencapsulamento- Efeitos colaterais- Testes inuficientes
  116. 116. ConclusãoClean code não foi escrito para ser uma lista de regrasVocê não se torna um bom programador aprendendouma lista de regras.As técnicas e práticas têm que começar a fazer partedo nosso dia a dia.Devemos nos preocupar com a qualidade do código enão somente fazê-lo funcionar.
  117. 117. “Você é responsável pelo código que escreve”
  118. 118. Referências
  119. 119. Muito Obrigado! @andrefaria @bruno_luihttp://blog.andrefaria.com http://brunolui.com http://blog.bluesoft.com.br
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×