Guilherme Silveira, Creator of Restfulie and Editorial chief of InfoQ Brazil

Once a project has chosen an appropriate architecture, it's all about the code. We have all joined projects which have good response time and supports the required number of users, but is impossible to maintain. Why?

We have all developed for one year in the same project and saw it becoming dirtier and dirties, until it reached the point of no return, the dark whole of code quality.

It can't be something nasty and big. We don't do big nasty things. So where are all those small nasty things that we do, that accumulate over time, culminating in that horrible piece of software that no one wants to maintain?

While developing, design and code decisions influenced its quality in a way that its impossible to say what happens, when it happens and where it happens. It is time to take code in our hands and care about it: not only on the short term, but also on the long run. This talk will go through some of the small and controversial decisions, that affect code both on the short and the long run. Issues with AOP for business logic, concise code, bad tests, long code and so on; always mentioning how average and above average developers affect those projects.

Another important point is that smaller projects are easier to be rewritten: should we favor them to always keep code in shape?

Note that as this is not a language specific issue, we will go through examples of perfect running code, that is impossible to maintain, in Java, Scala and Ruby.

If you are tired of seeing the same code design mistakes, while just jumping from one language to another, this session is for you. Come and also share your examples on poor code design.

The keywords for the workshop are: TDD, Design, Quality, java, ruby, .net, scala, OO, Solid, Patterns

The target audience: Developers and architects who care about good quality. Those who want to improve their design based on TDD and those who want to improve their TDD practices based on design.

TDD is not new and developers already know that, although it has "testing" in its name, TDD is a design technique. However, many developers still do not know how to interpret better the test feedback in design. This workshop shows how developers should use the feedback and improve their design, using good OO principles, like SOLID.

Programmers should bring a laptop and already download a Java project and are implement some behaviors the way they want in well-prepared exercises. After that, solutions will be discussed and speakers will present good advices on how to interpret test feedback and possible OO solutions to the problems.

For every problem, there is time for discussing implementation quality, and also points of view until in the design point of view. In the end, some examples of bad practices in other OO languages (Scala and Ruby) will be discussed, and how they can be refactored into other good OO or functional style code.

We have all developed for one year in the same project and saw it becoming dirtier and dirties, until it reached the point of no return, the dark whole of code quality. How can TDD help us with good OO principles?

Learning outcomes Real world TDD in practice
Design feedback
Good OO design
SOLID principles (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle) Pair programming

Method:

A set of prepared exercises is provided, one at a time, from easy to advanced. The participants are asked to implement a small feature using TDD and pair programming. They are free to solve the problem in any way they want.

After each exercise, speakers will inspect the attendee's solutions, debate them and show how to get design feedback from the test and use it to drive the code to the best possible design.

Requirements: Participants should bring their laptops with a Java compiler and Eclipse installed.

Keywords for the workshop are: TDD, Design, Quality, java, ruby,.net, OO, Solid, Patterns
Target audience: Developers and architects who care about good quality. Those who want to improve their design based on TDD and those who want to improve their TDD practices based on design.