FACULDADE DE TECNOLOGIA DE

SO JOS DO RIO PRETO

A Importncia do Cdigo Limpo na Perspectiva dos

Desenvolvedores e Empresas de Software

JOBERTO DINIZ JUNIOR

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

manutenes e novos requerimentos. Um cdigo escrito hoje ser, indubitavelmente,

modificado amanh. Demore semanas, meses ou anos, o fato que um cdigo no perdurar

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

uma mudana de paradigma de como escrever cdigo e melhorar profissionalmente. De

acordo com Martin (2008) escrever cdigo limpo o que voc deve fazer a fim de se
intitular um profissional. No h nenhuma desculpa razovel para fazer nada menos que o seu
melhor. Ficar evidente que ler um cdigo limpo melhor do que qualquer outro cdigo j
lido. Espera-se que esse sentimento seja passado adiante, pois o desenvolvedor no ficar
realizado diante de um cdigo mal escrito por ele e nem por mais ningum.
Da perspectiva da empresa, contratar profissionais que conheam as tcnicas
diminuir os bugs e aumentar a qualidade do cdigo produzido. Os benefcios estendem-se
para o financeiro, pois diante de um cdigo melhor estruturado e de fcil absoro, a sua
manuteno ser mais eficiente e rpida. Outro ponto em decorrncia disso sero clientes
mais satisfeitos.

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.

Equipes que trabalharam rapidamente no incio de um projeto podem perceber mais

tarde que esto indo a passos de tartaruga (Martin, 2008, p. 4). Nenhuma mudana trivial,
opta-se por remendos, o que piora cada vez mais o cdigo.
Ser que precisa ser sempre assim? Ser que no existem melhores formas de
escrever um cdigo que facilite o entendimento dos desenvolvedores atuais e futuros?
.

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.

CAPTULO 2. FUNDAMENTAO TERICA

2.1

Cdigo-fonte ruim custa caro

De acordo com Beck (2007, p. 11), a maior parte do custo do software constituda

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

Definio de Cdigo Limpo

Antes de definirmos o que um Cdigo Limpo, vejamos o que necessrio para

escrev-lo segundo Martin (2008, p. 7):

Escrever um cdigo limpo exige o uso disciplinado de uma
mirade de pequenas tcnicas aplicadas por meio de uma
sensibilidade meticulosamente adquirida sobre limpeza. A
sensibilidade ao cdigo o segredo. Alguns de ns j
nascemos com ela. Outros precisam se esforar para adquirila.
Em suma, um desenvolvedor que escreve Cdigo Limpo um artista ou por natureza
ou por obstinao.
Mas afinal, o que um Cdigo Limpo? Podemos assegurar que sua definio no
to simples. Existem variveis subjetivas como a elegncia, agradabilidade e legibilidade.
Escrever Cdigo Limpo uma arte (Martin, 2008), portanto defini-lo segundo parmetros
lgicos e mensurveis complicado. Podemos considerar aspectos tcnicos como
testabilidade, ndice de manutenibilidade e complexidade ciclomtica, entretanto, temos que
ter em mente que os aspectos subjetivos so to importantes quanto.
Martin (2008) entrevistou renomados especialistas em desenvolvimento de software
acerca da definio de Cdigo Limpo. A partir disso, ele infere que ler um Cdigo Limpo
deve fazer voc sorrir, deve ser to bem legvel quanto uma prosa bem escrita e deve ser
cercado por testes. Outra caracterstica notvel a afirmao de Michael Feathers, autor do
livro Trabalhando Efetivamente com Cdigo Legado: um cdigo limpo sempre parece que
foi escrito por algum que se importava. Essa palavra importar tem um significado
incisivo, e nos remete ao profissionalismo, visto que, ao no se importar, o desenvolvedor est
agindo de forma no profissional.

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

Quebrando o cdigo em pedaos pequenos

Abrir um cdigo-fonte e perceber que a barra de rolagem parece no ter fim uma

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.

1 Prefixar ou sufixar ao nome o tipo que aquela varivel representa.

2 Nomear variveis com a letra L minscula ou a letra O maiscula. Ambas desinformam o
leitor pois se assemelham aos nmeros um e zero, respectivamente.

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

Tabela 1 - Cronograma do trabalho.

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.