Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Kinda like performing surgery in the dark

Have you ever needed to make rule changes to an existing application?  I am sure you have.  Have you ever had to make these changes when you understand the change, but have pretty much no clue about the implementation of the code base you are changing?  This is kinda like performing surgery in the dark, hard to know if what you are doing is helping or hurting.

Making changes like this can be very dangerous.  If you don’t plan this correctly you may be up a creek without a paddle.

In my current situation I have been tasked to make some changes to an existing application where I have NO real experience in the code base, but I completely understand the changes needed.  However, the changes need to be made in 10-15 places and I no understanding of the ‘intent’ of the code I am changing.  My changes start at the data layer, go to the business layer and finally end up in the UI layer. 

In order to minimize my risk I have devised a plan of attack which I believe will reduce my risk and set me up for the highest level of success possible.

Steps:

  1. Create a new data access method. 
    This is needed because the signature of the data access is changing.  Doing this also allows me to change one area of the application at once.
  2. Implement the new data access method, but don’t implement the new business rules.  In my case this is possible, but may not be in all cases.
    This allows me to implement the new code without (in theory) changing the behavior of the application.
  3. Grab another member of the team who has extensive knowledge of the application and go over all points of contact for my changes.
    This allows me to have a knowledgeable sounding board for my up coming changes.
  4. Start making the changes one at a time, all the while trying to test the crap out of my changes (this project is not TDD, kinda sucks, but there are test for the data layer now)
  5. Hope, pray, wish upon a falling star that nothing I did broke things….  Guess we will find out when QA hits it L

 
I am pretty sure that if I follow the steps above I can make the changes with very little risk.  Now the downside to this is that it will be a slow process.  But when you task a inexperienced developer (in terms of knowledge on the given project) to make changes it will always be slower.

 

 


Posted 05-15-2007 10:53 AM by Derik Whittaker
Filed under: ,

[Advertisement]

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)