What is meant by refactoring of code?

Re-factoring of code or code refactoring is the topic of discussion of this article.

We can define the code refactoring technique as one of the disciplined techniques which is used for the following purposes:

- Restructuring of an existing body of the source code,
- Alteration of the internal structure of the code such that its external behavior remains the unaltered.

About Code Re-factoring

- The above two purposes are achieved by the application of a series of refactorings. - Each of the refactorings of the series is usually a tiny change in the source code of the computer program.
- The code refactoring technique is deployed for making improvements in the non – functional attributes of the software system or applications.
- A refactoring is not intended towards the modification of the functional requirements of the software system or application.

Advantages of Code Re-factoring

There are many advantages of the code re-factoring technique, few of which have been mentioned below:

- Improves the readability of the source code of the software system or application.
- Reduces the complexity of the code so as to improve it maintainability.
- Provides a more expressive object model or we can say an internal architecture for improving the extensibility and so on.

How is Re-factoring of code done?

It is obvious that with the continuous improvement in the design of the source code, it becomes better in its working and performing tasks.

- The developers, programmers and testers usually keep on adding new features in to the software system or application without performing adequate code refactoring which is quite an unhygienic technique.

- Carrying out the code re-factoring process continuously makes it easier to maintain and extend the source code of the program.

- The motivation to the code re-factoring is often provided by the code smell.

- Up on the identification of the problem, they can be effectively fixed by a series of code re-factoring.

- The code re-factoring solves the problem by simply transforming it in to a new form that possesses the same behavior as was in its previous form but the code is no longer found to “smell”.

- For re-factoring the longer routine, it is often sub divided into smaller sub routines which are then individually re-factorized.

- And for the duplicate routines, the duplicate is discarded and one shared function in its place is used.

- Technical debt is a serious consequence that can be faced if the code refactoring is not done effectively.

Categories in which benefits of code re-factoring should fall

The benefits of the code re-factoring usually fall in to two basic categories:

1. Extensibility
- After re-factoring, it becomes extremely easy for extending the capabilities of the software system or application if it makes use of design patterns that are recognizable and also provides flexibility in those parts of the program where there was no flexibility previously.

2. Maintainability

- Up on the code refactoring it becomes a lot easier to fix the errors and bugs because the readability of the code increases and then it becomes easy to grasp what the author intends to achieve.

- The maintainability is increased by the division of a monolithic routine in to individual single purpose methods and by placing them in to a more appropriate class.

- A solid set of automated unit tests is required before you start the process of code re-factoring.

- These tests will demonstrate the correctness of the module and then the whole process enters in to an iterative cycle making small program transformations each time iteration takes place.

- Whenever a test fails, you can undo the last transformation and keep on trying until you get it right. Such small transformations make your program what you want it to be!

What is Test Driven Development Methodology and its benefits?

Test-driven Development(TDD)is a method of developing software that adopts a test
first approach plus refactoring. The test-first approach is a programming technique, involving analysis, design, coding and testing all together. Refactoring is used to improve the design of the code without changing the observable behavior of the software, it changes the internal structure. It is cleaning up the bad code. In test-driven development, each new test provides feedback into the design process which helps in driving design decisions.

WHAT ARE DIFFERENT BENEFITS OF TEST DRIVEN DEVELOPMENT

- It allows simple incremental development.
- It involves a simpler development process.
- It provides constant regression testing.
- It improves communication.
- It improves understanding of required software behavior.
- It centralizes knowledge.
- It improves software design.

WHAT ARE DIFFERENT STEPS IN TEST DRIVEN DEVELOPMENT

- Write a test that defines how the software should behave.
- Make the test run as easily and quickly as possible.
- Clean up the code.

After integration testing, the system is tested as a whole for functionality and fitness of use. It includes performance testing, stress testing, security testing, recovery testing.
In object oriented, test requirements are derived from analysis artifacts or work products that use UML such as the class diagrams,sequence diagrams and collaboration diagrams. Use case diagram is a good source to derive test cases. They represent high functionality. Use cases are not independent. They have sequential dependencies. A scenario is an instance of a use case, or a complete path through the use case.

What is Design Engineering? What are different design concepts?

Design engineering focuses on the creation of a representation or model that are concentrated on architecture of the software, data structures, interfaces and components that are necessary to implement the software.

The design process is an iterative process of refinement, i.e.from a higher level of abstraction to lower levels of abstraction. The design should implement both explicit and implicit requirements. It should be readable and understandable. It provides an over-all illustration of the software from the perspective of the data, function and behavior.

Design concepts provides the software engineer a foundation from which design methods can be applied. These concepts include:
- Abstractions: Software engineers different levels of abstractions as we design the blueprint of the software. Two types of abstraction called data and procedural abstractions are defined.
- Modularity: It leads to information hiding and encourages functional independence.
- Coupling: It is the degree of interconnectedness between design objects. Two types of coupling are used: Interaction and Inheritance Coupling.
- Cohesion: It is the measure to which an element contributes to a single purpose.
- Refinement: Abstraction complements refinement as they enable a software engineer to specify the behavior and data of a class or module yet suppressing low levels of detail.
- Refactoring: It simplifies the design of the component without changing its function and behavior.

The work product of the design engineering phase is the design model which consists of the architectural design, data design, interface design and component-level design and deployment level design.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.

What are the basic components of Extreme Programming (XP) ?

The basic components of Extreme Programming (XP) are:

Test-First Programming
- Developers write unit tests before coding. It has been noted that this kind of approach motivates the coding, speeds coding and also improves design results in better designs.
- It supports a practice called re-factoring.
- Agile practitioners prefer tests to text for describing system behavior. Tests are more precise than human language and they are also a lot more likely to be updated when the design changes. How many times have you seen design documents that no longer accurately described the current workings of the software? Out-of-date design documents look pretty much like up-to-date documents. Out-of-date tests fall.
- Many open source tools like xUnit have been developed to support this methodology.

Refactoring
- It is the practice changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.
- Traditional development tries to understand how all the code will work together in advance. This is the design. With agile methods, this difficult process of imagining what code might look like before it is written is avoided. Instead, the code is restructured as needed to maintain a coherent design.Frequent refactoring allows less up-front planning of design.
- Agile methods replace high level design with frequent re-design. It also requires a way of ensuring whether the behavior was not changed inadvertently. That's where the tests come in.
- Make the simplest design that will work and add completely only when needed and re-factor as necessary.
- Re-factoring requires unit tests to ensure that design changes do not break existing code.

Acceptance Testing
- Make up the user experiences or user stories which are short descriptions of the features to be coded.
- Acceptance tests verify the completion of user stories.
- Ideally, they are written before coding.

Refactoring - Code improvement without changing behavior

Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code/design, yet improves its internal structure. When the software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure; once this inspection is done, then the results are analysed for getting a more improved design.
If you were to ask for a simple explanation, then code refactoring means that you 'clean up' the code. Refactoring is not meant to be used for changes where you added new functionality, or fixed bugs, or something similar. It is in principle used for analysing code to remove dead code, to make the code more understandable, and modify the internal structure and design (maybe to make the code more elegant, as well as to follow some standard code processes and layouts).
Why do refactoring ? The process intends to make code easier to read and comprehend, and also to be able to make modifications to it. Given the amount of time that code remains in-use, and with the people handling the code not remaining constant, it is important that the code be easy to understand and maintain. Sometimes people take on the task of improving the code in order to fix defects or solve other design issues, but that is not refactoring.
A common method used within refactoring is to change the definition of variables, such as when a non-meaning variable such as 'j' is instead changed to actually be closer to the real use of the variable, say 'ItemWeight'. This makes it easier for somebody else to quickly read the code and comprehend. This however, has its own set of complications since the same variable may be used in many different parts of the application, and the person making the modification may need to study each usage before making the change.