On 19 December 2014 at 03:44, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Thu, Dec 18, 2014 at 05:33:24PM +0000, Sebastiaan Koppe via Digitalmars-d > wrote: >> On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote: >> >>I find a much bigger problem is tendency for some programmers to >> >>commit over-abstraction, sacrificing heaps of efficiency/performance >> >>in the process. Most open-source engines are this kind, and will >> >>never release a AAA game in a competitive market. >> >ah, that's the other end of the spectrum (and my own problem too ;-). >> >i'm still searching for good heuristic that will tell me when i >> >should stop abstracting and just write the damn thing. ;-) >> >> Programming is a wicked problem; you only know how to do it after you >> done it. So my suggestion is to just write the damn thing, and then >> rewrite the whole thing if it bugs you too much. Essentially a lot of >> rinse-and-repeat. >> >> I always do refactoring manually, so I developed a nack for knowing >> how to write quick code that is easy to refactor. >> >> Ofcourse having clients screaming in your neck helps alot too :) > > IME, starting out with abstraction rarely works well. If you're a > one-man team, you'll never finish abstracting; if you're a multi-person > team, the whole thing will be so over-engineered, baroque, and > inefficient, that by the time you're halfway through it you already feel > like rewriting it (again). > > What works best IME is to just have a quick initial design to guide you > (don't worry too much about abstracting it to the ideal, just have > enough overall target items to set the direction so that you aren't > getting yourself into the forest, and so that you have a rough > high-level overview of how the whole thing is gonna fit together), then > start coding. Most of the abstractions will come from refactoring, which > should be done frequently. Abstractions derived in this way tend to be > far more effective, because they will arise from actual usage patterns > in your code, rather than some ivory-tower idealistic > theoretically-beautiful model that will either never get implemented or > is so far removed from reality that it's completely impractical and > doesn't work well in practice.
I agree. My rule for abstraction is to apply it as minimally as possible to avoid any platform-specific api being called from front-end code. That should be a good initial target. Further refinement will reveal it's self in practise, in the way that you say.