Page 258 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING
P. 258
Principles of Software Engineering
Notes with the title “Refractor Static Classes to Object Classes” and one at the end of iteration four
with the title “Refractor Architecture”. We refer to the implementation of these two user
stories as explicit refactoring; we analyze changes of productivity and quality measures
before and after their completion. Then we concern two methods are:
• H0A –Does productivity increase after “explicate factorings”?
• H0B –Cohesion, coupling and complexity: does refactoring improve code quality?
Although agile processes and practices are gaining more importance in the software industry
there is limited solid empirical evidence of their effectiveness. This research focuses in particular
on the practice of refactoring, which is one of the key practices of Extreme Programming
and other Agile Methods. While the majority of software developers and researchers agree
that refactoring has long-term benefits on the quality of a software product (in particular on
program understanding) there is no such consensus regarding the development productivity.
Available empirical results regarding this issue are very limited and not clear. This might
refrain managers from adopting refactoring, as they might be scared of loosing resources.
This work contributes to a better understanding of the effects of refactoring both on code
qualities in particular on software maintainability - and development productivity in a
close-to industrial, agile development environment. It provides new empirical, industrially
based evidence that refactoring rather increases than decreases development productivity
and improves quality factors, as measured using common internal quality attributes
reduces code complexity and coupling; increases cohesion that was too limited to be taken
as a reference. For internal quality metrics, our results are in accordance with the existing
literature. Altogether, we believe that our findings are particularly relevant, as this work
is a case study in a close-to-industry environment, a kind of empirical investigation that is
rare for the research problem we discuss here. Clearly, this is a first work in the area. A real
generalizable assessment of the implications of refactoring requires several repetitions of
studies like this, possibly also including data on defects. The findings of this research have
major implications for a widespread use of refactoring, as already mentioned by Beck in
his first work on XP. Of course refactoring as any other technique is something a developer
has to learn. First, managers have to be convinced that refactoring is very valuable for their
business; this research should help them in doing so as it sustains that refactoring if applied
properly intrinsically improves code maintainability and increases development productivity.
Afterwards, they have to provide training and support to change their development process
into a new one that includes continuous refactoring.
Questions
1. Define Agile refactoring process is maintain? Explain it.
2. Describe explicit refactoring.
Self Assessment Questions
6. A series of .................... without changing its observable behaviour.
(a) refactoring (b) factoring
(c) configuring (d) All of these.
7. The power of refactoring as a method lies in ……………
(a) systematically organized documents
(b) rapped documents
(c) simple
(d) All of these.
252 LOVELY PROFESSIONAL UNIVERSITY