Code refactoring

I have worked on green field projects / product which starts from scratch. I enjoyed every stages of software engineering in such project. But that is not the case with working on existing code.

Most of the times I had the busiest schedule working in office on week days and travelling and teaching in weekends. So I have to find opportunity for learning in office work. I started digging more information about the project and have put extra hours to find the improvement areas. One of the most entertaining work in software engineering is designing and refactoring. In the last 8 years, whichever the code I have touched, focused on improving the quality of the code and design. That's one area I would like to work.

Here I am taking you to the shortcuts for refactoring.

Stage 1 :

1.  Move all the hard coding string to constants or resources. Move UI constants to resources. 

2. Move the configurable values to app.config or json or xml or text file. I generally keep the structure in json.

3.  Keep methods short : Breakdown the larger methods into smaller methods and taking care of single responsibility for methods.

4. Find out the reusable code and write new methods for the reusable code and remove the duplicates.

5. Remove unwanted and commented code.

6. Use ghostdoc for proper comments.

7.  Rightclick on CodeFile and Click Organize Usings  => RemoveUnused usings.

8.  The red, green, refactor approach helps developers compartmentalize their focus into three phases: 

• Red — think about what you want to develop. 
• Green — think about how to make your tests pass. 
• Refactor — think about how to improve your existing implementation.

9.  Single responsibility for classes.

•  A class should do only one responsibility. 
• If a class doing multiple things, then breakdown into multiple classes.
• Make sure a file has only one class too.

10.  “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." We should write our code such a way that without modifying the existing code, we should add new features.

11. All the business implementation should have interfaces. Interfaces should be small and specific (Interface Segregation principle).

For example there can be different kind of driving system in Metro. There will be common driving features which can be a general driving system. For manual system, there might be few different additional functionalities. 

public interface GenericDrivingSystem {     public void Func1();     public void Func2(); } public interface ManualDrivingSystem : GenericDrivingsystem {     public void Func3(); }

Suppose we want semi-automatic driving system where we need to do few more functionalities like sending message to different units and get the updates. public interface SemiAutomaticDrivingSystem : GenericDrivingsystem {     public void Func4(); }

Similarly, we have automatic driving system which does everything done by SemiAutomaticDrivingSystem with few more functionalities. public interface AutomaticDrivingSystem : SemiAutomaticDrivingSystem {     public void Func4(); }

 12. For implementing Microsoft unity framework or any other framework for dependency injection, first understand the control flow and start creating the controllers for every layer which is the entry point for that layer.

Example I created the entry point for BL,DAL, Domain Layer. The repository pattern is the best way to have unit of work pattern implemented.

13. Application control flow should be dynamically changed as per the strategies. (Strategy pattern and Liskov Substitution Principle)

14. Implement Dependency Inversion which states that "High Level Modules should not depend on Low level modules but both should depend on abstraction."

That means consider class Car. Car has Engine, Now if Engine changes, the functionality of the car should run as expected. So we generally define low level modules with interface or abstract class.

References :

Sold Design Principles

https://stackify.com/solid-design-open-closed-principle/