s recommend that we DoTheSimplestThingThatCouldPossiblyWork
. The idea is that simple code means you're travelling light -- low up-front investment, and not much to slow you down when you want to change.
though? Is it "the first thing that comes to mind"? Is it "whatever takes the least effort"? "Whatever takes the least mental strain"? Well, here's the official scoop:
: The Four Commandments:
- Passes all the tests.
- Expresses every idea that we need to express.
- Says everything OnceAndOnlyOnce.
- Has no superfluous parts.
Wiki pages for each of the above, respectively:
- UnitTestsTellYouWhenYoureDone, ...
- SelfDocumentingCode, ...
- OnceAndOnlyOnce, DontRepeatYourself, RedundancyIsInertia, ...
- YouArentGonnaNeedIt, MinimumNumberOfClassesAndMethods, ...
- Runs all the tests.
- Maximizes Cohesion
- Minimizes Coupling
- Says everything OnceAndOnlyOnce.
agreed on a slightly more constructive
pronunciation of the four rules for emerging simple design:
- Runs all the tests.
- Contains no duplication (OnceAndOnlyOnce)
- Expresses all the ideas you want to express.
- Do not put the implementation of unrelated ideas in the same method.
- Classes should organize ideas in a readily understandable way.
- Use appropriate names so you don't have to explain method, member or class names with additional documentation
- Methods and classes should be implemented so they can be understood totally from their public interfaces. This not only allows for up-front testing, but decreases coupling.
- Minimizes classes and methods. This is actually redundant, but is a reminder that we are trying to make this simple and concise.
The way I like to derive this is to think about what is most important. The most important thing is that the code works. We use tests to show us that the code works therefore the first point must be that all the tests must run. The next most important thing is that the code is as easy to understand as possible, therefore we need to ensure that it expresses every idea that we need to express clearly. Even though it works and it's understandable, we still need to consider maintainability. Therefore say everything once and only once and minimize the number of classes and methods. -- JasonYip
Along similar lines, here is some discussion that was originally on OnceAndOnlyOnce:
I agree with WayneCarson
needs some constraint - or more explanation. I have seen this principle used to justify way too much inheritance for implementation (i.e., code sharing), which often limits reuse. Using DesignPatterns
terminology, I'd rather see OnceAndOnlyOnce
operate at the interface level, where it leads to a nicely factored set of interfaces, and encourages interface inheritance (in which case delegation can be used to reuse implementation). But expressing this rule simply in terms of raw code can be counterproductive.
In XP, the constraint is SimpleDesign
... too much inheritance implies too many classes, so perhaps you want refactor to combine classes, and then possibly refactor again to use composition instead of inheritance.
Later on in the OnceAndOnlyOnce page, the following paradoxical discussion took place:
I think the application of OnceAndOnlyOnce
to code should be restricted to not making the overall system too confusing or tightly coupled. Over reuse can make the system difficult to modify. Think of the extreme case of code produced by an efficient optimizing compiler. -- WayneCarson
My experience is quite the opposite. If I apply the once and only once rule to code until I can't any more, I certainly get lots of little pieces. This takes commitment. If I am committed to communicating through my code (SystemOfNames
, etc), though, the result is not confusing. And it certainly isn't tightly coupled. It is radically decoupled, in that changes tend to be very localized, and all without much in the way of planning.
I can see this happening, if *I* (or apparently Kent) does lots of refactoring, the result will be radically decoupled code. The nagging problem I have always had with XP is that I could not find which bit of XP said that we would end up with radically decoupled code. OnceAndOnlyOnce
kind of means that we will, but the once can wind up splattered all over the place and still be only once. If there was also an All_in_one_place XP/wiki word I would feel way more confident in what the XP protagonists are saying. I expect the XP people will say of course, but it has been my sad experience that what it is about code that smells is not obvious to all programmers. I could do an XP project and *know* the project would come out on time and on budget, just so long the team first agrees that one thing we are going to need that will never appear on any user story is RadicallyDecoupledCode?
Does anyone find that there is a learning tradeoff between systems that have lots of little pieces and those with fewer pieces? It seems that the chunkier systems might be easier to understand at first glance.
Yes, and cards and diagrams help, but when it comes down to actually doing things the highly-factored system is easier to modify by far. It's much easier to get to some specific thing you do need because the highly-factored system separates out all the information you don't need.
A related idea in the business domain: "Strategy as Simple Rules", an article
in Harvard Business Review (January? '01), online for a fee at http://www.hbsp.harvard.edu/hbsp/prod_detail.asp?R0101G
I don't know, I find it funny that they say "the success of ..., Enron ... " :) --VladEnder
The question WhatIsSimplicity
is closely related to the WhatIsQuality
Am I the only one that finds this list funny: "OnceAndOnlyOnce
No. That is, indeed, quite hilarious. Maybe a reflection on the fact that Wiki doesn't exactly encourage XP?
Or, that we're not refactoring the Wiki mercilessly.
'Au contraire. i believe it's the only rule worth repeating. repeatedly.' similar to 'The beatings shall continue until morale improves'
According to WorseIsBetter
there is a tradeoff (or at least a tension) between simplicity of interface and simplicity of implementation? If an XP team must make a choice which one does it choose? -- AsimJalis
An XP team does not make that choice up front. Write a test, make it pass, refactor, repeat. Refactor to the point of simplicity. Listen to the code.