Fatores que afetam a qualidade do código-fonte: a percepção dos desenvolvedores
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Fatores que afetam a qualidade do código-fonte: a percepção dos desenvolvedores

on

  • 1,420 views

 

Statistics

Views

Total Views
1,420
Views on SlideShare
1,420
Embed Views
0

Actions

Likes
0
Downloads
24
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fatores que afetam a qualidade do código-fonte: a percepção dos desenvolvedores Document Transcript

  • 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 ¸˜ ¸˜ asua manutencao. Tais mudancas dentro deste ambiente sem preparacao d´ origem aos ¸problemas de c´ digo (bad smells). [Fowler 1999] descreve, informalmente, vinte e dois oproblemas de design em c´ digos-fonte orientado a objetos. Defende tamb´ m a impossibi- o elidade da existˆ ncia de crit´ rios objetivos, como m´ tricas de c´ digo, capazes de detectar e e e oquais 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 ovolvedores 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 acompararam o resultado destas com os problemas apontados pelos desenvolvedores. ¸˜Surpreendentemente, em grande parte, os resultados das deteccoes n˜ o coincidiram. aNeste caso, ou as m´ tricas estavam mal formuladas, ou os pressupostos que embasam e ¸˜ ¸˜ aa conceituacao de “problema” pelas ferramentas de deteccao n˜ o est˜ o de acordo com ao que os desenvolvedores, de fato, consideram como problema. Uma boa parte dessasferramentas [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,eambiente 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 dec´ digo-fonte s˜ o percebidos pelos desenvolvedores analisados. Para tanto, foi aplicado o aum 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 percepcaoentre 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 ainfluenciou algumas respostas. Justificativas para duplas de fatores que foram percebidosde 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 oquanto 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 etados foram tamb´ m divergentes. No question´ rio, havia quest˜ es para que avaliassem o e a oquanto cada um sabia de cada m´ dulo de forma a atribuir a cada desenvolvedor m´ dulos o odos 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 ocomplexas. Pedia-se que os desenvolvedores identificassem problemas de design em tre- o a ` achos 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 serdetectado. Em ambos os casos a an´ lise ficaria prejudicada. a3. Metodologia e Objetivos da PesquisaNeste 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-seum question´ rio em que cada desenvolvedor graduou em uma escala de Likert de cinco apontos cada um dos itens perguntados. ¸˜ Para a obtencao do question´ rio definitivo, primeiramente criou-se um ques- ation´ rio preliminar. Este foi aplicado a alguns poucos desenvolvedores, com o objetivo ade valid´ -lo, de forma que o feedback dos respondentes serviu como sugest˜ o para sua a amelhoria. Tomou-se o cuidado para que as quest˜ es perguntadas fossem de f´ cil compre- o aens˜ o, de forma que os resultados n˜ o fossem prejudicados por uma dificuldade em seus a aentendimentos. De posse do question´ rio definitivo, este foi disponibilizado a desenvol- avedores que faziam parte de listas de contato e de discuss˜ o dos autores. O question´ rio, a aacess´vel na web1 , foi respondido, de forma n˜ o-supervisionada, por 109 desenvolvedores ı abrasileiros, 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 otores escolhidos para compor o question´ rio, optou-se pelos mais citados na litera- atura [Fowler 1999, Kerievsky 2004, Martin 2009, Beck and Andres 2004]. O objetivo doquestion´ 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- ocados como mais cr´ticos/importantes? Como a experiˆ ncia dos desenvolvedores influen- ı eciou em suas respostas? Como o fato de usar ou n˜ o framework as influenciou? Quais aitens foram percebidos de forma semelhante pelos desenvolvedores? Para alcancar estes objetivos, calculou-se a m´ dia, mediana, moda e desvio-padr˜ o ¸ e ados 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 itensrespondidos.4. Resultados e An´ lise de Dados a ¸˜As tabelas 1 e 2 representam, em ordem decrescente, a pontuacao m´ dia dada pelos de- esenvolvedores para as perguntas relativas aos itens que influenciam a qualidade de c´ digo, obem 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 anode 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 esuas respostas. Para tanto, foram analisados dois grupos extremos de desenvolvedores: oscom at´ 3 anos de experiˆ ncia e os com mais de 10 anos de experiˆ ncia. O objetivo foi e e edescobrir se as diferencas constatadas entre as m´ dias das respostas de cada um dos gru- ¸ epos possuem significˆ ncia estat´stica. Para isso, executou-se o teste de hip´ tese t-student a ı oda diferenca entre as m´ dias dos dois grupos para cada um dos 20 itens perguntados, su- ¸ epondo 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 en˜ 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 ohip´ 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 edesenvolvedor”. 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 efato de os desenvolvedores se dividirem em dois grupos: os que usam framework e osque n˜ o usam. Assim, foi analisado se esta pr´ tica influenciou em alguma das quest˜ es a a orespondidas. 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 aacham 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 ¸ econtra 2,346) quanto pela confiabilidade relativamente alta obtida. Cabe aqui ressaltarque entre os que n˜ o usam, nenhum pontuou este fator com o grau m´ ximo (igual a 5) de a aimportˆ ncia. a Com relevˆ ncia maior que 95%, os que usam framework acham o fator “Co- ament´ 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 ı ¸ aDa´ 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 oque 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 aenxergarem, 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 dePearson” 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 FinaisO 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 oelaborado 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 oque 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 atamb´ m como a experiˆ ncia dos desenvolvedores influenciou suas respostas. Foram ob- e etidas 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 aferramenta, denotando uma “consciˆ ncia” da importˆ ncia de seu uso por parte destes e ausu´ rios. Tal fenˆ meno n˜ o foi verificado para o item “Experiˆ ncia do desenvolvedor”. a o a eOu 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 aforma n˜ o-supervisionada, n˜ o havendo, pois, como garantir que as quest˜ es foram clara- a a omente 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 oconexos. Por exemplo, diferentemente do constatado, uma boa parte dos desenvolvedoresque acharam cr´tico o problema “Complexidade em excesso” deveria tamb´ m ter achado ı eimprescind´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 aexistente entre o problema “Coment´ rios indevidos” versus o fator “Coment´ rios perti- a anentes”. 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 dosque usam framework e consideraram o fator “Uso de frameworks” de alta importˆ ncia atalvez 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 “Experiˆ ncia do desenvolvedor” como de grande importˆ ncia poderiam e arepresentar mais fielmente este grupo. Adicionalmente, os resultados obtidos preliminarmente neste artigo apontam paraa 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 oe 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 acomo 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 aeste tema. Outro objetivo foi diminuir a lacuna que existe na literatura sobre a opini˜ o ados desenvolvedores, sobretudo no contexto nacional.Referˆ ncias eBeck, 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.