"deadalnix" wrote in message news:qawhxkzqdgzjwylzr...@forum.dlang.org...
I call them architecture astronautes. To avoid that pitfall, I have a
adopted the following method :
- Do whatever you need to to get to the next step toward you goal.
- Make a pause and observe. Is there some repeated patterns ? Is there
some part of the code that is growing in complexity ? Do part of the code
rely on fragile hacks ? Is part of the code doing useless work ? etc...
- If yes, refactor accordingly, either by adding new level of
abstraction, but better, by changing the interface of some abstraction to
better fit its actual usage (and not the you were thinking you'd get at
first).
This allowed me to avoid creating useless abstraction, and push me to
refine existing ones.
This is exactly the approach I use and I've found the extra time spent on
refactoring is well worth the time saved on not implementing things you
don't need or that don't match the needs of the problem you're solving.
It does help that D is rather easy to refactor, and I'm much better at
coming up with a good design after I've half-implemented it.
