Don't forget to refactor

Recently I've been a mentor of Test Driven Development to my colleagues. I find it interesting introducing TDD to developers who've never followed the approach and finding what I take for granted having practised TDD for many years.

TDD can be summarized succinctly: 

• Write a failing test to demonstrate the required behaviour of the code
• Write code to make test pass
• Refactor 

(Thanks to Guido Maliandi for the diagram.)

I find that the last step is often ignored or is not taken as an equally important step by TDD practitioners. TDD detractors will often point to a lack of up front design and this stage is probably the culprit. I concede that if you pay no heed to design in TDD, you'll end up with a poor codebase. i.e. I've got a green bar, now I'll continue with my next test. That's why the refactoring stage is important if not the most important stage.

When you've got a green bar, you have made a step in the right direction but it's not the last step you should take. The presence of a working unit test gives confidence that the code can be refactored. When I perform the refactoring stage, I look for any code smells  I may have introduced. This is an important consideration as I find TDD newbies dither a lot on whether the code they have written is 'perfect'. The initial goal should be to get that green bar. Once you're there, then you can consider other issues during the refactoring stage. 

The refactoring stage should also be a point where you ask questions of your code at a wider scope:

• Does the code fit into the overall architecture?
• Does the code achieve non-functional requirements i.e. performance ?

The thing about writing tests before production code is that you end up without complex classes. The test you write forces you not to write a complex test with lots of stubs. As a result you will create small classes with only one responsibility. Your code will be decoupled, flexible and configurable. You don’t have to worry about S.O.L.I.D. principles. They will naturally emerge.

The refactoring stage is an often overlooked stage. Lack of focus on this stage leads to build of code entropy resulting in technical debt that will eventually need to be repaid. It should be kept in mind TDD is not mainly a testing strategy, but a design strategy. The tests written first results in a better decoupled design. A better decoupled design in turn is easier to refactor. A case of positive reinforcement.  The code will also be easier to maintain and add new features should they be needed.

JAX London 2011

As a member of the London Java Community, I was gratified to hear of a Java conference, JAX London, on my own doorstep and eagerly signed up. It had been a while since I've attended a Java conference. I used to be a regular attendee of JavaOne but over the last few years, it has lost its lustre, especially now as it seems to be a bolt-on to Oracle OpenWorld. Maybe that'll change in future.


Day 1:

I eschewed the workshops on Android and JEE6/7 development in favour of talks focused on Spring technology. There were some excellent talks given on the new additions to Spring such as Spring Data as well as the upcoming functionality in the next version of Spring. There were also some good introductions to Spring Batch and Spring Security. A talk was also given on the interoperability of Spring and Scala which was informative on the use of Java DI frameworks with Scala rather than using inherent Scala approaches (see Cake pattern).

The most useful session in my eyes was the round table discussion at the end of the day in which the audience were allowed to ask questions to the Spring creators themselves. This was especially fruitful as you gain those nuggets of wisdom from these experts in their fields which you wouldn't normally get if it wasn't a vis-a-vis conversation.

Day 2:

My second day at the conference was mostly Agile focused. I attended a very good talk on the Scrum Product Backlog by Roman Pichler of which many salient points of advice were offered.

The next talk addressed software quality. The first talk on Software Craftmanship by Sandro Mancuso. This talked reinforced the idea that software development is a craft rather than purely engineering. He extolled the principles of the Software Craftsmanship movement, promoting self-improvement, knowledge share, professionalism, passion and care.  I resisted the urge to jump up from the audience and shout 'Amen brother' but that was what I was thinking. The next talk titled Slow and Dirty by Jason Gorman refuted the notion about that we should release code dirty due to unrealistic deadlines and worry about the clean up later. One of his memorable phrases was 'Anaerobic Software Development'. I'm sure a lot of developers will concur with this sentiment. This describes situations where development teams start projects at an unsustainably fast rate, causing entropy in their code to build up. This causes intense pain after a short while which results in the team having to stop for weeks, maybe months until enough detritus is removed so the project can start moving forward again. If you're lucky that is, sometimes there's so much build up (holding back on the profanity :)), that the project must be dropped entirely and a new one must be started. His guiding principle was that if you care about quality all of the time then you don't get into these situations. Next time a manager, tells you we need something quick and dirty, cut corners on quality, to get something out of door, you should be prepared to push back as much as possible. You're only making a rod for your own back and building technical debt which must be repaid later.

Given my interest in concurrency, the next session I attended was on message passing by Dr Russell Winder who opined (with many interesting, witty and funny anecdotes) about why the shared memory multithreading, the prevailing wisdom of currently popular languages should not be used. Instead they should be replaced by higher level constructs such as Actors, CSP and DataFlow so that issues seen in contemporary approaches are eradicated. He then gave a demonstration with Actors via the GPars library of which he is the author. The 50 minute talk did not allow him to give a fuller treatise of the subject but it has definitely piqued my interest in that library for further investigation.

The last session of the day was giving by Martijn Verburg and Ben Evans on some of the new features of Java 7. They then delivered an open coding session on some of the features of Project Coin. Unfortunately for me, this turned out for me to be a thought experiment as I didn't bring my laptop to the session, although I did get to ask Martijn some questions on some of the new concurrency features in Java 7.

Day 3:

In my previous blog, I opined about whether had Java had reached its peak. I may have to revise my opinion somewhat after two excellent keynotes from James Governor of RedMonk and Simon Ritter of Oracle. The latter reinforced my view that the really interesting stuff will happen in Java 8 with respect to lambdas and modularity. It was also interesting to see Oracle's roadmap for Java in that they intend to release a new version of Java every two years. The roadmap given was up to 2019. Wonder what Java will look like then?

Fredrik Öhrström of Oracle then gave a very informative talk on some of the expected features in Java 8 specifically lambdas, map filter reduce and interface extensions. Following the takeover of Sun by Oracle, there are now two competing JVMs i.e. JRockit and Sun Hotspot. There is now a plan is for JRockit functionality to subsumed into Hotspot VM with the non-enterprise JRockit features to be added later incrementally.

The next lively talk on Performance Tuning resulted in a well known adage, 'Measure don't guess'. The presentation centered on a mal-performing web application. By measuring the throughput and load using different tools such as JMeter, VisualVM and vmstat, they showed how to investigate and eventually find the culprit. One should never shoot in the dark when performance tuning.  A scientific approach should be followed such as baselining your application before any measurements are made so as to ensure that any changes actually lead to an improvement rather than degradation.

I then attended another talk on Java 8 concurrency giving by Martijn Verburg and Ben Evans advocating the use of Java concurrency library rather than relying on outdated constructs such as using synchronized. They also gave an on why parallelism will become more important in the upcoming years.

Changing tack for a few sessions, I then attend Ted Neward NoSQL session. This was a talk on what NoSQL actually meant as there's a lot of ambiguity in the community on this fundamental point. He then compared some of the common NoSQL variants such as db40, Cassandra, MongoDB and the typical situations where they could be used, a point sometimes missed. Use the right tool for the right job. Ted Neward is a great communicator and the session was enlightening in all respects.

The final session of the day was given by LMAX on their Disruptor Pattern. This was very interesting in many ways, as it seemed to go against the grain of previous sessions on concurrency. LMAX is a financial exchange so latency throughout their system is extremely critical. Through empirical evidence they demonstrated that accepted approaches to concurrency were non-performant due to the overhead of dealing with the JVM and JMM. This was especially interesting as being a Java programmer we're shielded from the low level details of the architecture your program is running on and assume that we need not worry about it too much as it's the JVM problem not mine. This is no longer the case. We know have to be increasingly wary of latencies between the processor, the L1, L2 caches etc and the main memory, as well as the JIT assembly code, a mechanical sympathy if you will. Their innovative solution rests on using a lock free ring buffer (the fundamental data structure at the heart of the Disruptor) rather than using the traditional work queue/thread approaches. I've not really given the Disruptor pattern the attention it deserves, as it really is a sea change in how applications could be architectured both from a business logic and data point of view. I will definitely be doing some investigation on this topic. There is a great introduction to this given by Martin Fowler and it's also advantageous that the Disruptor is an open source project.


Last thoughts:

Sadly though there were at least 10 other sessions I would like to have been at. I would have loved to followed Ian Robinson's session on Neo4J as well as attended some of some of the cloud offerings (some former colleagues of mine from Cloudsoft were presenting) but alas the timetable didn't allow me the opportunity. All in all, a feature packed 3 days which ended far too quickly. It's great to meet a lot of kindred spritis who were as passionate about technology as I am. I'm already looking forward to JAX 2012 :).

Peak Java?

Has Java peaked? To me the Java 7 release feels like it did when Java 3 came out; some gravy no meat. It's not a ground breaker as the evolution from Java 1.1 to 1.2 or when Java 5 was released. Sure there has been some nice language improvements but for me, Java as a language has pretty much stabilised. These new syntactical changes are just glossing over pain points for which they are ample (although sometimes arduous) workarounds.


The big changes I see in the future in Java 8 are the Java Module System (JSR 277) and Closures (JSR 335). The latter is needed to make Fork/Join more useable. Closures may have made a bigger impact a few years ago, but now with a plethora of other JVM languages, I feel this will no longer be the case.


What's becoming increasingly apparent is the increasing importance of  Java platform. The important thing is not the Java language itself but the JVM.  This acts as a substrate for different languages. Although from above the languages may seem different, it ensures that underneath the covers the the behaviour is consistent.


Some examples of JVM languages which have gained traction over the last few years are:

• Scala
• Groovy and its statically typed cousin Groovy++ (A great article outlining it's usefulness http://groovy.dzone.com/articles/sneak-peak-groovy-what-it-why)
• Clojure
• JRuby

And we have some new kids on the block:

• Ceylon, Red Hat's Java competitor
• CAL, a Haskell-inspired functional programming language.
• Gosu (programming language), an extensible type-system language compiled to Java bytecode.

Maybe Java has reached its peak. It's certainly looks like it reached its plateau. I'm looking forward to using Java 7 and 8, but for the JVM improvements only. The platform matters more than the language now.

Using generics with a fluent API

I've recently worked on an integration project requiring a message API.  It was to be responsible for building messages of various types to be sent on a variety of transports. Each message had numerous parameters but some were only used in particular contexts. This meant that frequently you'd get constructors where some of those parameters had to be set to null to indicate they were not to be used. This is a code smell. One solution would be to use the refactoring 'Introduce parameter object'. This refactoring is used to group parameters together into immutable classes so those parameters have a common context.  This may alleviate the problem somewhat but in practice I found this resulted in several overloaded constructors each with different combinations of parameter objects. I needed another solution.

I've had some success in the past using fluent API with builders. A fluent interface is implemented by using method chaining to relay the instruction context of a subsequent call. My expectation was to create something like:


Some parameters were common to all message types so it made sense to have these in a base class.

The message base class:


and it's associated builder:


I then subclassed the builder class to create the specialized message types. For brevity most parameters have been omitted.

An example of a specialized message class with inherits all the properties of the base class along with its own parameters.


The builder for this class:


However to get the expected usage of:


I've had to subclass all withXXX methods from the Message base class. In this example, it's not too painful as there's only a couple of common parameters but more realistically I could have numerous parameters which means for each specialized subclass I need to override those methods. This approach quickly becomes unwieldy and a maintenance headache. To make sure that method chain returns the correct type I've had to resort to calling the super method and then return the correct type i.e this. Not very good.What I needed was for each subclass to inherit the super class methods implicitly but with the proviso that they return the actual type not the super type.

A solution is to use Self Bound GenericTypes.  Angelika Langer gives a good explanation which she calls the getThis() trick.

The base MessageBuilder class has been changed to use self bound generic types. So for example, instead of hardwiring withId() to return the type of the builder that defines it,  a type parameter B is introduced and  withId() returns B via the abstract self() method. This self method implemented in the subclass to return the concrete type rather than the base type of the builder.  The self-referential definition MessageBuilder<B extends MessageBuilder<B>>  allows the return type of the inherited withId() in RequestBuilder to be RequestBuilder rather than MessageBuilder.



Now all the subclass has to do, in addition to its own fluent methods, is to provide an implementation of the self() method. Job done.


In this way, subclasses for builders only need be concerned with providing fluent methods for the parameters pertinent to that class. They will automatically inherit fluent methods from the super class so no overriding is required and the intent of the class is clearer.  I can build up that message's fluent methods to set the parameters I actually need for that particular context without resorting to long unwieldy parameter lists. Again the intent is clearer. Result !

Thanks to a bit of tinkering, this solution seems elegant and understandable now but as usual with generics it'll be mostly incomprehensible tomorrow :).

Links

• http://martinfowler.com/bliki/FluentInterface.html
• Angelika Langer's Generics FAQ

A comparison of FDD and Scrum

FDD and Scrum are two examples of agile development methodologies. Agile development tries to avoid the main weakness of "waterfall" by doing iterative development. Each iteration is meant to be short (1-2 weeks) and includes all of the following steps.

• Gathering user requirements
• Design and documentation
• Development
• Testing
• Deployment

This guarantees that design errors are discovered at early stages of development. I've had experience on working on projects using both methodologies and it was interesting to compare the salient features of both approaches.  Before the comparison, a short overview of each practice is given.

Feature Driven Development
Feature Driven Development, FDD  is an agile software development methodology by Jeff De Luca and Peter Coad.  It has more formal requirements and steps than Scrum from a development perspective.

 

FDD consists of five high level activities:

• Develop an overall domain mode
• FDD advocates light modelling up front to understand the shape and scope of the application.
• Build a list of features
Team builds a feature list.  Each feature represents 1-10 days worth of effort.  
A feature is a small piece of client-valued function expressed in the form: <action> <result> <object> i.e. Calculate the total of a sale
• Plan by feature
• Features are then assigned to iterative release cycles.
• Developers are also assigned to own particular classes identified in the domain model by a chief programmer.
• Design By Feature (DBF)
• Feature teams are assigned to a set of features and proceed to the design in detail i.e. sequence diagrams 
• Build By Feature (BBF)
• Those teams then carry out the code development and testing of those features.
• When chief programmer is satisfied then completed features are promoted to the main build.

FDD utilizes chief programmer, inspections, and class ownership. The chief programmers function as team leaders, mentors, and reviewers. While the term chief programmer may suggest micro-management and control, FDD teams stress the collaboration and knowledge sharing roles.


Progress and can be tracked and reported with accuracy by assigning a percentage weighting to each step in a DBF/BBF iteration The chief programmers indicate when each step has been completed for each feature they're developing. This enables a view on how much of a particular feature has been completed.  The cycle repeats itself either by refinement of the original domain model and subsequent activities or until all the features in the list have been built.

Scrum

Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering. Essentially Scrum boils down to the following points (from Scrum Alliance):

A tomato a day keeps the defects away

Recently I've been getting some odd stares from people passing by my desk. This was because on my desktop I have a large stopwatch prominently displayed in my work environment. This was not a brazen attempt to count down the hours until  I could go home. I was following a recommended practice to break my work patterns in order to increase my productivity.

A good technique is to take brief but regular breaks. I can sometimes fall into the habit of focusing on a problem too much to the detriment of other things, sometimes even forgetting to take lunch until much later in the day. 

A solution is to adhere to the Pomodoro Technique  which means tomato in Italian. In this approach, team members work in 30 minute increments. At the start of the increment, a timer is set for 25 minutes. The team works diligently during that time without distractions. Those emails and phone calls can wait. When timer goes off, then team takes a five minute break at which they can walk around, stretch etc. However that time should not be used to talk shop. It really is a break from work. When that break is up, you repeat the process. Every fourth Pomodoro you take a longer break i.e. 15 minutes.

• Choose a task to be accomplished
• Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
• Work on the task until the Pomodoro rings
• Take a short break (5 minutes is OK)
• Every 4 Pomodoros take a longer break

Although I still a Pomodoro newbie, I’ve found it useful to focus my work into manageable slices. As a Scrum practitioner, I can focus on a particular story and finish a task within a single increment. I've become accustomed to breaking a story I’m working on into several small tasks. I'm a big fan of Pivotal Tracker. In Pivotal, I can decompose stories into tasks, each of which are easily understandable and trackable so I can gauge my progress.

Normally if one was following Pomodoro you would have a physical kitchen timer on the desk but I’m a techie, I’ve found there are numerous online alternatives. A good one is http://tomatoi.st/bcdg.

JUnit Theories to the Rescue

I recently developed a restart manager to respond to JMS connection outages. After the connection was restored, I needed to reinitialize my message clients in order for them to rebuild their JMS sessions. But I needed to test that a restart only occurred for particular status transitions. At first I thought this would be an onerous task as I would have to work out all the status permutations. That is until I came across JUnit Theories.

JUnit Theories
Theories allows one to write tests that apply to a (potentially infinite) set of data points rather than having to recreate the same test multiple times with different data or creating one test and iterating through your own collection of data values.
Here is an example:

Messaging client
First off is the interface for the messaging client. It has two lifecycle methods, start and stop which are self-explanatory, as well as methods for reading and sending a message which for brevity are just strings.
Status Enum
The following enum represents the status of the JMS connection. As can be seen there are numerous states so it would be cumbersome to work out all the possible combinations for each status transition. This is where Theories become so useful. More of that later.

Restart Manager
This class is used to restart a message client when it recognizes a status transition from FAILED to STARTED.
Test class
Finally here's the test class. Notice I'm using mock objects here using Mockito. As I'm programming to the interface of the messaging client not its implementation, I can make use of a mock and verify its behaviour.  Presently as of JUnit 4.8, theories is still within an experimental package.
The most important bit of configuration is @Datapoints annotation. This sets up the data that'll be pass into the test methods. In this test I have two theory methods. One theory checks that the message client is restarted when there is a suitable status transition i.e. FAILED to STARTED. Another theory checks that the message client is not restarted if the status transition is not suitable. i.e. not FAILED to STARTED.
When you run the tests you'll find the all the combinations of the Status enums are passed to the test methods in question as shown below:
In this way, I ensure that all possible transitions are covered by my unit tests and the restart manager's behaviour is as required.
Conclusion
The use of theories allows tests to be devised that cover all possible combinations of data. This is in contrast to parameterized tests where the dataset to be passed to a test is strictly defined and the onus is on the developer to work out what data is needed for a particular range of tests. Each approach can be used in different situations as dictated by your requirements.