1. ¸˜
Fatores que Afetam a Qualidade do C´ digo-fonte: a Percepcao
o
dos Desenvolvedores
M´ rcio M. Sklar, Guilherme S. Lacerda, Daniel F. Wildt,
a
Marcelo S. Pimenta, Roberto T. Price, Mara Abel
1
Instituto de Inform´ tica – Universidade Federal do Rio Grande do Sul (UFRGS)
a
Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil
marcios@inf.ufrgs.br, {guilhermeslacerda,dwildt}@gmail.com
mpimenta@inf.ufrgs.br, tomprice@terra.com.br, marabel@inf.ufrgs.br
Abstract. This paper presents conclusions of a survey analysis on developers
perception on factors that affect code development and maintainability quality.
It contains questions about ten potentially harmful problems, as well as ten fac-
tors that would affect positively code produced. We made a statistical study
on answers obtained. We’ve verified developers experience and how the fact
of using or not a framework tool affected their answers. Ultimately, we line-
arly correlated similar answers perception between developers, besides trying
to justify these correlations.
Resumo. Este trabalho apresenta os resultados da an´ lise feita sobre a
a
percepcao de desenvolvedores em relacao a diversos fatores que influenciam a
¸˜ ¸˜
qualidade do c´ digo na construcao e manutencao de software. Para isso, foi dis-
o ¸˜ ¸˜
ponibilizado um question´ rio com uma lista de dez problemas potencialmente
a
prejudiciais, bem como dez fatores que influenciariam positivamente o c´ digo,
o
de forma que os desenvolvedores os graduassem em n´vel de importˆ ncia. Sobre
ı a
as respostas obtidas, realizaram-se alguns estudos estat´sticos. Foram verifica-
ı
das como a experiˆ ncia do desenvolvedor e o uso ou n˜ o de framework influ-
e a
enciaram em suas respostas. Por fim, via correlacao linear, foram detectadas e
¸˜
justificadas duplas de perguntas percebidas de forma semelhante.
¸˜
1. Introducao
´
Para a comunidade agil [Beck and Andres 2004, Highsmith and Fowler 2001], a quali-
´
dade do software e, sobretudo, medida pela qualidade de seu c´ digo-fonte. Um dos prin-
o
o ´
cipais problemas associados ao c´ digo e o gerenciamento de mudancas sem a devida
¸
¸˜
preparacao do c´ digo para recebˆ -las, deixando-o complexo [Martin 2009] e dificultando
o e
¸˜ ¸˜ a
sua manutencao. Tais mudancas dentro deste ambiente sem preparacao d´ origem aos
¸
problemas de c´ digo (bad smells). [Fowler 1999] descreve, informalmente, vinte e dois
o
problemas de design em c´ digos-fonte orientado a objetos. Defende tamb´ m a impossibi-
o e
lidade da existˆ ncia de crit´ rios objetivos, como m´ tricas de c´ digo, capazes de detectar
e e e o
quais trechos do c´ digo apresentam tais problemas.
o
Alguns trabalhos [Kafura and Reddy 1987, Mantyla et al. 2004,
M¨ ntyl¨ and Lassenius 2006] se utilizaram de t´ cnicas em que os pr´ prios desen-
a a e o
volvedores indicam onde estariam, conforme suas experiˆ ncias, presentes estes
e

2. problemas. Alguns desses trabalhos, para validar a efic´ cia de m´ tricas autom´ ticas,
a e a
compararam o resultado destas com os problemas apontados pelos desenvolvedores.
¸˜
Surpreendentemente, em grande parte, os resultados das deteccoes n˜ o coincidiram.
a
Neste caso, ou as m´ tricas estavam mal formuladas, ou os pressupostos que embasam
e
¸˜ ¸˜ a
a conceituacao de “problema” pelas ferramentas de deteccao n˜ o est˜ o de acordo com
a
o que os desenvolvedores, de fato, consideram como problema. Uma boa parte dessas
ferramentas [Van Emden and Moonen 2002, Marinescu 2001, Ratiu et al. 2004] s˜ o a
¸˜
baseadas nas descricoes de problemas de c´ digo [Fowler 1999]. Todavia, como estes
o
¸˜
possuem definicoes informais e complexas, seria plaus´vel imaginar que seu entedimento,
ı
por parte de desenvolvedores, pode variar por conta de fatores como experiˆ ncia,e
ambiente de desenvolvimento, entre outros.
e ¸˜
A ausˆ ncia de publicacoes no cen´ rio nacional sobre as quest˜ es aqui considera-
a o
¸˜
das foi a motivacao principal de nosso trabalho. Assim sendo, este trabalho se prop˜ e o
` ¸˜ ¸˜
a analisar como alguns fatores relacionados a qualidade na construcao e manutencao de
c´ digo-fonte s˜ o percebidos pelos desenvolvedores analisados. Para tanto, foi aplicado
o a
um question´ rio em cento e nove desenvolvedores diferentes, levantando o n´vel de im-
a ı
portˆ ncia por eles dado aos diversos fatores e comportamentos que influenciam a quali-
a
o e ¸ ¸˜
dade de c´ digo. Foram tamb´ m realizados estudos para verificar diferencas de percepcao
entre grupos distintos de desenvolvedores, os quais incluem “os novatos”, “os experi-
entes”, “os que utilizam alguma ferramenta de framework” e “os que n˜ o a utilizam”.
a
`
Especula-se que fatores relativos a experiˆ ncia e ao uso ou n˜ o de framework podem
e a
¸˜
explicar, em grande parte, uma poss´vel variabilidade importante de percepcao entre os
ı
desenvolvedores. Assim, buscou-se justificar como o fato de pertencer ou n˜ o a um grupo
a
influenciou algumas respostas. Justificativas para duplas de fatores que foram percebidos
de forma semelhante foram tamb´ m ensaiadas. O restante deste trabalho est´ divido da
e a
¸˜ ¸˜
seguinte forma: a Secao 2 analisa trabalhos relacionados; a Secao 3 descreve a metodo-
¸˜
logia empregada e os objetivos desta pesquisa; a Secao 4 informa acerca dos resultados
¸˜ ¸˜
obtidos, discutindo-os; a Secao 5 conclui e aponta limitacoes, que servir˜ o de est´mulo
a ı
para trabalhos futuros.
2. Trabalhos Relacionados
[M¨ ntyl¨ et al. 2003] descreve uma taxonomia dos problemas de design citados em
a a
¸˜
[Fowler 1999], correlacionando suas manifestacoes. Todavia nenhuma an´ lise causal des-
a
´ ´
ses problemas e feito, nem e estabelecida uma correlac˜ o com outros fenˆ menos. Em
a o
[Sammet 1983], foram utilizados grupos de quatro pessoas, com experiˆ ncia semelhante,
e
o ¸˜
para avaliar a qualidade de c´ digo. A avaliacao constituia-se de treze quest˜ es em uma
o
¸˜
escala de Likert de sete pontos. Os resultados mostraram que, na metade das avaliacoes,
¸˜
trˆ s dos quatro avaliadores concordaram sobre as avaliacoes feitas. Contudo, em ape-
e
¸˜
nas 43,1% das avaliacoes as diferencas entre elas foi de dois ou menos pontos na es-
¸
cala. Os autores justificaram as discrepˆ ncias devido a poss´veis incompreens˜ es das
a ı o
¸˜
quest˜ es ou da escala por parte dos avaliadores, sem levar em consideracao, por exem-
o
ı ¸ o ¸˜
plo, poss´veis diferencas de opini˜ es, estilos e percepcoes de bom design entre eles. Em
[M¨ ntyl¨ and Lassenius 2006], foram avaliados m´ dulos de um software tanto objetiva
a a o
quanto subjetivamente, verificando se ambos os m´ todos obtinham resultados correlacio-
e
¸˜
nados. Obteve-se boa correlacao entre problemas de design mais facilmente visualiz´ veis
a
¸˜ ` ¸˜
por humanos, mas em relacao a deteccao de problemas de design mais complexos, n˜ o a

3. ¸˜
obteve correlacao, em grande parte, devido a fatores individuais de cada desenvolvedor.
´
Em [Mantyla et al. 2004], e feito um estudo de caso na Cia Finnish, em que um ques-
a ´ ¸˜
tion´ rio e aplicado em desenvolvedores para verificar se suas avaliacoes de problemas de
a ¸˜
design em m´ dulos s˜ o congruentes com a avaliacao autom´ tica de m´ tricas. Os resul-
o a e
tados foram tamb´ m divergentes. No question´ rio, havia quest˜ es para que avaliassem o
e a o
quanto cada um sabia de cada m´ dulo de forma a atribuir a cada desenvolvedor m´ dulos
o o
dos quais fossem melhor conhecedores. Para alguns casos, houve uma grande variabili-
dade, concluindo que atitudes mais positivas ou negativas de cada desenvolvedor influ-
¸˜ ¸˜
enciaram em sua avaliacao na deteccao de problemas nos m´ dulos avaliados. Um dos
o
´
problemas do referido trabalho e o fato das quest˜ es perguntadas serem extremamente
o
complexas. Pedia-se que os desenvolvedores identificassem problemas de design em tre-
o a ` a
chos de c´ digo. Ocorre que, muitas vezes, o desenvolvedor ou n˜ o tem, a m˜ o, o trecho
o a ¸˜
de c´ digo a ser analisado ou n˜ o entende corretamente a definicao do problema a ser
detectado. Em ambos os casos a an´ lise ficaria prejudicada.
a
3. Metodologia e Objetivos da Pesquisa
Neste trabalho, foram estudados quais fatores 109 desenvolvedores analisados considera-
ram mais relevantes para a qualidade de c´ digo-fonte, bem como quais problemas foram
o
¸˜
considerados os mais significativos na deterioracao dessa qualidade. Para tanto, criou-se
um question´ rio em que cada desenvolvedor graduou em uma escala de Likert de cinco
a
pontos cada um dos itens perguntados.
¸˜
Para a obtencao do question´ rio definitivo, primeiramente criou-se um ques-
a
tion´ rio preliminar. Este foi aplicado a alguns poucos desenvolvedores, com o objetivo
a
de valid´ -lo, de forma que o feedback dos respondentes serviu como sugest˜ o para sua
a a
melhoria. Tomou-se o cuidado para que as quest˜ es perguntadas fossem de f´ cil compre-
o a
ens˜ o, de forma que os resultados n˜ o fossem prejudicados por uma dificuldade em seus
a a
entendimentos. De posse do question´ rio definitivo, este foi disponibilizado a desenvol-
a
vedores que faziam parte de listas de contato e de discuss˜ o dos autores. O question´ rio,
a a
acess´vel na web1 , foi respondido, de forma n˜ o-supervisionada, por 109 desenvolvedores
ı a
brasileiros, sendo a maioria (88%) do Estado do Rio Grande do Sul.
Os respondentes forneceram nome, idade, empresa onde trabalham, estado de ori-
gem, n´ mero de pessoas em sua equipe de desenvolvimento, linguagem de programacao
u ¸˜
utilizada, al´ m de fatores capazes de influenciar a qualidade de c´ digo. Sobre os fa-
e o
tores escolhidos para compor o question´ rio, optou-se pelos mais citados na litera-
a
tura [Fowler 1999, Kerievsky 2004, Martin 2009, Beck and Andres 2004]. O objetivo do
question´ rio foi o de buscar um entedimento mais profundo sobre indicadores subjetivos
a
¸˜
de qualidade e fatores que influenciam na variacao dessa subjetividade. Particularmente,
buscou-se respostas para as seguintes quest˜ es: Quais problemas/fatores foram classifi-
o
cados como mais cr´ticos/importantes? Como a experiˆ ncia dos desenvolvedores influen-
ı e
ciou em suas respostas? Como o fato de usar ou n˜ o framework as influenciou? Quais
a
itens foram percebidos de forma semelhante pelos desenvolvedores?
Para alcancar estes objetivos, calculou-se a m´ dia, mediana, moda e desvio-padr˜ o
¸ e a
dos itens respondidos. Testou-se, estatisticamente, a hip´ tese de que o n´vel de ex-
o ı
periˆ ncia e o uso ou n˜ o de frameworks influenciou as respostas. Tamb´ m verificou-se,
e a e
1
O formul´ rio empregado est´ dispon´vel em http://www.inf.ufrgs.br/∼marcios/formulario.html
a a ı

4. o e ¸˜
por meio de teste de hip´ tese, a existˆ ncia de correlacao significativa entre pares de itens
respondidos.
4. Resultados e An´ lise de Dados
a
¸˜
As tabelas 1 e 2 representam, em ordem decrescente, a pontuacao m´ dia dada pelos de-
e
senvolvedores para as perguntas relativas aos itens que influenciam a qualidade de c´ digo,
o
bem como o c´ lculo das respectivas modas e medianas. Para a quest˜ o sobre experiˆ ncia
a a e
¸˜
profissional dos desenvolvedores, obtiveram-se as seguintes proporcoes: menos de 1 ano
de experiˆ ncia: 5,5%; de 1 a 3 anos: 31,19%; de 3 a 5 anos: 24,77%; de 5 a 10 anos:
e
¸˜
18,35%; e mais de 10 anos: 20,18%. Em relacao ao uso de frameworks, 55,05% utilizam,
enquanto 44,95% n˜ o utilizam.
a
´
Tabela 1. Problemas em ordem decrescente de media
Problema M´ dia Moda Mediana
e
Falta de tratamento de erros 3,669 5 4
Complexidade em excesso 3,660 4 4
¸˜
Funcoes que fazem mais de uma coisa 3,330 4 3
Estruturas muito longas 3,330 3 3
C´ digo duplicado
o 3,211 3 3
Ausˆ ncia de padr˜ es
e o 3,137 3 3
Classes muito grandes 2,954 3 3
Estruturas aninhadas 2,733 2 3
¸˜
M´ formatacao
a 2,706 1 3
Coment´ rios indevidos
a 2,091 1 2
´
Tabela 2. Fatores em ordem decrescente de media
Fator M´ dia Moda Mediana
e
Simplicidade 4,412 5 5
F´ cil entendimento
a 4,357 5 5
Uso de nomes significativos 4,339 5 5
C´ digo organizado em pequenos trechos
o 4,009 5 4
¸˜
Uso de padr˜ es de codificacao
o 3,798 4 4
Uso de coment´ rios pertinentes
a 3,770 5 4
Experiˆ ncia do desenvolvedor
e 3,467 4 4
C´ digo que possa ser testado automaticamente 3,467
o 3 3
Uso de frameworks 2,816 3 3
Uso de DSLs 2,311 3 2
O pr´ ximo passo foi verificar a influˆ ncia da experiˆ ncia dos desenvolvedores em
o e e
suas respostas. Para tanto, foram analisados dois grupos extremos de desenvolvedores: os
com at´ 3 anos de experiˆ ncia e os com mais de 10 anos de experiˆ ncia. O objetivo foi
e e e
descobrir se as diferencas constatadas entre as m´ dias das respostas de cada um dos gru-
¸ e
pos possuem significˆ ncia estat´stica. Para isso, executou-se o teste de hip´ tese t-student
a ı o
da diferenca entre as m´ dias dos dois grupos para cada um dos 20 itens perguntados, su-
¸ e
pondo variˆ ncias iguais entre os dois grupos populacionais. Logo, a hip´ tese nula para
a o

5. o a ´
cada uma das quest˜ es (vari´ veis) e a que segue: “As m´ dias das respostas dos grupos
e
n˜ o diferem significativamente na vari´ vel avaliada”.
a a
Abaixo, s˜ o citadas e discutidas as vari´ veis para as quais se pˆ de rejeitar a
a a o
hip´ tese nula, com relevˆ ncia significativa maior que 95% (p < 0, 05):
o a
• Com relevˆ ncia maior que 98%, pode-se afirmar que os mais experientes se preo-
a
¸˜
cupam mais com o problema “C´ digo duplicado” em relacao aos menos experien-
o
¸˜
tes. A m´ dia da pontuacao dada para este problema por parte dos mais experientes
e
(mais de 10 anos) foi 3,681, contra a m´ dia de 2,925 dos com menos de 3 anos de
e
experiˆ ncia.
e
• Com relevˆ ncia maior que 99,9%, pode-se afirmar que os mais experientes se
a
preocupam mais com o problema “Complexidade em excesso”. Foi obtida m´ dia e
de 3,509 contra 2,175 dos menos experientes. Interessante notar que a diferenca ¸
entre a m´ dia dos dois grupos foi relativamente grande, al´ m de ter se obtido uma
e e
confiabilidade altamente significativa. Isso talvez seja explicado pelo fato de os
iniciantes tenderem muitas vezes a complicar seu c´ digo desnecessariamente, o
o
que faria com que eles entendam o problema da complexidade em excesso como
algo n˜ o t˜ o cr´tico quando comparado aos mais experientes.
a a ı
• Com relevˆ ncia maior que 95%, os mais experientes se preocupam menos (m´ dia
a e
a ¸˜
de 2,318) com o problema “M´ formatacao de c´ digo” do que os menos expe-
o
rientes (m´ dia de 3,1). Como os novatos ainda tem dificuldade de compreender
e
o ¸˜
c´ digos mais complexos, uma boa formatacao de c´ digo lhes seria mais indis-
o
a e ¸˜
pens´ vel do que aos mais experientes. Tamb´ m, o fato de a formatacao de c´ digo
o
ser uma quest˜ o mais recentemente levantada implica que os experientes n˜ o te-
a a
nham sido treinados a seguirem consistentemente esta pr´ tica.
a
• Com relevˆ ncia maior que 95%, os mais experientes se preocupam menos (m´ dia
a e
de 2,409) com o problema “Ausˆ ncia de padr˜ es” do que os menos experien-
e o
tes (m´ dia de 3,175). Os mesmo argumentos utilizados no problema de m´
e a
¸˜
formatacao poderia ser usado aqui.
• Com relevˆ ncia maior que 99,9%, os mais experientes acham mais importante o
a
fator “Simplicidade” (m´ dia de 4,590) do que os menos experientes (m´ dia de
e e
¸˜
3,863). Uma explicacao plaus´vel seria a mesma dada para o problema “Comple-
ı
xidade em excesso”.
• Com relevˆ ncia maior que 95%, os mais experientes acham menos importante
a
(m´ dia de 3,772) o fator “C´ digo estruturado em pequenos trechos” do que os
e o
¸˜
menos experientes (m´ dia de 4,25). A explicacao seria uma maior dificuldade por
e
parte dos menos experientes em ler c´ digos estruturados em trechos muito longos.
o
Cabe ressaltar que n˜ o foi poss´vel refutar a hip´ tese para o fator “Experiˆ ncia do
a ı o e
desenvolvedor”. Ou seja, tanto os novatos quanto os mais experientes tiveram a mesma
a ¸˜ `
opini˜ o em relacao a importˆ ncia desse fator (m´ dia de 3,467).
a e
o ¸˜
Ap´ s, a mesma verificacao de influˆ ncia anteriormente feita foi procedida para o
e
fato de os desenvolvedores se dividirem em dois grupos: os que usam framework e os
que n˜ o usam. Assim, foi analisado se esta pr´ tica influenciou em alguma das quest˜ es
a a o
respondidas. Os resultados foram os seguintes:
Com relevˆ ncia maior que 98%, pode-se afirmar que os que usam framework
a
o ¸˜
acham o fator “Padr˜ es de codificacao” mais importante (m´ dia de 3,983) do que os que
e

6. ¸˜ ´
n˜ o usam (m´ dia de 3,571). A explicacao para este resultado e que muitos frameworks
a e
a ¸˜
prov´ m um padr˜ o de codificacao. Logo, os que usam est˜ o mais prop´cios a enxergar, na
e a ı
pr´ tica, esta vantagem.
a
Com relevˆ ncia maior que 98%, pode-se afirmar que os que usam framework
a
acham que o fator “Uso de frameworks” mais importante (m´ dia de 3,2) do que os que
e
¸˜ ´
n˜ o usam (m´ dia de 2,346). Aqui a explicacao e a mesma que a anterior. Este e um
a e ´
resultado bastante expressivo, tanto pela alta diferenca das m´ dias dos dois grupos (3,2
¸ e
contra 2,346) quanto pela confiabilidade relativamente alta obtida. Cabe aqui ressaltar
que entre os que n˜ o usam, nenhum pontuou este fator com o grau m´ ximo (igual a 5) de
a a
importˆ ncia.
a
Com relevˆ ncia maior que 95%, os que usam framework acham o fator “Co-
a
ment´ rios pertinentes” menos importante (m´ dia de 3,6) do que os que n˜ o usam (m´ dia
a e a e
¸˜
de 3,979). A explicacao estaria no fato de ambientes com framework, por tenderem a pro-
duzir um c´ digo mais padronizado e leg´vel, exigem que se facam menos coment´ rios.
o ı ¸ a
Da´ a pouca importˆ ncia dada aos coment´ rios por este grupo.
ı a a
Com relevˆ ncia maior que 99,9%, os que usam framework acham o fator “C´ digo
a o
que possa ser testado automaticamente” mais importante (m´ dia de 3,766) do que os que
e
a e ¸˜
n˜ o usam (m´ dia de 3,102). A explicacao seria que muitos frameworks possuem ambien-
tes para testagem autom´ tica, o que faria os desenvolvedores que usam essas ferramentas
a
enxergarem, na pr´ tica, uma grande vantagem em seu uso.
a
Interessante constatar que o fato do desenvolvedor usar ou n˜ o framework influ-
a
o ¸˜
enciou as respostas do fator “Uso de padr˜ es de codificacao”, mas n˜ o influenciou o pro-
a
e o ı ¸˜ ´
blema “Ausˆ ncia de padr˜ es”. Uma poss´vel interpretacao para isso e que os que utilizam
¸˜
framework acham mais importante, em relacao aos que n˜ o usam, que exista um ambi-
a
¸˜
ente padronizado proporcionado por tal ferramenta, entretanto a falta dessa padronizacao
´
e vista, em termos de criticidade, da mesma forma por ambos os grupos.
Finalmente, verificou-se quais quest˜ es foram percebidos de forma semelhante
o
¸˜
pelos desenvolvedores. Para tanto, calculou-se o “Coeficiente de Correlacao Linear de
Pearson” para os 190 pares de quest˜ es. Ap´ s, procedeu-se ao teste de hip´ tese para
o o o
a ¸˜
avaliar a significˆ ncia dos coeficientes de correlacao obtidos. A hip´ tese nula de que
o
a ¸˜
n˜ o existe correlacao populacional foi refutada para 17 pares de quest˜ es. Todos esses
o
¸˜
pares foram de correlacao positiva, de n´vel moderado (Coeficiente de Pearson entre 0,30
ı
e 0,70) com relevˆ ncia altamente significativa. Abaixo, em ordem decrescente, est˜ o
a a
¸˜
descritas tais correlacoes:
• Correlacao de 0,454 entre os problemas “M´ formatacao” e “Ausˆ ncia de
¸˜ a ¸˜ e
e o e a ¸˜
padr˜ es”. Ausˆ ncia de padr˜ es geralmente implica tamb´ m em m´ formatacao.
o
Isso explicaria o fato de muitos desenvolvedores terem apontado ambos os pro-
blemas com o mesmo n´vel de criticidade.
ı
• Correlacao de 0,435 entre os problemas “Estruturas muito longas” e “Classes
¸˜
muito grandes”. Classes muito grandes s˜ o um tipo de estrutura longa. Por-
a
tanto, j´ que os problemas est˜ o correlacionados, os desenvolvedores tenderam
a a
a gradu´ -los de forma semelhante.
a
• Correlacao de 0,389 entre os problemas “Complexidade em excesso” e “Classes
¸˜
muito grandes”. Classes grandes tendem a ter demasiada complexidade.

7. • Correlacao de 0,386 entre os fatores “C´ digo que possa ser testado automatica-
¸˜ o
a ¸˜
mente” e “Uso de DSLs”. N˜ o houve explicacao plaus´vel para este fato.
ı
• Correlacao de 0,379 entre os problemas “Estruturas muito longas” e “Complexi-
¸˜
dade em excesso”. De fato, s˜ o problemas semelhantes.
a
• Correlacao de 0,364 entre o problema “Classes muito grandes” e o fator “C´ digo
¸˜ o
que possa ser testado automaticamente”. Aqui, provavelmente classes muito gran-
des indicam um c´ digo grande, o que necessitaria de um ambiente de testagem
o
autom´ tica para obter-se maior eficiˆ ncia.
a e
• Correlacao de 0,356 entre os problemas “Falta de tratamento de erros” e “M´
¸˜ a
¸˜ ¸˜
formatacao”. N˜ o se conseguiu deduzir uma explicacao plausivel.
a
• Correlacao de 0,352 entre os problemas “Classes muito grandes” e “Estruturas
¸˜
aninhadas”. Os desenvolvedores interpretaram tais problemas como manifestacao ¸˜
de uma complexidade prejudicial existente em ambos os itens.
• Correlacao de 0,346 entre o problema “Funcoes que fazem mais de uma coisa” e o
¸˜ ¸˜
¸˜
fator “C´ digo que possa ser testado automaticamente”. Aqui, funcoes que fazem
o
mais de uma coisa, em geral, s˜ o estruturas complexas dif´ceis de serem testadas.
a ı
Logo, um ambiente que possa test´ -las automaticamente seria de grande utilidade.
a
• Correlacao de 0,333 entre os problema “Funcoes que fazem mais de uma coisa
¸˜ ¸˜
e “Coment´ rios indevidos”. Provavelmente, quem atribui um grau alto de critici-
a
¸˜
dade ao problema das funcoes que fazem mais de uma coisa entende tamb´ m que e
a a ¸˜
coment´ rios indevidos s˜ o utilizados para que tais funcoes “se facam entender”.
¸
• Correlacao de 0,3304 entre o problema “Estruturas aninhadas” e o fator “C´ digo
¸˜ o
que possa ser testado automaticamente”. Novamente, estruturas aninhadas, por
sua complexidade, exigiriam meios de testagem autom´ tica.a
• Correlacao de 0,3302 entre os problemas “Estruturas muito longas” e “Estruturas
¸˜
´
aninhadas”. A segunda e um caso espec´fico da primeira.
ı
• Correlacao de 0,319 entre os problemas “Estruturas aninhadas” e “Funcoes que fa-
¸˜ ¸˜
zem mais de uma coisa”. Os desenvolvedores interpretaram tais problemas como
¸˜
manifestacao de uma complexidade prejudicial existente.
• Correlacao de 0,316 entre os problemas “Complexidade em excesso” e “Funcoes
¸˜ ¸˜
¸˜
que fazem mais de uma coisa”. Funcoes que fazem mais de uma coisa e, prova- ´
´
velmente, algo que colabora para a complexidade em excesso. Logo e justific´ vel a
dar a mesma importˆ ncia para esses dois tipos de problemas.
a
• Correlacao de 0,308 entre os problemas “Coment´ rios indevidos” e “M´
¸˜ a a
¸˜ ¸˜
formatacao”. N˜ o houve explicacao plaus´vel para este fato.
a ı
• Correlacao de 0,307 entre os problemas “Estruturas muito longas” e “Funcoes
¸˜ ¸˜
¸˜
que fazem mais de uma coisa”. Funcoes que fazem mais de uma coisa tendem a
possuir estruturas muito longas.
• Correlacao de 0,301 entre os problemas “Funcoes que fazem mais de uma coisa”
¸˜ ¸˜
¸˜
e “Falta de tratamento de erros”. Funcoes que fazem mais de uma coisa, devido a `
sua maior complexidade de entendimento, est˜ o mais suscet´veis a erros.
a ı
¸˜
5. Consideracoes Finais
O objetivo da pesquisa emp´rica aqui apresentada foi entender quais fatores influenciaram
ı
a qualidade de c´ digo do ponto de vista dos desenvolvedores participantes. Para isso, foi
o
elaborado um question´ rio com foco em quest˜ es simples capazes de influenciar nesta
a o
¸˜
qualidade e em futuras manutencoes deste c´ digo.
o

8. A influˆ ncia do fato de usar ou n˜ o framework nas respostas dos desenvolvedores
e a
¸˜
foi verificada, bem como obtiveram-se explicacoes para as diferencas constatadas. Este
¸
¸˜ ¸˜
fato influenciou, por exemplo, a percepcao dos itens “Padr˜ es de codificacao”, “C´ digo
o o
que possa ser testado automaticamente” e “Coment´ rios pertinentes”, os quais se rela-
a
¸˜
cionam, em alguma medida, com a pr´ tica de utilizacao desta ferramenta. Analisou-se
a
tamb´ m como a experiˆ ncia dos desenvolvedores influenciou suas respostas. Foram ob-
e e
tidas diferencas significativas na forma com que os novatos e os experientes enxergam
¸
¸˜
alguns itens. Para os casos constatados, buscaram-se explicacoes plaus´veis. Interessante
ı
notar que o fato de usar ou n˜ o framework influenciou a resposta relativa ao uso dessa
a
ferramenta, denotando uma “consciˆ ncia” da importˆ ncia de seu uso por parte destes
e a
usu´ rios. Tal fenˆ meno n˜ o foi verificado para o item “Experiˆ ncia do desenvolvedor”.
a o a e
Ou seja, novatos e experientes deram igual importˆ ncia para ele. Ao final do trabalho,
a
¸˜
buscou-se explicacoes para pares de itens percebidos de forma semelhante, fato compro-
e o ¸˜
vado atrav´ s de teste de hip´ teses e estudo de correlacao entre eles.
¸˜
Entre as limitacoes do trabalho, est´ o fato do question´ rio ter sido aplicado de
a a
forma n˜ o-supervisionada, n˜ o havendo, pois, como garantir que as quest˜ es foram clara-
a a o
mente entendidas. Al´ m disso, o n´vel de precis˜ o nas respostas pode n˜ o ter sido o ideal,
e ı a a
a a ¸˜
j´ que n˜ o se conseguiu estabelecer correlacao satisfat´ ria entre alguns itens claramente
o
conexos. Por exemplo, diferentemente do constatado, uma boa parte dos desenvolvedores
que acharam cr´tico o problema “Complexidade em excesso” deveria tamb´ m ter achado
ı e
imprescind´vel o fator “Simplicidade”. O mesmo deveria se aplicar aos fatores “Sim-
ı
plicidade” e “F´ cil entendimento”, por serem todos eles interligados. Outra correlacao
a ¸˜
´ ´
um pouco mais s´ til n˜ o constatada, mas que e citada em [Martin 2009], e a dualidade
u a
existente entre o problema “Coment´ rios indevidos” versus o fator “Coment´ rios perti-
a a
nentes”. A pr´ tica de fazer coment´ rios pertinentes rivaliza com o mau h´ bito de fazer
a a a
a ¸˜
coment´ rios redundantes ou como solucao para tornar “menos ruim” um c´ digo ileg´vel.
o ı
¸˜
Adicionalmente, mais de uma vari´ vel poderia ter sido combinada na formacao de grupos
a
¸˜
mais consistentes, obtendo-se correlacoes mais significativas. Por exemplo, o grupo dos
que usam framework e consideraram o fator “Uso de frameworks” de alta importˆ ncia a
talvez fosse mais representativo dos desenvolvedores que seguem mais fortemente a fi-
losofia desse tipo de ferramenta. Da mesma forma, o grupo dos mais experientes que
indicaram o fator “Experiˆ ncia do desenvolvedor” como de grande importˆ ncia poderiam
e a
representar mais fielmente este grupo.
Adicionalmente, os resultados obtidos preliminarmente neste artigo apontam para
a possibilidade de futuras pesquisas no cen´ rio nacional sobre como a qualidade e sua in-
a
¸˜ ´
fluˆ ncia na manutencao de c´ digo e vista e incorporada pelos atores do desenvolvimento
e o
e como isso afeta o trabalho em equipe. Nosso objetivo com este artigo n˜ o foi somente
a
¸˜
chamar a atencao sobre qual a vis˜ o dos desenvolvedores sobre atributos de qualidade e
a
como os processos e pr´ ticas adotados podem influenciar esta vis˜ o, mas tamb´ m aumen-
a a e
¸˜
tar a discuss˜ o de toda a comunidade de engenharia de software nacional em relacao a
a
este tema. Outro objetivo foi diminuir a lacuna que existe na literatura sobre a opini˜ o
a
dos desenvolvedores, sobretudo no contexto nacional.
Referˆ ncias
e
Beck, K. and Andres, C. (2004). Extreme Programming Explained: Embrace Change
(2nd Edition). Addison-Wesley, Boston.

9. Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Addison-
Wesley, Boston, MA, USA.
Highsmith, J. and Fowler, M. (2001). The agile manifesto. Software Development Maga-
zine, 9(8):29–30.
Kafura, D. and Reddy, G. R. (1987). The use of software complexity metrics in software
maintenance. IEEE Trans. Softw. Eng., 13:335–343.
Kerievsky, J. (2004). Refactoring to Patterns. Pearson Higher Education.
M¨ ntyl¨ , M., Vanhanen, J., and Lassenius, C. (2003). A taxonomy and an initial empirical
a a
study of bad smells in code. In ICSM ’03: Proceedings of the International Conference
on Software Maintenance, page 381, Washington, DC, USA. IEEE Computer Society.
M¨ ntyl¨ , M. V. and Lassenius, C. (2006). Subjective evaluation of software evolvability
a a
using code smells: An empirical study. Empirical Softw. Engg., 11:395–431.
Mantyla, M. V., Vanhanen, J., and Lassenius, C. (2004). Bad smells - humans as code
critics. In Proceedings of the 20th IEEE International Conference on Software Main-
tenance, pages 399–408, Washington, DC, USA. IEEE Computer Society.
Marinescu, R. (2001). Detecting design flaws via metrics in object-oriented systems.
In Proceedings of the 39th International Conference and Exhibition on Technology
of Object-Oriented Languages and Systems (TOOLS39), TOOLS ’01, pages 173–,
Washington, DC, USA. IEEE Computer Society.
Martin, R. C. (2009). Clean Code: A handbook of agile software craftsmanship. Prentice
Hall.
Ratiu, D., Ducasse, S., Gˆrba, T., and Marinescu, R. (2004). Using history information to
ı
improve design flaws detection. In CSMR, pages 223–232. IEEE Computer Society.
Sammet, J. E. (1983). Software psychology: human factors in computer and information
systems. SIGCHI Bull., 14:19–20.
Van Emden, E. and Moonen, L. (2002). Java quality assurance by detecting code smells.
In Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE’02),
pages 97–, Washington, DC, USA. IEEE Computer Society.