Studies on Developers, Refactoring and Code Smells Aiko Yamashita - - PowerPoint PPT Presentation

Aiko Yamashita

CWI, Netherlands Oslo and Akershus University College, Norway 2016-12-01

Studies on Developers, Refactoring and Code Smells

Sapporo, Japan San Francisco, USA mom dad Oslo, Norway San Jose, Costa Rica Gothenburg, Sweden Berkeley, USA

A SHORT INTRO ABOUT ME..

Amsterdam, Netherlands

What is going on there?

• utcomes

(effort, defects, etc)

Something happens here...

Maybe the absence/presence

• f difficulties?

code properties

Researcher Maintenance Project

TAXONOMY FOR INCREMENTAL CHANGE

What types of difficulties developers face?

The wider environment The containing system The system (operators and processes) The software product Code

User knowledge, programmer effectiveness, product quality, programmer time availability, machine requirements, and system reliability

Lientz & Swanson

Maintenance management,

• rganizational environment,

personnel factors, and system characteristics.

Dekleva Chapin

Maintenance tasks

Hall / Chen

Software Process Improvement scenario

Reddy

Configuration Management

Alexander, Ian F. "A taxonomy of stakeholders: Human roles in system development." International Journal of Technology and Human Interaction (IJTHI) 1.1 (2005): 23-59.

inspired by

factors f a c t

• r

s f a c t

• r

s

Karahasanovic

Program comprehension difficulties

Webster

Risk factors/programming difficulties

?

There is currently no Taxonomy for Programming related difficulties

Maintenance Project:

• 3-4 weeks
• Six developers
• Two companies

Data collection:

• Daily interviews
• Think-aloud sessions
• Observational Log

Data analysis:

• Open and Axial coding

METHODOLOGY

What types of difficulties developers face?

1) Introduction of faults as result of changes

2) Confusion and erroneous hypothesis generation 3) Slow acquisition of overview/general understanding of the system 4) Time-consuming information quests 5) Time consuming changes

Class A Class B Change Class C Change Change

I C S M E 2 1 3

RESULTS

What types of difficulties developers face?

Future work

Concept Extraction Concept Location I m p a c t A n a l y s i s A c t u a l i z a t i

• n

Incorporation C h a n g e P r

• p

a g a t i

• n

Refactoring

More concise, accurate categorizations Use the model of ‘Incremental change’ process by Raijlich & Gosabi

Goal:

• Level of insight on code smells
• How is currently used
• How can concept/tools potentially be used.

Non-probability sample Freelance marketplaces (Freelancer.com) Based on a bid (filling out the survey) which was paid 30US/hr for max. 2 hours 85 respondents

Are we concerned about the same smells?

• EXPLORATORY SURVEY-

Software Engineers Software Engineering Researchers Smell detector W C R E 2 1 3

Smell/Anti-Pattern Points

• 1. Duplicated code

19.53

• 2. Long method

9.78

• 3. Accidental complexity

8.32

• 4. Large class

7.09

• 5. Excessive use of literals

3.04

• 6. Suboptimal information hiding

2.70

• 7. Lazy class

2.33

• 8. Feature Envy

2.33

• 9. Long parameter list

2.31

• 10. Dead code

2.25

• 11. Bad (or lack of good) comments

1.50

• 12. Use deprecated components

1.50

• 13. Single Responsibility

1.20

• 14. Complex conditionals

1.12

• 15. Bad naming

1.12

Feature Points

• 1. Detection of duplicated and near-duplicated code

10.00

• 2. Dynamic analysis (number of calls, etc)

4.08

• 3. Define and customize detection strategies

3.50

• 4. Support code inspection

2.67

• 5. Suggest refactorings

2.50

• 6. Good usability

2.50

• 7. Detect potentially problematic areas

2.33

• 8. Real-time update

2.33

• 9. Detect memory leaks

2.25

• Are we concerned about the same smells?
• EXPLORATORY SURVEY-

• %
• '

( )

• ,

CF', 2BGBG0CF' 1F I8FGF CCF%, 49BG937F) 5CC6BCF I8FGF) 0CF7BI7 C7FFB7F%

Like!

Where do you read about code smells?

Are we concerned about the same smells?

• EXPLORATORY SURVEY-

Only two of the respondents (4%) used smell tools:

➡ JetBrains Re-sharper (smell detection + refactoring) ➡ DevExpress CodeRush + Refactor!Pro

Other usages:

• Coding standards/detect potentially problematic code:

➡ CheckStyle, FindBugs, FxCop, and PMD.

• Performance of web applications:

➡ FireBugs, Pagespeed,

Yslow and Pingdom

• Exploration and code organization for manual review

➡ Visual Studio, Eclipse

• Duplicated code (clone detection).

Are we concerned about the same smells?

• TOOL EXPERIENCES-

• 85 developers did the survey
• 32% did not know about code smells
• Main sources on code smells:

✓Blogs ✓Internet forums ✓Seminars and working place

• Majority moderately concerned about smells
• Level of knowledge explains perceived criticality
• Most developers refactor ‘on the fly’...

Are we concerned about the same smells?

• SUMMARY -

Developers showed interest in: automation, accuracy (less false positives) and not being intrusive during work.

do I really need to check all

• f them?

FALSE POSITIVES

• Refused Bequest
• Message Chains
• God Method
• God Class
• Feature Envy
• Dispersed Coupling
• Duplicated Code
• Data Clumps
• Data Class
• Shotgun Surgery
• Circular Dependencies Between Packages
• Subtype Knowledge

12 anti-patterns and code smells covered Definition Synonyms Description Argumentation for existence of FP Examples (code) Concrete instances of FP Relevant contextual factors Empirical studies Theory Practical experiences Factor Implication

Preliminary Catalogue of Anti-pattern and Code Smell False Positives Technical Report RA-5/2015

Poznań University of Technology

S A N E R 2 1 6 FIRST ATTEMPT TO BUILD A TAXONOMY

Code Smell and Anti-patterns False Positives

defect taxonomy

construction modelling/design requirements requirement captured incorrectly requirement not implemented requirement misunderstood while implementing design flaw / code smell / anti-pattern logic incorrect expression data-flow (incl. variable assignment / initialization) algorithm (control-flow) data database OR mapping interface user interaction API (technical interface) resources memory concurrency performance case completeness exceptions validation language environment

• perating environment

OS 3rd Party hardware built environment build tools (make/rake etc) configuration management system QA standards documentation testing

• ther

Building a metadata for improvig sampling of projects from GitHub TAXONOMY FOR DEFECT CLASSIFICATION

Can we have a simpler categorization of defects?

Programming (code-related) activities during Maintenance Reading Searching Navigating Editing Others

How do Code Smells affect Maintenance Activities?

• MINING IDE EVENT LOGS-

D C B A

Developer System

Study Design

• 4 Java Applications
• Same functionality
• Different design/code
• Size: 7KLOC to 14KLOC

Context Maintenance Tasks

Task 3. New Reporting functionality Task 1. Replacing external data source

✔

Task 2. New authentication mechanism

System System!

Experimental Setting: A Controlled Case Study

System Project context Tasks

Source code Daily interviews Audio files/notes Subversion database

Programming Skill

Defects*

Development Technology

Change Size** Effort** Maintenance outcomes

Think aloud Video files/notes Task progress sheets Eclipse activity logs Trac (Issue tracker), Acceptance test reports Open interviews Audio files/notes

Variables

• f interest

Data sources Moderator variables

Code smells

(num. smells** smell density**) ** System and fle level * Only at system level Maintainability perception* Maintenance problems**

Think aloud Video files/notes Study diary

• 50,000 Euros
• Sep-Dec, 2008
• 7 Weeks
• 6 Developers
• 2 Companies

fact-sheet

Experimental Setting: A Controlled Case Study

• Selection of artifacts in the package explorer
• Selection of Java elements in the editor window
• Selecting Java elements in the file outline
• Editing source files (Java files)
• Scrolling the source code window
• Switching between open files
• Running Eclipse “commands” (copy, paste, go to line)

Activity logs

How do Code Smells affect Maintenance Activities?

• MINING IDE EVENT LOGS-

➡Mostly performed activities:

Navigating (58.72%), Reading (28.27%), Editing (10.18%) and searching (2.47%)

➡Distribution is consistent with Ko

et al. 2006 (top four)

➡Reading as most consuming activity

in Ko et al. 2006.

• Definition of event/action belonging to

an activity

For our analysis, we only consider: Editing, Navigating, Searching and Reading

How do Code Smells affect Maintenance Activities?

DISTRIBUTION OF ACTIVITY EFFORT

S m e l l s e x p l a i n b e t t e r E d i t i n g a n d N a v i g a t i n g e f f

• r

t t h a n fi l e s i z e , b u t n

• t

f

• r

R e a d i n g a n d S e a r c h i n g Maintenance problems in previous work related to increased effort for editing, navigating and reading

How do Code Smells affect Maintenance Activities?

SUMMARY OF RESULTS

Developer Round Effort (time) System Main variables Refactorings (types, no.)

Is#there#an#individual#refactoring#style? What#are#the#general#tendencies#w.r.t.#refactorings? Is#there#a#learning#when#refactoring?#(diff#between#rounds) Research(ques+ons:

Refactored files and directories

Files and directories before maintenance Files and directories after maintenance

Dataset(1

What are the general tendencies for refactoring? Is there an individual refactoring style? Is there a learning when refactoring?

Code smells (initial) Type of task Associated to bugfix? Code smells (final) Main variables Size in LOC (initial) Total effort Total churn Size in LOC (final) Other variables Original file? Refactored files and directories Java files

Dataset&2 Does%the%ini*al%design**%affect%the%choice%of%refactorings%and%smell%evolu*on? Does%the%type%of%task%affect%the%types/effort%spent%on%refactoring? Research&ques.ons:

Do design or type of task affect refactoring?

How do Code Smells affect Refactoring?

ANALYSING LOGS TO UNDERSTAND REFACTORING CHOICES T

• b

e s u b m i t t e d s

• m

e w h e r e . . .

Only for developer 3, there was an effect from system, we suspect due to a more “ad-hoc” refactoring strategy

0" 20" 40" 60" 80" 100" 120" 140" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"A" 2"D" 0" 2" 4" 6" 8" 10" 12" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"D" 2"C" 0" 1" 2" 3" 4" 5" 6" 7" 8" 9" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"B" 2"A" 0" 10" 20" 30" 40" 50" 60" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"C" 2"B" 0" 0.5" 1" 1.5" 2" 2.5" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"C" 2"D" 0" 0.5" 1" 1.5" 2" 2.5" 3" 3.5" Rename"element" Select"refactoring"menu" Change"method"signature" Generate"constructors"using" Generate"constructors"from" Extract"local"variable" Organize"the"imports" Extract"method" Extract"Super"Class" Pull"Up" Override"or"Implement" Rename"informaFon" Infer"generic"type" Generalize"declared"type" Push"Down" Move"method/class" Convert"nested"to"top"acFon" Introduce"Parameter"AcFon" Generate"Delegate"Methods" Extract"Constant" Extract"Interface" 1"A" 2"B"

developer 1 developer 4 developer 2 developer 3 developer 5 developer 6

There seems to be an individual style for refactoring!

Model &2(Log( likelihood Cox(&(Snell(R( Square Nagelkerke(R( Square Variables((contributing Data(Clump!(Beta!=(4,093!p!<!0,05) Data(Class!(Beta!=!5,568!p!<!0,05) Feature(Envy!(Beta!=4,303!p!<!0,05) Shotgun(Surgery!(Beta!=!(3,657!p!<!0,001) Total(no.(smells!(Beta!=!(3,414!p<0,05) Extract!method 256,678 ,103 ,209 Lines(of(code!(Beta!=!0,197!p!<!0,01) ,371 ,081 72,718 Change!method!signature ,149 ,102 473,871 Organize!imports

0" 20" 40" 60" 80" 100" 120" 140" 160" R e n a m e " e l e m e n t " C h a n g e " m e t h

• d

" s i g n a t u r e " G e n e r a t e " c

• n

s t r u c t

• r

s " u s i n g " fi e l d s " G e n e r a t e " c

• n

s t r u c t

• r

s " f r

• m

" s u p e r c l a s s " E x t r a c t " l

• c

a l " v a r i a b l e " O r g a n i z e " t h e " i m p

• r

t s " E x t r a c t " m e t h

• d

" E x t r a c t " S u p e r " C l a s s " P u l l " U p " O v e r r i d e "

• r

" I m p l e m e n t " m e t h

• d

" R e n a m e " i n f

• r

m a G

• n

" I n f e r " g e n e r i c " t y p e " G e n e r a l i z e " d e c l a r e d " t y p e " P u s h " D

• w

n " M

• v

e " m e t h

• d

/ c l a s s " C

• n

v e r t " n e s t e d " t

• "

t

• p

" a c G

• n

" I n t r

• d

u c e " P a r a m e t e r " A c G

• n

" G e n e r a t e " D e l e g a t e " M e t h

• d

s " E x t r a c t " C

• n

s t a n t " E x t r a c t " I n t e r f a c e " Task"1" Task"2" Task"3"

For tasks, it was much more the task size what could explain the frequency, rather than the type of task Only few code smells could explain some refactorings (some with negative coefficients)

Effects from Task type and code smells were minor...

It appears as extract method could increase odds of defects!! (results from a series of binary logistic regression models)

Feature Envy God Class God Method Temporal variable used for several purposes Usage of implementation instead of interface Extract Method Bugfix (after refactoring) Bugfix (at some point) Generate constructors from super class Override or implement method Move method/class

decrease

• dds

decrease increase increase

• dds

increase

• dds

decrease

Churn

つずく... to be continued... Effects of refactoring on code evolution

ありがとうございます! Thank you!