Académique Documents
Professionnel Documents
Culture Documents
Orientador
Prof. Dr. Djalma Domingos da Silva
So Jos do Rio Preto
2013
SUMRIO
CAPTULO 1. INTRODUO.............................................................................................1
1.1 Apresentao do Tema.................................................................................................1
1.2 Justificativa...................................................................................................................2
1.3 Problema.......................................................................................................................2
1.4 Objetivos......................................................................................................................3
CAPTULO 2. FUNDAMENTAO TERICA.................................................................4
2.1 O custo de um cdigo-fonte ruim.................................................................................4
2.2 Definio de Cdigo Limpo.........................................................................................4
2.3 Nomes significativos....................................................................................................5
CAPTULO 3. METODOLOGIA..........................................................................................7
3.1 Tipo do trabalho...........................................................................................................7
3.2 Coleta de dados............................................................................................................7
3.3 Desenvolvimento..........................................................................................................7
3.4 Cronograma..................................................................................................................7
REFERNCIAS..........................................................................................................................9
LISTA DE ABREVIATURAS
IDE
Ambiente Integrado de Desenvolvimento
SRP
Princpio da Responsabilidade nica
SOLID
Princpio da Responsabilidade nica, Princpio Aberto-Fechado, Princpio da
Substituio de Liskov, Principio da Segregao de Interface, Principio da Inverso de
Dependncia
CAPTULO 1. INTRODUO
O desenvolvimento de sistemas uma rea em que a tecnologia est em constante e
acelerada mudana, fato que dificulta o profissional especializado a manter-se atualizado. A
busca pelo aprendizado importante, e deve ser continuo para, assim, assegurar a vaga no
mercado de trabalho. Diante disso, desenvolvedores se veem na obrigao de estarem
aprendendo algo novo diariamente, seja por uma notcia de uma nova tecnologia, ou por
vontade de aprender mais. Sem dvida h sempre novas habilidades para adquirir, treinar e
dominar. O Cdigo Limpo uma delas.
Dos anos noventa para c, observa-se diversas mudanas no dia-a-dia de
desenvolvimento de sistemas. Poderosos Ambientes de Desenvolvimento Integrado (IDE)
surgiram, controles de verses de arquivos foram criados, novos padres de projetos
nasceram, processos de desenvolvimento e paradigmas de programao amadureceram,
grande parte para facilitar e melhorar o ciclo de vida de sistemas.
Entretanto uma tarefa parece no ter mudado muito: a manuteno do cdigo-fonte.
Diferentemente do senso comum, programas so lidos mais frequentemente do que eles so
escritos (Beck, 2007). Constantemente lemos cdigo antigo como parte do esforo para criar
um novo. Isso se deve, principalmente, ao atraso que o cdigo ruim proporciona (Martin,
2008).
Se certas tcnicas de Cdigo Limpo fossem aplicadas na concepo do cdigo, esse
cenrio poderia ser diferente. Desenvolvedores no ficariam to frustrados em participar de
projetos que eles no fizeram parte, gerentes ficariam entusiasmados com a velocidade da
equipe e clientes mais satisfeitos com a qualidade dos resultados.
Este estudo espera apresentar a importncia do Cdigo Limpo tanto para os
desenvolvedores quanto para as empresas de software, visto que o cdigo a linguagem na
qual expressamos os requisitos e particularidades do sistema (Martin, 2008). Ele deve
expressar a sua real inteno, deve ser flexvel, deve ser cuidado com responsabilidade
(Martin, 2008).
1.1
Apresentao do Tema
Em um sistema sempre haver cdigo, e diante desse cdigo sempre haver
na forma que foi concebido. Um cdigo bem escrito pode facilitar a sua manuteno,
aumentar a produtividade dos desenvolvedores que o encontram, diminuir o tempo
despendido para adicionar uma nova funcionalidade ou substituir uma regra antiga, e
consequentemente, diminuir os recursos financeiros necessrios a realizao dessas tarefas.
Um bom profissional deve conhecer e aplicar constantemente as tcnicas do Cdigo
Limpo; estas sero apresentadas no decorrer deste trabalho. Escrever Cdigo Limpo muito
importante e poucos desenvolvedores parecem conhec-lo; este trabalho vai propor uma
mudana nesse paradigma, mostrando o que um Cdigo Limpo e sua importncia.
1.2
Justificativa
Do ponto de vista do desenvolvedor, conhecer as tcnicas do Cdigo Limpo trar
1.3
Problema
De acordo com os clculos de BIRD (2011), em um novo projeto estima-se que ao
final do desenvolvimento com 50.000 linhas de cdigo existam 750 bugs. Esse nmero
aumenta na manuteno: avalia-se que em 50.000 linhas de cdigo encontrem-se 1.080 bugs.
O tempo de familiarizao com um sistema j desenvolvido muito alto.
Desenvolvedores que no participaram do projeto possuem grande dificuldade em entender o
cdigo, qual o problema ele tenta solucionar. Perdem muito tempo navegando pelo cdigo,
depurando-o a fim de encontrar alguma dica, um vislumbre, que lhes permita entender a total
baguna em que se encontram.
1.4
Objetivos
O objetivo desse estudo apresentar as tcnicas e boas prticas para se escrever um
Cdigo Limpo. Desejamos tambm mostrar, por meio de um experimento e anlise estatstica,
a vantagem de se escrever um Cdigo Limpo, em termos de tempo de manuteno e mtricas
de cdigo-fonte, como quantidade de linhas de cdigo.
aps a primeira vez que ele implantado [...], portanto, se eu quero fazer meu cdigo barato,
eu deveria torna-lo fcil de ler. Em outro trecho e pela mesma premissa, Beck (2007, p. 12)
prope que o programa deveria ser fcil de modificar tambm. Simples afirmaes como
essas nos remete argumentao de que possuir um cdigo compreensvel e de fcil
manuteno pode diminuir os dispndios financeiros futuros.
Alm disso, Martin (2008, p. 4) argumenta que, diante de um cdigo confuso, a
produtividade de uma equipe ca drasticamente com o passar do tempo, aproximando-se de
zero. Com a reduo da produtividade, a gerncia adiciona mais membros na esperana de
aumentar a eficincia da equipe, at que o cdigo-fonte torne-se abominvel e um
replanejamento seja exigido. Ainda segundo Martin, esse grande replanejamento pode levar
anos; os mesmos erros so cometidos, e depois de pronto, a baguna a mesma e a nova
equipe demanda outro replanejamento.
Mas ser que um cdigo-fonte ruim influencia tanto assim o financeiro de uma
empresa? De acordo com Martin (2008, p. 3) sim: Foi o cdigo ruim que acabou com a
empresa, em referncia a um fato dos anos oitenta, em que uma empresa lanou um
aplicativo extraordinrio que se tornou muito popular. Depois de vrios bugs no consertados
nas novas verses, a empresa saiu do mercado. O motivo de tantos erros foi que o cdigo
estava um caos devido ao lanamento precipitado, e medida que novos recursos eram
adicionados o cdigo piorava at que no era possvel mais gerenci-lo.
Diante do supracitado, um cdigo ruim no pode ser negligenciado, visto que ele
diminui a produtividade dos desenvolvedores, afetando a empresa financeiramente, podendo
culminar em sua falncia.
2.2
2.3
Nomes significativos
A maioria dos desenvolvedores carece de expressar a real inteno ao nomear uma
varivel, mtodo ou classe, simplesmente porque escolher bons nomes requer boas
habilidades de descrio (Martin, 2008, p. 30). Normalmente, o foco deles est em resolver o
problema usando toda a expertise em lgica de programao e no em nomear
adequadamente, e isso um problema.
Nomear a fim de mostrar a real inteno uma tarefa rdua, por isso, necessrio
disciplina e ser destemido ao renomear as coisas. No por acaso que Fowler (2002, p. 22)
diz que se o intuito melhorar a clareza, renomear vale a pena. No ter medo tambm a
chave, pois difcil acertar o nome na primeira vez, porm, as IDEs atuais facilitam muito
essa tarefa.
Fowler (2002, p. 22) ainda afirma que um cdigo que comunica o seu propsito
muito importante. Evans (2004) compartilha o mesmo pensamento reconhecendo que um
cdigo bem escrito pode ser bastante comunicativo. Mas como conseguir uma boa
comunicao atravs do cdigo? Martin (2008) sugere usar nomes pronunciveis que revelem
a sua real inteno, no usar prefixos ou notao hngara1, evitar desinformao2, adicionar
contexto significativo e usar nomes do domnio do problema.
2.4
injeo de desnimo para os desenvolvedores. Em cdigos como esse, o tempo gasto para
entender e achar o ponto que precisa ser modificado uma tarefa rdua e enfadonha. Outra
caracterstica de cdigos assim a duplicao e repetio de lgicas semelhantes ou at
mesmo idnticas.
Para evitar esses tipos de cdigos devemos seguir algumas regras. Martin (2008, p.
34) assegura que a primeira regra para se escrever mtodos que eles devem ser pequenos; e
a segunda regra que eles devem ser menores que isso. Outro ponto apontado por Martin
(2008) que mtodos devem fazer uma coisa, e faz-la bem.
Fowler (2002, p. 18) afirma que pedaos menores de cdigo tendem a fazerem as
coisas mais manejveis. Eles so fceis de trabalhar. Beck (2007, p. 78) segue o mesmo
raciocnio ao relatar que um cdigo melhor lido quando quebrado em mtodos relativamente
pequenos.
A fim de obtermos classes com alta coeso e mtodos enxutos importante
conhecermos
tambm
os
princpios
S.O.L.I.D.3,
especialmente
Princpio
da
Responsabilidade nica (SRP), que declara que uma classe ou mdulo deve ter uma, e apenas
uma razo para mudar. Segundo Martin (2008, p. 139) o SRP um dos mais importantes
conceitos em orientao a objetos, um dos mais simples de entender, e apesar disso, parece ser
um dos menos seguidos.
2.5
Referncia nula
Hoare (2009) relatou em uma conferncia em Londres o que ele chama de um dos erros mais
caros de sua carreira: Eu chamo de meu erro de bilhes de dlares. Foi a inveno da
referncia nula em 1965.
Quantos bugs no foram introduzidos por causa de uma referncia nula? At hoje, com
todos os avanados compiladores e poderosas IDEs, os erros NullPointerException (Java) e
NullReferenceException (C#) so ainda muito comuns.
Mas por que isso acontece? Normalmente porque o desenvolvedor ou passou nulo para
um mtodo ou retornou nulo, e no fez a devida checagem. Erros assim so comuns, mas
podem ser evitados se o padro Objeto Nulo for seguido. Martin (2006, p. 440) e Fowler
(2002, p. 209) preferem o uso desse padro ao invs de retornar ou passar referncias nulas.
Eles relatam que utilizando esse padro ns podemos assegurar que os mtodos sempre
retornaro objetos vlidos, mesmo quando eles falharem, evitando a necessidade de comparar
por nulo.
2.6
Testes unitrios
Por que escrever testes importante? Fowler (2002, p. 73) responde essa pergunta
relatando como o desenvolvedor gasta seu tempo. Segundo Fowler, escrever cdigo uma
pequena frao do tempo gasto. Na verdade, o desenvolvedor perde seu tempo tentando
3 Acrnimo para Single Responsability Principle, Open-closed Principle, Liskov Substitution
Principle, Interface Segregation Principle e Dependency Inversion Principle.
descobrir o que est acontecendo com aquele cdigo, depurando para encontrar exatamente
onde o erro est ocorrendo. Consertar o bug na maioria das vezes simples, entretanto,
descobrir onde ele est um pesadelo. Por isso, a introduo de testes unitrios importante,
pois auxilia muito na deteco de erros antes de eles acontecerem em produo, alm de
evitar o dispndio com horas de depurao de programas.
Outro benefcio advindo com os testes segundo Martin (2006, p. 71) que eles servem
como uma forma de documentao, isto , basta olhar para o teste escrito para saber como
uma funcionalidade foi implementada. Alm disso, talvez o benefcio mais importante que os
testes proveem o impacto na arquitetura e design da aplicao, pois para escrever um cdigo
testvel requer que ele seja desacoplado e que no dependa de implementaes concretas e
sim de abstraes.
Todavia, no basta escrever testes a esmo. Eles devem ter um propsito e, acima de
tudo, devem ser limpos. Martin (2009, p. 124) diz que cdigo de teste to importante quanto
cdigo de produo e por isso devem ser to limpos quanto. Testes limpos so aqueles que
prezam pela legibilidade, simplicidade e clareza, por isso interessante escrever testes que
expressem em poucas linhas a complexidade do sistema que esto testando.
CAPTULO 3. METODOLOGIA
Este captulo aponta os mtodos adotados e materiais usados na execuo do
trabalho. H tambm um cronograma das atividades e os recursos utilizados.
3.1
Tipo do trabalho
Este trabalho ter carter exploratrio aplicado.
3.2
Coleta de dados
A amostra deste trabalho sero desenvolvedores na linguagem C# empregados em
So Jos do Rio Preto, SP, com no mnimo um ano de experincia no mercado de trabalho.
Os dados sero coletados de fontes primrias, aplicando algumas mtricas nos
cdigos elaborados pelos desenvolvedores.
3.3
Desenvolvimento
As tcnicas do Cdigo Limpo sero utilizadas para resolver um problema proposto.
O mesmo problema ser resolvido sem as tcnicas por outra pessoa. Cinco pessoas iro dar
manuteno no Cdigo Limpo para resolver outro problema proposto e outras cinco pessoas
faro a mesma coisa no cdigo sem as tcnicas.
A ferramenta usada ser o Visual Studio 2012, a linguagem de programao C#,
usando o paradigma de orientao a objetos. Os cdigos sero subidos no site
http://github.com/JobaDiniz/TCC, que utiliza o GIT como controle de verso.
Dados como tempo gasto, nmero de linhas de cdigo, complexidade ciclomtica,
ndice de manutenibilidade e acoplamento de classes sero extrados com o auxlio do Visual
Studio 2012.
Os dados passaram por uma anlise estatstica usando o Teste de Hiptese T, que
baseia-se nas mdias dos dados.
3.4
Cronograma
Atividades
Definio do tema
Levantamento
contedo terico
Anteprojeto
Jan
Fev
Mar
Abr
Mai
Jun
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
X
X X
X X X
REFERNCIAS
BECK, Kent. Implementation Patterns. Westford, Ma: Addison Wesley, 2007.
BIRD, Jim. Bugs and Numbers: How many bugs do you have in your code? Calgary,
Canada, 24 ago. 2011. Disponvel em: <http://swreflections.blogspot.com.br/2011/08/bugsand-numbers-how-many-bugs-do-you.html>. Acesso em: 18 mar. 2013.
EVANS, Eric. Domain Driven Design: Tackling Complexity in Software. Westford, Ma:
Addison Wesley, 2004.
FOWLER, Martin; BECK, Kent; BRANT, Jonh; OPDYKE, William; ROBERTS, Don.
Refactoring: Improving the Design of Existing Code. Westford, Ma: Addison Wesley, 2002.
HOARE, Charles A. R. Null References: The Billion Dollar Mistake. Londres, Inglaterra.
2009. Disponvel em: <http://qconlondon.com/london-2009/presentation/Null+References:
+The+Billion+Dollar+Mistake>. Acesso em: 28 abr. 2013.
MARTIN, Robert C.; MARTIN, Micah. Agile Principles, Patterns, and Practices in C#.
Westford, Ma: Prentice Hall, 2006.
MARTIN, Robert C.. Clean Code: A Handbook of Agile Software Craftsmanship. Westford,
Ma: Prentice Hall, 2009.