Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 548 posts at DZone. You can read more from them at their website. View Full User Profile

Consistency in the Code Base and Incremental Refactoring

05.06.2010
| 6420 views |
  • submit to reddit

I wrote a post a while ago about keeping consistency in the code base where I covered some of the reasons that you might want to rewrite parts of a code base and the potential impact of those changes but an interesting side to this discussion which I didn't cover that much but which seems to play a big role is the role of incremental refactoring.

In our code base we recently realised that the naming of the fields in some parts of a form don't really make sense and I wanted to start naming new fields with the new naming style and then go back and change the existing ones incrementally when it was a good time to do so.

Richard and Christian suggested that this wouldn't be such a good approach because it would make the naming issue even more confusing until all the fields had been renamed.

In order to avoid this problem we had to either go and change every single field to follow the new naming approach immediately or settle on the old names even though they might not be as descriptive.

Since doing the former would involve changing the names of around 15-20 fields across several different objects, in Hibernate mapping code, probably in the database, on HTML forms and in Watin tests we decided not to do that – the project is only for a short amount of time so the investment probably wouldn't be worthwhile.

Although in this case it makes sense not to make the improvement it doesn't strike me as being entirely satisfactory that we would need to make this type of change in a big bang fashion.

From my experience there are often insights into the code or improvements in the ubiquitous language as time goes on and while consistency is of course an important thing in any code base it's not the only thing.

When do we decide that actually gradually moving to a better approach is worth the temporary pain that having this inconsistency will cause?

From http://www.markhneedham.com/blog/2010/05/05/consistency-in-the-code-base-and-incremental-refactoring/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Eyal Golan replied on Thu, 2010/05/06 - 2:05am

well,

the first thing that poped up to my mind was "the broken window" rule.

whenever I see a  broken window, I fix it. So I guess whenever I see a bad property name, I should change it.

On the other hand, if it's a short / small project, maybe it doean't worth the effort. I

I can look at it differently: suppose I am a freelancer and I write my name in a comment in the  code, will I'll be hired afterwards?

In regard to the inconsistency, I think that this should not be a *big* consideration, as code evolve and eventually all property names will be changed.

Michael Eric replied on Wed, 2012/09/26 - 4:00pm

When we started to evolve our codebase we had exactly the same dilemma - with design approach more so than naming. If we figured out a better way to do something for feature number 2 compared to feature number 1 did we go back and change feature number 1? What if we were on feature numbers 10!

Figured that the best way is to accept that in an evolving design you are going to have code that doesn't quite live up to your current ideals. If all your devs have a good idea of the current 'ideal design' then design can be applied when you revisit the older code to add/change features. You have to rely on communication, awareness of evolving code and good test coverage. But how are those bad things...

ubuntu 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.