代码之外的功夫：程序员精进之路 -- 阅读笔记及总结

第一章 设计原型

Ross自己也不是很明确自己的需求。——好家伙，太真实了。客户不能明确清晰地传递自己的需求，客户可能只有一个大概的目标。这时候，该怎么办？

这时候可以和客户沟通，先出一个草图（线框图），然后用这个草图和客户沟通，看是否是客户想要的样子。这个过程可以从最早期最低成本地消除和客户之间沟通的误会问题。

客户认可草图后，可以开始做一个demo出来。这个demo要尽可能简单，根据YAGNI原则（You Aren't Gonna Neet It)，只需要关注核心功能。这个demo的界面可以尽可能简单，目的是让客户在功能方面提提意见。

在这个过程中，如果客户提出了一些不属于核心功能的问题，要善于和客户沟通，说明为什么在当前阶段不需要考虑这个功能/问题/界面设计。对于客户的担忧，要能够以合适的沟通方法来解决（可以就修复问题提出一些粗略的计划，并和客户交流想法）。

对于技术问题，客户很多时候都希望工程师能够提出想法。但是工程师也需要和客户沟通，看看客户心中有没有一个大概的想法。工程师可以给客户提出数种解决方案，并说明各种解决方案的利弊，并在沟通中逐步和客户达成共识。在这个过程中，客户可能会描述想要的功能，工程师可以依据客户想要的功能来实现一个进一步的demo。

通过这个demo，可以和客户进一步确认这是客户想要的原型。另外，可以尝试用可视化的方法解释系统背后的运行原理（这让我想到了Alpha Go比赛的时候会把当前的胜率实时显示出来，不管是不是同一种原理，我只是突然想起来Alpha Go了），让客户明白每次点击或者每次操作以后，系统内部发生了什么变化。（比如一个推荐系统，每次点击后推荐列表的更新情况可以实时显示出来）

客户可以通过这种方式更加理解系统背后的工作原理。

Demo是用来得到反馈的。

建立原型是为了探索问题空间，而不是做出完整的产品。

第二章 观察增量变更

“你经常故意把一些尚未完成的特性做得简略一点，免得别人以为它们已经准备好上线了。”

对隐藏的依赖关系要保持警惕（如扩大了用户范围，从数据库中取了之前不会取到的数据，存储的内容和存入的速度发生了变化，用户界面上增加了新的元素等等）。