The other day I saw a presentation at infoQ by Robert Martin (aka Uncle bob) on professionalism and ethics.

He gave a very colorful presentation on vast ranging topics on professionalism and software development.

His driving point was we as software professionals are ultimately responsible for what we deliver and that is code. There can be no valid excuse for sloppy work. It’s too easy to take refuge in tight deadlines and unreasonable managers.

I am also reading a book by him- Clean code , after Horea recommended to me. Though I have just read the first chapter so far- that seems to be  a promising read

One thing that didn’t resonate well with me was Robert’s views was on TDD.  I fully appreciate the benefits of Unit testing framework- but I found it difficult to reconcile with TDD as he explained it

As he explained- TDD has three laws

1) Do not write production code for which you do not have a unit test

2) Write only enough Unit test as is sufficient to fail the production code. And then stop.

3) Write enough Production code to pass the unit test. And then stop.

So as per this.. when you start coding on clean slate- you can’t start with Production code  (See rule #1) and so you start with Unit test- as soon as you write  a single line invoking production code which doesn’t even exist yet- you are done (Rule #2 kicks in at this point). In fact at this point you will get a compilation error !!! Now you move to Production code and write that class- then you stop- because you have satisfied the Unit test. See rule #3.

So practically – if you follow this discipline- you will be alternating between Production code and Unit test- like 30 seconds each. At any point you will write only few line of code at a  time- Production or Unit test

Whew !!!. This sounds extreme to me. Way too extreme actually.

These are my problems with TDD

1) How do you test for possible bugs in Unit tests ? write more Tests for that ?

2) The developer who coded a bug in Production code- why won’t he not introduce a similar bug  in Unit test

3) Unit testing is important- but how do you define that unit. Do we define each line as a unit- because that’s what we seem to be trying to do. I disagree that each and every line of code needs to be unit tested. Units can be more granule than a line of code

I think Unit tests are an excellent resource for preventing breakages and regressions and come in very handy especially before and after undertaking a  re-factoring exercise.

And then I came across another interview at InfoQ- . Now Luke Francl is speaking closer to what I think

He basically says that Unit testing is not end all means of software quality. He stresses a great deal on code reviews by peers, usability tests.

Oh well. I haven’t ever used strict TDD ever. Maybe some day…

 

Collection of resources on Database Deadlocks 

A) How unindexed foreign keys cause database deadlocks in Oracle

http://asktom.oracle.com/tkyte/unindex/index.html

B) What is a deadlock and causes- Oracle

http://www.oratechinfo.co.uk/deadlocks.html

C) Avoiding deadlocks

http://www.devx.com/getHelpOn/10MinuteSolution/16488

D) Definition of Locks , Blocks and Deadlocks

http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/blocking_deadlocks.html

 

This is the ‘eye’ of SOLID software design principles.

Definition:

Clients should not be forced to depend on methods that they do not use.

Alternate Definition (s):

The dependency of one class to another one should depend on the smallest possible interface

The idea

Consider two components- which interact with each other. The interaction between the two is defined by the API calls that one makes onto another. The component which makes calls to the other serves as the client.

The methods that the client can call upon the component serves as the contract between the two.This contract should be kept thin. It should have all that the client needs- and nothing more. Keep in mind- what the component exposes to the client is not limited only to the interface explicitly implemented by the component – but also included all the behavior inherited by that component from classes\interfaces up the hierarchy

Example of violation

Lets say I have  domain classes- PurchaseOrder, Appointment , Invoice etc. All domain classes  extend the same base class- DomainClass which contains common behavior.

All my domain class can be published to external entities. So we have a  method publish (). Now if we want to keep this behavior internal to these objects- i.e. only the domain classes will decide when its the time to be published- this method should be declared as protected. If we declare this method as public- all clients would have access to this method- if that was not the intention- we have violated the Interface Segregation Principle.

Another common violation is when we have an interface  say Animal with methods – run (); swim (); fly ()

And Classes – Fish , Horse etc.- all implementing the Animal interface

Now since flying is a behavior not exhibited by all animals- we provide a dummy implementation and throw and Error “NotSupported”. This is a voilation of the principle. You have exposed the method fly () to all clients of the class Horse when they didn’t even need it.

In fact – in a twisted sort of way – the Object class,the Parent of all classes in Java, is a violation of Interface Segregation Principle. All methods in Object are exposed to all clients.

The Benefits

This principle is important because it encourages two very important ingredients of a good software design

High cohesion – Keep all related methods together

Low coupling  – Keep dependence of one another to the bare minimum

Changes to fat interfaces tend to cause a ripple affect to classes who shouldn’t have been affected in the first place.

Credits

Read more about this from the Master , Robert Martin himself.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha