6 ms·

This. The best codebases I’ve seen have an abstraction layer at the foundation and the rest is just dumb repetitive code built on top of that layer. It’s temp

This. The best codebases I’ve seen have an abstraction layer at the foundation and the rest is just dumb repetitive code built on top of that layer. It’s tempting to look at that and think we can abstract it out a bit more, but then you cross the line pretty quickly and your abstractions now mean you have 20 parameters to control how the abstraction should work.

tstrimple 4y ago
I agree with you to some degree, but I've built an abstracted data layer in literally every project I've worked on since I learned it was a good practice around 20 years ago and I still have yet to be on a project where we actually needed to replace the database. I've moved plenty of databases from on-prem to PaaS, but never switching DB technology itself through an abstraction layer. That's not to say I haven't had to replace data storage, but they were never built as layers and inevitably it happens when moving from mainframes to more modern systems. At this point at least some of my abstraction feels like a waste of time. Maybe when we start moving to Quantum Databases someone will benefit from my extra due diligence from a decade ago.
- portsnadaptors 4y ago
  I don't think building an abstraction over the data layer is just to make it easier to change your database. The abstraction can define the data access patterns upfront and minimize bespoke data access code. I've spent a lot of hours trying to untangle ORMs and other data access code from business logic. I've found that extending an abstraction to support a new access pattern (that you really need) is much easier.
  - rlabrecque 4y ago
    This is one of the bigger discussions I've been involved with lately; and I agree it really comes down to "bespokeness". When you have a 'system' which is 500 LOC, and 10 usages of that system totaling 10 lines each; compared to 10 bespoke implementations of 50-100 LOC each... you get into a spot where the system is battlehardened because of all the users, while the bespoke implementation have issues all over. Then when someone goes to add the 11th use-case of this; they are going to learn from and copy/paste the other version, probably exposing some latent bug in the bespoke version.
- scotty79 4y ago
  I don't think MS built Entity Framework so that you can switch away from MS SQL Server in any other way than "potentially".
SkyPuncher 4y ago
IMO, it's a lot like building a house. It's okay to have someone else manufacture the bricks for you. However, you still have to lay them by hand. It's tedious, repetitive, and labor intensive, but gets you the exact result you want. The second you try to pre-cast bricks, you end up with something harder to work with.
ilyt 4y ago
I think the main problem is "pre-abstracting", "this looks like it might be used often, lets write quick layer of abstraction on top of that so there is less repetition". Then you end up calling it once, maybe twice in code, and need to bounce thru 3-4 files to even get to see what the code is actually doing. Also makes anyone new to the code have to go thru same dance.
oxfordmale 4y ago
There is a much simpler reason big code bases have less bugs. The size of the codebase is correlated with the investment a company is making into this codebase A larger code base will have seen many peer reviews from different Engineers over its lifetime, and as it is likely of the companies core products, a lot of testing, both internally by the test team, and externally by customers. On the other hand my hacky script, put together on a sunny summer afternoon, has zero love from senior management as they probably don't even know it exists.

tstrimple 4y ago

I agree with you to some degree, but I've built an abstracted data layer in literally every project I've worked on since I learned it was a good practice around 20 years ago and I still have yet to be on a project where we actually needed to replace the database. I've moved plenty of databases from on-prem to PaaS, but never switching DB technology itself through an abstraction layer. That's not to say I haven't had to replace data storage, but they were never built as layers and inevitably it happens when moving from mainframes to more modern systems. At this point at least some of my abstraction feels like a waste of time. Maybe when we start moving to Quantum Databases someone will benefit from my extra due diligence from a decade ago.

portsnadaptors 4y ago
I don't think building an abstraction over the data layer is just to make it easier to change your database. The abstraction can define the data access patterns upfront and minimize bespoke data access code. I've spent a lot of hours trying to untangle ORMs and other data access code from business logic. I've found that extending an abstraction to support a new access pattern (that you really need) is much easier.
- rlabrecque 4y ago
  This is one of the bigger discussions I've been involved with lately; and I agree it really comes down to "bespokeness". When you have a 'system' which is 500 LOC, and 10 usages of that system totaling 10 lines each; compared to 10 bespoke implementations of 50-100 LOC each... you get into a spot where the system is battlehardened because of all the users, while the bespoke implementation have issues all over. Then when someone goes to add the 11th use-case of this; they are going to learn from and copy/paste the other version, probably exposing some latent bug in the bespoke version.
scotty79 4y ago
I don't think MS built Entity Framework so that you can switch away from MS SQL Server in any other way than "potentially".

SkyPuncher 4y ago

IMO, it's a lot like building a house. It's okay to have someone else manufacture the bricks for you. However, you still have to lay them by hand. It's tedious, repetitive, and labor intensive, but gets you the exact result you want. The second you try to pre-cast bricks, you end up with something harder to work with.

ilyt 4y ago

I think the main problem is "pre-abstracting", "this looks like it might be used often, lets write quick layer of abstraction on top of that so there is less repetition". Then you end up calling it once, maybe twice in code, and need to bounce thru 3-4 files to even get to see what the code is actually doing. Also makes anyone new to the code have to go thru same dance.

oxfordmale 4y ago

There is a much simpler reason big code bases have less bugs. The size of the codebase is correlated with the investment a company is making into this codebase A larger code base will have seen many peer reviews from different Engineers over its lifetime, and as it is likely of the companies core products, a lot of testing, both internally by the test team, and externally by customers. On the other hand my hacky script, put together on a sunny summer afternoon, has zero love from senior management as they probably don't even know it exists.