Clean Code - Desenvolvendo como um Profissional Ágil

Download Clean Code - Desenvolvendo como um Profissional Ágil

Post on 19-Oct-2014

3.645 views

Category:

Technology

1 download

Embed Size (px)

DESCRIPTION

Apresentao 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 cdigo. Nessa palestra gostaramos de apresentar um pouco sobre o que temos aprendido utilizando as tcnicas de Clean Code e como voc pode, a partir delas, tornar sua equipe mais gil, melhorar a qualidade e produtividade e tornar sua aplicao flexvel para obter respostas rpidas s solicitaes do mercado.

TRANSCRIPT

<p>Desenvolvendo como um Profissional Agil</p> <p>Andr Faria@andrefaria @bruno_luiBruno Lui</p> <p>Clean Code</p> <p>Andr Faria Gomes</p> <p>@andrefariahttp://blog.andrefaria.comhttp://blog.bluesoft.com.br</p> <p>Black Belt Lean 6 Sigma</p> <p>+10 de Anos de Desenvolvimento de SoftwareCIO na Bluesoft</p> <p>Instrutor da Adaptworks</p> <p>Bruno Lui</p> <p>@brunoluihttp://brunolui.com</p> <p>+5 Anos no Desenvolvimento de Software</p> <p>Desenvolvedor na Bluesoft</p> <p>Ento voc quer ser um desenvolvedor de </p> <p>software profissional?</p> <p>Quer que as mes apontem para voc e digam a seus filhos para que sejam como </p> <p>voc?</p> <p>Cuidado com o que voc Pede!</p> <p>Profissionalismo sem dvida digno </p> <p>de honra e orgulho, mas tambm </p> <p>responsabilidade.</p> <p>Voc no pode se orgulhar de algo pelo qual no se responsabiliza...</p> <p> muito mais fcil ser um largado... No se responsabilizar pelo trabalho e pela carreira....</p> <p>Quando um no-profissional faz uma besteira, seu empregador limpa a </p> <p>baguna...</p> <p>Quando um profissional faz uma besteira, ele </p> <p>limpa a baguna!</p> <p>O que voc faz para escrever software sem defeitos?</p> <p>Voc se responsabiliza pelos defeitos que cria?</p> <p>Escrever testes essencial para garantir que seu software funciona...</p> <p>Como voc pode dizer que responsvel se </p> <p>no os escreve?</p> <p>Toda a linha de cdigo que voc escreve deve estar testada, e </p> <p>Ponto Final!Uncle Bob</p> <p>Cdigo escrito por profissionais pode ser alterado sem custos </p> <p>exorbitantes!</p> <p>Em outras palavras, voc tambm responsvel pela </p> <p>estrutura do cdigo que escreve!</p> <p>Sua carreira sua responsabilidade!</p> <p>TreineV a confernciasLeia</p> <p>No responsabilidade do seu empregador</p> <p>Sua empresa te ajuda com isso?</p> <p>timo! Esto te fazendo um favor.</p> <p>Mas a responsabilidade ainda sua!</p> <p>Tambm no responsabilidade do seu empregador te dar tempo para voc estudar...</p> <p>Voc recebe por 40 horas para resolver os problemas da sua </p> <p>empresa no os seus...</p> <p>Uncle Bob</p> <p>Faa as contas....</p> <p>Sua semana tem 168 horas.</p> <p>D seu empregador 40, e sua carreira 20</p> <p>Sobram 108</p> <p>+ 56 para dormir 48</p> <p>+ 52 para ...60</p> <p>S no desperdice...</p> <p>Durante essas 20 horas voc deve </p> <p>estar fazendo algo que gosta, que </p> <p>aumente ainda mais a sua paixo pelo </p> <p>que faz. </p> <p>Esse o grande segredo!</p> <p>Alm disso,o desenvolvedor </p> <p>profissional de verdadese preocupa com o cdigo que escreve...</p> <p>...desenvolve somente cdigo limpo e no consegue mais </p> <p>escrever cdigo ruim.</p> <p>Ningum gosta de encontrar um cdigo ruim !</p> <p>Raiva</p> <p>Perda de Tempo</p> <p>Frustrao</p> <p>Dor</p> <p>Voc fica P...</p> <p>Mas afinal, o que um </p> <p>cdigo limpo?</p> <p>O que um cdigo limpo ?SimplesDiretoEficienteSem duplicidadeEleganteFeito com cuidado</p> <p>Escolhemos nomes para tudo, ento devemos fazer isso bem feito</p> <p>Nomes significativos</p> <p>- Por que existe;- O que faz;- Como usado; </p> <p>O nome deve dizer...</p> <p>Use nomes que revelem sua inteno</p> <p> int d; // days</p> <p>Se um nome de classe ou mtodo requer um comentrio, ele no est revelando sua inteno</p> <p>a1?</p> <p>int d?a2?</p> <p>Faa distines significativas</p> <p> for (int j=0; j &lt; 34; j++) {s += (t[j]*4)/5;</p> <p> }</p> <p>Nomes com apenas uma letra ou numricos so difceis de serem encontrados e </p> <p>entendidos dentro do cdigo.</p> <p>Use nomes fceis de encontrar</p> <p>Use nomes pronunciveis</p> <p>Pronuncie seu cdigo</p> <p>private Timestamp genDMYHS()</p> <p>private Timestamp generateTimestamp()</p> <p>Evite palavras </p> <p>que no so </p> <p>palavras</p> <p>No economize palavrasUse vrias palavras para que o mtodo ou varivel sejam facilmente entendidos e possam transmitir seu </p> <p>propsito</p> <p>Evite desinformao</p> <p>Evite palavras que podem ser variveis ou palavras reservadas em outras </p> <p>plataformas</p> <p>Evite desinformao</p> <p>Evite dar nomes como listaDeLancamentos, o tipo no precisa estar no nome </p> <p>(notao hngara)</p> <p>Evite desinformao</p> <p>Evite trocadilhos, escreva exatamente o que voc </p> <p>quer dizer</p> <p>Nomes de classes devem ser substantivos e no devem conter verbos</p> <p>Boas prticas</p> <p>Nomes de mtodos devem conter verbos</p> <p>MtodosClasses</p> <p>Devem ser pequenosA primeira regra dos mtodos que eles devem ser pequenos. A </p> <p>segunda regra que eles devem ser menores ainda.</p> <p>Uncle Bob</p> <p>Classes menores so mais fceis de ler e entender o que esto fazendo.</p> <p>mtodo 0) { if (b &gt; 1) { if (c &gt; 2) { if (d &gt; 3) { if (e &gt; 4) {</p> <p>D espaos entre operadores, parmetros e vrgulas.</p> <p> public getSum(int one,int two,double number){double sum=number+(one*two);</p> <p> } </p> <p>Espaamento</p> <p> public getSum (int one, int two, double number) {double sum = number + (one * two);</p> <p> } </p> <p>Tratamento </p> <p>de erros</p> <p>Tratar erros responsabilidade do desenvolvedor, as coisas podem dar errado e ns temos que garantir que nosso cdigo tem </p> <p>um tratamento para cada situao</p> <p>Quem faz a chamada deve verificar se h erros no retorno do mtodo, e isso pode ser </p> <p>facilmente esquecido.</p> <p>Use exceptions ao invs de </p> <p>retornar cdigos de erro</p> <p>Crie mensagens informativas para os erros, mencione o que aconteceu, o que estava tentando fazer, e por que o erro ocorreu.</p> <p>Fornea o contexto na exception</p> <p> try {MealExpenses expenses = expensesDao.getMeals();total += expenses.getTotal();</p> <p> } catch (MealExceptionNotFound e) {total += expenses.getMealPerDiem();</p> <p> }</p> <p>Separe as regras de negcio de erros ou outras situaes.</p> <p>Prefira retornar Special case objects ou vazio no caso de </p> <p>colees</p> <p>No retorne null</p> <p>No passe null</p> <p>Evite passar null para seus mtodos, isso </p> <p>pode gerar as famosas </p> <p>NullPointerExceptions</p> <p>Testes unitrios</p> <p>As Trs Leis do TDD</p> <p>As Trs Leis do TDD</p> <p>1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.</p> <p>As Trs Leis do TDD</p> <p>1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.</p> <p>2 - Voc no pode escrever mais testes do que seja suficiente para falhar.</p> <p>As Trs Leis do TDD</p> <p>1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.</p> <p>2 - Voc no pode escrever mais testes do que seja suficiente para falhar.3 - Voc no pode escrever mais cdigo do que o suficiente para passar o teste que esta falhando.</p> <p>conceito por teste</p> <p>Separe um teste que esteja testando mais de um </p> <p>conceito em outros testes.</p> <p>Facilite o entendimento de cada teste.</p> <p>1</p> <p>F.I.R.S.TTestes</p> <p>Os testes devem ser rpidos para executar, pois quando so lentos a frequncia de execuo </p> <p>diminui.</p> <p>Fast</p> <p>Testes no podem depender uns dos outros, pois se um falha os outros tambm </p> <p>falharam</p> <p>Independent</p> <p>Ao executa-los mais de uma vez, devem sempre retornar o mesmo resultado</p> <p>Repeatable</p> <p>Devem possuir respostas booleanas, sem precisar de interpretao para saber o </p> <p>resultado.</p> <p>Self-Validating</p> <p>Os testes devem ser escritos antes do cdigo. Aps o cdigo ser mais </p> <p>difcil fazer o teste.</p> <p>Timely</p> <p>O cdigo do teste to importante quanto o cdigo da produo</p> <p>O teste precisa sofrer alteraes da mesma forma que o cdigo.</p> <p>Quanto mais sujo o teste mais difcil dar </p> <p>manuteno, e menor a flexibilidade para alter-lo.</p> <p>Se voc deixar seus testes </p> <p>apodrecerem, seu cdigo tambm apodrecer</p> <p>Fique atento aos Maus cheiros</p> <p>- Comentrios pobres, obsoletos e redundantes</p> <p>- Cdigo comentado</p> <p>- Testes que requerem mais de um passo</p> <p>- Muitos parmetros ou parmetros boolean</p> <p>- Mtodos mortos ou que fazem muita coisa</p> <p>- Responsabilidades fora do contexto</p> <p>- Nomes pequenos e inexpressivos</p> <p>- Duplicao- Inconsistncia- Inteno obscura- Variveis e funes inexpressivas- Despadronizao- Nmeros mgicos- Desencapsulamento- Efeitos colaterais- Testes inuficientes</p> <p>Voc no se torna um bom programador aprendendo uma lista de regras.</p> <p>Clean code no foi escrito para ser uma lista de regras</p> <p>As tcnicas e prticas tm que comear a fazer parte do nosso dia a dia.</p> <p>Devemos nos preocupar com a qualidade do cdigo e no somente faz-lo funcionar.</p> <p>Concluso</p> <p>Voc responsvel pelo cdigo que escreve</p> <p>Referncias</p> <p>Muito Obrigado!</p> <p>@andrefariahttp://blog.andrefaria.com</p> <p>http://blog.bluesoft.com.br</p> <p>@bruno_luihttp://brunolui.com</p>