人和交互重于过程和工具。

即便你的团队都是一等一的人才，有着超强的技术和超强的表达力。但是如果过程是一团混乱，并且还没有趁手的工具。那一切依然是扯淡。所谓关注人这个核心生产力是对的，但不是说其他就不重要。

可以工作的软件重于求全责备的文档。

相信很多人鼓吹敏捷就是为了以这条来遮羞。写出同样垃圾的软件，而且还能逃避写清晰文档的责任。多么美好的事情啊。课要知道，真正的程序员所追求的不应该只是可以工作，而是要那种可以工作的非常好的软件，比如架构简单，代码整洁。同时，在你代码无法说明问题的时候，依然需要编写完备适时的文档，来提高维护性。

客户合作重于合同谈判。

这点我不懂，但是我想如果合同都是模糊不清责任不明的，将来出现分歧应该会更头痛吧，我相信，客户总有不高兴的时候，无论你怎么合作。

随时应对变化重于循规蹈矩。

又是看似很合理但很傻逼的一句话，如果你的计划是确实可行，考虑周全的。那么我真得不相信你上哪里来那么多变化，需要不停的应对，即便是软件这个所谓变化频繁的行业。这句话是头脑不清晰，做事不周全的人最好使用的借口。

我依然如同03年刚接触敏捷时候一样相信这宣言本身是真诚的确实有重大意义的，但是这么多年过去了，看着周围各种的绕梁小丑群魔乱舞的，让我本能的已经对‘敏捷’这个词产生了条件反射性的恶心。所以才产生了上面这些诡辩，真的。你们这些的所谓的‘敏捷专家’、‘敏捷布道者’让我看来跟坨狗屎好不了哪去。真比忽悠，宁亚还真不一定是我对手。

我觉得这篇写不长，因为其实关于文档的一些理念基本都是那种说着很简单，做着很难的。

文档多了好？

记得以前看CMM的时候，很强调文档的重要性。这是为什么咧？因为CMM是典型的软件工程理论嘛，而软件工程怎么来的咧？就是从建筑工程学来滴嘛。君不见，黄河之水天上来盖栋房子得有多少文档啊，来描述这个建筑的架构，每个房间的布局。这啊哪的，反正肯定很多就是了。都是设计师仔仔细细设计规划好弄好了，然后由俺们最可耐滴农民工一砖一瓦的，蹭蹭的，一栋building就出来了。所以CMM挺强调文档滴，整个软件周期，都要有这文档那文档的，堆积如山的。而实际效果呢？用猜的也知道肯定不怎么好了，不然现在人都表当自个Agile，而不说自个CMM了呢。

好吧，那你说这是为什么呢？我来告诉你。如果你建个大楼，建完之后你会没事拆着玩么？比如把18~20楼拆了，换个盖法。或者把楼里的钢筋全换一遍，换个回扣给的工作的牌子。你不会吧。所以你盖好之后，你那份文档描述的就是你的building，所以可以从下水道偷偷溜到你楼顶。所以这份文档是即使的反映了这个building的结构与状态的。

反过来，看软件开发。你能保证你写完之后的code有几天不被改？重写，重构，bug fix，需求变更。这些常见的活哪个不是要你改code。而你弄了那么多的文档，最后发现和code完全不一致了，那你说这效果能好么。文档说CLASS A是干这事的。结果一看code发现CLASS A根本就不是干那事的。当然，也可能你根本已经找不到CLASS A这么一个玩意儿了。

所以说文档足够多并不一定好，因为软件开发中，变化是从头到尾的。所以如果文档的变化跟不上项目的变化，太多的过时信息。最终非但不能帮助项目，却还会拖后腿，造成更多的怀疑，浪费经历。

少就是多？

爱扯Agile的肯定都说过这么一句话：代码即文档。

嗯，如果我没记错，好像这句应该是敏捷宣言中的？（刚查了下，原话和我记性不太一样，原话是：Working software over comprehensive documentation.）就是说如果你的代码写的足够好，本身就足够说明很多问题（比如通过起带有意义名字的变量，比如使用元数据编程，比如加恰当的注释）。那么就不需要和外在另外一个地方写场面大论来描述代码是怎么回事。

其实这方面我觉得很有代表性的就是javadoc和Xdoclet。javadoc也影响了很多后来的框架和语言啊。因为做的确实不错。通过在注视中加入一些符号，可以自动通过程序来抽象出注释，组成有意义的文档。这是多么automatic的事情。而且特别是你的注释和你的code在一起，就减少了很多两遍对不上，描述过时这类的事情。Xdoclet当然也是关于这方面的一个工具吧。

嗯，还有元数据以及DSL这种编程方式也在很大程度上为代码可读性做出了优秀的贡献。

比如Rails中，在Model之间声明关系用的belongs_to, has_many之类的关键字（当然，其实他们不算关键字，也是方法，只是表现形式cool了些）。是多么的简洁，有力，聪明，异动啊。

所以我基本上很赞成，因为大科学家爱因斯坦都说简洁性就是一种美。因为俺觉得懒惰的程序员才是好程序员。如果代码就够清楚的，或者通过代码就能生成出来很清楚的文档，那么鬼才写文档。当然，其实这观点是偏激的。因为我们确实需要文档。因为代码只能从微观角度看问题，即便你给我一个SDK文档，我还是很难看出你当初都是为什么这么设计，那么构造之类的。So，我们依然需要文档。但是要强调一定，我们需要的是高质量的文档，正确的文档。因为Diane说过：方向很重要（嗯，某次开大会说滴，很富哲理啊）。文档都是错了，就算你看个三天三夜，你也只能越看越错下去。所以，文档只有在正确的时候，才具有很大的重要性。如果只是过时的玩意儿，那么不如放到回收站吧。

The End

到现在，观念应该清楚了，文档其实还是需要的，但是我们如何去写文档呢？怎么使得文档是正确，有重大价值的呢？

嗯，我又发明了一个小所写KISSS原则。全称是：Keep it simple, stupid and synchoronous with your project. 嗯，别小看后半句噢，其实是一件非常难滴事情呢。因为锻炼你的写作技巧，尽量使得文档简洁又易懂，也许需要一些时间的锻炼，都能达到。但是synchoronous with your project需要的可是你长期的坚持啊。如果你的项目中某方面的改变牵扯到一些文档，会造成一些文档的过时，那么不要犹豫，立即更新它吧。真的不骗你，bad document的味道不比代码中bad smile造成的伤害小多少。

好吧，最后的结论就是，尽量写具备自描述能力的代码。如果某些时候，必须要写文档才能解决问题的时候，记得随时更新它。使它和你的项目保持同步。

眼睛一睁一闭，一天就过去了，嚎~~~~

嗯呐，一不小心，就又是好几天没更新blog。时间真的过的太快了。今天开了一上午的会，大伙聊了很多东西，搞的人比较high，这会离下班还有半个小时。任务也提前完成了。所以拿来写篇BLOG吧。

今天呢，就是同事给我们讲了一些Pair Programing的一些东西，算是Agile的一部分吧。当然，像我这种一贯喜欢否定的人总还是会提出很多自己的看法，毕竟，独立的思想与完整的人格我觉得是必须坚持滴。哇咔咔

好吧，不自夸了。今天要说的三点究竟是哪三点呢。请看大屏幕下面继续。

一，Pair Programing不一定就提高生产效率以及代码质量。记得我第一次看完《人月神话》之后，就坚信了一个观点：没有银弹。任何方法论或者所谓的最佳实践都有其自身的局限性，所以你要是给我说一个东西怎么都好，我直接心里就否定了。没有怎么都好的东西，包括现在这么hot，甚至都快过气的Agile这个big buzz word，当然也就有PP这个子集了。因为想起这些我就想起了CMM在很多年前的样子。诚然，Agile是有很多不错的理念，但千万要记得，没有银弹。PP也不可能面面俱到的。比如，性格不合的两个人去PP，互相谁也说服不了谁，结果一个变量的命名究竟是叫love_you还是LoveYou就争执了一上午，导致啥都没干。我主观不认为这会提高任何效率与质量。同样，俩人如果关系特好，互相默契很高，但如果很不专业，在一块躲在角落里偷偷的看《Prison Break》，然后每个小时看一集，再用剩下的不到20分钟时间里随便堆砌点垃圾去提交。这也是敷衍了事滴。再比如，如果你的上级给你们小组4个人每个人分了30个ticket。要求2天做完。这种根本是Mission Impossible的事情。你说这4个人会有心情PP么，会有心情考虑如何帮对方把代码写的优雅，把逻辑写的清楚不？反正我不信。还有，如果说我今天只不过是要修改一些页面上的typo或者是小样式，如果叫个人跟我Pair，他80%的时间里肯定觉得非常无聊。你觉得呢？上面举了好几坨例，有时候两个人会把事情搞的更糟，有的时候虽然不会搞的更糟，但是也会造成效率的浪费。想想Yahoo的衰败以及SINA的收购，过分的民主或者过分的股权分散，其实都是很不好的事情，会浪费很多机会，也会浪费很多时间去扯皮。在PP这里呢，就是PP不能确保提高效率以及质量。

二，一切方法论，包括Pair Programing其实最重要的因素都是人。嗯，确实是这样，从我上面举的例子应该看出来基本都是人造成的PP好用或不好用。其实这基本等于废话，计算机来说1+1等于2那就是定了。人喝多了那他可什么答案都敢说。人本身充满着不确定性，所以，把一切问题都归结到人肯定是放之四海而皆准的废话。可我还是喜欢强调这个，就是因为我发现虽然大家都知道人是问题的根源，但大家却不一定能重视这个认知。我把这个现象叫做‘认知回避’，是啊，谁没事愿意觉得自己这个物种是很不完善的呢。需要改进的呢。但回避也没用，反而后果更大。早点正视这个问题，正视你我包括所有人都有优缺点，都有不完善的地方，都会犯错误这个神一般存在滴事实，是很有益处的。只有你清楚的知道你的优缺点，你才知道如何去改掉缺点，或者如何避免你的缺点所造成的负面影响。好吧，说远了，回到PP，PP其实好处也是一大堆呢，具体的就google吧。可是如果想使PP发挥到如同那些大牛所说的魔力或威力的话，有一个很重要的条件，就是实施PP的人（之所以不说是第一重要的条件是因为第一条件肯定是得有台电脑-_-###）。你想想大牛说的那些魔力威力来自于PP，其实很大一部分也来自于那些人本身。因为他们本身就足够优秀，所以如果配上合适，科学的方法的话。那肯定做出来的成绩就更加的优秀了。所以，你如果想用PP也能收到同样的效果，那有很重要的一点就是除了按照大牛告诉你的最佳实践来实施PP本身，还一定要努力让自己向大牛看齐。包括你的人品，素质，性格，看待问题的角度，理解能力，沟通能力等等。这就好比乘法：PP比如说是5，如果你是2，那么得到的结果就是10，如果你是-2，那么得到的结果就是-10了。现在想明白了吧，PP重要的其实是你自身，流程啊，方法论，书上的探讨了，但是大部分PP的资料都不会讲关于提高你自身的方法，所以，速度补上这块短板吧。不然即便PP再好，你是个-2，那也没辙。

三，客观点，科学点。嗯，今天其实听同事讲PP这个topic，真的是听起来很美，但是最让我感到忐忑的就是没有数据。虽然developers都积极的表明PP提高了很多代码质量，可是从QA的角度就是还没有个数据。我觉得其实数据很重要。否则，空对空，很容易使大伙回到几十年前“赶英超美”那个疯狂的年代。所以，务实点，尽量脱离主观感觉，通过客观的数据来证明一件事物的属性，或者一件事情的好坏，或者一套方法论的可用性。这才是科学的态度啊。所以，我在会上也提了，希望可以量化PP带来的好处。看看PP对于我们的实际帮助到底是怎样的？不能莽撞认为我实施了PP，那PP资料里面所描述的那些个好处，我自然就得到了（想象曾经的EJB，真正让你得到了多少好处呢？）。科学的态度不是这样的，因为不要忘记了，想要发挥PP最大威力，你还得是那个2才行。（参见第二点）。

嗯，一不小心，就说了这么长，其实挺恨自个的，老喜欢跟人抬杠。但是吧，我爱科学啊。科学家最喜欢干的事儿就是怀疑与否定了。所以，对于这些看起来都很美的东西，一定不能让自己一下子就被带进去。不管是SOA, Agile还是最近的REST和SNS。因为真理往往掌握在少数人手里，也许你能多独立思考那么一晚上，你可能就能领悟到比别人更多的东西。同时也能训练着自个变得更加的客观。何乐而不为啊。

咳，老是一不小心就又扯的没边儿。好吧，准备就此搁笔吧。关于PP，其实我并没有深仇大恨，只不过赞扬的人太多了，我就想客观的说点别人没说或者没想的东西。

其实经历过这5，6年的软件开发，真的慢慢感觉出来一个道理：

成功的因素存在太多偶然性，而失败的因素中，很多原因确是具有必然性的，所以关注失败也许是为了迈向成功更好的一种途径。

所以，我现在很喜欢研究失败，研究最差实践，嗯，基本大伙管这个叫-教训。我想也许以后我会多聊聊关于失败，关于错误的事情？哈哈，看我时间吧。

PS：下一篇，准备简单聊下我对项目中各色各样的文档的看法。欢迎拍砖。