Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
There are a whole bunch of architecture books published by Oreilly that I have bought and plan to read. They were available for a few bucks in a previous Humble Bundle, and cover the topics:
All are available on Anna's Archive. I like the Head First book to have an overview of architecture.
I second this and would also recommend the Software Architecture Book Club podcast where the authors cover a chapter each episode (Head First Software Architecture and then Fundamentals of Software Architecture).
I would also recommend the InfoQ architecture RSS feed to stay current.
Amazing, thanks.
Edit: I never knew that InfoQ was a good resource. That's a nice additional link.
I recommend "Software Architect's Handbook" by Joseph Ingeno as an intro/overview
Martin Fowler’s “Patterns of Enterprise Application Architecture” really helped me understanding how to break things down. Pretty sure it’s still just as relevant today.
"Build APIs You Won't Hate: Everyone and their dog wants an API, so you should probably learn how to build them "
Great book, if a bit dated on the coding examples. It goes over common issues with APIs that I have seen play out.
"Working Effectively with Legacy Code" - Excellent book that goes over what to do in plain english when you got stuck with legacy code.
This is a bit beyond architecture, but being competent to build a mathematically bug-free API is probably something that few programmers would even bother trying to compete-against..
https://leanpub.com/algebra-driven-design
I think there is a fundamental mis-framing, throughout the entire software/development understanding..
I think that the architecture needs to be simultaneously agilely-devloped, but into an executable-model, a kind of toy-implimentation, so it is easy to change the architecture, low-cost, BEFORE one converts it into load-bearing, & therefore unchangeable architecture ( architecture's the hardest thing to change, as it's most-fundamental )
So, I think that the proper way is to do it in 2 stages:
This is part of an idea from years ago: I read in a Wiley GAAP book that I happened to be glancing into, that it's a violation of GAAP to prototype any project in any language other than the final-implimentation-language, & expense that prototype.
Which is totally insane!
Prototype in the highest-level-language you can, to get the domain+architecture right, then reimpliment what you have to in the most production-efficient/effective language for that project.
GAAP ( of that year ) is categorically wrong: it penalizes optimal-prototyping.
It was years-later before I discovered that an English mathematician ( roundish ginger, worked in Glasgow, no idea what his name was, sorry ) had studied the difference between complex projects which worked vs ones which died, & it was the visual-spacial-representation-of-the-model, & the complete-coverage executable-model which made the successes win.
So, I just put those ideas together.
_ /\ _
Easy. Just leave the bad parts out.