4 ms·
Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that
by gimboland 7y ago
Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well-defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.
- zo1 7y agoI highly agree with this. It's almost a necessity these days with a major push to hire "junior" developers at a discounted rate. By doing those lower abstraction layers, you allow them to write the necessary high-volume business code while reducing their ability to do something subtly stupid for the business/data. Usually this involves abstracting away a lot of the database transaction-type stuff. And on a side note: Never let juniors anywhere near the database design without supervision by the team/seniors. They won't learn anything that way, and they will inevitably make a mess.
- 29athrowaway 7y agoIn genetic algorithms, you select the best from each generation to breed the next generation. I think this holds true in software development teams as well. When you indoctrinate new developers, you should delegate mentorship to the best* performing teams, so new developers can assimilate good practices and develop an intuition for how thing should work. I think this is much more valuable than giving them grunt work. *: just like with genetic algorithms, picking the right fitness function is everything. Good performance is about steady, consistent, sustainable development... rather than trading today's problem with tomorrow's problem.