Archive | refactoring RSS feed for this section

Making Too Much of TDD

The thing that fascinates me the most these days is where TDD and refactoring fall apart.  I’m most concerned with the “you can’t easily get there from here” problem. In a nutshell, it seems that incremental development of a design works fine until you confront stories which force you to change internal structure drastically to accommodate them.  A simple example would be something like a text editor.  You can march along very far maintaining a document as a single string before you encounter situations that make that representation impractical.

(Full Story: Michael Feathers’ Blog: Making Too Much of TDD)

Technical Debt: Refactoring vis-a-vis Starting Afresh

Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:

For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.

Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.
(Link: Technical Debt: Refactoring vis-a-vis Starting Afresh)

How FreshBooks secretly switched from php to rails

To stay on the safe side, FreshBooks decided to disguise the new Rails app to appear as though it was still the old PHP version. Thanks to Rails’ flexibility, this was surprisingly easy to achieve. The heart of the disguise is a single line added to a routes.rb file.

map.connect ‘:fake_filename.php’, :controller => ‘php’, :action => ‘dispatch’

This takes what appear to be requests for php files and sends them over to the PhpController controller. In the dispatch action, we lookup the “filename” that was requested and map it to an action and a controller to actually handle the request.
(Link: How FreshBooks secretly switched from php to rails)


Follow

Get every new post delivered to your Inbox.