2012.5.23 微博热报：需求分析、性能调优

@阿里巴巴中国在微博中举了一个对设计花瓶的需求分析示例，引起了大家对需求分析技巧的讨论； @左耳朵耗子在微博中表示性能调优不一定要自己使用缓存，因为许多层面已经设计了缓存机制。

需求分析

@阿里巴巴中国在微博中举了一个例子：“需求方说：帮我设计一个花瓶。小 A 设计师直接去做花瓶去了。小 B 多问了几句：多大的？什么材质的？什么时候要？预算是多少？小 C 则问：你要花瓶做什么的？是放鲜花还是做室内装饰用的？小 A 肯定做出了花瓶，但是未必是顾客想要的。小 B 也做了花瓶，顾客也买单了，已经合格了。但是小 C 则有可能让顾客惊喜。”

大家对此的看法：

刘光裕：只有抓住用户真正的需求，才能做出好产品。但不等于只有通过用户调研才能做出好产品。很多东西，真的只有放在用户面前，用户才会理解其价值。

宋安：因为小 C 考虑了具体的用户需求场景，具有用户体验和品牌营销的思维，而不仅是制造一个简单的产品。

chennychen ：乔布斯直接做了，然后告诉客户：这就是你要的花瓶。客户惊喜，欣然买单。

JAMU 時尚插畫師：但是很可笑的是很多老板只会告诉你我要一个花瓶~ 而且即便做到问清楚材质神马的老板各种不满意~ 所以这个理论现实生活中根本不可能。

loary311 ：小 C 的成功是在于了解产品的用途，然后在生产的时候尽最大可能去满足客户的这个需求，物善其用，客户有物超所值的感觉自然会感到惊喜。

innovate511 ：IT 面向业务需求，何其相像，不仅仅是业务部门面向用户时才会碰到，任何服务性的双方都会面临这个问题。

七斗先生：非也，有时候顾客并不知道自己真正需要什么。好的产品并不是满足顾客的所有需要，而是给他们一个购买的理由。

@宋安：用户需求和需求场景的识别是销售的前提，产品和服务的本质是如何满足需求，并创造良好的用户体验。

Skydesign ：客户往往很难表达他们要什么，但是他们知道他们不要什么。所以在中国很多时候，DEMO 比 PPT 来得有效果~

李结林：如果客户对小 C 说“和你有关系吗？”小 C 该怎样回答，创新固然重要，但是要以客户的利益和需求为出发点，小 B 的做法，不错。在懂得了客户的需求后，在客户的可接受范围内，适当加入小 C 的角色是可以考虑的！

性能调优

@左耳朵耗子在微博中说：“每每一和人说到性能调优的东西，就会听到人马上说要建个 cache 或是用个 hash table 缓存什么的，我总是觉得并不一定啊。因为 cache 这个东西到处都有啊，从 CPU 的 L1 L2 到 RAM 都有 cache，OS 读文件运行程序也有 cache，RDBMS 也有 cache，语言层面 JVM 里也有 cache，网卡上也有 cache……，有时候真没必要自己建了。”

大家对此展开了讨论：

jametong ：在很多人眼里，速度不行，那就上个缓存吧！至于缓存到底是什么？该如何利用各种不同的缓存，他所处理的具体业务场景是否需要缓存？那则是另一个问题！

压力很大同志：缓存也算是一种空间换时间的方法嘛，有的结果明明可以反复用的就存起来。业务逻辑部分能得到的为什么非要去 RDBMS 去走一遭，再说细点 CPU 的 L1、L2 也没法缓存业务逻辑需要的数据，不是在一个级别上的东西，要是指着 CPU 缓存了、IO 缓存了、RDBMS 缓存了，就反正他们都缓存了，我就不管了，这跟耍流氓无区别。

kylemick ：如果单纯 IO 角度，应该是要的吧…瓶颈点在那里，不然也不会在这么多层面做了这么多 Cache。至于算法调优，都是根据实际情况吧，没有具体情况，调优岂不是无敌了？

steedhorse ：我觉得所有的动态规划算法都与 Cache 机制异曲同工。不过现实中我也对一碰到性能调优就想 Cache 的做法存有疑虑。经典线性规划问题可以用现成算法。其他问题也常可以通过算法和数据结构的改进来减少重复计算。

左耳朵耗子：我这里说的“有时候不需要”。举个例子，某应用有读很多小图片，但又不是很多，比如 25 万个小图片，大约不到 1GB，于是想做一个 cache 把图片预读到内存以减小磁盘 I/O，但是 OS 的内存管理已经帮你干了，真的没必要自己再干了。

吴尔平 -andy ：不支持这种说话，换个顺序理解一下，为什么 CPU 需要 L1、L2、L3，为什么有了 CPU 的这几级还要文件 Cache, 要 db 的 Cache。就知道为什么有些应用需要有应用级的 Cache。

校园猫：如果用 OS 的 cache，需要从内核空间拷贝到用户空间，如果用 DBMS 的 cache，要从数据库进程空间拷贝到用户进程空间，如果对这些时间开销可以容忍，当然可以不需要自己建 cache，如果不能容忍，那还得自己建，另外 cache 的淘汰算法也不能控制，除非完全能装下不考虑淘汰。

steedhorse ：这个话题好像说乱了。原因是楼主前半句跟哈希表相提并论的 cache 指的是“计算结果缓存”，比如很多人都会不太严格地讲“把运算结果 cache 起来”，这是 cache 的一种不太正宗的用法。而后半句的 cache 指的是存储结构上的 cache，这个是 cache 一词的正宗本义。前后两个 cache 在含义上不太一致，导致了各说各的。

Robin 圈：性能问题之所以难解决，通常是我们错过了第一解决时间，搞的自己都不知道问题再哪里了。所以如果性能成为了关键指标，那么就应该集成到 CI 中，如果要求是 1s，那么超过了就该给个 failed。

jametong : 瓶颈更多是基于设计、业务来定位的，深入业务、系统，找到有共享资源的点（L1/L2 缓存，CPU 调度、业务热点账户，流程设计的热点），通过测试来寻找瓶颈是代价非常高昂的方式，测试很多时候只是用来验证，而不是寻找！没有针对性的优化，没有经过测试找到瓶颈。

一线天色天宇星辰：往往测试一把，解决影响性能的最主要因素，就能解决问题了，十全十美的设计是不可能的，把可能遇到的性能问题都测试一把，挑主要的解决掉，否则过度设计会搞死自己的。