StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>There's no "theory of everything" here. You got it right, there's a problem. I remember confronting it myself a while back.</p> <p>My conclusions started here:</p> <h2>Application vs. Framework/Library Development</h2> <p>If your clients are developers, this job is much harder. Not only is it harder, but there are no clear guidelines. Great framework designers got their prestige because they happened to take risks that paid off. At the same time, in an alternate universe, their risks could have <em>not</em> paid off. That's because appreciating a framework depends on the direction of its growing usage, and subjective opinions which are much harder to reason about than in the application domain.</p> <p>So there's no clear cut answer in this case. Fortunately, I think you're interested mainly in Application development here. So let's get on to that.</p> <h2>Starting point: We're developing applications</h2> <p>This makes a huge difference. Because we're supposed to have a much better idea of where the system is going, and what kind of code could turn out to be useful. We're not prophets, but at the same time this assumption allows us to give more credit to our intuition, which is based on our knowledge of the requirements, and the needs of our customers (at least as much as we were able to understand).</p> <p>At this point, we can still divide this into 2 cases:</p> <h3>Abstraction to Implementation</h3> <p>There are cases where it is beneficial, or even necessary, to define abstraction ahead of the implementation. In cases like this, one has to realize that much more research about the problem is required before defining the abstraction properly. For example, is the domain synchronous or asynchronous? Serial or parallel? High or low level? And other much more concrete questions.</p> <p>Some extreme agilers will have you believe that you can just write some code and fix it later. However, that claim is falsified very easily once reality hits. If you find hope in it, I encourage you to test it yourself and report if you made any significant discovery. My personal experience, and thought that I have tried putting into the matter, suggest that in big projects this approach is very problematic.</p> <p>The conclusion in this case is that, if you indeed <em>need</em> to define abstraction ahead, then you should already have a very good idea of the implementation. The better idea you have about it, the higher the chance it will succeed in actually being a proper abstraction.</p> <h2>Implementation to Abstraction</h2> <p>This is my default choice. It has been said in many ways. "Frameworks should be extracted", "Extract 'till you drop", and even "Convention over Configuration" has some similarities in concept.</p> <p>Basically this means that you implement your required components as necessary, but keep a sharp eye on what's going on. The trick here is to look out for chances to abstract in ways that actually benefit you practically in terms of development and maintenance.</p> <p>This often comes up as a class that does what you want, but more. In which case, you abstract the intersection away into a more general case. You repeat this process as necessary throughout development.</p> <p>It's important to not get caught up and still keep your feet on the ground. I've seen many abstraction attempts go wrong to a point where there's no way to reason about its name and deduce its intent except reading thousands of lines of code that use it. For example, in the current code base I'm working on, the type which should have been called <code>Image</code> is called <code>BinaryData</code>. All across the code are attempts to treat it as a concrete (Image), and as an abstract concept at the same time.</p> <h2>To sum up</h2> <p>As I always remind myself, the best <em>best practice</em> you can have is to tame known best practices to fit your problem, rather than the other way around. If you can't do that, well, maybe the problem is interesting enough to require further attention, and a bit of original thought.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload