{"id":141,"date":"2011-07-07T20:13:48","date_gmt":"2011-07-07T20:13:48","guid":{"rendered":"http:\/\/leonardocotta.com.br\/blog\/?p=141"},"modified":"2011-07-07T20:13:48","modified_gmt":"2011-07-07T20:13:48","slug":"codigo-limpo","status":"publish","type":"post","link":"https:\/\/leonardocotta.com.br\/?p=141","title":{"rendered":"C\u00f3digo Limpo"},"content":{"rendered":"

C\u00f3digo Limpo
\nPublicado em 07\/07\/2011 por vonjuliano<\/a><\/p>\n

<\/p>\n

Estive presente no Agile Brazil 2011, e dentre as v\u00e1rias palestras que assisti, uma que me fez pensar bastante foi a do Vinicius Teles, intitulada \u201cO dia em que a Terra acabou parou, porque o software travou\u201d . De forma bastante resumida, Vinicius disse que v\u00e1rios dos problemas que encaramos diariamente \u00e9 culpa nossa, dos desenvolvedores, e ele tem raz\u00e3o. Vide os problemas (seja lentid\u00e3o ou dificuldade de utiliza\u00e7\u00e3o) dos sistemas dos correios, aeroportos ou bancos, os quais geram filas quilom\u00e9tricas que todos temos que enfrentar. Ou seja, todos pagam pelos bugs dos sistemas que n\u00f3s criamos!<\/p>\n

Ele sugeriu um novo manifesto, o Manifesto Vergonha Na Cara, que estabelece que C\u00f3digo de verdade \u00e9 c\u00f3digo testado e limpo! Como tamb\u00e9m estou cansado de enfrentar c\u00f3digo de p\u00e9ssima qualidade, resolvi fazer uma pequena contribui\u00e7\u00e3o; durante a palestra, foi sugerido como um dos primeiros passos a leitura do livro Clean Code do Uncle Bob, e como muita gente ainda n\u00e3o leu esse livro, criei um pequeno resumo, o qual, espero, desperte o interesse pelo mesmo, levando os leitores \u00e0 produzir c\u00f3digo limpo, j\u00e1 que, como foi muito falado durante o evento, programador profissional \u00e9 aquele que produz c\u00f3digo limpo e testado!<\/p>\n

O resumo que fiz aqui \u00e9 referente a apenas alguns t\u00f3picos do livro, os quais acho que devem ser os primeiros passos para um c\u00f3digo melhor.
\nNomes significativos<\/p>\n

Nomes de classes, vari\u00e1veis, m\u00e9todos, etc, devem ser significativos, indicando claramente o que um m\u00e9todo faz ou o que um atributo representa. A inten\u00e7\u00e3o deve ser vis\u00edvel atrav\u00e9s dos nomes. Crie nomes pronunci\u00e1veis para facilitar a comunica\u00e7\u00e3o, evite acr\u00f4nimos e siglas.<\/p>\n

Evite nomes confusos, os quais podem levar quem l\u00ea o c\u00f3digo a conclus\u00f5es erradas.<\/p>\n

Use nomes que refletem o dom\u00ednio do sistema, o contexto e os problemas que devem ser resolvidos.
\nFun\u00e7\u00f5es<\/p>\n

Fun\u00e7\u00f5es devem ser pequenas. Ali\u00e1s, elas devem ser ainda menores. Deve haver apenas um n\u00edvel de abstra\u00e7\u00e3o por fun\u00e7\u00e3o.<\/p>\n

Fun\u00e7\u00f5es devem fazer uma coisa, e apenas uma. Novamente, utilize um nome que descreva bem o que a fun\u00e7\u00e3o faz. Utilize o menor n\u00famero de argumentos poss\u00edvel, fazendo o m\u00e1ximo para que n\u00e3o passem de tr\u00eas.<\/p>\n

Cuidado com \u201cefeitos colaterais\u201d, fun\u00e7\u00f5es n\u00e3o podem fazer nada \u201cescondido\u201d. Use exce\u00e7\u00f5es ao inv\u00e9s de c\u00f3digos de erro, e considere que tratar exce\u00e7\u00f5es \u00e9 uma coisa.
\nComent\u00e1rios<\/p>\n

Coment\u00e1rios n\u00e3o salvam um c\u00f3digo ruim. Procure explicar o que o c\u00f3digo faz COM C\u00d3DIGO.<\/p>\n

Crie nomes de m\u00e9todos e de vari\u00e1veis informativos, ao inv\u00e9s de explicar com um coment\u00e1rio o que um m\u00e9todo com um nome ruim faz. Use coment\u00e1rios para deixar uma express\u00e3o complexa mais clara, para avisar sobre as poss\u00edveis conseq\u00fc\u00eancias de uma altera\u00e7\u00e3o, ou para ressaltar a import\u00e2ncia de certo ponto do c\u00f3digo.<\/p>\n

Coment\u00e1rios ruins tamb\u00e9m poluem o c\u00f3digo. N\u00e3o escreva coment\u00e1rios redundantes, in\u00fateis, ou pior, com falsas informa\u00e7\u00f5es. Tamb\u00e9m n\u00e3o deve ser usado para indicar quando ou por quem foi alterado, para isso temos ferramentas de controle de vers\u00e3o. N\u00e3o escreva coment\u00e1rios confusos ou grandes demais.<\/p>\n

N\u00e3o comente c\u00f3digo que n\u00e3o ser\u00e1 mais usado, simplesmente remova-o.
\nObjetos e estruturas de dados<\/p>\n

Siga a Lei de Demeter. Fa\u00e7a boa abstra\u00e7\u00e3o e encapsulamento. N\u00e3o crie objetos burros.
\nTratamento de erro<\/p>\n

Use exce\u00e7\u00f5es ao inv\u00e9s de c\u00f3digos de erro. Use exce\u00e7\u00f5es n\u00e3o checadas, e utilize mensagens de erro informativas.<\/p>\n

N\u00e3o retorne e nem passe null.
\nTestes<\/p>\n

Siga as 3 leis do TDD.<\/p>\n

Use uma assertiva por teste, e teste um conceito por vez.<\/p>\n

Os testes devem ser r\u00e1pidos, independentes, reprodut\u00edveis em qualquer ambiente, auto-valid\u00e1veis e escritos no momento certo. Mantenha o c\u00f3digo de seus testes limpo.
\nClasses<\/p>\n

Classes devem ser pequenas e seguir o princ\u00edpio da responsabilidade \u00fanica. Devem ser coesas, essa coes\u00e3o resulta em classes pequenas. Classes devem ser criadas visando a mudan\u00e7a, ent\u00e3o programe orientado \u00e0 interface.<\/p>\n

Outros pontos que n\u00e3o posso deixar de citar s\u00e3o: Todos os testes devem estar passando; refatora\u00e7\u00e3o deve ser feita constantemente, visando \u00e0 melhoria cont\u00ednua; c\u00f3digo duplicado deve ser evitado a todo custo; classes e m\u00e9todos devem ser pequenos; o c\u00f3digo deve ser o mais expressivo poss\u00edvel.<\/p>\n

Esse resumo \u00e9 um levantamento de alguns pontos importantes, tanto que aqui \u00e9 mostrado o que deve ser feito, n\u00e3o o porqu\u00ea ou o como, isso pode visto encontrado no livro. Esse post \u00e9 o primeiro passo, espero que todos d\u00eaem continuidade lendo esse livro e muitos outros, buscando criar um c\u00f3digo melhor. Eu n\u00e3o quero mais c\u00f3digo sujo atrapalhando a minha vida. E voc\u00ea?<\/p>\n","protected":false},"excerpt":{"rendered":"

C\u00f3digo Limpo Publicado em 07\/07\/2011 por vonjuliano<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[20],"tags":[263],"class_list":["post-141","post","type-post","status-publish","format-standard","hentry","category-programacao","tag-trabalhando-com-spring-mvc-3-de-forma-simples"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=\/wp\/v2\/posts\/141","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=141"}],"version-history":[{"count":0,"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=\/wp\/v2\/posts\/141\/revisions"}],"wp:attachment":[{"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leonardocotta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}