Unfortunately many developers think they already know enough values and principles, so its not worth spending anytime learning or practicing them. Instead they want to learn the holy grail of software design – “the design patterns.”

While the developers might think, design patterns is the ultimate nirvana of designing, I would say, they really need to learn how to think in their paradigm plus internalize the values and principles first. I would suggest developers should focus on the basics for at least 6 months before going near patterns. Else they would gain a very superficial knowledge about the patterns, and won’t be able to appreciate its true value or applicability.

Any time I get a request for teaching OO design patterns, I insist that we start the workshop with a recap of the values and principles. Time and again, I find developers in the class agreeing that they are having a hard time thinking in Objects. Most developers are still very much programming in the procedural way. Trying to retrofit objects, but not really thinking in-terms of objects and responsibilities.

Recently a student in my class shared that:

I thought we were doing Object Oriented Programming, but clearly its a paradigm shift that we still need to make.

On the first day, I start the class with simple labs, in the first 4-5 labs, you can see the developers struggle to come up with a simple object-oriented solution for basic design problems. They end up with a very procedural solution:

• main class with a bunch of static methods or
• data holder classes with public accessors and other or/er classes pulling that data to do some logic.
• very heavy use of if-else or switch

Its sad that teams don’t understand nor give importance to the following important OO concepts:

• Data and Logic together – Encapsulation (Everyone knows the definition of encapsulation, but how to put it in proper use, is always a big question mark.) Many developers write public Getters/Setters or Accessors by default on their classes. And are shocked to realize that it breaks encapsulation.
• Inheritance is the last option: It is quite common to see solutions where slight variation in data is modeled as a hierarchy of classes. The child classes have no behavior in them and often leads to a class explosion.
• Composition over Inheritance – In various labs, developers go down the route of using Inheritance to reuse behavior instead of thinking of a composition based design. Sadly, inheritance based solutions have various flaws that the team can’t realize, until highlighted. Coming up with a good inheritance based design, when the parent is mutable, it extremely tricky.
• Focus on smart data-structure: The developers have a tough time coming up with smart data-structure and putting logic around it. Via various labs, I try to demonstrate how designing smart data-structures can make their code extremely simple and minimalistic.

I’ve often noticed that, when you give developers a problem, they start off by drawing a flow chart, data-flow diagram or some other diagram which naturally lends them into a procedural design.

Thinking in terms of Objects requires thinking of objects and responsibilities, not so much in terms of flow. Its extremely important to understand the problem, distill it down to the crux by eliminating noise and then building a solution in an incremental fashion. Many developers have a misconception that a good designs has to be fully flushed out before you start. I’ve usually found that a good design emerges in an incremental fashion.

Even though many developers know the definition of high-cohesion, low-coupling and conceptual integrity, when asked to give a software or non-software example, they have a hard time. It goes to show that they don’t really understand the concept in action.

Developers might have read the bookish definition of the various Design Principles. But when asked to find out what design principles were violated in a sample design, they are not able to articulate. Also often you find a lot of misconception about the various principles. For example, Single Responsibility, few developers say that each method should do only one thing and a class should only have one responsibility. What does that actually mean? It turns out that SRP has to do more with temporal symmetry and change. Grouping behavior together from a change point of view.

Even though most developers raise their hands when asked if they know code smells, they have a tough time identifying them or avoiding them in their design. Developers need a lot of hands-on practice to recognize and avoid various code smells. Once you learn to recognize code smells, the next step is to learn how to effectively refactor away from them.

Often I find developers have the most expensive and jazzy tools & IDEs, but when you watch them code, they use their IDEs just as a text-editor. No automated refactoring. Most developers type “Public class xxx” instead of writing the caller code first and then using the IDE to generate the required skeleton code for them. Use of keyboard shortcuts is as rare as seeing solar eclipse. Pretty much most developers practice what I call mouse driven programming. In my experience, better use of IDE and Refactoring tools can give developers at least 5x productivity boost.

I hardly remember meeting a developer who said they don’t know how to unit test. Yet time and again, most developers in my class struggle to write good unit tests. Due to lack of familiarity or lack of practice or stupid misconceptions, most developers skip writing any automated unit tests. Instead they use Sysout/Console.out or other debugging mechanism to validate their logic. Getting better at their unit testing skills and then gradually TDD can really give them a productivity boost and improve their code quality.

I would be extremely happy if every development shop, invested 1 hour each week to organize a refactoring fest, design fest or a coding dojo for their developers to practice and hone their design skills. One can attend as many trainings as they want, but unless they deliberately practice and apply these techniques on job, it will not help.

If you’ve inherited a Legacy Project (project without any tests) and say you want to enhance an existing feature, where do you start?

In such situations, I find myself building some form of workflow tests (scaffolding). I start off using a record and play back testing tool to record couple of scenarios for the feature, I want to enhance. Most often, I would take the recorded tests and covert them into a re-entrant, independent scripts. So that I can execute them over and over again, without needing manual intervention. Basically this would mean, automating the set up and tear down of the application’s external dependencies like data-stores, email servers, etc correctly. This should not take more than a couple of hours to configure.

This helps me build the initially safety net to start off. This also gives me a decent understanding of how the feature works. Now I can go inside the code, change something really small and see what impact it has on my tests. Some times I tweak my test to see what impact it has on the feature. Basically I’m using this test as a probe to gain deeper understanding of the feature’s functionality.

Doing this give me some confidence to jump in and start refactoring the code, so that I can create an inflection point, break dependencies and start writing unit tests around the core of my feature. In couple of hours, I should be able to build a solid safety net, around my feature using unit tests and/or business logic acceptance tests.

At this point, I almost always, go and delete the initial workflow test that I had built. This is the reason, I call this approach as the scaffolding technique.

• Build some initial workflow tests to help you get in there,
• Make the necessary code/config changes to write direct tests
• Gradually build a solid safety net around the feature
• The scaffolding (initial workflow tests) did its job, now its time to throw them away

Intent

Provide the participants with a hands-on-experience of real world refactoring by taking an open source project and refactoring it.

Summary

Refactoring is a very well established practice not just in the Agile Community, but outside as well. Following are some of the books that have been published on this subject:

• Refactoring: Improving the Design of Existing Code: Martin Fowler
• Refactoring to Patterns: Joshua Kerievsky
• Working Effectively with Legacy Code : Michael Feathers

Unfortunately, in-spite of such great knowledge available, there are lots of misconceptions around refactoring. The word “refactoring” is often used in a broad context where “enhancement” or “rewrite” would be a better term, and can cause nightmares to project stakeholders.

This session is an attempt to help the development community understand refactoring a little better. It will provide a hands-on opportunity for developers to explore these concepts in action. This session will try to amplify the participant’s learning process by pairing them with other practitioners and peers.

Slides

http://www.slideshare.net/nashjain/refactoring-fest

Intended Audience

This session is suited for developers and architects who are interested to learn how to refactor real projects.

Benefits

After attending this session, the participants should be able to:

• Build a common vocabulary in the refactoring space
• Identify code smells
• Eliminate code smells by applying the simple refactoring techniques explained in Martin Fowler’s “Refactoring”
• Write better unit/functional tests for legacy code
• Understand some of the techniques and pitfalls in refactoring legacy code in the absence of unit and functional tests [“Working effectively with legacy code “]
• Take existing code and refactor it to standard design patterns [Refactoring to patterns]
• Learn about the internals of the open source project chosen to refactor
• Know where to look to continue learning the techniques of refactoring

Content Outline

Section 1 – 90 Minutes

Iteration 0 / Overview : 45 mins

1. 20 mins: Quick overview about refactoring with some examples.
2. 10 mins: High level overview of the open source project’s design
3. 05 mins: The participants form pairs and each pair picks up a module/package of the open source project.
4. 10 mins: The participants spend time understanding the functionality of the module/package picked up by the individual pairs.

Iteration 1 : 45 mins

1. 10 mins: I’ll show 2-3 simple code smells, explain associated refactoring techniques.
2. 15 mins: Each pair identifies one or more classes from the module/package, which has these code smells. They try and understand what it does, in the process they might do some basic refactorings like extract method and rename variables/methods. Eventually the goal is to writes one or more unit tests around it. Once they have sufficient passing unit tests [safety net], they start cleaning up code by applying some advanced refactoring techniques. In some cases, sufficient unit tests might not be required to do simple refactoring like extract method, rename variable, etc. Sometimes internally restructuring the code, can help us understand it better. Hence the participants will have to constantly switch between ‘understanding’, ‘unit testing’ and ‘refactoring’ hat.
3. 20 mins: The pairs stops refactoring. Couple of pairs connect to a central project and demonstrates their accomplishment to the rest of the group. We can break into a discussion about each team’s refactorings.

Break – 30 Minutes

Section 2 – 90 Minutes

Iteration 2: 40 mins

1. The pairs swap partners so that each team gets a new member and one old member continues on the selected module/package.
2. 10 mins: I’ll show 2-3 little more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

Iteration 3: 40 mins

1. The pairs swap partners again.
2. 10 mins: I’ll show 2-3 more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

10 Minutes – Retrospective

• What worked? The participants indicate what they learned.
• What did not work?
• What to do differently next time? Suggestions from participants on how to improve the session.

Infrastructure Required

• U shaped table setup with a projector at the center of the table which can connect to all the computers.
• Either the participant get their own laptops with required software setup or we provide the participants with computers. We’ll need 10-15 computers for the participants. Each computer is set up for a pair [2 chairs]. The presenters will set up the computers with the required software a day in advance of their session.
• 10-15 flip charts, one per team.

Pre-requisites for attending the session

1. Object Oriented Programming
2. Java and Servlets knowledge [don’t worry too much about this, pairing can save you]
3. You need the following software setup on your machine before you come:

1. Latest Eclipse IDE for Java Developers
2. Latest Sun JDK
3. Latest Apache Tomcat Web Server
4. Latest Very Quick Wiki

Set up instructions:

1. After downloading, JDK, install it
2. Set the JAVA_HOME env variable is not already set
3. Unzip eclipse and try running eclipse executable [eclipse.exe]
4. Unzip tomcat and try running startup.bat or startup.sh from the bin folder
5. Take the vqwiki war and drop it into tomcat/webapps folder. Depending on the version of vqwiki you have downloaded, there will be a folder created under tomcat/webapps called vqwiki-x.x.x Where x.x.x represents the version number. For the purpose of these set up instructions, please replace x.x.x with your correct version number. Example if you have downloaded vqwiki version 2.7.8, then replace x.x.x with 2.7.8
6. Start your favorite browser and go to [http://localhost:8080/vqwiki-x.x.x] Make sure the vqwiki page shows up
7. Go to tomcat/webapps/vqwiki-x.x.x/WEB-INF/classes folder. Copy all the files expect the vqwiki folder to WEB-INF/src folder
8. In Eclipse, create a new project called vqwiki. While creating the new project select the option “create project from existing source” and point it to the tomcat\webapps\vqwili-x.x.x folder
9. Project would have compile time issues, since it needs the servlet.jar which is under the tomcat/common/lib folder. Add it to the libraries under the Java Build Path tab. Make sure that the code compiles without any problems.
10. If you don’t want to start and stop tomcat from command prompt, there is Sysdeo/SQLI Eclipse Tomcat Launcher plugin for eclipse which can simplify some of those issues. Please note that this is optional.
11. If you want changes to your classes being automatically detected by Tomcat, add the following line to tomcat/conf/server.xml

<Context path=”/vqwiki-x.x.x” reloadable=”true” docBase=”vqwiki-x.x.x” />

Note: Some of you might already have lots of these set up. Use your judgment if you want to skip some steps.