Decomposing systems

Today I begin decomposing our system into separate components. I felt that I will have to do it sometime, but I was reluctant to do it because I never did it before.

What I learned thinking about decomposition is this:

• Never postpone things you have to do. Always remember - You have to do what you have to do.


• Castle.Windsor is great.
  

  
  Castle.Windsor is a IoC container (Inversion of Control), which helps build system from small components. I found it to be very simple, and easy to use.
  
  Now, as I have moved all generic controls and helper stuff from UI to Core, and concrete stuff from Core to UI, ia have 50 tests not running.
  
  Probably, most of them are ActiveRecord.InitializationExceptions, but anyway, unit tests again help me make good pace without worrying of damaging my system
  
  
  

  
  

The best part of Unit Testing

The best part of unit testing is that it gives confidence that the code is yet again maintanable!

Sadly, but my code is falling apart just at the moment. The parts that worked before are not working for some mysterious reasons. And the worst thing is that i discover those bugs by sheer accident!

I mean - there's no testers in our team. And there's no way the bugs can be found when they bring up, except unit testing.

When i write a unit test, i feel a very strong feeling, that my code is secured from future bugs, which pop out unnoticably. It gives me confidence, and allows me to further refactor and expand the system

Interesting Undo/Redo solution

A few weeks ago i found a very peculiar Undo/Redo solution here .

The way it was written surprised me. It even took me 2 or 3 minutes to get the idea how the code works :).

All the magic is hidden inside a UndoRedo class. The idea is that instead of creating your variables directly, you wrap them with UndoRedo class like this:

readonly UndoRedo name = new UndoRedo();
public string Name
{
 get { return name.Value; }
 set { name.Value = value; }
}

This solution is very interesting, but, from my perspective, it asks too much from the programmer. To use this UndoRedo mechanism you would require to rewrite all your classes, which needs capabality of UndoRedo.

What is more, you could not make TextBox undoable, without overriding the TextBox class. And of course we know, that some classes in M$ field are for some mysterious reason sealed, so you can not inherit.

But overall, the solution is interesting, and it does work :)

Unit testing is leaking into me slowly but constantly

Finally I start to embrace test-driven-development.

Whenether I fix a non-trivial defect, I first write a unit test to catch that error, and then fix the bug.

Even now, for example, I have to create a new command which creates a new contract for each student. Instead of writing immediatelly whole working code, I make a sketch of what my working code might look like, then I write unit test to test that my sketch code does not work.

Finally, (in a few minutes or hours) i implement the feature and the tests pass. Then I run all my tests (64 right now), and commit the code to svn.

That's my life.