Perfection and Simplicity A Conversation with Ken Arnold, Part I 阅读笔记

(题外话: 这是  Ken Arnold 系列访谈的第一篇 , 之前的"Designing Distributed Systems "是该系列的第三篇)

 

这篇访谈 , 讨论的是设计的问题.

 

Ken 认为不存在所谓的"完美"的设计, 原因有:

1. "One is that all designs take place in context.",  "So part of the reason no perfect design exists is that no matter what you do, you end up making one design trade off over another. You make choices that are right for your context, but bad for some other set of circumstances. "

所有的设计都存在一个语境, "完美", 则只是相对一个特定的语境而言. 换一个环境, 设计可能就有问题, 因此, "完美"是一个相对的, 不断变化的概念, 没有绝对的"完美"

 

2. "Another reason, which is in a different category, is that if you try to create a perfect design you will expend a huge amount of effort."

追求完美, 需要耗费过多的精力与时间. 做软件的, 应该都了解 2/8 法则, 为了达到"完美", 需要为最后的 20% 付出 80% 的精力, 而"完美"又是个很不可靠的事物, 因此可能往往费了大力气, 最后却不讨好. "The difference in effort between delivering something perfect, as opposed to something good, is significant. It just isn't worth the trouble in 98 percent of the cases. "

 

另外, "And then there's the problem of predicting the future.", "If you over commit to any of those directions, you can hurt your design.", 也即 "爱得越深, 伤害得越深". 无论你的设计如何"完美" && "灵活", 之前已经提到, 这个设计都依赖于一个特定的语境. 而变化, 是软件中很常见的情况. 因此很有可能, 最后就是这个 "完美" && "灵活", 给软件的演化带来了最大的阻碍.(是否每一个好的软件设计师, 本质上都是一个实际主义者?)

 

所以, 既然追求"完美"即不科学也不实际, 那只要追求"足够好"即可. "The best that people can reasonably hope for is to put forth an appropriate amount of effort and get a good design that is sufficient."

 

不过"足够好"这个概念也很虚, 只能凭借个人自身的把握, Ken 给了一个他的标准 "Your design should do as little as it can to get the job done so you can add the right thing when you discover what that right thing is. " 先把"好"放在一边, 就我理解, Ken 眼中的"足够", 似乎就是"尽量少"的意思, 也就是说, 不要太好, 过得去就可以了.

 

之后, 讨论到 API 接口的设计, Ken 倾向于, 提供尽可能少的, 必要的接口.

" I think that comes from focusing on what the user needs to do, rather than what the user might want to do."

"Many people approach designs by asking, "What might the user want to do?" If you start with that question, the set of answers is infinite. You end up with interfaces that have 80 or 90 methods, or 50 or 60 interacting classes."

 

这里有个概念, "surface area of design, which is what you must understand about a design to know which part you care about.", 即试图理解单个部分之前, 你必须理解系统的全部. 因此, 提供太多的, 过于复杂的接口 会导致 API 的使用者理解上的困难. "The problem is you need to know enough about those other methods to know you don't need to understand them."

 

接着谈到, 简单, 尽可能少的标准是什么, Ken 给出了一个观点 "programmers are people."

"Now if you accept this premise, then the next step is to say that designing tools for programmers, including languages, APIs, and compilers, is a human factors problem."

程序的编写, 由机器语言, 汇编, 进到到现在的高级语言, 都源于 "programmers are people." 程序语言也好, API, 编译器也罢, 都是让程序员"生活更美好"的工具. 进一步深究, 程序员工作的核心价值是解决问题, 因此这些工具的价值也在于, 帮助程序员更好的组织, 表达, 并交流他们苦心造诣出来的解决方案.

 

因此设计 API 跟设计 GUI 没什么差别

"And so we should ask the same kinds of questions that people ask about GUIs [graphical user interfaces]. Is it easy to do what you need to do? Is it natural? Are simple things simple? Are complicated things complicated? Are dangerous things hard to do? Are common things easy to do? Are similar things done in a way that is naturally similar to the person?"

 

之后 Ken 就 "programmers are people." 又讲了一堆, 就不复述了.