Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Make Time to Refactor  : Page 3

Somewhere between bare minimal code maintenance and total system reengineering lies refactoring. It can be very difficult to get the organization behind refactoring, but if you pair refactoring efforts with new feature implementations, you can improve code extensibility and reliability without holding up progress.


advertisement
I advise that people starting the refactoring process establish a set amount of time that they feel comfortable adding to a project for the refactoring effort. It is better to establish the boundaries as a general rule up front, rather than to discuss it anew for each feature implementation. The amount can also be adjusted as the organization becomes more comfortable with the process and its benefits.

It's valuable to look at some different possibilities for refactoring and try to measure them against the three questions outlined above. Because I spend most of my time coding SQL, I have provided examples in that language. Each organization will have different methods of software development and technologies so these categories and measures will need to be modified appropriately.

Item Example Effort Needed Benefit Risk of Introducing bugs Suggested Approach
Poor syntax—Changes to the code to clarify it and improve readability. An example of this would be taking a bunch of If statements and recoding as a case statement. Very little. Badly written code can take much longer to understand than necessary and is frustrating to live with. Small—The key issue is whether the code (badly written or not) is understood. The chances of a bug being introduced can be minimized by having two people read the code that has been changed. This level of refactoring should always happen whenever the code in question is being modified anyway.
Changing an algorithm—Sometimes we discover that there is a simpler and clearer solution to the problem. Some common occurrences; a solution that uses procedural logic (i.e. processing one record at a time) instead of using a set-oriented approach. Another example is taking logic branches (i.e. if step =5 next step = N) and driving it via a table. Depends—The new method will need testing, the extent of which depends on the level of complexity. This is a more extensive re-factoring and can produce much simpler and cleaner code. Medium—We need to prove that we have identified the correct way of solving the problem. Emphasis should be on a simpler algorithm, not a faster one, unless performance is an issue. Weigh this possibility along with others that suggest themselves on the project.
Modularizing code—Often enough, the code is written as one chunk and could be broken down into smaller and more manageable sections. I've seen stored procedures that are well over five hundred lines. That's a lot of code to take on in one piece. Moderate—we are not necessarily re-writing the code, simply breaking it up into separate procedures or functions. Small pieces of code are much easier to modify and work with. The level of effort required supporting drops dramatically with well modularized code. Moderate—We are reshaping the code, but we are not necessarily rewriting it. Walk through the proposed restructuring before attempting it. Balance this opportunity with others on the project.
Modifying schema—As the business changes, we realize a way of modeling the data that better reflects the current business. This can be as simple as renaming some fields to better reflect their use to adding or dropping whole tables and or modifying the relationships between tables. Moderate—Can be higher if a significant data conversion is needed. A bad data model can lead to garbage data. It also significantly increases the cost of maintenance. Moderate to high—depending on the amount being changed and the data conversion required. Because of the risks associated with anything more than a trivial change to the schema, this needs to be well thought out and is typically only justified when the business has changed enough that the schema must change.



Putting it All Together
If you've successful evaluated the overhead for refactoring and made strategic decisions about where to tackle it and where not to, you will have a fairly simple process for driving your refactoring effort. Whenever you have a feature to implement, you simply identify the parts of the system that you need to modify and create a proposed design for the new feature. During this stage, with a little additional effort, you can:

  • Identify the candidates for refactoring among the areas that you need to modify for the new feature.
  • Assess the benefits, risks, and effort of each refactoring candidate. Your estimates will get better as you do more refactoring.
  • Throw out of consideration anything that increases the time of the project beyond the agreed-upon timeframe. Beyond that, the actual decision will depend on the details of each candidate. The team should agree on the targets and the intended benefit.

Once the refactoring is accomplished, evaluate whether you've met your goals. Is the code easier to read? Is the algorithm less complex? Is the schema more flexible or easier to query? While you will probably never revert to the previous version, this process will help you make more informed decisions the next time.



Joe Lax has spent the last 10 years working in various database environments and has been a practicing DBA on all versions of SQL Server from version 4.2 onward. Joe is also a MCSE and an MCT. Recently, he has started to learn Oracle, which affords him no end of fun. He can be reached at joelax@verizon.net.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date