Fatores que Afetam a Qualidade do Codigo-fonte: a Percepcaodos Desenvolvedores

Marcio M. Sklar, Guilherme S. Lacerda, Daniel F. Wildt,Marcelo S. Pimenta, Roberto T. Price, Mara Abel

1Instituto de Informatica – Universidade Federal do Rio Grande do Sul (UFRGS)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 developersperception 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 studyon answers obtained. We’ve verified developers experience and how the factof using or not a framework tool affected their answers. Ultimately, we line-arly correlated similar answers perception between developers, besides tryingto justify these correlations.

Resumo. Este trabalho apresenta os resultados da analise feita sobre apercepcao de desenvolvedores em relacao a diversos fatores que influenciam aqualidade do codigo na construcao e manutencao de software. Para isso, foi dis-ponibilizado um questionario com uma lista de dez problemas potencialmenteprejudiciais, bem como dez fatores que influenciariam positivamente o codigo,de forma que os desenvolvedores os graduassem em nıvel de importancia. Sobreas respostas obtidas, realizaram-se alguns estudos estatısticos. Foram verifica-das como a experiencia do desenvolvedor e o uso ou nao de framework influ-enciaram em suas respostas. Por fim, via correlacao linear, foram detectadas ejustificadas duplas de perguntas percebidas de forma semelhante.

1. IntroducaoPara a comunidade agil [Beck and Andres 2004, Highsmith and Fowler 2001], a quali-dade do software e, sobretudo, medida pela qualidade de seu codigo-fonte. Um dos prin-cipais problemas associados ao codigo e o gerenciamento de mudancas sem a devidapreparacao do codigo para recebe-las, deixando-o complexo [Martin 2009] e dificultandosua manutencao. Tais mudancas dentro deste ambiente sem preparacao da origem aosproblemas de codigo (bad smells). [Fowler 1999] descreve, informalmente, vinte e doisproblemas de design em codigos-fonte orientado a objetos. Defende tambem a impossibi-lidade da existencia de criterios objetivos, como metricas de codigo, capazes de detectarquais trechos do codigo apresentam tais problemas.

Alguns trabalhos [Kafura and Reddy 1987, Mantyla et al. 2004,Mantyla and Lassenius 2006] se utilizaram de tecnicas em que os proprios desen-volvedores indicam onde estariam, conforme suas experiencias, presentes estes

problemas. Alguns desses trabalhos, para validar a eficacia de metricas automaticas,compararam o resultado destas com os problemas apontados pelos desenvolvedores.Surpreendentemente, em grande parte, os resultados das deteccoes nao coincidiram.Neste caso, ou as metricas estavam mal formuladas, ou os pressupostos que embasama conceituacao de “problema” pelas ferramentas de deteccao nao estao de acordo como que os desenvolvedores, de fato, consideram como problema. Uma boa parte dessasferramentas [Van Emden and Moonen 2002, Marinescu 2001, Ratiu et al. 2004] saobaseadas nas descricoes de problemas de codigo [Fowler 1999]. Todavia, como estespossuem definicoes informais e complexas, seria plausıvel imaginar que seu entedimento,por parte de desenvolvedores, pode variar por conta de fatores como experiencia,ambiente de desenvolvimento, entre outros.

A ausencia de publicacoes no cenario nacional sobre as questoes aqui considera-das foi a motivacao principal de nosso trabalho. Assim sendo, este trabalho se propoea analisar como alguns fatores relacionados a qualidade na construcao e manutencao decodigo-fonte sao percebidos pelos desenvolvedores analisados. Para tanto, foi aplicadoum questionario em cento e nove desenvolvedores diferentes, levantando o nıvel de im-portancia por eles dado aos diversos fatores e comportamentos que influenciam a quali-dade de codigo. Foram tambem realizados estudos para verificar diferencas de percepcaoentre grupos distintos de desenvolvedores, os quais incluem “os novatos”, “os experi-entes”, “os que utilizam alguma ferramenta de framework” e “os que nao a utilizam”.Especula-se que fatores relativos a experiencia e ao uso ou nao de framework podemexplicar, em grande parte, uma possıvel variabilidade importante de percepcao entre osdesenvolvedores. Assim, buscou-se justificar como o fato de pertencer ou nao a um grupoinfluenciou algumas respostas. Justificativas para duplas de fatores que foram percebidosde forma semelhante foram tambem ensaiadas. O restante deste trabalho esta divido daseguinte 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 resultadosobtidos, discutindo-os; a Secao 5 conclui e aponta limitacoes, que servirao de estımulopara trabalhos futuros.

2. Trabalhos Relacionados

[Mantyla et al. 2003] descreve uma taxonomia dos problemas de design citados em[Fowler 1999], correlacionando suas manifestacoes. Todavia nenhuma analise causal des-ses problemas e feito, nem e estabelecida uma correlacao com outros fenomenos. Em[Sammet 1983], foram utilizados grupos de quatro pessoas, com experiencia semelhante,para avaliar a qualidade de codigo. A avaliacao constituia-se de treze questoes em umaescala de Likert de sete pontos. Os resultados mostraram que, na metade das avaliacoes,tres dos quatro avaliadores concordaram sobre as avaliacoes feitas. Contudo, em ape-nas 43,1% das avaliacoes as diferencas entre elas foi de dois ou menos pontos na es-cala. Os autores justificaram as discrepancias devido a possıveis incompreensoes dasquestoes ou da escala por parte dos avaliadores, sem levar em consideracao, por exem-plo, possıveis diferencas de opinioes, estilos e percepcoes de bom design entre eles. Em[Mantyla and Lassenius 2006], foram avaliados modulos de um software tanto objetivaquanto subjetivamente, verificando se ambos os metodos obtinham resultados correlacio-nados. Obteve-se boa correlacao entre problemas de design mais facilmente visualizaveispor humanos, mas em relacao a deteccao de problemas de design mais complexos, nao

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-tionario e aplicado em desenvolvedores para verificar se suas avaliacoes de problemas dedesign em modulos sao congruentes com a avaliacao automatica de metricas. Os resul-tados foram tambem divergentes. No questionario, havia questoes para que avaliassem oquanto cada um sabia de cada modulo de forma a atribuir a cada desenvolvedor modulosdos 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 modulos avaliados. Um dosproblemas do referido trabalho e o fato das questoes perguntadas serem extremamentecomplexas. Pedia-se que os desenvolvedores identificassem problemas de design em tre-chos de codigo. Ocorre que, muitas vezes, o desenvolvedor ou nao tem, a mao, o trechode codigo a ser analisado ou nao entende corretamente a definicao do problema a serdetectado. Em ambos os casos a analise ficaria prejudicada.

3. Metodologia e Objetivos da PesquisaNeste trabalho, foram estudados quais fatores 109 desenvolvedores analisados considera-ram mais relevantes para a qualidade de codigo-fonte, bem como quais problemas foramconsiderados os mais significativos na deterioracao dessa qualidade. Para tanto, criou-seum questionario em que cada desenvolvedor graduou em uma escala de Likert de cincopontos cada um dos itens perguntados.

Para a obtencao do questionario definitivo, primeiramente criou-se um ques-tionario preliminar. Este foi aplicado a alguns poucos desenvolvedores, com o objetivode valida-lo, de forma que o feedback dos respondentes serviu como sugestao para suamelhoria. Tomou-se o cuidado para que as questoes perguntadas fossem de facil compre-ensao, de forma que os resultados nao fossem prejudicados por uma dificuldade em seusentendimentos. De posse do questionario definitivo, este foi disponibilizado a desenvol-vedores que faziam parte de listas de contato e de discussao dos autores. O questionario,acessıvel na web1, foi respondido, de forma nao-supervisionada, por 109 desenvolvedoresbrasileiros, sendo a maioria (88%) do Estado do Rio Grande do Sul.

Os respondentes forneceram nome, idade, empresa onde trabalham, estado de ori-gem, numero de pessoas em sua equipe de desenvolvimento, linguagem de programacaoutilizada, alem de fatores capazes de influenciar a qualidade de codigo. Sobre os fa-tores escolhidos para compor o questionario, optou-se pelos mais citados na litera-tura [Fowler 1999, Kerievsky 2004, Martin 2009, Beck and Andres 2004]. O objetivo doquestionario foi o de buscar um entedimento mais profundo sobre indicadores subjetivosde qualidade e fatores que influenciam na variacao dessa subjetividade. Particularmente,buscou-se respostas para as seguintes questoes: Quais problemas/fatores foram classifi-cados como mais crıticos/importantes? Como a experiencia dos desenvolvedores influen-ciou em suas respostas? Como o fato de usar ou nao framework as influenciou? Quaisitens foram percebidos de forma semelhante pelos desenvolvedores?

Para alcancar estes objetivos, calculou-se a media, mediana, moda e desvio-padraodos itens respondidos. Testou-se, estatisticamente, a hipotese de que o nıvel de ex-periencia e o uso ou nao de frameworks influenciou as respostas. Tambem verificou-se,

1O formulario empregado esta disponıvel em http://www.inf.ufrgs.br/∼marcios/formulario.html

por meio de teste de hipotese, a existencia de correlacao significativa entre pares de itensrespondidos.

4. Resultados e Analise de Dados

As tabelas 1 e 2 representam, em ordem decrescente, a pontuacao media dada pelos de-senvolvedores para as perguntas relativas aos itens que influenciam a qualidade de codigo,bem como o calculo das respectivas modas e medianas. Para a questao sobre experienciaprofissional dos desenvolvedores, obtiveram-se as seguintes proporcoes: menos de 1 anode experiencia: 5,5%; de 1 a 3 anos: 31,19%; de 3 a 5 anos: 24,77%; de 5 a 10 anos:18,35%; e mais de 10 anos: 20,18%. Em relacao ao uso de frameworks, 55,05% utilizam,enquanto 44,95% nao utilizam.

Tabela 1. Problemas em ordem decrescente de mediaProblema Media Moda Mediana

Falta de tratamento de erros 3,669 5 4Complexidade em excesso 3,660 4 4

Funcoes que fazem mais de uma coisa 3,330 4 3Estruturas muito longas 3,330 3 3

Codigo duplicado 3,211 3 3Ausencia de padroes 3,137 3 3

Classes muito grandes 2,954 3 3Estruturas aninhadas 2,733 2 3

Ma formatacao 2,706 1 3Comentarios indevidos 2,091 1 2

Tabela 2. Fatores em ordem decrescente de mediaFator Media Moda Mediana

Simplicidade 4,412 5 5Facil entendimento 4,357 5 5

Uso de nomes significativos 4,339 5 5Codigo organizado em pequenos trechos 4,009 5 4

Uso de padroes de codificacao 3,798 4 4Uso de comentarios pertinentes 3,770 5 4Experiencia do desenvolvedor 3,467 4 4

Codigo que possa ser testado automaticamente 3,467 3 3Uso de frameworks 2,816 3 3

Uso de DSLs 2,311 3 2

O proximo passo foi verificar a influencia da experiencia dos desenvolvedores emsuas respostas. Para tanto, foram analisados dois grupos extremos de desenvolvedores: oscom ate 3 anos de experiencia e os com mais de 10 anos de experiencia. O objetivo foidescobrir se as diferencas constatadas entre as medias das respostas de cada um dos gru-pos possuem significancia estatıstica. Para isso, executou-se o teste de hipotese t-studentda diferenca entre as medias dos dois grupos para cada um dos 20 itens perguntados, su-pondo variancias iguais entre os dois grupos populacionais. Logo, a hipotese nula para

cada uma das questoes (variaveis) e a que segue: “As medias das respostas dos gruposnao diferem significativamente na variavel avaliada”.

Abaixo, sao citadas e discutidas as variaveis para as quais se pode rejeitar ahipotese nula, com relevancia significativa maior que 95% (p < 0, 05):

• Com relevancia maior que 98%, pode-se afirmar que os mais experientes se preo-cupam mais com o problema “Codigo duplicado” em relacao aos menos experien-tes. A media da pontuacao dada para este problema por parte dos mais experientes(mais de 10 anos) foi 3,681, contra a media de 2,925 dos com menos de 3 anos deexperiencia.• Com relevancia maior que 99,9%, pode-se afirmar que os mais experientes se

preocupam mais com o problema “Complexidade em excesso”. Foi obtida mediade 3,509 contra 2,175 dos menos experientes. Interessante notar que a diferencaentre a media dos dois grupos foi relativamente grande, alem de ter se obtido umaconfiabilidade altamente significativa. Isso talvez seja explicado pelo fato de osiniciantes tenderem muitas vezes a complicar seu codigo desnecessariamente, oque faria com que eles entendam o problema da complexidade em excesso comoalgo nao tao crıtico quando comparado aos mais experientes.• Com relevancia maior que 95%, os mais experientes se preocupam menos (media

de 2,318) com o problema “Ma formatacao de codigo” do que os menos expe-rientes (media de 3,1). Como os novatos ainda tem dificuldade de compreendercodigos mais complexos, uma boa formatacao de codigo lhes seria mais indis-pensavel do que aos mais experientes. Tambem, o fato de a formatacao de codigoser uma questao mais recentemente levantada implica que os experientes nao te-nham sido treinados a seguirem consistentemente esta pratica.• Com relevancia maior que 95%, os mais experientes se preocupam menos (media

de 2,409) com o problema “Ausencia de padroes” do que os menos experien-tes (media de 3,175). Os mesmo argumentos utilizados no problema de maformatacao poderia ser usado aqui.• Com relevancia maior que 99,9%, os mais experientes acham mais importante o

fator “Simplicidade” (media de 4,590) do que os menos experientes (media de3,863). Uma explicacao plausıvel seria a mesma dada para o problema “Comple-xidade em excesso”.• Com relevancia maior que 95%, os mais experientes acham menos importante

(media de 3,772) o fator “Codigo estruturado em pequenos trechos” do que osmenos experientes (media de 4,25). A explicacao seria uma maior dificuldade porparte dos menos experientes em ler codigos estruturados em trechos muito longos.

Cabe ressaltar que nao foi possıvel refutar a hipotese para o fator “Experiencia dodesenvolvedor”. Ou seja, tanto os novatos quanto os mais experientes tiveram a mesmaopiniao em relacao a importancia desse fator (media de 3,467).

Apos, a mesma verificacao de influencia anteriormente feita foi procedida para ofato de os desenvolvedores se dividirem em dois grupos: os que usam framework e osque nao usam. Assim, foi analisado se esta pratica influenciou em alguma das questoesrespondidas. Os resultados foram os seguintes:

Com relevancia maior que 98%, pode-se afirmar que os que usam frameworkacham o fator “Padroes de codificacao” mais importante (media de 3,983) do que os que

nao usam (media de 3,571). A explicacao para este resultado e que muitos frameworksprovem um padrao de codificacao. Logo, os que usam estao mais propıcios a enxergar, napratica, esta vantagem.

Com relevancia maior que 98%, pode-se afirmar que os que usam frameworkacham que o fator “Uso de frameworks” mais importante (media de 3,2) do que os quenao usam (media de 2,346). Aqui a explicacao e a mesma que a anterior. Este e umresultado bastante expressivo, tanto pela alta diferenca das medias dos dois grupos (3,2contra 2,346) quanto pela confiabilidade relativamente alta obtida. Cabe aqui ressaltarque entre os que nao usam, nenhum pontuou este fator com o grau maximo (igual a 5) deimportancia.

Com relevancia maior que 95%, os que usam framework acham o fator “Co-mentarios pertinentes” menos importante (media de 3,6) do que os que nao usam (mediade 3,979). A explicacao estaria no fato de ambientes com framework, por tenderem a pro-duzir um codigo mais padronizado e legıvel, exigem que se facam menos comentarios.Daı a pouca importancia dada aos comentarios por este grupo.

Com relevancia maior que 99,9%, os que usam framework acham o fator “Codigoque possa ser testado automaticamente” mais importante (media de 3,766) do que os quenao usam (media de 3,102). A explicacao seria que muitos frameworks possuem ambien-tes para testagem automatica, o que faria os desenvolvedores que usam essas ferramentasenxergarem, na pratica, uma grande vantagem em seu uso.

Interessante constatar que o fato do desenvolvedor usar ou nao framework influ-enciou as respostas do fator “Uso de padroes de codificacao”, mas nao influenciou o pro-blema “Ausencia de padroes”. Uma possıvel interpretacao para isso e que os que utilizamframework acham mais importante, em relacao aos que nao usam, que exista um ambi-ente padronizado proporcionado por tal ferramenta, entretanto a falta dessa padronizacaoe vista, em termos de criticidade, da mesma forma por ambos os grupos.

Finalmente, verificou-se quais questoes foram percebidos de forma semelhantepelos desenvolvedores. Para tanto, calculou-se o “Coeficiente de Correlacao Linear dePearson” para os 190 pares de questoes. Apos, procedeu-se ao teste de hipotese paraavaliar a significancia dos coeficientes de correlacao obtidos. A hipotese nula de quenao existe correlacao populacional foi refutada para 17 pares de questoes. Todos essespares foram de correlacao positiva, de nıvel moderado (Coeficiente de Pearson entre 0,30e 0,70) com relevancia altamente significativa. Abaixo, em ordem decrescente, estaodescritas tais correlacoes:

• Correlacao de 0,454 entre os problemas “Ma formatacao” e “Ausencia depadroes”. Ausencia de padroes geralmente implica tambem em ma formatacao.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 sao um tipo de estrutura longa. Por-tanto, ja que os problemas estao correlacionados, os desenvolvedores tenderama gradua-los de forma semelhante.• Correlacao de 0,389 entre os problemas “Complexidade em excesso” e “Classes

muito grandes”. Classes grandes tendem a ter demasiada complexidade.

• Correlacao de 0,386 entre os fatores “Codigo que possa ser testado automatica-mente” e “Uso de DSLs”. Nao houve explicacao plausıvel para este fato.• Correlacao de 0,379 entre os problemas “Estruturas muito longas” e “Complexi-

dade em excesso”. De fato, sao problemas semelhantes.• Correlacao de 0,364 entre o problema “Classes muito grandes” e o fator “Codigo

que possa ser testado automaticamente”. Aqui, provavelmente classes muito gran-des indicam um codigo grande, o que necessitaria de um ambiente de testagemautomatica para obter-se maior eficiencia.• Correlacao de 0,356 entre os problemas “Falta de tratamento de erros” e “Ma

formatacao”. Nao se conseguiu deduzir uma explicacao plausivel.• Correlacao de 0,352 entre os problemas “Classes muito grandes” e “Estruturas

aninhadas”. Os desenvolvedores interpretaram tais problemas como manifestacaode 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 “Codigo que possa ser testado automaticamente”. Aqui, funcoes que fazemmais de uma coisa, em geral, sao estruturas complexas difıceis de serem testadas.Logo, um ambiente que possa testa-las automaticamente seria de grande utilidade.• Correlacao de 0,333 entre os problema “Funcoes que fazem mais de uma coisa

e “Comentarios indevidos”. Provavelmente, quem atribui um grau alto de critici-dade ao problema das funcoes que fazem mais de uma coisa entende tambem quecomentarios indevidos sao utilizados para que tais funcoes “se facam entender”.• Correlacao de 0,3304 entre o problema “Estruturas aninhadas” e o fator “Codigo

que possa ser testado automaticamente”. Novamente, estruturas aninhadas, porsua complexidade, exigiriam meios de testagem automatica.• 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 comomanifestacao 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 justificaveldar a mesma importancia para esses dois tipos de problemas.• Correlacao de 0,308 entre os problemas “Comentarios indevidos” e “Ma

formatacao”. Nao houve explicacao plausıvel para este fato.• 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 apossuir 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 asua maior complexidade de entendimento, estao mais suscetıveis a erros.

5. Consideracoes FinaisO objetivo da pesquisa empırica aqui apresentada foi entender quais fatores influenciarama qualidade de codigo do ponto de vista dos desenvolvedores participantes. Para isso, foielaborado um questionario com foco em questoes simples capazes de influenciar nestaqualidade e em futuras manutencoes deste codigo.

A influencia do fato de usar ou nao framework nas respostas dos desenvolvedoresfoi verificada, bem como obtiveram-se explicacoes para as diferencas constatadas. Estefato influenciou, por exemplo, a percepcao dos itens “Padroes de codificacao”, “Codigoque possa ser testado automaticamente” e “Comentarios pertinentes”, os quais se rela-cionam, em alguma medida, com a pratica de utilizacao desta ferramenta. Analisou-setambem como a experiencia dos desenvolvedores influenciou suas respostas. Foram ob-tidas diferencas significativas na forma com que os novatos e os experientes enxergamalguns itens. Para os casos constatados, buscaram-se explicacoes plausıveis. Interessantenotar que o fato de usar ou nao framework influenciou a resposta relativa ao uso dessaferramenta, denotando uma “consciencia” da importancia de seu uso por parte destesusuarios. Tal fenomeno nao foi verificado para o item “Experiencia do desenvolvedor”.Ou seja, novatos e experientes deram igual importancia para ele. Ao final do trabalho,buscou-se explicacoes para pares de itens percebidos de forma semelhante, fato compro-vado atraves de teste de hipoteses e estudo de correlacao entre eles.

Entre as limitacoes do trabalho, esta o fato do questionario ter sido aplicado deforma nao-supervisionada, nao havendo, pois, como garantir que as questoes foram clara-mente entendidas. Alem disso, o nıvel de precisao nas respostas pode nao ter sido o ideal,ja que nao se conseguiu estabelecer correlacao satisfatoria entre alguns itens claramenteconexos. Por exemplo, diferentemente do constatado, uma boa parte dos desenvolvedoresque acharam crıtico o problema “Complexidade em excesso” deveria tambem ter achadoimprescindıvel o fator “Simplicidade”. O mesmo deveria se aplicar aos fatores “Sim-plicidade” e “Facil entendimento”, por serem todos eles interligados. Outra correlacaoum pouco mais sutil nao constatada, mas que e citada em [Martin 2009], e a dualidadeexistente entre o problema “Comentarios indevidos” versus o fator “Comentarios perti-nentes”. A pratica de fazer comentarios pertinentes rivaliza com o mau habito de fazercomentarios redundantes ou como solucao para tornar “menos ruim” um codigo ilegıvel.Adicionalmente, mais de uma variavel poderia ter sido combinada na formacao de gruposmais consistentes, obtendo-se correlacoes mais significativas. Por exemplo, o grupo dosque usam framework e consideraram o fator “Uso de frameworks” de alta importanciatalvez fosse mais representativo dos desenvolvedores que seguem mais fortemente a fi-losofia desse tipo de ferramenta. Da mesma forma, o grupo dos mais experientes queindicaram o fator “Experiencia do desenvolvedor” como de grande importancia poderiamrepresentar mais fielmente este grupo.

Adicionalmente, os resultados obtidos preliminarmente neste artigo apontam paraa possibilidade de futuras pesquisas no cenario nacional sobre como a qualidade e sua in-fluencia na manutencao de codigo e vista e incorporada pelos atores do desenvolvimentoe como isso afeta o trabalho em equipe. Nosso objetivo com este artigo nao foi somentechamar a atencao sobre qual a visao dos desenvolvedores sobre atributos de qualidade ecomo os processos e praticas adotados podem influenciar esta visao, mas tambem aumen-tar a discussao de toda a comunidade de engenharia de software nacional em relacao aeste tema. Outro objetivo foi diminuir a lacuna que existe na literatura sobre a opiniaodos desenvolvedores, sobretudo no contexto nacional.

ReferenciasBeck, K. and Andres, C. (2004). Extreme Programming Explained: Embrace Change

(2nd Edition). Addison-Wesley, Boston.

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 softwaremaintenance. IEEE Trans. Softw. Eng., 13:335–343.

Kerievsky, J. (2004). Refactoring to Patterns. Pearson Higher Education.

Mantyla, M., Vanhanen, J., and Lassenius, C. (2003). A taxonomy and an initial empiricalstudy of bad smells in code. In ICSM ’03: Proceedings of the International Conferenceon Software Maintenance, page 381, Washington, DC, USA. IEEE Computer Society.

Mantyla, M. V. and Lassenius, C. (2006). Subjective evaluation of software evolvabilityusing code smells: An empirical study. Empirical Softw. Engg., 11:395–431.

Mantyla, M. V., Vanhanen, J., and Lassenius, C. (2004). Bad smells - humans as codecritics. 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 Technologyof 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. PrenticeHall.

Ratiu, D., Ducasse, S., Gırba, T., and Marinescu, R. (2004). Using history information toimprove design flaws detection. In CSMR, pages 223–232. IEEE Computer Society.

Sammet, J. E. (1983). Software psychology: human factors in computer and informationsystems. 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.