特别注明一下，我虽然一直在用Mongodb，但是仅关注其性能、方便，最重要的是方便地对单个document进行原子的findAndModify操作，反而对稳定性要求非常低，低到数据都不用备份的程度。因此，对于Mongodb的了解程度在会场人群中应该不算很高。

会议安排：上午先后有两场10gen工程师Roger和Alvin的演讲，下午分别是国内四位工程师分两个会场同时讲四个主题。

上午两场比较像Live Tutorial，对于我这种没有系统研究过的人来说还是蛮实用的。

第一场是Roger同学的Intro & Schema Design，从数据建模引入，重点还是在于通过Blog的案例，针对Document-Based数据库Schema Design，对比传统的关系型数据库，进行详细的分析，纯属教学性质的分享。特别说明的是，刚下载slides后发现有两个backup分别是DBRef和BSON，貌似大家都熟悉了，Q&A环节中没有用到。

第二场Alvin同学分享的是Replication and Sharding，同样是Tutorial性质的介绍。不过，对相应的机制及很可能遇到的隐患做了系统的说明，不得不说在讲解Replication Sets和Sharding机制时Slide动画做得干净、明了，貌似这点国人很少有兴趣去折腾。

总之，以上两场算是Mongodb官方分享，都只是系统性地做入门介绍。关于Replication Sets中Primary Member失效时Time Windows内仍然会有数据丢失风险，Alvin解释是需要getLastError，在应用层做处理；同样，Auto-Sharding也没有像官网提到的”without compromising functionality”。难怪有人评论没有说服力。

下午，分了两个会场同时进行，我选择了Yottaa那个实践分享的会场。这是一家刚成立一样的Startup，使用的技术和工具都比较新，这点很有意思。关于Mongodb的使用除了看Slide其他的也没什么好说的。在看到500G的数据，机器8G Memory时我就好奇问了一下性能问题，答案是Yottaa不太关心数据实时性。提问时有个插曲，我提到了500G数据文件load到内存时，大家都笑了，但是这不是我的问题，会后在微博我也解释了，Mongodb这类NoSQL基本还是将内存管理工作交给OS处理，所谓的LRU算法只不过是OS处理虚拟内存是常见的一种方法而已。数据文件全部load到内存的说法没啥错误，这点官网也有明确的解释：Mongodb.org: Caching – Memory Mapped Storage Engine

关于我提的数据量问题，会后在微博上也有童鞋很Nice地继续解释了一下：新浪微博评论。对于数据实时性以前可能我还不在乎，但是经历酒店价格数据实时处理后（包括搜索结果页的实时性），对这个还是比较谨慎的：1) 4sq宕机教训证明了虚拟内存性能值得担忧；2) 自身教训来说数据实时性要求不高的结论慎重点比较好。3) 突然需要调整为实时响应最新的数据的话，改动还蛮大，特别是针对我们这种搜索引擎来说，相信看过twitter实时搜索技术介绍大概能了解。

由于临时有事回公司了，没看最后一场。唯一遗憾的是没有GridFS和Map/Reduce的专门介绍。

很遗憾的是这门课程不是大家都学，也不是所有人都学会了，所以经常看到一下违背这个逻辑的事情。比如，仅仅只是假设，你的KPI(Key Performance Indicators，关键业绩指标)中有没有这样一条：当同事A与B打架时，你做了事情X可以得到基本分，做了事情Y可以得到超出期望分。其实按照特定企业文化、团队目标设定某些特定的KPI（再强调一下前面打架的例子仅仅是假设，实际上应该没有这么荒唐的指标吧）都很正常，关键在于假设不成立时，该项得分给了满分还是零分，或者提前调整该项指标。按照真值表，条件（即打架事件）不成立时，结论（即你采取的行动）不论如何，命题永真，该项得分应为满分，但实际操作时往往是0分，杯具了吧。

以上仅是引子，我想说的是，合理地制定以结果为导向KPI真的很重要。上面的例子中很显然非常消极被动，面对一个指标，只能有心无力，感兴趣的事情做好了反而没人关注。

以结果为导向主要原因有三方面。

• 首先，结果导向能更有效的提高工程师的主动性，虽然也有其他方法去促使积极主动，但是绩效考核中的结果导向能起到一个很大的正向推动作用；

• 其次，在一个年轻的工程师团队中，考核中结果导向的指标与团队的指标直接或间接关联，能使得团队成员，尤其是工程师，有更大的成就感；

• 最后，通过结果导向的KPI，在提高积极性的同时，能让工程师更快的成长，不至于每个季度下来零碎的过程性指标完成不少，但是难有很好的成长。

目前，有些工程师，尤其是前端工程师可能更多地是被动响应产品经理大量零碎的需求，这样很难制定结果导向的绩效指标。

如果加重结果导向的绩效指标也是可行的。

• 首先，产品经理将更多的精力用于用户行为分析等，并制定出高阶的产品改进需求。细化的需求主要由工程师提出，使得被动响应变成主动积极。这一点在Facebook用得比较极致，甚至产品经理提出的需求如果不能打动工程师，那么就很可能不会被采纳；

• 其次，很多时候细化的产品需求背后涉及了大量的技术点，由工程师来细化需求，在产品改进与技术成本及代价上做出较好的平衡，尤其是展现层面的改进，前端工程师对页面元素、交互方式有更全面、深刻的认识。例如，产品经理在分析用户，研究产品后得出一个通过图片展现降低跳出率的想法，转交给工程师后，由工程师通过白板给出UI原型图并解释交互方式。这时，工程师可以根据自己的特长给出一个技术复杂(可能)但是效果很好的方案，反而由产品经理提出细化的方案的话要么很粗糙，要么实现起来极其复杂。需要强调的是，细化需求如果由产品经理提出，不管事后通过多么好的沟通、讨论过程，终究不如先由工程师分析的效果好，因为细化的过程可能涉及到架构层面，甚至项目风险等问题；

• 第三，工程师不应当仅关注技术点，反而应当拿出一定的精力去理解产品，理解用户需求，以求得在小团队中充分发挥出每一个人的最大作用。我们已经被学上了十几年，好不容易从学校熬出来了，就不要再被工作给上了；不能像学校那样总感觉做的、学的没啥用。在一个商业公司，永远都是先有用户然后有产品最后有技术，不能最大化的服务于产品的技术都是扯淡。

面向结果的方式明显有很多好处：通过制定若干长期的目标，使得我们从每周，甚至每天，这种细分粒度的固定办公时间中解脱出来；员工成就感更高、成长更快；流失率更低；更强调结果，前提是个人目标应对应于团队的目标。

相比以上积极面来说，花些精力去克服这些负面影响还是值得的：难免有些工作很难做准确的效果评估；管理难度更大；有可能出现员工之间的竞争，如果没处理好的话，等等。

* 参考：Wikipedia: ROWE – Results Only Work Environment

–
注：审阅时看到“扯淡”两字觉得都不像是我写的，其实大多时候我都是可以通融和变通的，但不想再改动了，只是补充一点：以上看法只是我觉得可行，行得通，必要时可以甚至必须要变通，所以现实中与以上相反的观点很多时候我也是认同的。部分例子对观点仅作解释，不起到论证作用。

“两打程序员，三年时间，4732个bugs，和对非凡软件的不懈追求，只为打造卓越软件”

做软件难，尤其是大型软件，难于上青天。

以上就是本书的内容，作者通过3年时间跟进项目，在书中讲述了Chandler开发过程中的各种大大小小的故事，最终结论就只有一个：做软件难。

就像豆瓣上其他人评论的，这本书算是本奇书吧，OSAF团队有时间、有资金、有牛人，最终历经6年打造出1.0版，并行将就木。梦幻的开局，让人唏嘘不已的结局，其中的故事会是怎样呢？Scott Rosenberg在书中就讲述了这样一个长篇故事……

看此书，就如参加了一次次OSAF的内部会议，跟进开发的详细过程，从故事中也能看出软件工程有别于机械、土木等传统工程，进度不可控、项目不可见等等，软件开发注定就是游离于工程与艺术之间。

我也是刚接触软件开发行业，看不透为什么这个项目会延期几年，最终6年时间才出1.0版。不论细节的话，只能说Chandler生不逢时，出生在这个Web快速发展的年代。今天尝试了Google Wave内测版，感觉似乎一觉醒来，世界已经完全变了。常规软件项目我没真正做过，但是基于Web的产品在大量的设计类书里都是有个基本原则：最小化设计。也就是说1.0版能实现最最基本的功能即可，“it works”就是1.0版的全部。2009 csdn软件英雄会上支付宝用户体验师白鸦(过去好久，希望没记错，blog: http://uicom.net )提到了这点，并拿gmail举例子，gmail刚开放时基本上就只有收发邮件功能，连中文都没处理好，但是通过逐步的改进做到今天难以替代。OSAF一开始就想打造超越OUTLOOK的卓越的软件，但是当Chandler缓慢前进中，很多其他产品早已从web那条道路上飞快的超越过去了。

书中有些事情还是很有意思的。

“跟踪进度是为了协调工作，而不是要表扬或者批评谁；‘完成啦’在不同人眼里定义不同；”，这个没什么好说的。

“到OSAF后不久，杜索特就利用午餐时间向同事们做了个关于WebDav的讲座。将它描述为一种“秘密协议”：内建到Microsoft Windows和苹果Mac OS X系统中，也在许多要提供某种远端共享和编辑功能的软件包中存在，但却鲜为人知。”，注意，这里说的是午餐时间，事先的沟通远胜于会议中突兀的提出后好很多，能有效避免大量的争论。

最难忘的是这句：“如果不坚持，我什么都不是”，不可知因素太多了，“坚持”在很多时候就是最好的选择。虽然OSAF失败了，但是个中体会，也只有当事人最清楚了。

最后，这本书应该比较适合刚入软件行业的，或者软件项目管理者、或者产品经理阅读，刻骨铭心的失败的故事兴许能让人对软件工程这个特殊行业有更深入更新的了解。另外，douban上与该书相关的话题就有软件工程管理、产品的设计。不知道资深软件相关人员整天想啥，就不推荐了。