We usually get some guidelines from the overall architecture of the application but after that it always seems to be a free for all. I think we can all do better.<p>Like, math books are chocked full of techniques to handle specific situations. But imagine if instead of using those techniques we just invented our way through each problem. That's how I think programming is. Because, perhaps we don't have a rich enough vocabulary to describe what we are doing and so every day people solve the same problem in many offices. But if architecture were more codified we could just look up how to do something.<p>Maybe there could be a site that listed abstract solutions that people could vote and leave comments on. So, for example, someone might leave a comment saying that the solution doesn't scale well. If you need something that scales consider solution_93748.<p>I think this could help developers create better architected code because we could offload some architecture tasks to the hive mind. What do you think?
Architecture principles are codified. For day to day programming, you're looking for design patterns. The main reference is the Gang of Four's Design Patterns: Elements of Reusable Design (<a href="https://springframework.guru/gang-of-four-design-patterns/" rel="nofollow">https://springframework.guru/gang-of-four-design-patterns/</a>). If you're looking for more of a systems architecture, the architecture of open source is a good resource: <a href="http://aosabook.org/en/index.html" rel="nofollow">http://aosabook.org/en/index.html</a>
> <i>"Maybe there could be a site that listed abstract solutions that people could vote and leave comments on"</i><p>Sometimes all you need is the right jargon to search for. "Design Patterns" is the thing you're looking for. They help you express architecture in common abstract concepts.<p><a href="https://sourcemaking.com/design_patterns" rel="nofollow">https://sourcemaking.com/design_patterns</a>
I think it’s all about workflow. The closer you bring feedback to the developer, the more likely they are to follow guidance.<p>Linters and prettiers are a perfect case study. Saying don’t do X doesn’t work. But preventing you from doing your work unless you do X (and helping you do it) works really well.<p>We need linters for architecture patterns — but of course this is really hard to do in practice.
Isn't that what design patterns are? you have books for OO design patterns, enterprise patterns, even microservices patterns, with code examples and everything. Most of them go far beyond the overall architecture.