Isn't it so that the more powerful the solution the easier it is to forget what the original problem was?
It seems to me that this applies also quite well to infrastructure frameworks. I mean their primary goal should be enabling people to focus on writing better business logic. However after having learned all the details of these frameworks it is very easy to start believing that this is all there is about design.
Probably this situation is also fueled by the nature of code samples shipped with such products. The intention of samples is to provide overview of as many features as possible. Result is that several other aspects of good application design (like business logic layer best practices) are often neglected (good examples are Spring sample apps). Unfortunately these samples usually become best practices not only in use of given framework but in general application design as well.
So what is the solution? I think one should keep in mind that even the best frameworks cannot replace good design. Also framework sample applications should not be taken out of their intended context (e.g samples of some MVC framework may not necessarily show good business layer design).
Comments (5)
May 03, 2006
Risto Alas says:
This is a bit different topic, but I'm wondering if the act of writing unit test...This is a bit different topic, but I'm wondering if the act of writing unit tests would "force" developers to see (and correct) such bad design...
May 03, 2006
ahti says:
What's cool about frameworks is how elegantly they add better granularity and de...What's cool about frameworks is how elegantly they add better granularity and decoupled code. At the same time they force you to split one logic/business concept between different layers - dividing your initial business concept by decoupling it in a different dimension.
The best systems are built using great frameworks but the code you write with them is like a DNA molecule that is extremly small+efficient. But watch out! Even a small misconfiguration will produce chihuahuas, string-theorists, disco-music and of course, microsoft.
Final question: Where should one draw the line to differentiate FRAMEWORK and ARCHITECTURE?
May 03, 2006
ahti says:
Risto, I think you know the answer for your question, such a provocative comment...Risto, I think you know the answer for your question, such a provocative comment!
I believe (read: hope) that even the best frameworks can't force bad design if you're able to have properly unit-tested code.
But while getting serious.
I think that this tendency about writing sample-based code is also caused by thinking that it's not cool anymore to plan or design your application.
Years ago waterfall and RUP was cool. Now is XP and agile. People are so eXtreme that don't take enough time to read the concepts of XP and believe that XP is asking you to start coding right away, start from anywhere you want, you can refactorit later. Which is, ironically, also a good strategy.
May 03, 2006
Ürgo Ringo says:
Big thanks to excellent comments! I think this is very good point about becomi...Big thanks to excellent comments!
I think this is very good point about becoming too eXtreme that you brought out Ahti. I have to admit that I have made this mistake myself on some occasions.
Now about frameworks - what I meant was infrastructure frameworks that are external tools used by the project team. I do not want to say in any way that such frameworks are inherently bad but I think that as with processes one can become too extreme with frameworks too.
On one hand good framework should force you to use good practices in its target area (e.g persistence, remoting etc). However ideally it should not be intrusive to other areas of you system design (mostly how you define your business logic).
What do you think guys how strong is the correlation between good architecture and proper unit testing? I mean aren't unit tests a bit too low level stuff do have really significant impact on general architecture (e.g subsystem composition etc)?
May 04, 2006
Risto Alas says:
I don't know what exactly you mean by general architecture/subsystem composition...I don't know what exactly you mean by general architecture/subsystem composition, but I have a quote that might fit:
"...just as unit tests drive you to make superior design decisions in the small, acceptance tests drive you to make superior architecture decisions in the large"
(Robert C. Martin, page 27 of his Agile Software Development book.)