쉐도잉 연습: What Software Architecture Should Look Like • Dave Farley • GOTO 2022 - 영상으로 영어 말하기 배우기

연습 모드 선택

각 모드는 전체 화면 연습실로 열립니다.

210 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

Wikipedia defines software architecture as the functional structures of a software system and the discipline of creating such structures and systems.

Well you can kind of see what they mean

but it's a pretty dry definition and it raises as many questions as it really answers.

After all, what does fundamental mean anyway?

And for that matter, what does structure mean in this context too?

The last bit is really only saying architecture is produced by a disciplined approach to architecting things.

To be fair to Wikipedia, this is a difficult idea to nail down.

Even though I think that most of us would agree that it's an important one in some way.

So here is my take on software architecture.

What does it mean and what does it take to do a good job of it?

Hi, I'm Dave Farley of Continuous Delivery.

Welcome to my channel.

If you haven't been here before, please do hit subscribe.

And if you enjoy the content today, hit like as well.

My thinking on software development, design and architecture is deeply informed by what I think of as an engineering approach.

I describe this generally applicable approach in my new book, Modern Software Engineering.

It's doing rather well in the rankings on Amazon at the moment, and he's collecting some very nice reviews.

So do check it out.

There's a link to that in the description below too.

I think of myself as a software developer.

Probably more accurately these days, I'm a consultant first and a developer second.

But I also spent a considerable part of my career being called a software architect in one form or another.

I couldn't then and can't now tell you any significant difference in my focus between the times

when I was called a developer and the times when I was called an architect.

Ultimately, I think this is about design.

Maybe it's about design at different scales, but I confess that I'm rather skeptical of that.

The slippery nature of defining architecture as design on a bigger scale is that design in information systems is kind of fractal.

There are things that matter at all levels of detail

and there are tiny details that will invalidate grand assumptions

and there are grand assumptions that can prevent effective progress at the level of tiny detail.

A popular description of software architecture comes from Grady Booch who says architecture represents the significant design decisions

that shape a system where significance is measured by cost of change.

I don't disagree with this definition but I don't like it very much it implies

that these are the details

that we need to get right at the start to succeed it makes some sense

if we're looking retrospectively at a system

but it's a pretty poor guide to building one be omniscient for something this complex

that simply isn't going to happen for me there's only one approach to architecture that makes any sense at all.

It has to be an evolutionary process.

We will guide the design of our system by modifying the constraints that we apply to that design.

These constraints or rules of the road are what we think make sense at any given point.

These form an important aspect of our architecture.

We create a kind of tourist map of the system that we can use as a tool to guide design choices.

Here's the tourist map from one of my systems.

This map guides the evolution of the system in the direction of the outcomes that we aim to achieve.

If we're doing a good job we'll discover our inevitable mistakes and update our tourist map as our understanding deepens.

Let's try and walk into this problem a little bit more carefully.

One great definition of software architecture is it's the stuff that we wish we'd got right at the start of a project.

perhaps a little more helpfully it's the shared understanding

that the expert developers have of the system design both of

these definitions come from ralph johnson i'd add a couple of

words to the second it's a snapshot of the shared understanding

of the expert developers you hope it doesn't change too often

but you should expect it to change i think that in combination these definitions get something rather important right.

At the start of any project, we don't yet know the answers, but we still need to make some guesses about what may work in order to begin.

If we're going to be creating this system as part of a team, we need a way to discuss design ideas to communicate with each other about the system

and think about where different behaviours of the system will be handled.

Our tourist map will help a lot with these conversations.

Debating new features in front of the tourist map can we can explore the implications of our design choices

and maybe spot improvements or mistakes in the map.

I like Ralph Johnson's focus on the stuff we wish we

got right rather than a focus on the stuff we must get right.

We focus on the stuff that worry us.

I like it because we almost certainly won't get it right first time but it is important stuff.

That aligns very nicely with my thinking

and my approach to development in general really which is significantly focused on maintaining my freedom to get things wrong.

That probably sounds a bit weird but I want the freedom to make a mistake

and the ability to learn and recover from it.

For that we need the ability to contain the complexity and to manage it.

Fundamentally the architecture of our system is realized in the shapes that we make with our code.

All software has an architecture.

in some of them though it happened by accident in others it was worked on with great care

and grew to be something good good architecture allows us to

isolate one part of the problem from another this could be functional let's create services aligned with bounded context

so that they can change more independently of one another

or it could be in the jargon of architects non-functional let's shard the data in our system

so that it can scale linearly as demand rises

more formal approaches to architecture often discuss architectural measures of quality

this is the list from ISO I can see how talking about the illities of a system can help

but in reality I don't really buy into the idea of non-functional requirements very much

inside every non-functional requirement is a feature of the system that users care about If not, why are we doing it at all?

Even something as seemingly self-centered as making our code maintainable is

really about ensuring our ability to continue to deliver value to our users in the future.

These things, security, performance, scalability, testability, deployability, resilience, and so on,

are behaviors of our system as much as taking payment with a credit card.

We have to design the system to exhibit these behaviours.

If we are sensible, we will design our system to manage the complexity of these things by compartmentalising them from other behaviours where we can.

The reason that people get worried about these kinds of qualities of a system

and try to teach them somewhat differently is that they tend to have a broader impact than many features.

can't usually fix security or scalability or resilience in a single place in your system.

These are often referred to as cross-cutting concerns but that doesn't mean

that these things are architectural concerns and other things are not.

These are just behaviors that people often forget about while chasing other kinds of features.

Whether you call yourself an architect or not and and whether you work in a big team or alone, for any given piece of software,

you need to decide how it should behave.

And that means how you process credit cards or what color your buttons are, as well as is it okay to leak money to attackers

or fall over when there are more than three people using it.

This is our responsibility as software developers.

For some types of systems, some of these problems are genuinely difficult And it helps a lot when you have smart,

100

experienced people on the team who have seen ways to cope before.

101

But that doesn't mean that architecture is somebody else's problem.

102

Whether you are in your first day on the job or a grizzled veteran, your decisions may impact on the architecture of the system.

103

This is another of those slippery aspects of software.

104

There is very little distance between what looks like a small change and that small change having a massive impact.

105

In fact, the only things between that being true are luck

106

or a good working design and architecture that we understand and can use to guide our fine grained decisions.

107

So that gives us another step forward in understanding this complex concept a little better.

108

The architecture of our software is the collection of constraints

109

that we agree to adopt and maintain that will provide us some protection from making dumb mistakes.

110

My preference is to engage every developer, whatever their experience in architectural discussions,

111

allowing everyone to develop their own understanding of the architecture and to contribute to it as development proceeds.

112

Architect as a job description has seen a bit of a decline in recent years.

113

This is mostly in response to agile development's reaction against big upfront design.

114

The problem with this is, as Dave Thomas famously said, big upfront design is dumb, no upfront design is dumber.

115

So we need to start somewhere, but where?

116

The real answer is that you make a guess based on your understanding of the problem so far and your experience.

117

If you're any good at this kind of thing, you try to treat this guess as an experiment.

118

How could you show that your guess is wrong.

119

Try that.

120

Working incrementally, whether in fine-grained design or big picture architecture, is essential to doing a good job of anything complex.

121

There's a caveat to this, but as ever, you need to understand the trade-offs.

122

If the problem that you are solving is pretty common, then you could adopt a tried and tested architectural approach,

123

an off-the-peg architecture if you like.

124

This is a good idea as long as you understand the constraints and the fit of that architecture to your problem.

125

Because the other big problem with software architecture as an idea is that there's no one size fits all.

126

There's no such thing as a generically good architecture.

127

Rather it's a matter of whether a particular architecture fits the needs of the system.

128

one of the most successful widely applicable architectures was a layered

129

system backed up by a relational database something like this a ui some logic

130

and a database for systems with a moderate number of users

131

and relatively simple crud style features this was a very good choice i think

132

that one of the reasons it was a good choice though is quite informative i think a principal reason

133

that the clever but slow idea of transactions in relational databases took hold was

134

because it allowed programmers to write multi-user systems without worrying too much about the horrible complexity of concurrency.

135

If you open a transaction, read some data, change it, and write it out again, the database will block any other access to that data

136

while you're dealing with it and as long as

137

that as long as your transaction lasts it locks access to the data this was very good

138

if this architecture fit your problem it kept the programming model simple it's still good

139

if it fits your problem today and it fits quite a lot of problems quite well

140

however as the web grew in influence

141

and massive scale computing became more common having a relational database management system as a synchronization point to your data,

142

a source of truth, simply didn't scale.

143

So people started experimenting with other approaches.

144

I was once asked to consult on a huge project.

145

They had decided to use a NoSQL database as their primary data store,

146

which is fine, but they'd forgotten or didn't realize the importance of the protection

147

that transactions that they were more accustomed to had given them.

148

This NoSQL database wasn't transactional.

149

So data was shared by multiple processes and written to by multiple processes and the results were essentially random.

150

Whoever wrote last got to store their changes.

151

Everyone else would lose theirs and without any indication of the loss.

152

It made me feel a bit queasy just to think about this big system with all the data shared

153

and no protection or coordination between concurrent processes.

154

This was a problem of not really thinking about the architecture of the system but only the tools.

155

That's not the same thing.

156

A collection of tools alone doesn't make a software architecture.

157

This team had seen one of the big web companies develop

158

this great looking NoSQL database to help them scale up and it did that,

159

but only in the context of a whole raft of other choices and constraints that this team hadn't thought to apply.

160

There is another somewhat similar very common mistake that probably is a little closer to your own software.

161

Microservices were invented to decouple development.

162

They're intended to be independently deployable, freeing teams to work separately from other teams,

163

which means you don't get to test them together before you release.

164

If you are Netflix or Amazon, this is fantastic.

165

If you are a small development shop with a handful of developers, it's almost certainly overkill and so pretty inefficient.

166

And worse than that, most teams that I see that claim to practice microservice approach aren't.

167

They don't have independently deployable services, which means that they have to test them all together before they feel confident to release them.

168

This is in fact a distributed monolith, which is a rather complex choice, good for some things, but never simple.

169

I think that software is more complicated than we often think.

170

So the sensible thing is to approach it with a little bit more caution.

171

I don't mean that we should agonise for weeks or months before taking the first step, completely the opposite in fact,

172

but we should work on the assumption that our best guess so far is almost certainly wrong.

173

So architect our systems to allow us to recover when we learn more and find out where it's wrong.

174

This takes skill, certainly, but it is realistically the only sensible choice in my opinion.

175

Architecting a complex system is not something that someone in an ivory tower does at the start of a project.

176

It's also only partly intentional.

177

Like more fine-grained design decisions, it's an iterative incremental exercise in a kind of guided evolutionary process.

178

This is not terribly precise, and sometimes, even despite cleverness, expertise, and experience, people get things wrong.

179

That is, I am afraid, an inevitable consequence of dealing with something as tricky and complex as software.

180

A few years ago, a performance optimization strategy in Intel processors meant that encryption could be broken,

181

obviating all of the clever security architecture features in the web, cloud, on-premises systems, even mobile devices, and on pretty much every operating system.

182

That is a salutary lesson in how fragile architecture and design can be to tiny things.

183

a good way to approach this is to think about the things

184

that you are unsure of I was chatting to my friend Kevlin Henney a few days ago

185

and we were talking about design he said as soon as

186

someone says I don't know there's a seam in the design

187

that's quite a good way to think start the design of

188

your system with your best guesses based on what you know

189

so far and be on the look at for the things that you don't know or are unsure about.

190

You don't have to do a depth first exploration of these things.

191

In fact, you shouldn't.

192

But you do think about how to insulate the stuff that you do understand from the things that you don't.

193

Crude sketches in code of those things that you don't yet understand

194

and abstraction can act as placeholders while you make progress

195

and grow your understanding for the bits of the code that you do know.

196

Don't build world-class security into the first sketches of your system.

197

Don't take on the burden of making your system perfectly scalable from day one, but do design your system as best as you can imagine

198

so that you will be able to enhance security without undoing the progress

199

that you've already made and that you can take advantage of your great work

200

so far and allocate it differently so that it does scale up if that's a demand.

201

Insulate the parts of the system that you understand well from those that you don't yet.

202

These kinds of design approaches are at the heart of what I describe in my modern software engineering book.

203

Using the techniques to manage complexity, to give you a chance to go back and enhance or even correct architecture missteps when you discover them.

204

When we built our exchange at LMAX, we had three different fundamental attempts at the basic architecture of our system.

205

But because we'd taken an incremental approach to its design, only a small part of our effort was lost on each change.

206

My final piece of advice on software architecture is to aim to be intentionally a little bit vague about the detail.

207

Architecture should guide our decisions with constraints,

208

but in great architecture there are actually relatively few constraints but those that are there are pretty rigidly enforced.

209

Thank you very much for watching.

210

Thank you.

앱 다운로드

유창하게 말하는 데 필요한 모든 것

AI 발음 평가문장마다 점수 확인

IPA 발음 연습모든 소리 마스터

단어 학습나만의 단어장 만들기

단어 게임놀면서 외우기

QR 스캔

Download on theApp Store Get it onGoogle Play

✨ 추천 영상

129 문장

이 비디오로 영어 회화 연습하면 좋은 이유

데이브 패럴이 소프트웨어 아키텍처에 대해 이야기하는 이 비디오는 영어 회화 연습에 완벽한 자료입니다. 특히 IELTS 스피킹 준비생이나 전문적인 주제를 다루는 회화 실력이 필요한 분들에게 유용해요. 자연스러운 속도로 이야기하는 발화 패턴과 논리적인 설명 구조를 배울 수 있고, 전문 용어도 실제 맥락에서 익힐 수 있기 때문이죠. shadowspeak 또는 shadow speak 기법을 사용해 발음과 리듬을 따라하기에도 좋은데, 복잡한 아이디어를 명확히 전달하는 방법을 배우면서 동시에 회화 실력을 쌓을 수 있습니다.

맥락 속 문법과 표현

"Well you can kind of see what they mean but...": "kind of"는 말을 부드럽게 하는 표현으로, 영어 회화에서 자주 사용됩니다. 이를 통해 논평을 덜 직접적으로 전달할 수 있어요. 예: "I kind of agree with you but..."
"It raises as many questions as it really answers": "as ~ as" 구조로 두 가지 사물을 비교할 때 사용됩니다. 여기서는 "물어보는 것만큼 답도 주는"이라는 뜻으로, 균형을 강조할 때 유용해요.
"I think of myself as a software developer": "think of ~ as"는 "~을 ~로 생각하다"는 뜻으로, 자신의 정체성이나 역할을 설명할 때 자주 사용됩니다. IELTS 스피킹에서 개인적인 경험을 이야기할 때 활용할 수 있어요.

발음의 함정

이 비디오에서 주의해야 할 발음이 몇 가지 있습니다. "disciplined"는 "디시플린드"가 아니라 "디시플인드"로 발음해야 하고, "fractal"은 "프랙탈"이 아닌 "프랙털"로 발음합니다. 또한 "architecture"의 "ch"는 "카"가 아니라 "키"로 발음하는 것이 자연스러워요. shadowing site에서 이 부분을 집중적으로 연습하면, 전문 용어도 자연스럽게 발음할 수 있을 거예요. 특히 데이브 패럴의 부드러운 영국식 발음은 리듬을 따라하기 좋으니, shadowspeak 기법을 사용해 반복해서 연습해 보세요.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
조건문 if + 절, will/would + 동사 — 조건과 그 결과	If we're doing a good job we'll discover · If we are sensible, we will design
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	is produced · being called · was called
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	haven't been · have seen · has seen
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	really which is · services, which means · monolith, which is

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: What Software Architecture Should Look Like • Dave Farley • GOTO 2022 - 영상으로 영어 말하기 배우기

연습 모드 선택

앱 다운로드

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

What is an Organization? - the Nature of Organizations

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

What does an Architect Do?

Inside PMBOK Guide 8: What Project Managers Must Know | Episode 542

Directness with Respect: How to Make the Hard Conversations Easy

Cybersecurity Architecture: Data Security

Course Preview | AZ-104 | Azure Administrator Associate

Design Systems vs. Style Guides

What Are Microservices Really All About? (And When Not To Use It)

Want To Make Your Ideas Stick? Make It Into A Meme!

#02 Common Pitfalls of building Human Resources Strategies

이 비디오로 영어 회화 연습하면 좋은 이유

맥락 속 문법과 표현

발음의 함정

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법