More than One Frameworks Are Exist in One Product

What’s that?

Plenty of applications are exist in more than one era, chances are these kind of applications would have more than one frameworks in their application.

For example, Data Access Layer pattern has significant changes over the years. When I was writing my first .Net application in college, we were using SqlConnection directly in our UI , then on my first time in my professional career, I was introduced to Active Record pattern. Few years later, Data Mapper seems the make sense way to build Data Access Layer.

There! I have been introduced to more than three style of architectures in the relatively short period of time, how about if a product survives more than two or three years? than we are going to see a plenty of frameworks in there.

Obviously this leads to major confuse in maintenance. When developers need to fix or enhance in the old modules, they would see a different set of frameworks in there, which one to follow?

Reducing Integration Conflict by Check in and Get Latest Often

Interesting enough, for few recent years, I always see few people just refused to get latest often. They always complain about: “This is not get latest new code, this is get latest new problem” That’s happen because they felt that something just went broken everytime they get latest from source control, natural I thought.

But, that mindset would bring another set of problem itself. One of them is increasing integration conflict in the end of the development iteration.

Let say there is a changes in Data Access API, or Domain Model. These changes would have plenty effects in upper layers above them: facade, service, presentation, etc. If developers not get latest these changes early, they will continue to develop by the wrong code base for plenty of items, when finally developers decided to get latest, the error would be massive.

That can be avoided by get latest often, let say every morning, so that developers can detect early what are newer integration conflicts this time.

Why Using Dependency Injection

Basically I would use Dependency Injection to seperate between infrastructure and logic concern in my business logic class (or anything else). Example:

class TaxService { private ILogger _logger = null; public TaxService() { _logger = LoggerFactory.CreateLogger(this); } public void LogicA(object A, object B) { // Do important stuff here _logger.InspectStates(A); } }

At above code, I initialised _logger in the TaxService’s constructor. Although this is quite good enough rather than creating concrete ILogger implementation class, however, I found this inisialisation is somewhat distracting users from TaxService main intention.

Then, I can rewrite my above code to use Dependency Injection, so that TaxService shouldn’t have to know how to create _logger explicitly:

My Introduction with Automatic Unit Test

It was crossed my mind before, that creating automatic unit test is just wasting time activity because we need to create a test first, make sure our code is failing, before we can build up a code that should pass that test.

Like my friend always told me:  “asking people to use automatic unit testing, instead of manual testing, is just like to ask them to change their mindset of development”. Yap, it is in my mindset that I can do mental unit test toward my code , which is speedier rather than I need to write a unit test first.

But, after reading up Jimmy Nilsson’s Applying Domain-Drive Design and Patterns, I realized that I need unit test to make sure my code satisfied the requirement that it need to fulfill, and survive across refactoring processes.

Not to mention refactoring is just way too common thing to do in development phase (and maintenance), how can we be sure that our code is as good as it was?

Without Unit Test, we should test the refactored code manually, that’s hard.

Obviously unit test need to be built with very attention to detail, to make sure all requirements are there to test.

There … I change my mind again, I’ll use automatic unit testing from now on.

Tools are also widely available for this practice, my favourites are NUnit and Visual Studio Unit Testing.

Converted to Agile

I always a big fan of Big Upfront Design approach, whether that is RUP, MDA or even Waterfall methodology. I thought that is the most ‘make-sense’ approach, ever.

However, my last project shows the biggest problem with them: inflexibility to handle changes, not natural and too frigid. Although they are, obviously, still useful in many projects.

Now, in the next project, we are going to adopt Scrum methodology, since changes may be often to happen and we have luxury for having our client working with us in almost entire project duration.

I take my time to read Agile book, and I think this methodology is great in term of flexibility to handle changes. Can’t wait to practice it in the real world. (start on Monday, March 2, 2009 anyway )