After digging through the new code (golang, if that's important), I discovered a large number of interfaces that could easily be removed - they did not affect anything. But I decided to bring up this topic.
It became clear in advance that this was about the near-SOLID concept of “clean code”. I am neither against nor for, it has both pros and cons, but, in some aspects, in my direction of decision:
- All articles on this topic begin with the same example: creating an access interface to a database (template repository) so that it can be implemented for several databases. This is motivated as follows: suddenly you intend to move from postgres to Mongo. A similar example, of course, can be expected in reality, but, as for me, it is still quite loose. I don't believe in simply moving from sql to nosql and back for any project, more than todo. Motivation number two is to implement it for both postgres and sqlite, because it is difficult for a programmer to run postgres locally. From this moment you already want to start giggling, having provided for a certain number of additional problems, you choose a communication method, where the foundation of the project changes radically during development and operation. I would like to add that, for sure, there is already an abstraction for the sql database, where to replace the database you only need to replace the driver.
In my head, it so happens that interfaces are created at the moment when two entities make up one contract, but all attempts to reach two entities in the examples above look strange. But, the trick here is to take off his hat, and from the hat the metal unit tests are being mocked, namely the unit. Do you have some code, but can't come up with a second entity? - then this entity will be tests for this code, any code has (should have) tests, therefore, there is a second entity, therefore, everything should be as abstract as possible.
And this logical twist, because of the example, shows better, it seems strange to me, i.e. tests pull the code onto themselves, and not vice versa. Again, I don’t want to say that this shouldn’t be said - everyone decides for themselves whether TDD or not TDD, but presenting this as the only correct option for everything seems strange to me. I add that if you replace unit tests with integration tests, which I have seen quite often, then this concept falls apart again.
It would be possible to add about poly- and monomorphism - generics and duck typing, but there’s still a lot
- added - A good example of the convenience of this concept that was given to me is caching
Top comments (0)