Comments on: When refactoring is no use

By: matteo

matteo — Sat, 13 Nov 2010 13:18:18 +0000

@Franco: I would not call it a complete failure. We still were able to reuse all of the lower level pieces that were built with TDD and had the responsibility of displaying various bits of information. It was the high-level design that was lacking. It was the first TDD project for that team.

I would say it was partially successful, and I took a few days more of training-on-the-job to turn it into a success. :-)

By: Extreme Enthusiasm » Blog Archive » When refactoring is no use « ZenAndSoftwareDevelopment

Wed, 10 Nov 2010 14:24:29 +0000

[…] Extreme Enthusiasm » Blog Archive » When refactoring is no use. Pagine […]

By: matteo

matteo — Mon, 08 Nov 2010 20:26:41 +0000

Hi Mikalai,

Thank you for your comment.

It’s difficult to reason here about which is the best way to solve a coding problem, as I don’t have an example of your style of Swing coding, and I can’t show you my customer’s code.

I agree that whiteboard design sessions are important, in fact that’s what we did in our case. I agree that knowing patterns like MVC and others is important. But I also think that it’s better not to start with a preconceived idea like “it’s a Swing app so I will apply MVC”. It might work well without MVC. It’s better to let MVC emerge from the design session, if indeed it’s needed.

By: Mikalai Alimenkou

Mikalai Alimenkou — Mon, 08 Nov 2010 20:02:01 +0000

At first, I want to note, that it is very strange not to use MVC pattern with pure MVC framework like Swing. It is hard to identify what was the root of your problems, may be you don’t have any other layers in your application and have all business logic inside controllers, may be you don’t use other UI design patterns like Mediator, Observer, etc. But it definitely not MVC itself. From my experience all elements of the MVC with Swing should be as thin as possible, delegating all logic to other layers. In this case they are easy to test with both unit and funtional tests.

At second, I agree with previous comment. TDD a great tool for “tactic” design, not for the “strategic” one. TDD has little impact on overall architecture, much more on low level design decisions. But it is again strange to me why you ignored the pain of testing your large controllers and didn’t do something to reduce it. TDD doesn’t solve problems (you fix them yourself), it makes them visible.

At last, I want to add some words about refactoring. It is rarely possible to fix architectural problems with basic refactoring practices like method and class extraction. They are used to improve local design, not the whole approach. Design meetings are the best tool to improve application design and architecture. After decisions are made you also apply refactoring (I hope :) you will not rewrite application from scratch), but this is another type of refactoring. It is refactoring to patterns, refactoring to new design solution. This refactoring is also based on small simple steps, but the goal is different – apply new better solution. There is great book on this theme: “Refactoring to Patterns” from Joshua Kerievsky.

In any case I’m happy for you, because you identified issues early and avoid large problems in future.

By: Franco Lombardo

Franco Lombardo — Mon, 08 Nov 2010 17:25:58 +0000

Matteo,

you say: “TDD is about design. It’s not about testing.”
Well, it seems that (also) this time TDD failed to create the right design! :-)
I think that TDD is sometimes overestimated as a design tool. Well, I mean, it’s a great tool for “tactic” design, not for the “strategic” one.

By: matteo

matteo — Sun, 07 Nov 2010 14:40:20 +0000

Controller gone. “Model” gone. They were not needed :-)

You could say that there’s now a collection of objects that take the place of what was the controller.

By: Gicappa

Gicappa — Sun, 07 Nov 2010 11:04:33 +0000

So interesting. But I’m curious: at the end the mvc pattern evaporated with the big controller or it was still there?