软件设计的哲学——约翰·奥斯滕霍特

还有一些情况，其实没那么重要。

Other cases where they're not so important.

所以在那一章里，我想表达的是，异常越多并不一定越好。

So in that chapter what I was trying to argue is that exceptions having more exceptions is not better.

有时候确实有必要。

It is sometimes necessary.

但我总觉得，有些设计师以为，一个类抛出的异常越多，就越能体现自己是个优秀的程序员。

But I sometimes think that designers think that the more exceptions I throw from a class, the better a programmer I'm being.

觉得自己更谨慎、更周到。

I'm being a more cautious, careful programmer.

但我想说，不对，每个你抛出的异常，都会给使用你这个类的人增加负担。

And I would say, No, the problem is every exception you throw is imposing complexity on the users of your class.

所以如果你能减少抛出的异常数量，减少那些特殊处理的情况，整个系统的复杂度就会降低。

And so if you can, if you can reduce the number of exceptions you throw, the number of special cases you generate, that will reduce system complexity.

我在那一章里举了很多例子，说明只要对系统设计稍作调整，很多类型的错误根本就不会出现。

And I gave a bunch of examples in that chapter where in fact by just a slight change in the design of the system, whole classes of errors simply disappear.

这种情况根本不会发生。

They can't happen.

根本没什么需要处理的错误。

There is no error to deal with.

不过我要提醒一下，这种事偶尔确实会出现，但你必须格外小心。

But I will say this is something that this happens occasionally, but you have to be very careful about this.

在我教的软件设计课上，几乎每届学生都有人误解这一点。

And in the class I teach on software design, students have virtually every class there are people that misunderstand this.

他们在第一个项目里，完全没做任何异常处理。

And in the first project they have essentially zero exception handling.

他们正在构建一个分布式服务器，机器可能会崩溃，但他们连网络错误都不检查。

They're building a distributed server where machines can crash and they don't even check for errors in the network.

我就问他们：你们这里连错误检查都没有，要是系统崩溃了怎么办？

And I say, you have no error checks here, what happens if a system crashes?

他们回答：哦，我们直接把那些错误给排除掉了。

And they say, oh, we just defined those errors out of existence.

我说，不对，错误依然存在，只是你没去管它。

I say, Well, no, the errors are still there, you're just ignoring them.

你不能这么干。

You can't do that.

所以，我觉得这一章我得特别提醒大家注意。

So anyhow, I think this is a chapter I have to warn people about.

这个东西很容易被用偏了。

It's really easy to take this one in bad directions.

就像香料一样，用一点点，炒菜能提味，但要是放多了，整个就毁了。

It's kind of like a spice, you know, they use tiny amounts of it and you're cooking and you get a good result, but if you use very much, you end up with a mess.

是的，但我觉得错误、异常、系统出问题这些事，我们在设计时根本谈得太少了。

Yeah, but I feel errors, exceptions, things going wrong, they're they're one of the things that are we don't really talk to enough about it when we think about design.

我回顾那些系统宕机事件时，记得很多都是在优步发生的，其他公司也一样。

When I look at outages, I I remember a lot of outages that we had specifically at at Uber, but even at other companies.

很多时候我们查原因，发现都是因为错误处理不当。

A lot of the times when we looked into what caused it, it was, you know, like a mishandling of of an error.

问题出在一个系统，我们误把它当成成功了。

It came from one system, we mapped it incorrectly as a success.

还有很多类似的边缘情况，我们要么误解了错误，要么误解了意外的响应。

And there was a lot of these edge cases, which were we we misunderstood either errors or unexpected responses.

说到底，其实都是同一类问题。

You know, they're all the same thing.

说到底，还是跟错误有关。

It it was something with errors.

我们当时就是说不清楚到底哪里出了问题。

And I think we struggled to put a finger on it.

我们试过一些办法，比如改进响应的映射方式。

You know, we we we looked at ways that were like, okay, let's map map responses better.

搞个白名单。

Let's have white list.

搞个黑名单。

Let's have black list.

但在规划阶段，我真不记得有这回事。

But during the planning phase, I don't really remember.

我觉得规划的时候，大家总是很乐观，觉得系统会怎么运行，组件之间会怎么通信。

I feel for planning, people tend to be optimistic of here's how it works, here's how these things will communicate.

我几乎不记得有哪次规划会讨论：‘万一出问题怎么办？’

And I rarely recall planning sessions where we thought, okay, what could go bad?

我们怎么才能发现这些问题？

How will we catch it?

我们怎么去恢复？

How will recover?

你说得对，我同意你的看法——人们在做整体系统设计时，根本不会优先考虑异常处理。

So it's just I think you make a good point in that I think people don't I don't think exception handling is top of people's mind when they are doing the overall system design.

通常都是等实际遇到问题了，才临时想办法解决。

It just kind of it just sort of happens tactically once people discover potential problems.

没错，你正好说出了我想表达的这个观察。

Yes, this is I think you're putting what I'm trying to put as this observation.

这真是个挺有意思的问题。

It's just a very interesting one.

我给人们的建议是，当你在设计一个模块、考虑通过接口暴露哪些特殊情况和异常时，应该试着站在调用者的角度想一想：他们会怎么处理这些情况？在设计时，尽量代入用户的心态。

So the one general piece of advice I have for people is that when you're building a module and thinking about what kinds of special cases and exceptions you're going to export through your interface, You should think about how you think the callers are going to deal with these and try and put yourself in the mindset of the user as you're thinking through these.

你看，与其搞出十种不同的异常，不如想想其实用户也就那么两三种处理方式，干脆把所有情况归成两类异常就够了，没必要搞十种。

See, rather than having 10 different exceptions, is it actually there's only really two different ways people are going to handle this and so I can boil it all down into two kinds of exceptions rather than 10 kinds of exceptions, for example.

所以关键是要从调用者的角度来考虑问题。

So I think the key thing is to think about it from the caller's standpoint.

说到这个，我想起一个优秀设计师最重要的特质之一，那就是

By the way, that brings me to I think what I think is one of the most important attributes of a really good designer, which is

是什么？

What is it?

他们能切换思维模式，从完全不同的视角来看待问题。

They can change their mindset and think about things from very different point of views.

当我设计一个模块时，我会考虑这个模块的所有细节。

So when I'm designing a module, you know, I'm thinking about all of the details of that module.

但这时候我可以切换视角，站在用户的角度来想，其实我不需要关心这些细节。

But then I can change my mindset to think about the user of this module and realize I don't want to have any awareness of those details.

尤其是当我使用一个模块的时候，我绝不会去利用那些我知道的内部实现。

And in particular, you know, when I'm using a module, don't want to take advantage of things I might know about the inside of that module.

我只该用接口里明确提供的那些功能。

I only wanted to use things in the interface.

所以，能随时切换思维方式——一会儿深入细节，一会儿又彻底抛开它们，从完全不同的角度看问题，这真的特别重要。

And so being able to shift your mindset and think about things at one point, but then completely put those out of your mind and take a totally different view some other time, that's really powerful.

好设计就是这样来的：设计的时候，也要想着将来谁会用它，他们会有怎样的体验。

That's how you come up with good designs, think, again, when you're designing something, can also think about it from the standpoint of somebody that's going to be using it.

挺有意思的。

Interesting.

所以你的意思是，具备同理心，能站在别人的角度思考——不管是用户、其他开发者，还是将来要维护这段代码的人——这能让我们成为更好的工程师？

So are you saying that having empathy and having the being able to put yourself in the shoes of another role, may that be a customer, another developer, another developer who will be working on this, that could make us a better software engineer?

我正想说‘同理心’这个词。

I was about to say the word empathy.

我本来想说的是，这种能力不仅在工程领域很有价值，在人际交往中也同样重要。

What I was going say is, I think this skill set has tremendous value in social context as well as in engineering context.

能够站在别人的立场上去思考问题。

The ability to think about things from some other person's viewpoint.

顺便说一句，我特别喜欢计算机科学的一点是，别人总觉得我们是书呆子，但其实我们用在系统里的很多理念，跟社会系统里的情况都有很有趣的对应关系。

By the way, one of the things I love about computer science, people think of us as sort of geeky, nerdy people, but many of the ideas that we use in computer systems actually have interesting analogies in social systems as well.

确实挺有意思的，因为我刚开始走软件工程这条路的时候，跟你一样，学编程、上大学、找第一份工作，等等。

Yeah, it's just interesting because when I, you know, I'll start off like you on the software engineering journey, you know, start to learn to code, go to college, get my first job, etcetera.

一开始我以为最难的是写代码，但后来跟每个有几年经验的开发者聊过之后，我们都达成一个共识：软件工程、编程里最难的，其实是人。

And initially I thought the hard part is the coding and every developer I talk to, every engineer I talk to above a certain years, we always have this discussion that the hardest part in software engineering, computers, and programming, it's the people.

回想一下你工作头几年，等你掌握了语法、学会了调试，再回头看那些最让你头疼的项目，最大的问题往往不是技术，而是沟通不畅——比如需求理解错了，或者大家对事情的预期不一致。

You know, when we think back of after your first few years, once you get the syntax and and you learn how to debug and those things, you think about what was the hardest project that was, what was the biggest problem, what caused me the most headache, and it's oftentimes miscommunication, you know, like we misunderstood each other, the spec was off, etcetera.

当然，系统崩溃也会发生，但通常根本原因是我们没料到这种情况会出现。

Of course, there's outages as well, but what usually the root cause is we did not expect this to happen.

因为我们缺乏对用户的同理心。

We didn't have the empathy for the user.

而且，最常见的是和同事之间的冲突，就是一起工作的人。

And and, yeah, it it usually and the biggest one is is conflicts with teammates, with people that you work with.

全是人与人之间的问题。

It's all human things.

这挺有意思的。

So it's interesting.

有个笑话常说，计算机科学里最难的是缓存和命名，但我还得加上人这一项。

There's this joke that the hardest thing in computer science are, I think, caching and naming things, but I will add people as well.

是的。

Yeah.

这说法挺有意思。

That sounds interesting.

没错。

Yep.

你书里没提到的一点是，当然，书不可能涵盖所有内容，但很多团队和科技公司都会做一种叫设计评审和讨论的实践。

One thing that in your book you don't touch on, of course, know, the book cannot touch on anything, but it's a practice that a lot of teams and and tech companies use is these things called design reviews and discussions.

意思是，在开始构建系统之前，有人会先把计划写下来。

The idea is that someone, before building a system, will write down a plan.

然后大家可能会开个会。

People will either have a meeting.

亚马逊就特别注重这种写作文化，大家聚在一间屋子里，先读计划，再一起讨论。

Amazon famously has this writing culture where people get get into a room, they they read the plan, and then they discuss.

其他地方则常用谷歌文档，甚至像Figma这样的工具来完成。

In other places, it's done with Google Docs and and even some others like like Figma.

他们会用自己熟悉的工具画图、做标注，互相反馈。

They use their own tools to kind of, like, draw visuals and comment on it.

你觉得在动手之前，先通过白板或其他方式把计划讲清楚，再互相挑毛病，这做法怎么样？

What what is your take of before building a system explaining a plan, either whiteboarding or other ways, and then kind of criticizing each other's plans?

你自己有没有在工作中用过类似的方法？

Have have you either done this to to some of the things that you do?

你在教设计课的时候，会鼓励学生这么做吗？

Do you encourage students in your class, on design classes, to do this?

当然了，我所有参与的项目都会这么做，以前做创业的时候，我们经常搞设计评审。

Oh yeah, we do this certainly all the projects I work on and certainly when I was doing startups, we would do design reviews.

这些评审通常比较随意。

They were relatively informal.

我们不会写很长的文档，但会聚在一起讨论想法。

We didn't have lengthy written documents, but we'd get together and talk about ideas.

这时候，不同方案就会冒出来，大家讨论各自的利弊——只要能让多个人一起思考一个问题，出来的点子肯定比一个人单打独斗强得多。

And this is where again you get the multiple designs and you talk about the trade offs and you know, it's just if you can get multiple minds to think about a topic, it's pretty clear you're going come up with better ideas than if just one person does it.

这其实也是个关键点，有些聪明人得先放下过去的习惯，因为他们以前待的环境里，根本指望不上别人给出有用的反馈。

Again, this is how, this is an area where smart people sometimes have to get past their history because they've been for much of their life in environments where they couldn't expect to get a lot of useful input from other people.

但当你和一群顶尖聪明的人一起工作时，两个人的脑子肯定比一个人强，这是明摆着的。

But when you're working at the very highest level with very, very smart people, you know, two minds are better than one, clearly.

所以我完全支持这种方式。

So I'm all for it.

不过呢，也别陷入过度分析的陷阱里。

Again, you know, you don't want get caught in analysis paralysis.

所以得琢磨清楚，到底该在什么时候做，花多少时间合适。

And so trying to figure out what's the right place to do it, how much time to spend on it.

把握好这个度确实是一门艺术，但我完全支持这么做。

There's a certain art to getting just the right level, but I'm all for that.

而且

And

我觉得最近几年因为远程办公，情况可能变了。

I think this might have changed in the last few years because of remote work.

你知道，远程办公曾经爆发式增长，现在又稍微收缩了一些。

You know, we've had an explosion of remote work and now it's a bit of a contraction.

但2020年之前，那些最有创新力的公司，尤其是正在崛起的初创团队，办公室里到处都是白板。

But I remember before 2020, some of the most innovative companies, when you went into their thing or startups who were gaining momentum, what they had is whiteboards and and these erasable whiteboards everywhere.

在那些地方，实际发生的情况是——我以前带过一个团队，我们甚至主动要求配白板——人正忙着自己的事，突然有人冒出个想法，你就说‘等等’，然后立马跑去白板前画起来，画完能擦掉，有时候就留着，有时候拍张照保存。

And what would happen in these places actually, I even had one of my older teams where we actually requested a whiteboard, is people, you know, you're just doing your thing, someone says something, you're like, hold on, and then you go to the whiteboard, you start whiteboarding and, you know, you can erase it, Sometimes you leave it there, sometimes you photograph it.

说到底，就是随时触发、随需而动，任何一点灵感都能成为起点。

Basically, it it's just like on on demand when there's a it could be any trigger.

也可能是听错了。

It could be just mishearing.

有时候就是人聚在一起，把想法都摊出来，这种面对面交流有种特别的效果。虽然很多初创公司试图用数字工具来复制这种体验，但真正在现场把想法画出来，尤其是像软件这种东西，画框和箭头真的很有帮助。

It can be doing you just have people come together, do their ideas, and there's something special about there haven't startups have tried to replicate this digitally, but there's something special about in in person just, you know, like doing just getting your ideas out there, especially when we're talking about something like software where you do you know, boxes and arrows do help.

我完全同意。

I totally agree.

我特别喜欢白板，也喜欢面对面开会。

I love whiteboards and I like having meetings that are in person.

在我的职业生涯中，我还发展出一种用白板解决复杂问题的方法，这些问题未必是技术性的。

I've also over my career developed a technique for using whiteboards to resolve complex issues, which may or may not even be technical.

比如公司里其他类型的管理难题。

Other kinds of management issues in a company.

我发现很多人开会时，总是各说各的，反复争论同样的观点，一圈一圈地打转，就是没法得出结论。

And what I found is that oftentimes people get in meetings and they just kind of talk past each other, repeat the same arguments and counter arguments and it just goes round and round and round and never reaches a conclusion.

所以遇到这种情况，我会站在白板前，把支持和反对的理由都列出来。讨论的规则是：只要你觉得有道理，任何观点都可以提。

So what I do in these situations is I stand at the whiteboard and basically I list typically we're arguing for or against something, just list all the arguments for and all the arguments against and the rule of discussion is you can make any argument you think is reasonable.

没人能说你的观点不成立，必须删掉。

No one is allowed to tell you your argument has to be removed, it's a bad argument.

每个观点都要写到白板上。

Every argument goes on the board.

但已经写上去的观点，不能再重复说。

But you are not allowed to repeat an argument that is already on the board.

这一点特别关键。

And this is really important.

把所有观点都公开摆在那儿，每个人的看法都算数，谁都能参与，没人能阻止你把自己的想法写上去。

So having the arguments up so everybody can see, everybody's argument is valid, you know, everyone's allowed to contribute, no one can stop you from putting your argument on the board.

所以每个人的论点都会被列出来。

So everybody's arguments goes up.

然后讨论会自然地走到一个没人再有新想法的节点。

And then the discussion just naturally reaches a point where nobody has anything more to say.

这样一来，讨论时间就大大缩短了。

And so this shortens the discussion.

接下来我会做个快速投票。

And then what I do after that is I take a straw poll.

最让我惊讶的是，你真该试试看，因为这真的很惊人——人们在两边激烈争论，你以为他们完全对立。

And what's amazing to me, you should try this sometime because it's really, it's quite shocking, is that people will be arguing violently on both sides and you'll think there's total disagreement.

但到最后，我们会做一次快速投票，告诉大家：你可以根据自己的判断，给这些观点赋予不同的权重。

And then at the end, and then we do a straw poll, you tell everybody, You get to weight these arguments in any way that you think is appropriate.

你自己决定哪些观点更重要，哪些不那么重要。

You decide which ones you value, which ones you don't value.

我们该选A还是B？

Should we do A or B?

我们几乎总能达成非常强烈的共识。

We almost always end up with a really, really strong consensus.

这真的让人意外。

It's shocking.

我经常参加这样的会议，明明觉得大家意见完全不合，结果一投票，居然全票通过。

I'll be in these meetings where I think we have total disagreement here and then we do the vote and it's unanimous.

嗯，看来我还没试过，所以这事儿听起来就像那种——我不是不信你，只是我自己没经历过，抱歉。

Well, it sounds I have not done it, so it's it's, you know, it sounds one of those things where I don't believe I wouldn't believe you, I'm sorry.

但我真的相信你。

I I I do believe you.

不过，就像你说的，我想我还是会去试试这个方法。

But, yeah, as as you said, I think, you know, I'm I'm gonna try to try this out.

这事儿得靠白板。

It's a whiteboard.

关键就在于

It's all about

白板，我觉得。

the whiteboard, I think.

没错。

Yeah.

我觉得不管是听还是看的，都能明白为什么我这么喜欢这样的讨论。

And I think anyone listening or watching, just like this is why I love these discussions.

这就像是拿到一个可以亲自试试的策略。

It's just like getting a tactic that you can try out.

现在越来越多公司要求员工每周至少来几天办公室，你就可以拿块白板，直接试一试。

And now that more and more companies are doing at least a few days in the office, you get a whiteboard, try it out.

顺便说一句，这种方法最适合那些人普遍聪明、理性，而且目标一致的环境。

By the way, this works best in environments where people are first generally pretty smart and reasonable and goal aligned.

比如在初创公司或者工程团队里，大家通常目标一致，都想达成同样的结果。

Like, you know, in a startup for example, or an engineering team, you're typically goal aligned, you all want to achieve the same result.

你说，这方法能在国会里用吗？两边政党意见对立的那种？

You know, would this work in Congress with opposing political parties?

不行。

No.

完全不行。

No.

在政治环境中是行不通的。

Not in political environments.

幸运的是，我们主要并不处在那样的环境中。

Fortunately, we don't operate mostly in those environments.

确实如此。

Well, yeah.

我觉得，从我的角度看，科技行业的发展趋势越来越明显了：即使在大公司里，大家也越来越认可团队需要有清晰的目标，因为如果没有目标，每个人都会往不同方向走。

And I think, you know, one nice thing about how the tech industry seems to be evolving from my perspective is it's more and more common and accepted, even at large companies, that you do want teams to have clear goals, like have those goals, because if you don't have it, everyone's gonna go in different directions.

所以我觉得这种做法正变得越来越普遍。

So I think it's becoming more common.

要是公司不这么做，很快就会陷入混乱。

Also, companies don't do it, they fizzle out pretty quickly.

关于设计，也有个类似的问题。

So similar question on design.

在设计这件事上，主要有两种看法。

There's two schools of of thoughts when it comes to design.

一种是提前把设计做好，另一种是别提前设计。

One is let's design up front, and the other one is let's not let's not design up front.

不如直接做原型吧，或者干脆先搭个东西出来，让代码自己说话。

Let's just do prototyping or just, you know, build something and let let the code decide.

你更认同哪一种做法？

Do you subscribe to either of these approaches?

是花时间提前规划，还是直接上手原型？你有没有遇到过某些项目，明显更适合其中一种方式？

Taking time upfront or just dropping into and prototyping, or have you seen times or types of projects where one just works better than the other?

我个人觉得，设计贯穿在整个开发过程中。

My personal belief is that design permeates the entire development process.

从一开始就要考虑设计，写代码的时候要，测试的时候要，修bug的时候也要，设计这个事得一直想着。

You do it upfront, you do it while you're coding, you do it while you're testing, you do it while you're fixing bugs, that you should constantly be thinking about design.

我觉得至少得在开始前稍微规划一下。

I think you should always do at least a little bit of design upfront.

当然，不是那种瀑布式的方法。

Again, you know, not waterfall method.

我们必须意识到，现在的软件系统太复杂了，根本没法完全预判设计决策会带来什么后果。

It's important to realize that our software systems are so complicated that we are not able to predict the consequences of our design decisions.

我们根本做不到。

We simply can't.

但我认为提前做一些设计，带着一些假设去推进，真的很重要。

But I think it's really important to do some design and to have some hypotheses to work from.

然后你开始实现，当然，一旦真正动手，所有计划都会被打乱，你会发现一大堆问题。

And then you start implementing and of course, you know, once you get in battle all your plans kind of fall apart and you'll discover lots of problems with it.

所以一旦发现问题，你必须随时准备调整。

And so you have to be prepared to revise as soon as you discover problems.

但如果你连一点前期设计都不做，我觉得你是在浪费时间写那些几乎不可能有用的代码。

But if you don't do any design upfront, I think you're wasting your time on code that is just very unlikely to be useful.

我唯一会支持不设计就写代码的情况，是你太年轻、经验太少，根本不知道该怎么设计。

The only time I'd argue for coding without design is if you're so young and inexperienced that you really have no clue how to do design.

那时候，你可能只能先写点代码，从实践中慢慢学。

Then, you know, you may just have to write some code and start learning from it.

但无论如何，一旦发现问题，一定要做好重新设计的准备。

But in any case, absolutely be prepared to redesign, you know, as you discover problems.

是的，很多年前我有个同事说过一句特别有意思的话，那时候我们已经都是有经验的工程师了，正在讨论为什么软件开发总是这么难。

Yeah, like I had one of my colleagues a long time ago, many years ago, he said something super interesting because we were talking about why software is and we were experienced engineers at this point.

明明前期做了充分规划，为什么有些项目还是拖得特别久？

Like, why do some projects take a lot longer even if we do proper planning upfront?

为什么有些项目反而挺顺利的？

Why are some projects actually, you know, they're they're pretty easy?

他当时说了一番很耐人寻味的话。

And he says something interesting.

他说，写软件就像在一片未知地形里行军，我们看得见目标，但脚下是什么完全不清楚。

He's like, software like, building software is a little bit like like we're in a terrain, you know, like and we need to march to that location.

我们能看到终点，可路到底怎么走，谁也不知道。

We we we see that we see the target, but we the terrain is unknown.

有时候一路走过去，一切都很顺，完全符合预期。

And sometimes you just walk there and it's exactly how you'd expect.

但有时候正走着，突然一块大石头冒出来，你得爬过去，结果刚翻过去，又一块冒出来了。

Other times you're walking and, oh, suddenly there's a big kind of boulder appears out of nowhere, and you kind of climb over it, then another one comes.

有时候你正走着，突然前面的地雷炸了，眼前出现一个大坑，你根本没想到这地方竟是雷区。

Sometimes you walk and, like, a mine explodes right in front of you, and suddenly you have this massive hole and you you didn't know this this was a minefield.

他说了这话之后，我特别有共鸣，因为我觉得关键就在于有多少未知因素，以及应对方式完全不同。

And and he said and this analogy kind of resonated with me because I realized a lot of it is about, like, how how much unknowns are are unknowns, and the approach is just very different.

对吧？

Right?

比如你开发一个之前做过的技术栈或产品，跟完全全新的东西，或者用新技术、用框架的测试版，这些情况风险不一样，可能出问题，也可能顺利运行。

Like, if you're building a tech stack or product that you've done before versus something that is completely new, or using new technology, or using a beta version of a framework, it could have issues but maybe it'll work and so on.

是的，我觉得很大一部分取决于你是否在熟悉的领域里工作。

Yeah, I think a lot of it has to do whether you're in a domain you've been in before or not.

不是你运气好，碰上了一片平坦的地形。

It's not that you got lucky and there was a flat field.

而是因为你以前走过这片山区，知道哪些路能走。

I think it's more that, oh, I've actually walked through this mountain range before and so I know the right paths.

就像你之前做过五个设备的驱动，现在做新的，心里大概清楚会遇到哪些坑，流程也就更可预测、更顺畅了。

And so, you know, if you're a driver for a new device and you've built drivers for five devices before that, you kind of know what the main problems are and the process is much more predictable and smooth.

如果你处在新环境里，说实话，也许我只是运气不好，但我从来没在新环境里有过顺顺利利的经历。

If you're in a new environment, well I don't know, maybe I'm just unlucky but I don't think I've ever had a smooth experience when I'm in a new environment.

太难预测了。

It's just too hard to predict.

我也是。

Neither have I.

唯一算得上新环境的，其实也不算真新，比如框架的新版本，改动不大，或者语言的新版本，向后兼容所有重要功能，你也没用什么新特性，就是这类情况。

Like the only kind of new environment, well it's not really a new environment, like a new version of a framework and it's not a big change or you know, a new language release, which is backwards compatible with all the important stuff, but you're not using a new features, that kind of stuff.

但这种算假的新吧？

But it's kind of fake, right?

其实跟以前差不多。

Like you're, it's kind of the same as before.

我想聊聊写这本书的事。

One thing I'd like to get into is the writing of this book.

因为这本书给我的感觉是，里面全是特别实用的见解。

Because again, like this book, it feels to me, it has just a lot of really kind of practical insights.

首先，我没怎么见过专门讲软件设计的书。

Now, first of all, haven't seen many books written about software design specifically.

你是怎么想到要写这样一本书的？说实话，这事儿挺难理清的。

Did you get the idea to even start writing a book about this, you know, like a It's pretty hard to tangle

这其实是个挺漫长的过程，但它的起点是我当年在斯坦福教的那门课。

kind of a long process, but the path leads through the course I taught at Stanford.

所以背景是这样的，就像我之前说的，我特别喜欢写代码。

So the background for this is, as I mentioned earlier, I love coding.

我是少数还坚持写大量代码的教授之一。

I'm one of the few professors that still writes large amounts of code.

我每年至少要写个五六万行，甚至十万行代码。

You know, I try to write five or 10,000 lines of code a year, at least.

写代码占了我相当大一部分时间。

It's been a significant fraction of my time coding.

而且我特别喜欢设计。

And I love design.

我觉得，设计是人类历史上最了不起、最有创造力的形式之一。

I think design is one of the most amazing, creative forms that has ever existed in the history of humankind.

这真是个既迷人、优美，又充满挑战的领域。

It's just really fascinating, beautiful, challenging domain.

所以我经常琢磨，到底什么才算好的设计？怎样才能写出优秀的软件？又该用哪些方法呢？

And so I've often I think about it and I try to think, what is a good design and how do I get to how do I design software that's good and what are the techniques for that?

但渐渐地，我惊讶地发现，根本没人教这个。

But over time I noticed, to my shock, nobody teaches it.

说实话，除了我后来在斯坦福开设的这门课，我敢说全世界再找不到第二门课，把软件设计本身——而不是工具或流程——作为核心内容来教。

Literally, other than the course I eventually started at Stanford, I don't think there's a single course anywhere in the world where software design, not tools or processes, but the act of software design is the primary element of the course.

这件事在我心里压了十多年，越来越重。

And so this just kind of graded on me for, I don't know, a decade or more.

等我回到斯坦福的学术圈，加上之前在业界积累的大量开发经验和想法，我才真正开始认真思考这个问题，最后决定：管它结果如何，先开一门课试试看。

And once I got back to academia at Stanford and now I have this experience in industries where I'd have a lot more software development experience and more ideas myself, I started thinking about this and I finally decided I'm just going who knows what's gonna happen, but I'm just gonna try teaching a course, see what I can do.

这逼着我梳理自己的想法，试着把它们提炼成一些简单明了的原则。

And so that forced me to start thinking about my ideas and try and capture them in sort of simple principles.

你说没人教设计。

You said no one teaches design.

我跟你讲讲在科技公司工作的人怎么看这个问题。

You know, I'll tell you the perspective from like someone working at a tech company.

通常我们招聘应届生或者工作几年的新人，都不会考软件架构这类问题。

Like, usually we don't interview new grads or people with a few years experience on this on software architecture topics.

面试一般就两块：写代码，然后设计一个复杂系统。

Usually there's interviews coding and then software architecture or design a complex system.

原因很简单，你得在行业里干上几年，才能慢慢体会到这些东西。

And the reason being, well, you need to work in the industry for several years to start to get a sense for for for this thing.

但我感觉你其实是把这整个逻辑给翻过来了。

But I have a feeling you kind of you know, you turned this upside down.

你通过这门课，其实是在证明——哪怕刚学会编程的学生，也能学会设计。

You're you're you've kind of proven or well, you're attempting to to to do with the class that design can be taught even for students who have recently learned to code.

你的方法是什么？那些上过课的人反应怎么样？尤其是现在，有些人已经工作好几年了，他们回来的时候，带着一套同龄人没有的本事。

What what was your approach and and what what has your response been from from the people who've done it, especially now that, you know, some of those folks are have been out of industry for years, and I'm sure they're coming back with some of their experience because they now have a skill set that a lot of their peers do not.

是的，所以我决定开这门课，接下来的问题就是：我该怎么教呢？

Yeah, so I decided to teach this class and then the question is, well, how do I teach it?

我用的模式，是我高中时的英语写作课。

And the model I used was my English writing classes from high school.

我不确定现在是不是还这样教，但当年我学英语写作时，老师布置作业，你写完交上去，老师批改后，你再修改重交。

I don't know if this is the way it's still done today, but back when I took English, the way you learn to write is you would get an assignment, you'd write something, your teacher would mark it up and then you would rewrite it and submit it again.

有时候得反复改好几遍。

And you might do several iterations on it.

我觉得关键有两个：第一，得到反馈。

And I think the key elements are first, getting feedback.

得有人能对你的作品提出批评意见。

So you have somebody that can criticize your work.

第二，根据反馈重新做一遍。

And then second, redoing to incorporate that feedback.

真正把反馈和概念内化，其实是在反复修改的过程中发生的。

And it's the process of redoing something, I think, where you really internalize the feedback and the concepts.

所以这门课就是这样教的。

So that's the way the class is taught.

整个学期下来，学生们会分三个阶段完成一个比较重要的项目，然后我们会进行深入的代码评审。

It's over a course of a quarter, people do basically three stages where they build something significant and then we do extensive code reviews.

比如说，我每一份团队的代码都会逐行审阅，这意味着

For example, I read every line of code for all the teams in the class, which means

那学生们到底都做些什么呢？

And only what do people build?

这个项目具体是做什么的？

What is the project?

能举一个具体的项目例子吗？

Or what was one of the projects?

实际上，前两个项目正好是把 Raft 一致性协议拆成了两个阶段来实现。

So actually the first two projects happened to be the raft consensus protocol divided up into two phases.

这个设计其实有不少巧妙的难点，特别容易让学生犯错。

And that's actually turns out to have some really interesting design problems that confound students and lead to lots of mistakes.

整个过程是这样的，一开始我什么都不提示，不给任何线索，也不提供结构。

So it's this process of, and when they start off I give them no clues, no hints, no structure.

他们必须从零开始完全自己搞定。

They have to do it completely from scratch.

这可是他们人生中第一次做这种事。

This is the first time in their lives they've ever done anything like that.

所以对学生来说，这既特别有趣，又特别让人紧张。

So it's actually both very fun and very scary for the students.

接着我们会进行深入的代码评审：课堂上大家互相看项目、提意见，而我会逐行阅读每一份代码，每支团队我都会花大约一小时跟他们讨论。

And then we do this extensive code review where they review it in class and other students read their projects and give feedback and then I read every line of code and I spend about an hour with each team.

他们写的代码通常有两三千行，我会给出五到一百条反馈。

They typically get 50 to 100 comments from me on their, so two to 3,000 lines of code they've written.

然后他们再回去修改。

And then they go back and they rework.

我觉得真正的成长时刻，就发生在这些时候。

And I think that's when the moments come from students.

当他们收到我的反馈，我指出代码太复杂的时候。

When they get the feedback from me where I can point out code is complicated.

大家通常都知道代码复杂，但我会具体说明为什么复杂——因为你没遵循我们之前讲过的那个原则，而如果你照着做，代码就能简单多了。

People generally know that code is complicated but then I can point out, here's why it's complicated because you didn't follow this principle that we've been talking about and here's how if you apply the principle, you can make it simpler.

等到他们交第二个项目时，质量明显提升了很多。

And then they come back with their second projects and the second projects are so much better.

你能感觉到学生特别兴奋，因为他们真正体会到了自己的能力。

And you can tell the students are really excited because they can kind of feel their power.

他们意识到，原来我能让这个东西变得好这么多。

They can feel that I was able to make this a lot better.

所以我一开始还担心学生会对这门课有什么反应，结果他们的体验非常好。

And so, you know, I was worried about how the students would react to the class, so it's an extremely positive experience for the students.

整个学期下来，你能明显看到他们对软件的理解发生了深刻的变化。

You can tell over the course of the quarter the way they think about software has changed really in significant ways.

学期快结束时，我还特意提醒他们：你们以后进公司会发现，很多连资深工程师都不懂的东西。

And actually I warned them at the end the quarter, I say, you know, I just want to warn you, when you go into companies, you're going to find you know a lot of stuff that people in the companies don't know, even much more senior engineers.

所以我们讨论如何应对这种情况，因为作为新人，你可能没什么能力去改变公司。

So then we talk about how do you deal with that because as a junior employee you may not have much ability to change the company.

但我完全相信，设计是可以通过教学传授的。

But anyhow, so I totally, totally believe design can be taught.

当然，经验还是必不可少的。

Now you still need experience.

不是说上完我这门课，你就能立刻成为世界级程序员。

Know, it's not like you're going be a world class programmer after one quarter in my course.

是的。

Oh yeah.

但我认为，至少他们可以启动这个过程，获得一种全新的软件思维方式，这跟他们以前在课堂上学到的都不一样。

But I think that's they can start the process in motion and give you a new way of thinking about software that you've never thought about in your classes up till now.

对。

Yeah.

我觉得，经历过这门课的学生，他们的经验会慢慢积累起来。

And I think you can probably like my sense is that the students who go through this class and and, you know, they they build up their experience.

他们也在这个过程中更了解自己。

They also learn about themselves.

他们学会如何挑战自己，以及如何表达这些想法。

They they learn how they can challenge themselves, how they can talk about it.

其他软件开发者通常进入行业后的头几年，都是靠碰壁慢慢积累经验的。

Other software developers take, you know, like, when you enter the industry, like in the first few years, you're just gonna like learn the hard way.

我记得我刚毕业、还是初级开发者的时候，那时候我其实还在上学，但已经在公司上班了，一位资深开发者告诉我：你得这么做。

Like, remember that when I was a new grad or a junior developer, you know, started out of college, right, I was actually still doing college, but I was working at a workplace And a senior developer told me, I need to do this.

他让我做规划，说我们要用这项技术，你得实现这个功能和那个功能。

You know, did the planning, we're gonna use this technology, you need to implement this and this.

我当时心里总觉得不对劲，但还是照做了。

And I just had a bad feeling about it, but I did it.

结果问题越积越多，越来越复杂。

And it it it just became worse and worse and more and more complicated.

那个解决方案用的是公司自研的数据库，本来就性能不好，情况变得更糟了。

And if the the solution that it was some some in house database that had performance issues, it got bad.

情况变得特别糟，后来那些资深开发人员都躲开了。

It it got really bad, and, you know, the developers the senior developers stepped away.

结果项目搞了几周后，客户特别不满，因为页面加载要十五秒，这完全说不过去。

And in the end, like, weeks into the project, the the customer is frustrated because, like, a page load took fifteen seconds, which is on a like, it's it's not it was not okay.

然后我就在周末一口气干了二十多个小时，没怎么休息。

And then I I just, over a weekend, I I I worked I must have worked for, like, I don't know, twenty plus hour.

我干脆重写了整个系统，按我自己的方式来，所有问题一下子就解决了。

I just rewrote the whole thing the way I I would have done it, and it all of the things were fixed, etcetera.

但那时候我心里总在想，我是不是有点太固执了？

But it it felt to me like I I was kind of like I was thinking like, am am I being crazy?

毕竟那位有经验的人明明告诉我该这么做。

Like like, this experienced person told me to do this.

我当时根本说不清哪里不对。

I just didn't really have the vocabulary.

我也不够相信自己，没底气觉得我能做得更好。

I didn't have the the faith in in myself as well that that I I can do this.

每个人迟早都会经历这些。

So and everyone goes through these things eventually.

对吧？

Right?

你慢慢就会明白，得自己碰过壁才知道，但我感觉你可能在给这些学生省去一些弯路。

Like, you kinda learn, you you burn yourself, but I I feel you might be giving those students a bit of a shortcut to to maybe avoid some of these pitfalls.

我觉得那段经历对你来说特别有帮助。

I suspect that experience was really good for you.

确实很有帮助，完全没错。

Oh, it was really good, totally.

先走错一遍，让你的直觉得到验证。

Do it the wrong way and see your gut feeling validated.

下次你就能说得更清楚，为什么那样做有问题，再回头用正确的方法做一遍，就能体会到差距有多大。

So next time around you can probably kind of put some words to that and talk more with more authority about why that's a problem and then going back and doing it the right way and seeing how much better it is.

那对你来说一定是一段特别宝贵的经历。

Mean that must have been a really great experience for you.

我觉得最棒的是，这些经历都是特别好的学习机会。

Like the the cool thing is that I think all of these things are like really good learnings.

我本来想说的是，

I wouldn't have Shout out

或许能帮其他人少受点罪。

any to other suffering maybe.

对，不过我

Yeah, but I

我觉得有时候这才是最让人印象深刻的学习经历。

feel that's sometimes that's the most memorable learning.

我认为几乎所有学习都来自于犯错。

I think almost all learning is about making mistakes.

学习最有效的方式就是犯错，然后去观察、理解为什么会错，最后加以改正。

That the way you learn, the most powerful ways to learn are to make mistakes, see, understand why they're mistakes and then fix them.

对我来说，教育本质上就是创造一个安全的环境，让人们能够犯错并从中学到东西。

And to me, education is about basically creating a safe space where people can make mistakes and learn from them.

我会在课堂上跟学生们讲这件事。

And I tell the students in the class about this.

我会告诉他们：你们会收到大量的批评。

I tell them, you know, you're going to get a tremendous amount of criticism.

我会逐行挑你们代码里的毛病。

I tell them, I am going to pick every single knit with your code.

你们可能会因为我挑的这些问题生气，但我就是要让你们看到每一个错误，因为我想让你们意识到这些问题的存在。

Going to think there, you're going probably be mad at me for things I'm picking, but I'm going to show you every single thing that's wrong because I want you to be aware of that.

我希望学生们从这门课中学到的一点是，这种经历其实非常有帮助。

One of the things I hope students get out of the class is realizing that's a really productive experience.

有人来挑我的毛病、仔细审查我的代码、给我反馈，这对我来说其实是好事。

It's actually good for me to have people come in and challenge me, scrutinize my code and give me feedback.

我觉得很多开发者其实挺敏感的。

Because I think a lot of developers out there are kind of sensitive.

他们可能担心，别人批评自己的代码，就等于说他们不是个好程序员。

Maybe they worry that if somebody criticizes their code, maybe that means they weren't such a good coder.

或者他们觉得，如果得想第二个方案，那就说明自己不够聪明。

Or maybe they think if I have to come up with a second idea, maybe I'm not that smart.

只有笨人才会把同一件事做两遍。

Only dumb people have to do things twice.

聪明人第一次就能把事情做对。

Smart people always get things right the first time.

于是你就死死抓住一个想法：我绝不能承认自己的第一个想法不够好。

And so then you latch onto this, I can't ever admit that my first idea isn't great.

所以我觉得，承认犯错这个观念特别重要，也特别有建设性。

So I think it's really important, whole idea of making mistakes is so important and so constructive.

作为工程师，我们真该尊重这一点。

We need to honor that, I think, as engineers.

话题稍微换个方向，你和鲍勃叔叔——罗伯特·马丁——曾经在网上就他的《代码整洁之道》有过一场有趣的讨论，你们俩分别对书里的不同部分写了看法。

Slightly different topic, but you and Uncle Bob, Robert Martin, had an interesting discussion about his book, Clean Code Online, where you both like wrote your thoughts on different parts.

其中有几处，你们的观点不太一样。

And there were a few parts where your opinions diverged.

我其实挺想深入聊聊这些观点的。

And I I was interested in in getting into some of these.

第一个是关于短方法，也就是每个方法只做一件事。

So first was on short methods and the methods doing just one thing.

罗伯特·马丁特别推崇这种做法。

You know, Robert Martin is is a big fan of of doing so.

他说这样能让代码更干净，职责更清晰，等等。

He's saying this will lead to cleaner code, clear responsibility, and so on.

但你的看法稍微有点不一样。

And you had a slightly different take on this.

没错，我确实这么认为。

Oh, sure do.

我之前提到过，设计本质上是权衡取舍。

So I mentioned earlier on that design is about trade offs.

任何理念一旦走极端，最后都会陷入困境。

And if you take any idea and take it to the extreme, you end up in a bad place.

所以我觉得，整洁代码在很多地方确实带来了这样的影响。

And so I think clean code has done that in many places.

而这正是我最担心的整体问题。

And this was my biggest overall concern.

因此，方法的长度就是其中一个方面。

And so method size is one of them.

当然，我们都同意，特别长的方法通常比短方法更难理解和维护。

So of course I think we agree that really long methods are probably harder to understand and deal with than shorter methods.

所以短小确实有它的价值。

So there's some value in shortness.

但对我来说，最重要的不是方法有多短，而是它的抽象深度。

But it isn't the method length per se that's most important to me, it's this notion of depth.

我们有没有把复杂性隐藏起来？

Are we hiding complexity?

而在整洁代码的理念里，短小被当成了一种绝对的好，没有任何界限。

And so what happened in clean code is that shortness was taken as an absolute good with no limits on it.

越短越好。

The more you get shorter, the better.

按照《清洁代码》的说法，三行的函数比五行的更好。

And so a three line method is better than a five line method according to clean code.

但问题在于，虽然单个函数可能更容易理解，但函数太短会导致数量暴增，接口也跟着变多。

And the problem with that is that, well, maybe that one method is a little bit easier to understand but by having shorter methods you now have a lot more methods and so you have a lot more interfaces.

结果，接口的复杂性反而让整个系统比以前更难搞了。

And now the complexity of the interfaces ends up actually making the system more complicated than it was before.

特别是他的风格，他觉得函数之间互相交叉也没关系。

And in particular, his style, he is comfortable if methods are entangled.

一堆短函数，结果你得同时看好几个才能搞懂其中一个。

Having multiple short methods where in fact they're so entangled that you can't understand one method without actually looking at the code of the other methods at the same time.

是啊，那干脆就这样吧。

Yeah, so might as well, yeah.

在我看来，这种做法根本没什么好处。

To me I see no benefit of that.

我觉得这样反而让事情变得更糟了，而不是更好。

I think to me that has made things worse, not better.

如果某些东西确实密切相关，不如把它们合并在一起。

That if things are really related, you're better off pulling them together.

别光盯着‘深度’这个概念，它其实能帮你权衡利弊。

So don't think about the notion of depth as it kind of captures the trade offs.

我们希望功能丰富，但接口必须尽量简单。

That we want to have a lot of functionality but it needs to have a relatively simple interface.

我觉得这个理念能帮你避免走向任何一个极端。

And so I think that notion will keep you from going astray in either one direction or the other.

而像单一职责原则、只做一件事这些说法，只会一味地推着你往一个方向走，毫无节制，最后反而出问题。

Whereas this, for example, the single responsibility principle, the do one thing principle, that just pushes you relentlessly in one direction without any bounds and you get in trouble that way.

你刚才提到方法要短、只做一件事，可以有很多小方法，也可以把它们合并成更大的方法，虽然做的事更多，但更合理。

And it's interesting how, you know, you talked about methods being short doing one thing and you can have a lot of them or you can like group them and have bigger methods that do do more thing, but they're more sensible.

听你这么说，我想起我们行业里微服务也遇到过类似的情况。

I was thinking as you're talking about this, in the industry, we've had a similar thing with microservices.

那时候我正好在Uber工作，公司当时流行说有五千多个微服务，我们确实有很多特别小的微服务。

So I happened to work at Uber at the time where it was popularized that the company had more than 5,000 microservices, and we had a lot of really small microservices.

这些年下来，至少在我所在的领域——支付系统——我们之所以用这么多小服务，是因为它们启动起来方便。

And what happened over the years is, at least in my I cannot speak for the whole company, but I can talk about the domain I was, which was in the payments domain, we had a lot of small services because they were easy to spin up.

每个服务就做一两件事，或者少数几件事。

They did like one thing or two things or a few things.

但过了一阵子我们发现，维护起来太难了，根本搞不清哪个服务负责什么，来回调用特别多。

And after a while, realized like, it's it's just really tough to maintain, to know which lives there, a lot of communication back and forth.

所以我们开始把它们合并起来，搞一些中等规模的服务，每个服务对应一个明确的业务领域。

So we started to just pull them together and create like mids I would say, like mid sized services that kind of had a domain responsibility.

我们没走极端，但说实话，一开始那种极端做法听起来确实很吸引人。

And it wasn't either extreme, but, like, I think we saw that one extreme it sounds good.

刚听说的时候，感觉特别棒，确实有不少好处。

It it sounded really good, by the way, initially, and it has benefits.

但时间一长，发现实际操作起来并不靠谱。

But over time, it just wasn't as practical.

所以这跟你所说的有点相似。

So it's somewhat similar to to to what to what you say.

极端的做法，不管哪一边，都不太好。

Like, extremes on one end are not great.

搞一个什么都能做的巨型服务，其实并不理想。

It's not great to have, like, one massive service that does everything.

以前Uber就是这样。

You know, we Uber used to have that.

那个服务叫API，啥活都干。

It was called API, and it did everything.

后来拆成了很多小服务，再后来又慢慢收拢，归到一些明确的领域里，规模也适中了。

And then it got broken into smaller things, and then it came back into, like, kind of domains or or reasonably sized ones.

这样你心里才清楚每个部分是干嘛的。

So so you could actually keep track in your head.

你能明白系统里到底有哪些模块在运行。

You could understand here are the different parts that are there.

明白了。

Okay.

你可以深入进去，看看各个部分是怎么运作的。

You can go inside and then you can understand the parts.

所以我觉得关键在于，什么时候才算是恰到好处？

So there's I think there's a level of when does it make sense?

你怎么判断这些划分是否合理呢？

How can you follow those kind of things as well?

我觉得两边都有道理，但如今很多人倾向于过度拆分。

I think there's a you know, again you can on both sides, but I think these days people often on the side of over decomposing.

比如《代码整洁之道》就提倡一种我认为过于拆分的做法，反而会带来问题。

And I think so Clean Code, for example, advocates that, what I consider to be over decomposing that causes problems.

所以我常告诉学生，有时候把东西合并起来，反而能让设计更深刻。

And so one of the things I tell my students is often you can make something deeper by actually combining things together.

如果两个东西本来就很相关，把它们合并成一个类、一个方法、一个模块或者一个子系统，不仅能保留全部功能，还能让整体接口更简洁，避免两个独立组件之间产生大量耦合——那可是大忌。

If they were closely related, you may discover that if you bring them together into one class or one method or one module or one sub system, you end up with the combined functionality but with a simpler overall API and without having two separate things with a lot of dependencies between them, which is really bad.

不过这种做法也容易走极端，毕竟凡事都有权衡，有时候把单元做得大一点，反而能让代码更好。

Again, you can overdo this, you know, so everything is trade offs, but you can often make things better by making the units a little bit larger.

屏幕上另一个话题是测试驱动开发，我们之前稍微提过。

Another area of this screen was test driven development that we touched on a little bit.

罗伯特·马丁特别推崇测试驱动开发，主张先写测试，再写能通过测试的代码。

Robert Martin is a big fan of using TDD as a way to write code, write the test first, then write the code that makes it pass.

这种方法在2000年代初还挺流行的。

This method was also pretty popular in the early 2000s.

不过现在没那么时兴了。

It's kind of gotten a little bit out of style.

你的看法也不太一样。

Your take was different as well.

是的，我不太认同测试驱动开发。

Yeah, I'm not a fan of TDD.

没错。

Yep.

因为我觉得它会妨碍设计。

Because I think it works against design.

所以再说一遍，对我来说，软件测试很重要。

So again, to me, software, so tests are important.

我特别喜欢单元测试。

I love unit tests.

我写的每一段代码都会配上测试。

I've read them for everything I do.

它们是必不可少的。

They're essential.

一个负责任的开发者，都会写出高覆盖率的单元测试。

If responsible you're developer, you write unit tests with very high coverage.

这一点我们先达成共识。

So let's agree on that.

但我们的开发过程应该更聚焦在设计上。

But we want the development process to be focused on design.

我觉得，我们所有开发工作都应该围绕着做出最佳设计来展开。

I think that should be the center of everything we do in development should be organized towards getting the best possible design.

我认为TDD恰恰与此背道而驰，因为它让你只关注一个个微小的设计片段。

And I think TDD works against that because it encourages you to do a little tiny increment of design.

我写一个测试，然后写代码让这个测试通过。

I write one test and then I implement the functionality to make that test pass.

接着再写一个测试，再写代码让它通过。

Then I write one more test and write the functionality to make that test pass.

整个过程中，根本没人鼓励你停下来，从整体上思考任务和大局。

And so there's no point in the process where you're encouraged to step back and think about the overall task, the big picture.

这些部分该怎么协同工作？

How do all these pieces fit together?

什么样的架构才最简洁、优雅，能一次性解决十个问题，而不是为每个问题单独拼凑十个方案？

What's the most pleasing, simple, clean architecture that will handle, that will solve 10 problems rather than coming up with 10 solutions to individual problems.

所以，我认为这样做的风险是，最终会陷入一种极度短视的开发模式，产出的东西一团糟。

And so it results in what I believe the risk is you can end in an extremely tactical style of development that produces just a horribleness.

这就是我的担忧。

So that's my concern.

我们之前为此争论了很久，我觉得Bob喜欢TDD的主要原因，是他觉得这样能确保测试代码被写出来——因为你必须先写测试，再写功能代码。

And we had this long back and forth about it and I think the main reason that Bob likes TDD is it ensures that the tests get written, because you have to write the test before the code.

所以，

So I

我同意，这一点确实说得通。

agree Which that that is should fair.

但我并不觉得，除了确保测试被写出来之外，先写测试再写代码还有什么特别的优势。

But I don't think there's anything he was not able to convince me that there's any particular advantage in writing the test before the code other than ensuring that the tests get written.

我看不出它能让设计变得更好，反而能想到很多理由说明它可能会让设计变得更糟。

It does not I can't see any reason that makes the design better and I can see a lot of reasons why it might make the design a lot worse.

我觉得一个有趣的问题是：我们开发时，应该以什么为单位来划分工作？

I think an interesting question is what should be your units of development?

你知道，开发总是要分块进行的，那这些块应该怎么划分才合理？

You know, you're going to do development is always in chunks of work, what should those chunks be?

我认为这些开发单元应该是抽象层面，而不是单个测试。

And I would argue those chunks should be abstractions, not individual tests.

这种粒度还是太小了。

That's too small of a chunk again.

你应该考虑足够大的单元，这样才能权衡利弊，设计出一种通用的解决方案，一次性解决多个问题。

You want to think in a big enough chunk that you can consider trade offs and try and come up with a fairly general purpose solution that will solve many problems.

顺便说一句，我认为设计中最重要的原则之一，就是尽量逼自己走向通用性，避免过度特化。

By the way, one of the most important elements of design, I think, is pushing yourself towards general purpose, to avoid specialization as much as you possibly can.

而TDD的做法反而让你专注于写专门的代码来通过每一个测试，而不是去思考一个能一劳永逸解决多个问题的通用方案。

And so the TDD approach encourages you to do something very specialized to pass each test rather than thinking about the general purpose thing that solves many problems in one place.

明白了。

Alright.

是的。

Yeah.

确实如此。

That that is true.

确实如此。

That that is true.

事实上，我记得有一次我们搞TDD团队编程，轮流敲键盘，一个人写测试，另一个人让测试通过。

In fact, like, I remember, like, at at some point when we did we did some TDD mobbing where we would pass the keyboards around, then someone would write a test, someone would make it pass.

那时候感觉有点做作，因为你写代码的时候总得提醒自己：别写这个，别写那个。

We were trying to it felt a bit artificial because when you wrote more code that you needed to come to, like, uh-uh, no, don't write that.

你写的代码不能只是为了让测试通过。

That doesn't make just just make the test pass.

所以整个过程显得有点刻意。

So it almost felt a little bit of artificial.

当然，我也相信在某些场景下，比如业务逻辑特别复杂的模块，或者需要谨慎扩展代码的时候，这种做法可能还是有它的价值，但也许正因如此，它才慢慢变得不那么流行了，现在大家也不太提了。

And and again, like, I've I'm sure there are times and cases where it it could be useful may maybe in a more formal way, maybe where it's more about adding extending additional code where it's, like, very heavy in business logic, maybe maybe that could be a good good fit, but there might be a reason that it kind of slowly, you know, became less popular, and we're we're not talking about it too much these days.

至少目前是这样。

At least.

我唯一建议先写测试的情况，是在修复bug的时候。

The one place where I'd recommend writing the test first is when you're fixing a bug.

我会说，先写一个能检测出这个bug的测试，然后再去修复它。

I would argue write the test that will detect the bug and then fix it.

不过说实话，我平时其实是有点偷懒的。

Although actually what I typically do is I honestly I kind of cheat on this one.

我先直接写好修复代码，再为这个修复写个测试，然后把修复代码撤掉，看看测试是不是真的会失败。

I write the fix and then I write the test for the fix and then I back out the fix and make sure the test fails.

这样我就有把握了，不过说到底，我觉得在修复bug的时候提前写测试确实挺有用的。

So I know that but anyhow, that's one place where I think doing the test early can be useful.

还有一个你不同意的点，是关于代码注释的。

Now, one more area that you disagreed is comments.

所以鲍勃说，不出所料，代码里的注释应该越少越好。

So Bob says unsurprisingly that you should have as few comments of the code.

代码本身就应该能说明一切。

The code should speak for itself.

你也不完全认同这个观点。

You also did not fully subscribe to this one.

如果代码真能完全自解释，那当然再好不过了。

If the code could fully speak for itself, that would be wonderful.

我一点意见都没有。

I would have no objection.

但现实是，它做不到，而且永远也做不到。

But it can't, and it never will, as far as I'm concerned.

有很多东西，根本没法直接写进代码里。

There's just so much stuff that can't be described in the code itself.

我们后来聊到一些例子，他说：看看这段代码，根本不需要注释，对吧？

And we ended up discussing examples where he said, Look at this code, it needs no comments, right?

我就说：可我这儿有五个问题，代码里完全没解答。

And then I said, Well, here's five questions people have that I don't see answered in this code.

他听了之后就有点回避这个问题。

And then he kind of hedged about that.

所以我觉得吧，他对于注释的抵触实在太强烈了。

And so I don't know, he's very, very biased against comments.

我不明白，他是不是之前有过什么不好的经历。

I'm not sure why, if he had some scarring experience.

他坚持认为，人们因为过时的注释而被误导所浪费的时间，比因为缺少足够注释而浪费的时间还要多。

And he argues that he I believe he basically said he thinks that people lose more time by being misled by comments that are out of date than time lost because you haven't had adequate comments.

但这跟我自己的经验完全不一样。

And that certainly is not my experience.

不，不是说那个

No, no, not the

有时候注释确实过时了，但这种情况很少，而且即使过时了，里面通常还是有有用的信息。

Occasionally their comments are out of date but rarely and even then there's usually useful information.

他还说，如果你和别的开发者一起做项目，根本不需要注释，因为大家都把代码记在脑子里了。

And then he also argued that well if you're working on a project that you and other developers work, you don't need any comments because everybody's got it all loaded into their minds.

我完全不认同这种说法。

And I just don't agree with that.

也许他的记忆力比我强，但我没法把所有东西都记在脑子里，写完几周后我就忘了代码是干嘛的，所以我需要注释。

Now maybe his mind is better than my mind, but I can't keep everything in my mind and I forget code within a few weeks of when I've written it, so I need those comments.

所以归根结底，代码本身是没法传达很多信息的。

So the bottom line is there's just a lot of stuff that you can't get from the code.

那你的评论习惯是怎样的？你一般怎么写注释？

And then what is your kind of approach on like, how do you do comments?

你倾向于在注释里写些什么内容？

What do you like to put into comments?

还是说只要觉得有必要，就随手加点，反正多点信息对以后总有帮助？

Or is it just like whenever you feel like it, just put there because it's going be additional information that could help later?

再说一遍，第一条原则是：注释应该补充代码里看不出来的信息。

Well, again, the number one rule is comments should tell you things that aren't obvious from the code.

现在网上有很多糟糕的注释，就是把代码里明摆着的东西再重复一遍。

And so, know, there are a lot of bad comments out there where people are basically just duplicating stuff that's obvious from the code.

这种情况下，根本没必要写注释。

So no need for comments in those situations.

我在上课带学生做项目时，经常把他们那些多余的注释删掉，跟他们说：这个注释纯粹在复述代码。

And, you know, in my student projects in my class I often take comments out, tell students, This comment just repeats the code.

你根本不需要写。

You don't need it.

我觉得注释最重要的地方是在接口上。

I think where comments are most important is for interfaces.

这一点特别关键，因为接口的假设就是你不希望别人去读你所调用的那段代码，只看接口就够了。

This is where they're really, really important because the assumption of interface is you don't want people to have to read the code of the thing that you're communicating with, talking about, just want to look at the interface.

光靠函数签名根本没法提供用户使用这个模块所需的所有信息。

And there's simply, it is impossible in the functional signatures of a module to provide all the information people need to use that module.

所以注释在这里就特别重要。

And so that's where comments are most important there.

对我来说，这才是最重要的。

To me, that's the most important.

第二重要的就是给类的成员变量做详细说明。

The second most important thing is documenting the member variables of classes.

这个必须写得非常详尽。

That needs really extensive documentation.

至于方法内部，我一般不需要写太多注释。

And then I tend to find that inside methods I don't tend to need a lot of comments.

因为如果你明白这个方法的目的，代码本身通常就已经很清楚了。

Because if you know what the method's trying to do, the code typically speaks for itself pretty well there.

我只会在那些比较复杂、或者我是在调试时才发现的意外情况旁边加注释。

I tend to have comments where things are tricky or where there was unexpected stuff I only discovered when there were bugs and things like that.

很多时候，我的方法内部根本没注释，只有接口层面的说明。

Often my methods won't have any internal comments, they'll just be the interface comment.

我觉得这场关于注释的争论可能会重新升温，因为AI工具现在生成的代码越来越多，经常直接生成整个方法——你只要提个要求就行。

I think comments are going to have a bit of a resurgence of this debate potentially because AI tools increasingly generate more code, They often generate whole methods, you know, you can ask.

我发现，当我让AI助手帮我生成某个功能时，它写完代码后，往往会加上行内注释来解释这段代码的作用。

And what I'm noticing is when I when I'm telling, you know, one of these AI assistants, generate something that does this for me, it generates the code, but it often adds inline methods, which explains what it does.

这种情况下，因为生成得太快了，反而对我有帮助——我知道这些工具容易胡编乱造，所以我得确认它到底在干什么，注释正好帮了我理解。

And actually, that case, because it's just coming so quickly, it actually kind of helps me because I'm I know these tools hallucinate, and I actually want to make sure what it does so it kind of helps me understand.

但与此同时，这也引出一个问题：它为什么非得加这些注释？

At the same time, it's a good question of why it's doing it.

你知道吧，这些模型通常是用网上现有的代码训练的，不管是开源的还是别的什么授权的代码。

You know, these are trained on typically code that's out there, either either open source or who knows what kind of licensing.

所以它很可能就是照搬它见过的那些内容。

So it it probably is copying however it's it's seen it.

不过一般来说我同意你的看法，但这次我觉得加点注释也未必是坏事。

But you know, usually I would agree with you, but in this case maybe comments are not a bad thing.

谁知道呢？

Who knows?

这确实是个挺有意思的话题。

It's an interesting area.

是的，我有点犹豫说这个，因为我怕自己是在为不良习惯找借口。

Yeah, so I'm a little hesitant to say this because I'm fearing I may be justifying bad habits.

但我发现，AI工具在某种程度上能弥补注释不足的问题。

But one thing I've found is that AI tools can, to some degree, compensate for the lack of comments.

我最近在搞 Linux 内核，开发一个新的网络传输层。

So I've been working in the Linux kernel, building a new network transport.

说实话，Linux内核本身并不是什么糟糕的软件，但在我看来，它的注释实在太少了。

Know, overall, Linux kernel is not a bad piece of software but it's pretty significantly under commented in my view.

我花大量时间只是想搞清楚Linux里到底在发生什么，接口是怎么设计的，该怎么接入进去。

And I spend a lot of my time just trying to figure out what is going on in Linux, what are the interfaces, how do I hook into this.

ChatGPT已经成了我最好的帮手。

ChatGPT has become my very best friend.

它在回答关于Linux内核的问题上特别厉害，很多问题我用谷歌怎么都搜不到答案，它却能搞定。

It's amazingly capable at answering questions about the Linux kernel that I can't answer via Google search or any other way.

它也不总是对的，有时候会瞎编，但大多数时候是对的；就算错了，也能把我引到正确的方向，让我知道该从哪儿下手去找到答案。

It's not always correct, sometimes it hallucinates, but it's often right and even when it's wrong it typically gets me in the right vicinity and helps me to figure out where to look to figure out how to answer my questions.

我觉得AI工具确实有帮助，但话说回来，如果Linux开发者肯花一点点时间加点注释，根本不用这么费劲地靠ChatGPT去猜。

So I think the AI tools may be able to help but even saying that, if the Linux developers just spent a little tiny amount of time putting comments in it would have made things so much easier than using ChatGPT to try and figure it out.

所以我觉得，注释的需求不会彻底消失。

So I don't think the need for comments is going to go away completely.

我们也不能拿AI当借口，让开发者不去写注释。

And we shouldn't use AI tools as an excuse for people not to write comments.

至少现在还不是。

At least not yet.

在播客开始前，你提到你最近还在写代码，这挺有意思的。

So before the podcast, one interesting thing that you mentioned is you are actively writing code.

实际上，播客结束后，我觉得你会重新投入编程工作。

In fact, after this podcast, I think you're gonna be getting back to to writing code.

你现在正在做什么项目呢？

What what are you working on right now?

你提到跟Linux内核有关的事。

You mentioned there's something with the Linux kernel.

是的。

Yeah.

我的一位博士生，贝纳尔·蒙特塞里，六七年前完成的博士论文里提出了一种新的传输协议，叫Homa，H-O-M-A，专为数据中心设计，他在论文里展示的结果非常出色。

So one of my PhD students, Benal Monteseri, has his PhD dissertation six or eight years ago developed a new transport protocol called Homa, H O N A, which is intended for use in data centers and the results he got in his dissertation are really fabulous.

在很多应用场景下，它的速度比TCP快上十到一百倍。

It's 10 to 100 times faster than TCP for a whole lot of interesting cases.

哇哦。

Wow.

所以我没有让这个项目像很多博士研究一样昙花一现，而是把它当成自己的使命，看看能不能真正把它推广开来，取代数据中心里一部分TCP的使用。

And so rather than let this just come and go as a PhD project that nobody ever cares about, I've taken it as my own personal project to see if it is actually possible to bring this into widespread use and displace some of the TCP traffic in data centers.

我已经实现了这个协议的Linux内核版本，现在还在持续优化，并且正在把它提交进内核主线。

So I have developed a Linux kernel implementation of that, which I'm continuing to enhance and I'm now in the process of up streaming that into the kernel.

我现在主要在处理内核开发者们给我的大量反馈，逐一解决他们指出的问题。

So actually what I'm really dealing with is a whole bunch of comments I've gotten from the Linux kernel developers about this and trying to fix all the problems they pointed out.

这正好说明了代码审查的价值所在。

Here's an example of code reviews and you know the benefits of all of that.

今天下午我正准备提交下一轮补丁，不过……

And indeed this afternoon I'm getting ready to submit my next round of patches to And the how how are

你觉得怎么样？这是你第一次向Linux内核贡献代码吗？还是之前有过相关经验？

you finding is this your first contribution to a Linux kernel or have you previously worked on it?

是的，这是我第一次参与Linux内核开发，我之前并没有……

Yeah, this is my first involvement with a Linux kernel and I have not How are you