Friday, March 24, 2006

Does Code Duplication Have To Be A Bad Thing?

This is a bit of a crazy idea. I'm curious what anyone reading this blog might think about it...

The project I am currently working on validates the data coming from forms and imports in the domain. If you try to save a record with bad data in it, the domain will catch the error. The users also want irrelevant fields not to appear on the screen. A generic example would go something like this: Let's say you have a form which lets you enter a sales person's total sales for the month. If the sales exceed a certain threshold, then you can enter in a bonus. The back end of the system validates the bonus. It makes sure that you are not allowed to enter a bonus if the total sales are too low. The customer also requests that the screen not show the entry field for the bonus if the sales entered are too low. There are a couple of options I can think of: In one case, you drive the screen code from the domain validation logic. Otherwise you can duplicate the logic, e.g.

In the form code:

if (totalSales > MIN_BONUS_SALES) {
displayBonusField();

}

In the back-end domain code:

if (totalSales < MIN_BONUS_SALES) {
createNotEnoughSalesError();
}

This is bad because it means you have to maintain this logic in two places. What if the development environment allowed you to set up dependencies so you could still maintain the duplicate code, but the compiler would warn you if you changed code in one function and not the other? e.g.

In the form code:

@depends_on SalesPerson.validateBonus
if (totalSales > MIN_BONUS_SALES) {
displayBonusField();

}

In the back-end domain code:

validateBonus() {

if (totalSales < MIN_BONUS_SALES) {
createNotEnoughSalesError();
}
}


The point I'm making is that just updating both pieces of code isn't really a big problem, but knowing about all of the dependencies is. The normal way of dealing with it is to remove the dependencies and to develop a code framework that allows these ideas to be maintained in one place, but that can mean more work than one might want to do. I wonder if enabling tools to help manage code dependencies like this would be a viable option.

Saturday, March 04, 2006

Ruby and Rails

For the past few weeks I've been playing around with Ruby and Rails. I was somewhat hesitant at first, because I had heard such great things about Ruby and Rails. My natural reaction to that sort of effusive enthusiasm is to be skeptical. After all, the software development world seems to have an endless appetite for fads. Every time a new technology emerges, it promises to make programming easy and to solve the difficult problems that cause so many projects to fail, or at least to run into serious delays and cost overruns. However, at present I must say that I am quite impressed. It really does seem to be such a nice clean framework, and it really is easy to do stuff. One of the things I like best about it so far is that my code doesn't have to be instrumented with a bunch of dependencies on the rails environment. I can write a pure ruby class and it will just work with rails. If I want to persist to a database, I can take advantage of the object-relational mapping, but the framework seems to do a great job of staying out of my way. It's not
like J2EE where I can remember having to produce multitudes of classes and configuration data just to implement some trivial functionality. I am no expert on ruby or rails yet, but I must admit that I am pretty enthusiastic about the whole thing and hope to learn more as I go along.