Very good blogpost about 'No Frameworks' strategy. (Have to read the Comments section & follow-up bloposts as well)
http://codeofrob.com/entries/look-ma,-no-frameworks.html
The strategy for No Frameworks would be -
We start off a project without a framework.
After a certain point, if the requirements start giving us 'pain', then we pull in a framework, whichever one is appropriate.
We'll have to refactor our existing code to use the framework.
A very important pre-requisite for the above strategy to work -
We need to know at least one or two frameworks, and know them pretty well, in order to know how they will benefit us. Otherwise, we will not know, at which point in the project, a framework could start being helpful.
http://codeofrob.com/entries/look-ma,-no-frameworks.html
Abstractions should be used because there is a pain that needs solving, whether that be because you're talking to third party code, or slow remote calls that need hiding during testing or because there is complexity that needs hiding. Putting abstractions in before we feel any of this pain just means more code to wade through when trying to get stuff done - no thanks.This goes against current-popular-thinking as of today.
The strategy for No Frameworks would be -
We start off a project without a framework.
After a certain point, if the requirements start giving us 'pain', then we pull in a framework, whichever one is appropriate.
We'll have to refactor our existing code to use the framework.
A very important pre-requisite for the above strategy to work -
We need to know at least one or two frameworks, and know them pretty well, in order to know how they will benefit us. Otherwise, we will not know, at which point in the project, a framework could start being helpful.
No comments:
Post a Comment