Click here to Skip to main content
15,559,342 members
Articles / Desktop Programming / WTL
Technical Blog
Posted 25 Aug 2010

Tagged as

Stats

15.6K views
7 bookmarked

Refactoring: What’s the origin of bad design?

Rate me:
Please Sign up or sign in to vote.
4.00/5 (3 votes)
25 Aug 2010CPOL3 min read
What’s the origin of bad design?

Refactoring is defined as the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

Refactoring improves the quality of application design and implementation, but unfortunately the expression “If it is working, don’t change” is many times used to bypass it.

We can find in general three cases concerning refactoring:

  1. Iterative refactoring: Each application can’t be developed perfectly in the first iteration without any feedbacks, even if the team has the best of the architects, designers and developers. The easy way to do refactoring without investing a lot of money and without wasting time is to integrate it in the development process and do it after each iteration.
  2. Refactoring when is necessary: After the application is deployed, there are some feedbacks and bugs, if resolving them take a lot of time or some client needs are very complex to develop and integrate to the existing system, a refactoring can be a good solution to improve the quality of the code base, but in this case it can be very risky and we have to take care to avoid regression in the existing code.
  3. Not refactor: Sometimes even if there are many problems in the existing application, a refactoring is never begun, because the boss does not want to invest in this process, and the support team has to manage the stress generated by all bugs and feedbacks.

Which Factors can Influence the Quality of Design and Implementation?

To avoid investing a lot of money and time when refactoring, the good solution is to design the application well, but there are some traps that can influence the code quality:

No architect and designers in the team

Unfortunately there are some projects initiated with only developers, and no architect is present, the problem is that we can discover this misconduct very early and it can contribute of the project failing.

Prototype

A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.

Unfortunately many projects are based on the prototype without any review of architecture, design and implementation, and this trap is due to the rapidity of development and the team thinks that’s a good solution to continue with a prototype to gain time.

Frameworks used

Some frameworks provide useful classes but can influence the design too, for example MFC or Qt are intrusive frameworks.

Using some bad designed functionalities of such frameworks can influence to complicate the design of project, let’s take as example the Doc/View design provided by MFC, if a designer chose to consider CDocument as the model as encouraged by the MFC documentation, it will be a bad choice.

The model must be independent of MFC to be used in other contexts easily; however CDocument can be used as controller.

Technology high coupling

Some architects and designers forget the low coupling concept, and propose a high coupled design with the technology or the frameworks used.

For example, if CORBA is used for a distributed system, it must be isolated in the communication level, and all other classes must be CORBA independent.

Unfortunately in some projects, we can find CORBA types used also in the business classes and it complicates the application a lot.

In my opinion, this problem is the most popular and the very dangerous one; it has an enormous impact especially for C++ projects. Indeed currently finding a good C++ developer is not very easy, and finding one who masters many technologies and frameworks become very hard, so creating a high coupling application with technology used implies that all the team must know it, but if the application is low coupled with technology, it will facilitate the human resource department task and they can find easily C++ developers.

Your experience is very interesting to identify the bad design origin, for that you can vote to identify each factor is the most responsible.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior)
United States United States
CppDepend lead developer.

Comments and Discussions

 
GeneralMy vote of 2 Pin
Aescleal27-Aug-10 21:26
Aescleal27-Aug-10 21:26 
GeneralRe: My vote of 2 Pin
Issam Lahlali28-Aug-10 2:06
Issam Lahlali28-Aug-10 2:06 
GeneralRe: My vote of 2 Pin
Aescleal28-Aug-10 12:25
Aescleal28-Aug-10 12:25 
GeneralRe: My vote of 2 Pin
Issam Lahlali28-Aug-10 12:50
Issam Lahlali28-Aug-10 12:50 
GeneralRe: My vote of 2 Pin
Aescleal28-Aug-10 13:46
Aescleal28-Aug-10 13:46 
GeneralRe: My vote of 2 Pin
Issam Lahlali28-Aug-10 14:01
Issam Lahlali28-Aug-10 14:01 
GeneralRe: My vote of 2 Pin
Aescleal31-Aug-10 8:35
Aescleal31-Aug-10 8:35 
GeneralRe: My vote of 2 Pin
Issam Lahlali31-Aug-10 9:09
Issam Lahlali31-Aug-10 9:09 
You are right , but you describe only one kind of iteration , the iteration when developing a specific task, and to explain why you need refactoring here's a description of what happen in the real world:

- The client submit its specification.
- after developping its needs , a version is released, maybe after 2 weeks, 1 month or more , it depends of project and how the team manage the project.
- the client receive a version but can have many many feedbacks, and maybe the version dont satisfy their needs, and in general it's not because the developement team didnt develop well the needs, but many misunderstanding happen in general between client and company developing the product.
- and here we have two choices , the first one is let the design without any refactoring and try to resolve all client feedbacks , and the second choice is to take into account all client feedbacks and do a refactoring.

in your case you talk of micro refactoring , where we have all informations to master what hapen in the Time T, and its a good choice, but in the real world in many other cases we didnt have all informations and we need some feedbacks especially from clients and final users , and here a refactoring is needed before developing other features.
GeneralRe: My vote of 2 Pin
Aescleal31-Aug-10 10:35
Aescleal31-Aug-10 10:35 
GeneralRe: My vote of 2 Pin
Issam Lahlali31-Aug-10 10:44
Issam Lahlali31-Aug-10 10:44 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.