TIL, 2018-09-29
Does following SOLID lead to writing a framework on top of the tech stack?
- The SOLID approach turns your code into framework code (code you’d design if you were creating a framework for other people to use.)
- Programming rules are subject to interpretation and edge cases. So they can mean different things to different people.
- Extreme forms of SOLID imply big investment, you’ll usually use your chosen stack anyway. There’s a good chance that you are going to stick with your chosen stack.
- Provide the flexibility other developers actually need AS SOON AS THEY NEED IT, not earlier. Wait until you have an actual use case for reuse and refactor. Don’t implement more configurability or entry points of abstraction into such a class as you need for the actual case.
- Automated tests are for making the code SOLID enough and make it possible for you to move the code around.
- Before trying to write reusable code, write usable code.
- When writing an app, you have three choices:
- Write code that fulfills the requirements,
- Write generic code that anticipates future requirements, as well as fulfilling the current requirements,
- Write code that fulfills the current requirements, but in a way that’s easy to change later to meet other needs.
- Last case is the one to aim for: write code that is loosely coupled, that’s easy to modify, yet still quick to write. So small classes, functions, interfaces, dependency injection.
- Skipping good practice can only be justified if your requirements are immutable, and there will never be any change/addition to the code base.