|
> Any codebase that I had complete control over. This is probably one of the pillars of good codebases, or at least decoupling the bits that you don't control as well as you can (this includes external services). I remember needing to write a wrapper around another JWT library, but because it was quite important, I aimed for >95% test coverage, some of the tests acted as documentation for how to use the code, there was also a nice README, there was CI configuration for pushing the build artifacts to Maven and suddenly even managing dependency updates became easy because of the test suite. Years later, it's been integrated in a bunch of services and "just works". Come to think of it, things always get less pleasant once you add a bunch of complex dependencies and libraries/frameworks. Need to make a few RESTful Web APIs in Java? Something like Dropwizard will probably give you fewer headaches than Spring (or Spring Boot) and all of its inherent complexity, in the case of the former you might even need to do configuration in XML and that has honestly never been pleasant. If you need to integrate with a bunch of other stuff and want something opinionated, going for Spring Boot will make sense then, but for simple use cases it's overkill. Same for ASP.NET, Ruby on Rails, Laravel and many others, while they might be easier to use, updates (especially across major versions) and breaking changes will give you a headache and just add a bunch of churn to the project. Similarly, if you need a message queue, externalizing that into RabbitMQ might make a lot of sense, same with storing files in an S3 compatible store, using something like Redis or Valkey for key-value storage, as well as not trying to shove too much logic into your RDBMS. Just pick whatever tool feels best for the given task at hand, instead of shaping things into what they're not (using the database for blob storage, for example), unless you have a whole bunch of constraints to contend with. Otherwise, sometimes you just get the worst of both worlds, like needing to use Oracle for a project, not having easily launchable local environments (because Oracle XE doesn't support some features), having to share DB instances with others during development and also running into weird obscure issues like DATABASE LINK queries taking 100 times longer in some cases, even when executing the same SELECT query on the remote DB works without issues. To not go into a rant, I'd sum it up like this: be in control, isolate the things that you cannot control, pick the correct technologies, do the simplest thing that you can get away with without overengineering and think about the person who'll have to maintain, debug and grow the system in the following months and years (which might also be yourself, sans knowledge about what the code did, if you don't make it explain itself or don't comment the non-trivial stuff). |