Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 544 posts at DZone. You can read more from them at their website. View Full User Profile

XP 2011: J.B. Rainsberger – A Simple Approach to Modular Design

05.12.2011
| 4442 views |
  • submit to reddit

After finishing my own session at XP 2011 I attended the second half of J.B. Rainsberger’s tutorial on modular design.

For most of the time that I was there he drove out the design for a point of sale system in Java while showing how architectural patterns can emerge in the code just by focusing on improving names and removing duplication.

The second half of the session was much more interesting to watch as this was when J.B. had set all the context with the code and we could start to see the points that he was trying to make.

These were some of the interesting bits that I picked up:

  • J.B. talked a lot about being able to detect smells in code both mechanically and intuitively. The latter comes from our general feel of code based on our experience while the former comes from following a set of rules/heuristics. He wrote about this earlier in the year.

    For example we might feel intuitively that our tests are unclear to read while mechanically we can see that there is duplication between our tests and code which is what’s leading to the unclearness.

  • By removing duplication from the point of sales example code we ended up with the MVC pattern albeit with the responsibilities in the wrong place e.g. the model/controller both had some logic that would typically belong in the view.

    I’m curious as to whether other types of code would naturally lead towards another architectural pattern without us noticing.

    It would make sense if they did seeing as patterns are typically extracted when people see a common way of solving a particular problem.

  • J.B. encouraged us to use long names to help us see problems in the code. For example naming something ‘priceAsText’ might help us see that we have primitive obsession which we may or may not want to do something about.

    It was interesting how using longer/more descriptive names made it easier to see which bits of code were similar to each other even though it wasn’t initially obvious.

  • I hadn’t heard of temporal duplication which was defined as ‘unnecessarily repeating a step across the run time of a program’.

    In the example code we were creating a map of bar code -> price every time we called the method to scan the bar code which was unnecessary – that map could be injected into the class and therefore only be created once.

  • J.B. described his 3 values of software which he suggested he uses to explain why we need to keep our code in good shape:
    1. Features – lead to the customer making money in some shape or form
    2. Design – we want to try and keep the marginal cost of features low i.e. we want to build a code base where there is a similar cost no matter what feature we decided to implement next.
    3. Feedback – we want to get the customer to say “not what I meant” as soon as possible since they’re bound to say it at some stage i.e. we want to reduce the cost of a wrong decision
  • He drew an exponential curve showing the cost of software if we only focus on features. It was interesting to note that if you finish the project early enough then it might not be such a big deal.

I think it’s very easy to dismiss the important of naming in our code because it seems so trivial.

After this session I can now see that I should be spending much more time than I currently do on naming and have much room for improvement.

 

From http://www.markhneedham.com/blog/2011/05/11/xp-2011-j-b-rainsberger-a-simple-approach-to-modular-design/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Zheng Dan replied on Fri, 2011/05/13 - 11:35pm

I think the naming is so easy for the English Speaking guys, but sometimes It is ambitious and unknown for me to naming the specific variable related to some professional domain!! so English Naming is still on the way

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.