SOLID Go Design
For middle of the road companies with middle of the road developers, I find SOLID is not really a great set of principles to focus on.<p>&#x27;S&#x27; is pretty good because it helps encourage developers to get away from huge classes that have dozens of methods.<p>&#x27;O&#x27; is basically useless when applied to a single codebase, because one of the worst parts of middle-of-the-road developers is when they start to realize they can extend classes. You end up with horrendously complicated and deep class hierarchies. I find that when it&#x27;s time to add functionality, it&#x27;s far better to just refactor and create new classes for composition.<p>&#x27;L&#x27; is deeply confusing, and the difficulty in understanding it is what leads to the deep and brittle class structures above.<p>&#x27;I&#x27; drives intermediate developers to create more and more interfaces that have 1-2 methods, which when combined with their difficulties with &#x27;O&#x27; and &#x27;L&#x27;, just leads to confusion and high cognitive load when trying to maintain the codebase.<p>&#x27;D&#x27; is good.