<audio id="audio" title="06｜小心那些平淡无奇、人畜无害的简单小词！" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/82/d4/828c2a3bfcc488e5ba5da8ae499887d4.mp3"></audio>

你好，我是陈亦峰，欢迎你和我一起学英语。

## 课前朗读

今天我们继续来阅读[The Product-Minded Software Engineer](https://blog.pragmaticengineer.com/the-product-minded-engineer/?utm_source=wanqu.co&amp;utm_campaign=Wanqu+Daily&amp;utm_medium=website)这篇文章，我来带你精讲文章的第六段。

> 
<ol start="6">
<li>Pragmatic handling of edge cases<br>
Edge cases are a funny thing. On one extreme, engineers often forget about many of these, having to come back to addressing them, after getting feedback from people testing the product or end users. On the other hand, handling all possible edge cases in a new product or feature can take a lot of time.<br>
Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work. They are focused on the “minimum lovable product concept” and evaluate the impact of an edge case and the effort of handling it. They come with good middle-ground suggestions: mapping out most things that can go wrong and bring suggestions on what edge cases need to be addressed, before shipping even an early version.<br>
For example, if one in a thousand users might be hit by an error, they will consider the effort to fix it and think about what happens if they don’t do anything. Can customer support help the person in this case, during validation? Can the user just retry and succeed the next time? Can the product be slightly modified, so this edge case won’t occur?</li>
</ol>


我先来给你翻译下这几段话的意思。

> 
<p>6.以务实的方式处理边缘案例<br>
边缘案例是一件很有意思的事情。有的工程师经常会忘记边缘案例的存在，最后从产品测试人员或最终用户那里得到反馈之后，才不得不回过头来解决这些问题。这是一个极端，而另一方面，如果在一个新产品或功能中试图处理所有可能的边缘情况，则可能会耗费大量的时间。<br>
具有产品意识的工程师会很快制定出关于边缘案例的计划，并思考如何减少工作量，并经常会找到不需要额外工作量的解决方案。他们专注于“最小可爱产品”的概念，评估边缘案例的影响和处理所需的工作量。他们会提供很好的折衷建议: 在发布早期版本之前，列出大多数可能出错的地方，并提出需要解决哪些边缘案例的建议。<br>
例如，对于一个千分之一的用户可能会遇到的错误，他们会考虑修复这一错误涉及的工作量，以及如果什么都不做会发生的后果。在产品验证过程中，客服专员是否可以在这个案例中帮助用户？用户下一次再遇到同样问题可以自己尝试成功解决吗？对产品进行略微调整，是否就可以避免边缘案例？</p>


## 知识讲解

### 1.edge case

我们先来看标题中的关键词edge case。维基百科对这个词的定义是：**Edge case** occurs at an extreme (maximum or minimum) operating parameter.

edge case较为常见的译法为“边缘案例”，指“一个运行参数或条件为极值（最大值或最小值）的情况”。类似的，我们来看下corner case这个词。

**Corner case** occurs outside of normal operating parameters, specifically when multiple environmental variables or conditions are simultaneously at extreme levels, even though each parameter is within the specified range for that parameter.

“边角案例”一词应该来自边缘案例，两个边缘的交叉点构成角，所以边角案例就是多个参数或条件均为极值的情形。如果音量调到最大，声音失真，这属于边缘案例；如果问题在音量最大、周边环境高湿、且同时一万人以上同时在线时才会出现，这属于边角案例。边角案例一般在复杂系统的测试或除错过程中才会出现。

Boundary case occurs when one of inputs is at or just beyond maximum or minimum limits.

还有一个词boundary case，我们也叫“边界案例”或者“边界条件”，也是指系统输入刚好在上下限或是恰好超过上下限一点点的状态。不过，我不是软件工程方面的专家，从字面上看不出边界案例和边缘案例有什么区别。你如果知道的话，可以在留言区告诉我。

### 2.pragmatic

小标题中的另一个关键词是pragmatic。它既可以强调“一种务实的态度”（A pragmatic way of dealing with something is based on practical considerations, rather than theoretical ones.），也可以用来说“一个人非常务实”（A pragmatic person deals with things in a practical way.）。

傅高义教授（Ezra F. Vogel）是哈佛大学教授、费正清东亚研究中心前主任。在其著作《邓小平时代》中，他一直用pragmatic这个词来形容邓小平。媒体也经常称邓小平为“伟大的务实主义者（The great pragmatist）”。

例句：Incorporating both risk-based and customer-based analysis into your solution will yield a more pragmatic test plan.<br>
翻译：将基于风险和基于客户的分析整合到您的解决方案中，将会产生一个更加务实的测试计划。

### 3.funny

> 
Edge cases are a **funny** thing.


英语里有些看似平淡无奇、人畜无害的简单小词，例如funny，其实它们并不简单。在使用过程中要加倍小心，需要理解透字面背后的含义，谨防用错、踩雷。我们看下面这几个场景。

例句：<br>
A: Sorry I’m late. My car broke down half way here.<br>
B: Oh, very funny. Tell me another!<br>
翻译：<br>
A：抱歉我迟到了，我的车半路抛锚了。<br>
B：你得了吧，接着编。（有点类似于“呵呵”的口气）

例句：It’s not funny! Someone could have been hurt.<br>
翻译：这不好玩（这太危险了）！没人受伤算是运气好。

例句：If there has been any funny business, we’ll soon find out.<br>
翻译：如果这里面有任何猫腻（非法勾当），我们很快会发现的。

例句：My computer keeps going funny.<br>
翻译：我的计算机老出故障。

能看出funny这个词的感情倾向吗？其实在很多语境下，funny的意思都是偏负面的。

例如，要想夸别人很风趣，我们一般不说“You are so funny.”或者“You are a funny guy.”，容易让人误会你在说他“逗比”“二货”之类。而常用的是“You are so much fun”。

另外，还有一些可以用来夸人的词汇，也比较常用。这些词不含负面意思，在交流的时候，你可以放心使用。这些词有：hilarious、humorous、amusing、entertaining等。

那除了funny外，还有很多类似的词，使用的时候也要特别小心。例如interesting，其实它也是“呵呵”的意思。这里我整理了一些工作和生活中非常常见的表达，你可以感受一下，相信你一定用得上……

- Could we consider some other options？能否考虑其他方案？（你的方案是狗屎）
- It was a bit disappointing that…我感到有些失望……（你们XXX干的叫什么事！！！）
- Oh, by the way…顺便提一句……（下面要说的可能是谈话里最重要的一件事……）
- It is quite good. 还行吧。（不咋地。）
- It is not bad. 不坏。（真心不错，但不要骄傲。）
- With all due/the greatest respect…恕我冒昧，恕我直言……（后面跟的话就是要骂人了。）
- I hear what you say…你的意见我听到了……（你给我闭嘴吧！）
- It is a very brave proposal. 这真是个勇敢的提议。（我看这个愣头青大概是疯了吧！）
- I almost agree…我基本同意？（同意个鬼，基本不同意。）

这些表达你可以自己多读一读，多体会一下，平时在看美剧或者电影的时候，也可以注意观察一下他们的表达。至于文章作者为什么说边缘案例很funny，背后有什么微妙，如果你是工程师的话，我想你应该比我更清楚，这里我就不多说啦。

### 4.现在分词短语（做状语和主语）

> 
On one extreme, engineers often forget about many of these, **having to come back to addressing them, after getting feedback from people testing the product or end users.** On the other hand, **handling all possible edge cases in a new product or feature** can take a lot of time.


接下来，我们用这两句话来复习一下现在分词短语做状语和做主语的情况。

这两句话讲了两个极端，一个是程序员完全忘了边缘案例这回事（一定是新手干的），还有一个就是在这个事情上花太多的时间和精力。

第一个极端，有的工程师经常健忘。结果怎么样呢？having to come back to addressing them，现在分词做状语，表示结果，结果不得不回过头来解决这些问题。什么时候发生的事情呢？after getting feedback from people testing the product or end users， 还是现在分词做状语，表示时间，从产品测试人员或最终用户那里得到反馈之后。

另外一个极端，handling all possible edge cases in a new product or feature can take a lot of time。从handling这个现在分词开始一直到feature，这整个短语都是句子的主语，表示在一个新产品或功能中试图处理所有可能的边缘情况，can take情态动词加上实义动词做谓语，可能会耗费大量的时间。

### 5.map out

> 
Product-minded engineers quickly **map out** edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work.


map out是“计划、规划、提前安排”的意思。例如，map out the future的意思是“筹划未来”。它的英文解释是：If you map out something that you are intending to do, you work out in detail how you will do it.

我们还是通过几个例句来感受使用场景。

例句：With the whole IT picture in hand, we can map out how the information flows from start to finish.<br>
翻译：掌握了整个IT蓝图之后，我们就可以规划信息从头到尾的流动方式。

例句：It is important to map out the big picture first so that we can systematically identify user requirements.<br>
翻译：为了系统地识别用户的需求，我们首先需要制定一个全局规划。

### 6.focus和focused

> 
They are **focused** on the “**minimum lovable product** concept” and evaluate the impact of an edge case and the effort of handling it.


focus是动词，表示“（某人）集中精力于某件事情上”。focused是过去分词，可作形容词，表示“（注意力、眼神、焦点、光线等）集中的，（论文、计划等）目标明确的”。这个词比较简单，我们主要来看例句。

例句：I am exhausted, and just can’t focus on the work anymore.<br>
翻译：我筋疲力尽了，实在难以集中注意力工作了。

例句：I think it is time you woke up and focused your thoughts on more worldly matters.<br>
翻译：我认为该是你清醒过来把思想集中到更为现实的问题上的时候了。

例句：Every eye at the conference was focused on the rostrum.<br>
翻译：代表们的眼光都集中在大会主席台上。

例句：Focused light rays can set something afire.<br>
翻译：聚焦光线可以点燃东西。

例句：I spent the next year just wandering. I wasn’t focused.<br>
翻译：接下来的一年我一直在闲逛。没有什么明确的目标。

由上面这些例句我们可以看出，本段中的They are focused on the “minimum lovable product concept”，改为They focus on the “minimum lovable product concept”，其实会更好一点，直接用focus做They这个主语即程序员们的谓语动词。当然，如果非要说They are focused on（focused做形容词）意思也勉强说得通，不能算错。

### 7.minimum lovable product

无论你是产品经理，还是工程师，想必你对MVP和MLP这两个概念都不会陌生。

MVP指的是Minimum Viable Product，按照字面含义可以直译为“**最小可行产品**”。这种产品只包含最简单的基本核心功能。

而MLP指的是Minimum Lovable Product，可以直译为“**最小可爱产品**”。这个翻译听上去有点奇怪，不像中文惯常的表达。你也可以根据自己的理解，提出好的建议，例如最小有爱产品、最小点赞产品之类的。

这两者之间的本质区别究竟在哪里？几年前，我在Medium.com上面看到过一篇文章，是快乐创业学校的联合创始人Laurence McCahill写的。在文章里，他提供了两个定义：

**MVP** is the version of a new product that brings back the maximum amount of **validated learning** about your **customers** with the least effort. （强调以最小的努力换回最大数量的**经过验证的客户反馈数据**；目标在于了解用户体验。）

**MLP** is the version of a new product that brings back the maximum amount of **love** from your early tribe members with the least effort. （强调以最小的努力换回最大数量的**首批部落成员的爱**；目标在于直接开始圈粉。）

极客时间的tribe（部落），你应该很熟悉。这就是我们在建立忠实客户群体。毕竟几乎所有的产品都是面相某一人群开发的，只有达到最小程度的“有爱”，才有可能形成产品的“部落”。

所以，MVP的问题出在哪里？我觉得，MVP的问题在于缺少爱。每一个用户都是情感丰富而细腻的活人，我们需要在一堆硬件和软件里注入情感，不仅仅是满足用户的某项功能需求，也不仅仅是去取悦用户，而是用心和“有爱”的产品和用户去交朋友。这样的话，即便产品还不成熟，即使犯了错，也更容易得到谅解，因为只有朋友才会给你一次次的机会，有耐心陪伴你不断改进、慢慢变得更好。

### 8.middle ground

> 
They come with good **middle-ground** suggestions: mapping out most things that can go wrong and **<s>bring</s> bringing** suggestions on what edge cases need to be addressed, before shipping even an early version.


顾名思义，middle ground的意思是“中间地带”，表示“折中、妥协之后的立场、观点、决定、协议”等等。字典里的解释是：a set of opinions, decisions, etc. that two or more groups who oppose each other can agree on; a position that is not extreme.

例句：More and more in this age of social media, it seems like people of differing views are unwilling to attempt to find a middle ground.<br>
翻译：在这个社交媒体时代，越来越多持不同观点的人似乎不愿意尝试找到一个中间立场。

最后一句话的bring应该改成bringing，我觉得应该是作者的笔误。

## 小结

好了，今天的讲解就到这里了。

今天读的这几段话句式结构相对比较简单，我们学习的重点主要是一些重点词汇。经过这几次讲解，你或许已经了解到词汇学习的几个要领。这里我来和你聊一聊，平时你自己在阅读的时候可以慢慢养成的一些习惯。

首先，阅读过程中碰到不认识的词，这是非常正常的现象。在不影响大意理解的前提下，我们要勇敢地无视生词，直接碾压过去。千万不要每一个词都去查，否则除了效率降低以外，阅读的乐趣也会大打折扣。

其次，如果发现这个词绕不过去，影响核心内容的理解，那就一定要查了。但是呢，也不要只查一个中文的意思就结束了。

既然我们花时间去查一个词，那就顺便做三件事情：第一，查阅英英字典，了解一下英文的解释；第二，比较全面地了解一下这个词的几个不同意思，想一想这几个意思之间的关联性；第三，多读几个例句，了解这个词活生生的用法。这样三步做到了，那这个词就算真正吃透了。当然，好记性不如烂笔头，建议你找一个自己喜欢的本子，把这一个个好不容易吃透的词汇积累下来，这样你掌握的就不是之前的学习那样，只记了一个单词一个中文意思。

最后，要善于去发现一些你似乎认得，但并不真正了解的“小词”。例如我们今天讲的funny，以及相关的语言现象。这些词其实在生活中非常常用，也很容易被我们忽略。千万不要轻易放过它们。

用这样的方法，我们一起学习几个月后，你慢慢就会发现，语法和句式结构其实是最容易解决的问题。浩瀚的词汇海洋，才是陪伴你一生的朋友，熟悉又陌生。尽管时常找你麻烦，但也时常会给你惊喜。

这里我还是给你准备了一个简单的连线小游戏，你可以在大脑中把左右两列对应的项连起来，通过这个过程来回顾这些词的使用场景。

<img src="https://static001.geekbang.org/resource/image/2d/23/2d819805bf070d06d1aa2bd1a1d2a323.jpg" alt="">

## 课后作业

今天，我们讲到了Laurence McCahill写的这篇关于MVP和MLP的文章，[How to Build a Minimum Loveable Product](https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c)，推荐你课下花时间来读一读。

如果在学习中有什么问题，你可以在留言区提问，同时欢迎你把学习心得分享出来，我们一起每天进步一点。
