『E11 - What Is Software Architecture』のカバーアート

E11 - What Is Software Architecture

E11 - What Is Software Architecture

無料で聴く

ポッドキャストの詳細を見る

【Amazonプライム会員限定】今ならプレミアムプランが4か月 月額99円。

10月19日まで。※適用条件あり
In this episode of Fundamentals of Software Engineering, Nate and I dig into the question the whole show is named after and the one our book only had a single chapter for: what software architecture actually is. We start where Neal Ford and Mark Richards start, with architecture as the things you cannot Google, and we work out why that definition holds up. By the time a decision reaches an architect, the easy answers are gone. Nobody escalates a variable name. What gets escalated is whether this should be a modular monolith, a set of microservices, or something event driven, and none of those have an answer that survives being lifted out of your context.From there we get into the part that makes architecture uncomfortable: it is trade-offs all the way down. We talk about quality attributes, the ilities that routinely conflict with each other, and why a manager asking for all of them at once is asking for something that does not exist. We cover architectural malpractice, the habit of picking a pattern because it is fashionable rather than because the problem demands it, and what happens when a whole platform gets rewritten around one team's favourite language. We also talk about legacy systems and why reimagining beats dragging, about evolutionary architecture and fitness functions, about the difference between design and architecture, and we close on what we would tell an engineer who wants to grow into the role.__________________________________________________Key Highlights🔎 Architecture is the things you can't Google: Neal Ford and Mark Richards coined it and it holds. The answer always depends on your constraints and the forces you are actually up against.🏛️ No easy answers reach the architect: If a question had an obvious answer, it would have been solved further down. What lands on your desk is what is left.⚖️ The ilities conflict with each other: Scalability, maintainability, simplicity and the rest pull in different directions. Prioritising them is the job, not a failure to deliver all of them.🚨 Architectural malpractice: Reaching for microservices because they are in fashion, when the team shape and the actual demand say otherwise, is malpractice rather than ambition.🐍 Don't replatform a whole team for one capability: If your people are strong on the JVM, moving the organisation to Python to reach one library is rarely the trade you think it is.🔄 Reimagine legacy, do not drag it: Carrying every old defect and unfixed feature into the next system is a choice, and usually the wrong one.🌱 How to grow into the role: Talk to the architects around you about how they got there, what they like, and what they do not. Ask what the path looks like before you try to walk it.__________________________________________________Resources & Next Steps📘 Fundamentals of Software Engineering, the book and the podcast📚 Building Evolutionary Architectures by Neal Ford, Rebecca Parsons and Patrick Kua (second edition out now)📖 Software architecture writing by Neal Ford and Mark Richards🖥️ Fundamentals of Software Engineering on YouTube for the video version🎤 Catch Dan and Nate at KCDC, Devnexus, Dev2Next and QCon San Francisco🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________YouTube Chapter Timestamps00:00 Cold open: reading Carnegie is as useful as another framework03:19 Conference season: what is coming up06:53 Dev2Next and Venkat's conferences07:36 QCon San Francisco and some good news09:31 Today's topic, and where to find the book10:28 Why one chapter on architecture was never going to be enough11:36 Three shelves of architecture books and what they have in common13:31 By the time the question reaches you, the easy answers are gone14:30 Architecture is the things you can't Google16:43 Knowing which questions to ask, and how to get answers18:36 Does this problem actually require Kafka20:34 Structure, teams and what architecture you can realistically run23:21 Architectural malpractice, defined24:43 Designing for scale you do not have yet27:23 AI on the JVM, and not replatforming a team to chase a library28:48 New leadership, rewrites, and the defects you carry across31:34 Who should be an architect these days34:45 Where design ends and architecture begins42:29 Evolutionary architecture and fitness functions46:23 The ilities, quality attributes and real trade-offs55:46 Advice for engineers who want to grow into architecture
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません