Technology Cafe

This is review of the 11th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

In this chapter we go higher up and look at the software as a system- in whole. Just like clean code is important – so is the cleanliness of the system

In this chapter, Robert talks about Separation of concerns,  Dependency Injection and Cross cutting concerns.He also draws contrast between the EJB architecture (EJB1 to EJB3) and  Spring.

The biggest strength of Spring is- that when you never code for Spring. Spring adopts you rather than you adopting Spring.

AOP and AspectJ are also discussed along with Java Proxies. There are pretty powerful mechanisms to implement separation of concerns.

Its infeasible to design the whole system upfront. What works is small steps- keep room for improvement as things grow.

Robert concludes this chapter with a very sagely advice-

Use the simplest thing that can possibly work

For review of other chapters- please see this post.

This is review of the 9th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

Robert’s love for TDD is legendary and reflects so much in this chapter
He starts with stating the “three laws of TDD”

First Law You may not write production code until you have written a failing unit test.
Second Law You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
Third Law You may not write more production code than is sufficient to pass the currently
failing test.

If you want to have successful testing strategy based on Test Cases (whether you subscribe to the strict philosophy of TDD or not)- you have to treat test cases with same lover, respect and reverence as Production Code. Keep your test cases as clean as you keep Production code. All rules of cleanliness and Godliness that you apply on Production code are relevant to Test Cases as well.

Well- there are few exception like- you don’t have to kill your self to get the same performance as you would from Production code. (But at the same time- Test cases shouldn’t take too long to run:))

A unit test should ideally test only one concept – this is somewhat like the guideline we use for functions- do one thing alone.

And then you have the F.I.R.S.T rules.

Test should be Fast

Tests should not depend upon each other.

Tests should be repeatable in any environment

Test should have a boolean value- Pass or Fail

And they should be written in Timely fashion.

For review of other chapters- please see this post.