Facebook在今年2月2日发布了HipHop for PHP，实现了将PHP代码转换为高品质C++代码，然后用G++编译成可执行的二进制文件，从而大幅减少服务器CPU和内存消耗。今年2月份的版本可以减少50%的CPU使用率，通过不断优化，到8月份现在又可以再提高1.8倍的速度，目前Facebook绝大部分PHP均已采用。HipHop for PHP的优化效果是非常显著的，例如WordPress在HipHop下提升幅度可以达到2.7倍。

记录下来的原因是：某些片段，和我太像了。。。

你想寻找一个名字叫做“橡皮人”的人。

他总是坐在会议圆桌的10点钟方向，因为这个位置既不显眼也不担心被提问；他在MSN上的头像总是忙碌，因为正忙于在找不到开心的开心网偷菜；他总是一个人在茶水间抽烟，因为此时他的工作座机正响个不休。

他早晨可以准时起床，但感觉像一晚上没睡般疲乏；他和所有人一样善良，但从不见义勇为，连围观群众也不会去做；他不是无情无义，但从不让座；他拥有一颗温柔的心，但在致电父母时找不到语言；他有些孤独，但坚信沉默是金；他洞悉情趣的学问，但连送宠物回家都叫快递公司；他不是不渴望爱情，但连结婚都懒。

橡皮人没有病，只是心很累。为了不会不开心，他连快乐都不要了。他的形象模糊，有时隐藏在这个时代的人潮之中，有时就在每个人的镜子里——他面无表情地塞在拥挤的电梯中，他不起眼地混入地铁站汹涌的人潮中，他默默地站在斑马线前等待通过的整齐队伍中，他疲惫地沉睡在午夜依然满员的公交车座位上……他活在这个社会的潜规则之中，活在职场的金科玉律之中，活在世故的熟人社会之中，活在阶层板结的崛起大国之中，活在周遭变化速度让人皮肤都感到麻木的国度之中。

橡皮人似乎就是你自己，也许亦是所有人。皆因橡皮人患上了一种叫做没有感觉的病，和你的病一模一样。

这段时间准备利用空闲时间把这个的原型做出来。应该会比sourceforge多一些想法，但是具体什么时候能全部实现，先实现什么再实现什么，需要把所有的需求罗列出来之后再做决定。

废话不说了，先看转载：

这个想法由来已久，也是因为自己在现在效力的公司中能看到一些不良的现象，但自己却不是管理层，没有任何的执行力去改变它。

软件公司管理职位越往上，越不熟悉技术方面，加上此举和重构一样，很可能是吃力不讨好的做法，要得到执行则是想当困难的。客户没有这些要求，我们为什么要去做呢？如果员工有这个念头，我基本上可以看出他对自己的公司是没有想法的，工作如快餐式开发，做完拉倒的迹象很明显。

软件公司越往大规模发展就越要注意可重用代码的利用，最好就是建立自己的代码库。

我在公司做了一阵子开发后发现，开发团队中根本没有这个意识。当然开发团队没这个意识不是团队的错，而是带团队的人的错误。就是上层管理不重视，所以下层也就不重视了。为什么说团队中没有可重用代码的意识呢？很显然，公司没有建立自己的可重用代码库，员工在开发时也没有这个意识，当碰到问题不会先去问一下公司里是不是已经写过类似的算法了，这导致信息的极度不共享。员工可能会在不同的项目中反反复复地写那些简单的小函数。稍微能有点意识的人可能自己会把代码收集起来，自己用时拷贝粘贴即可。但是个人的东西一般是不会拿出来秀的，所以团队的水平仍然是大众的平均水平。个别案例，甚至为了一个简单的函数而研究很多工时，那可真是让人哭笑不得了。而且研究的时候，管理层还不一定知道他把时间全花在了那个小函数上，而是以为开发确实可能需要那些时间。这一定层次上也影响到管理层的管理和进度把握。

那么我们怎么去组建公司自己的可重用代码库呢？

一、做好精神领袖。

有想法是好事，但一定要去做，不做的想法再好也没有用。我们首先就要给员工灌输这个意识，不仅仅是程序员，做设计的、搞测试的也要有这个意识。在工作中随时寻找可以抽象成复用的那一部分。要把这种意识从新人培训开始，就要深入的植入。此外也要培养员工对公司的家庭归属感。

二、建立专门组织和电子化管理

员工有了意识，那么接下来，我觉得公司应该有专门的人员管理这个库，建立起相关的组织来维护它。对外可以采用接口的形式，即一般不提供源码，只提供访问接口和库。

首先要建立一个查询系统，提供库内已收入的方法，函数等等详细信息的查询，这个查询可以不设权限，和项目有关的人员都能自由使用。这一步很重要，因为写程序的人大多不善交际，如果你说谁有好的方法要抽象出来的，和项目经理反应，我估计就没人出来反应，这样这个想法就得不到很好的互动了。

三、惰性增量式与后台研发式创建库。

对于小公司可能没有太多人力资源，很多重要的东西只能在实战中积累，那么就是所谓的惰性增量式。即遇到一个问题实现一个问题，最后入库，不做单独的可重用库开发。有实力的公司可以同时由专人来负责其它可能的需求（当前并没有遇到），把它开发成重用库即为研发式创建。

四、制定重用的准则。

首先关于什么代码应该重用？一方面是通用的，每个产品都能用到的代码，肯定要入库；另一方面是具有专业性的算法，比如图形算法等等，这种代码的通用性仅限于那个领域，不是所有产品都能用上的，但也要建立，因为他的技术含量高，避免二次反复开发。

对于客户而言，我们是一家人，是软件的开发和提供方，所以公司的代码一般不分服务与客户，代码大家都能看到，如果任其自由复制修改应用，那么虽然也叫重用但没办法统一，也就无法管理了。所以我主张，公司的重用库一般情况下最好实现封装，普通项目开发人员一般也得不到它的代码。他们要做的就是上报可重用的代码、查询库中已有的代码、直接调用。即使测试过程中发现是重用库的Bug，也和开发人员没有关系，由管理重用代码库的组织来解决，找到代码的作者，由其修改，新库一发布，就行了。所以说公司内部建立这种请求－－服务的关系的话，各自的职责便明确化了。

开发人员一般比较偷懒，有了请求－－服务的模式后，请求的人就会增多，这对于加深开发人员可重用意识也很有积极的意义。一般我们也懒得去动脑筋写算法，有这个查询机会何乐而不为呢？系统上一查，没有，于是可以请求。可重用管理组的人在评定通过后，可以由他们来开发把这个算法添加到库中，我们在得到信息后可以直接调用。重用管理组背后的技术支持可能是牛人们，这有什么问题呢，我们是要开发产品，不是去比试哪个大学毕业生牛，大家各自有各自位置！有现成的就可以复用，有更强大的开发技术资源的就可以用，不要什么东西都自己去做。这一点很重要。

当然，如果开发组的需求不是很通用，和库中的接口不协调的话，也可以变通，可以向管理组请求提供库的代码，在代码的基础上修改后直接应用，这样一来这些代码就不应该算是调用重用库了，一般是不推荐这样做的。或者项目组可以考虑应用适配器模式，适配接口，尽量用上库。实在需要改代码内部算法的也就只能提供源码让其修改后使用，总之尽量不要重新开发。

另外，如果开发人员上报的可重用代码抽象地不理想，换言之，抽象地不通用，那么管理组应该要与项目组协调，必须把接口设计成通用性高的，由项目这边妥协修改调用形式；当然，如果因某些原因（比如接口是客户规定的），无法修改的，就不要收入库中了（可以收入改正后的版本单独入库），因为很明显这段代码是为了项目而生存的，没必要重用化。

五、维护。

这个就不用多说了，既然决定一试，就不是创建出来后可以袖手不管。诸如库的更新升级或者修改Bug的事务可能也不会很轻松，但是不能因此而荒废。可重用库的价值很大程度上就要看维护了。

修改库的Bug原则上谁写谁改，如果是开发人员提供的，应该由开发人员修正，管理组审核。

再一个就是文档，文档一定要详细，一定要实时更新。程序即时编辑提示文档、外部API手册、不同的版本、函数的不同用法、使用场合等等一定要详细，说白了，内部算法就算是爱因斯坦再世写的，放出的接口和文档，也要让傻瓜用的起来。我非常注重这点，因为我也有和这类开发人员合作过，算法的调用相当复杂（就是要你调用的人也要懂这个懂那个，否则用不来）。这个我很奇怪，但也怪不着他们，因为他们自己懂就以会天下人都懂，而没有这方面的意识了。哪天，微软和你说想用Windows？把这个二极管焊在主板的X位置，把那个三极管焊在Y位置，不要焊反，否则电脑烧了，你就别用Windows了。反正我们提供你Windows了，是你不会用，和我们无关。技术人员是有牛人，但人外有人，对于用Windows再牛的程序员，微软如果这样做，他也牛不起来了，除非去用Linux。所以做技术的一定要考虑怎样让不懂技术的人用得爽，这绝对是一个功力。诚然，他们的解释是合情合理的：算法就应该是纯净的，任何与算法无关的事前准备之类的，不属于算法内部。解释得很好，我也赞成，那么请麻烦一下，算法都写出来了，你就再写个适配接口吧，就把这部分当成应用，而不是你的算法不就行了吗。

六、单元测试

这是极其重要的一环，如果有专职的维护和技术人员的话，一定要建立对已有库的单元测试用例和相关测试程序。Bug修正后，首先要做的是，把原测试用例测试通过，保证修正后不破坏其它功能。然后新添加测试用例测试。

可重用库，必须以严谨的方式管理，否则基础的东西出了问题，上层的构建将会直接面临崩溃的风险。千万不要等新库一发布，客户的新系统，老程序，产品A，产品B都崩溃了。

以上谈了些个人对公司建设可重用代码库的一些想法，最后总结一下好处和风险：

好处：

１、这是公司的无形资产，是公司的发展日志。员工是公司的，员工创造的思想也是公司的，既然是公司的，公司不去注意收集、管理这些无形的东西，将来造成技术流失，能怪谁呢（只见管理层抱着一堆产品的源码，感叹地说，我们是有技术的，全在这里面，但是却没人用的起来）？

２、降低以后的项目开发难度和缩短开发速度，提高软件质量。

３、对公司的产品的架构形式统一管理。也就是说这些可重用的代码不要嵌在各个软件产品中，而是独立成通用的包或库。需要时只要对外发布更新库而不用更新客户程序。

４、可重用代码库相当于公司的笔记，公司不怕核心员工跳槽，因为他曾努力写下的算法以经整理成可重用的库了。注意，一定要整理成规范易用的接口（算法再复杂也不要影响使用者的使用心态），不整理的随心所欲的源代码禁止入库。

５、加强团队成员间的交流与和作。因为加强了这方面的意识，开发人员随时会注意这些问题而与周边组员，甚至重用库的管理人员进行沟通。

风险：

１、具有高风险，执行前需要一个深远的考虑和计划。否则不易执行及运行长久。

２、维护库需要花费不少时间和精力，否则一旦发布新库，很有可能，所有产品受影响。不过可以考虑只针对部分产品发布库。但是如果你能确定现有库有一个Bug，而目前所有产品都使用这个库，那么从职业道德上来说，应该通知所有产品更新库，而不能等到客户Bug再现后再做处理。或者我们可以在公司网站上发布库，让客户自由决定是否下载最新的库。

３、正因为这些库是基础的基础，所以在评定审查以及讨论良好通用的接口是十分重要的，一旦决定将无法随意变更，公司要有这个实力安排这些专业人员，从而增加了成本。只有做好了，才能收回成本，应用于以后的所有开发，做不好就真的是吃力不讨好了。

４、产品系列具有严重依赖于这些库的特性，所以没有很好的管理，一旦出问题往往不是一个产品出事情，所有产品都会出问题。如果公司没有这种管理能力付不起这种风险，宁可一个产品一个产品分开开发，也不愿做一劳永逸的事，请不要使用这个方案。

５、这个风险是采用这个方案的一个很大风险。就是人力资源上容易出问题。大学刚毕业的有些人还是很有牛劲的，总希望做些厉害的开发，如果他总是用公司的基础库，甚至代码都看不到，对他来说可能会不爽，觉得学不到东西，造成人才流失。这个只有进行教育了，实际上，在业务逻辑上也是很有用武之地的，不可能练不到人，或者往设计方向走，怎么可能练不到人，不要一味追求写底层的东西，公司能提供给你也是开发人员的福气啊，要学会站在巨人的肩膀上。所以一定要让开发人员理解公司的这种做法。

说到这里，我又在想自己现在效力的公司，完全不注重“整理”。可重用库的建设我们就不去谈了，这种花成本没收益的事公司决计不做，那也应该注意下最简单的代码整理吧，至少在开发一个很有难度的项目时，管理层不懂得整理资源。以至于其它组开发类似的东西时，往往会听到管理层说这样的话，“好像某某在N年前做过这个东西，去问问他吧！”然后就看到开发人员从一个部跑到另一个部去取经。就算别人N年前做过，别人可不是闲人啊，专门给你解决这问题吗。就算愿意，他自己估计也忘了差不多了吧，还得再重新捡起来。对两个部来说都是降低效率的做法。如果别人已经离职了呢？那就把当年的项目源码翻出来吧，一起啃一起学，先把项目理解了，再找到你要的东西。于是加班开始了，公司还振振有辞，说加班是没有办法的，竞争激烈啊。要知道，良好的管理是不会加班的，加班绝对是哪个环节出问题了。

自己亲自体会，越发觉得建立可重用库的重要性。不是说公司没有重用的思想，而是觉得不到位。公司的重用思想，就是粘贴拷贝，修修补补，完全没有管理。如果把重用意识上升到管理层次，那么对公司的将来，至少在技术上，我是非常有信心的。

这个想法由来已久，也是因为自己在现在效力的公司中能看到一些不良的现象，但自己却不是管理层，没有任何的执行力去改变它。　　软件公司管理职位越往上，越不熟悉技术方面，加上此举和重构一样，很可能是吃力不讨好的做法，要得到执行则是想当困难的。客户没有这些要求，我们为什么要去做呢？如果员工有这个念头，我基本上可以看出他对自己的公司是没有想法的，工作如快餐式开发，做完拉倒的迹象很明显。　　软件公司越往大规模发展就越要注意可重用代码的利用，最好就是建立自己的代码库。　　我在公司做了一阵子开发后发现，开发团队中根本没有这个意识。当然开发团队没这个意识不是团队的错，而是带团队的人的错误。就是上层管理不重视，所以下层也就不重视了。为什么说团队中没有可重用代码的意识呢？很显然，公司没有建立自己的可重用代码库，员工在开发时也没有这个意识，当碰到问题不会先去问一下公司里是不是已经写过类似的算法了，这导致信息的极度不共享。员工可能会在不同的项目中反反复复地写那些简单的小函数。稍微能有点意识的人可能自己会把代码收集起来，自己用时拷贝粘贴即可。但是个人的东西一般是不会拿出来秀的，所以团队的水平仍然是大众的平均水平。个别案例，甚至为了一个简单的函数而研究很多工时，那可真是让人哭笑不得了。而且研究的时候，管理层还不一定知道他把时间全花在了那个小函数上，而是以为开发确实可能需要那些时间。这一定层次上也影响到管理层的管理和进度把握。　　那么我们怎么去组建公司自己的可重用代码库呢？　　一、做好精神领袖。　　有想法是好事，但一定要去做，不做的想法再好也没有用。我们首先就要给员工灌输这个意识，不仅仅是程序员，做设计的、搞测试的也要有这个意识。在工作中随时寻找可以抽象成复用的那一部分。要把这种意识从新人培训开始，就要深入的植入。此外也要培养员工对公司的家庭归属感。　　二、建立专门组织和电子化管理　　员工有了意识，那么接下来，我觉得公司应该有专门的人员管理这个库，建立起相关的组织来维护它。对外可以采用接口的形式，即一般不提供源码，只提供访问接口和库。　　首先要建立一个查询系统，提供库内已收入的方法，函数等等详细信息的查询，这个查询可以不设权限，和项目有关的人员都能自由使用。这一步很重要，因为写程序的人大多不善交际，如果你说谁有好的方法要抽象出来的，和项目经理反应，我估计就没人出来反应，这样这个想法就得不到很好的互动了。　　三、惰性增量式与后台研发式创建库。　　对于小公司可能没有太多人力资源，很多重要的东西只能在实战中积累，那么就是所谓的惰性增量式。即遇到一个问题实现一个问题，最后入库，不做单独的可重用库开发。有实力的公司可以同时由专人来负责其它可能的需求（当前并没有遇到），把它开发成重用库即为研发式创建。　　四、制定重用的准则。　　首先关于什么代码应该重用？一方面是通用的，每个产品都能用到的代码，肯定要入库；另一方面是具有专业性的算法，比如图形算法等等，这种代码的通用性仅限于那个领域，不是所有产品都能用上的，但也要建立，因为他的技术含量高，避免二次反复开发。　　对于客户而言，我们是一家人，是软件的开发和提供方，所以公司的代码一般不分服务与客户，代码大家都能看到，如果任其自由复制修改应用，那么虽然也叫重用但没办法统一，也就无法管理了。所以我主张，公司的重用库一般情况下最好实现封装，普通项目开发人员一般也得不到它的代码。他们要做的就是上报可重用的代码、查询库中已有的代码、直接调用。即使测试过程中发现是重用库的Bug，也和开发人员没有关系，由管理重用代码库的组织来解决，找到代码的作者，由其修改，新库一发布，就行了。所以说公司内部建立这种请求－－服务的关系的话，各自的职责便明确化了。　　开发人员一般比较偷懒，有了请求－－服务的模式后，请求的人就会增多，这对于加深开发人员可重用意识也很有积极的意义。一般我们也懒得去动脑筋写算法，有这个查询机会何乐而不为呢？系统上一查，没有，于是可以请求。可重用管理组的人在评定通过后，可以由他们来开发把这个算法添加到库中，我们在得到信息后可以直接调用。重用管理组背后的技术支持可能是牛人们，这有什么问题呢，我们是要开发产品，不是去比试哪个大学毕业生牛，大家各自有各自位置！有现成的就可以复用，有更强大的开发技术资源的就可以用，不要什么东西都自己去做。这一点很重要。　　当然，如果开发组的需求不是很通用，和库中的接口不协调的话，也可以变通，可以向管理组请求提供库的代码，在代码的基础上修改后直接应用，这样一来这些代码就不应该算是调用重用库了，一般是不推荐这样做的。或者项目组可以考虑应用适配器模式，适配接口，尽量用上库。实在需要改代码内部算法的也就只能提供源码让其修改后使用，总之尽量不要重新开发。　　另外，如果开发人员上报的可重用代码抽象地不理想，换言之，抽象地不通用，那么管理组应该要与项目组协调，必须把接口设计成通用性高的，由项目这边妥协修改调用形式；当然，如果因某些原因（比如接口是客户规定的），无法修改的，就不要收入库中了（可以收入改正后的版本单独入库），因为很明显这段代码是为了项目而生存的，没必要重用化。　　五、维护。　　这个就不用多说了，既然决定一试，就不是创建出来后可以袖手不管。诸如库的更新升级或者修改Bug的事务可能也不会很轻松，但是不能因此而荒废。可重用库的价值很大程度上就要看维护了。　　修改库的Bug原则上谁写谁改，如果是开发人员提供的，应该由开发人员修正，管理组审核。　　再一个就是文档，文档一定要详细，一定要实时更新。程序即时编辑提示文档、外部API手册、不同的版本、函数的不同用法、使用场合等等一定要详细，说白了，内部算法就算是爱因斯坦再世写的，放出的接口和文档，也要让傻瓜用的起来。我非常注重这点，因为我也有和这类开发人员合作过，算法的调用相当复杂（就是要你调用的人也要懂这个懂那个，否则用不来）。这个我很奇怪，但也怪不着他们，因为他们自己懂就以会天下人都懂，而没有这方面的意识了。哪天，微软和你说想用Windows？把这个二极管焊在主板的X位置，把那个三极管焊在Y位置，不要焊反，否则电脑烧了，你就别用Windows了。反正我们提供你Windows了，是你不会用，和我们无关。技术人员是有牛人，但人外有人，对于用Windows再牛的程序员，微软如果这样做，他也牛不起来了，除非去用Linux。所以做技术的一定要考虑怎样让不懂技术的人用得爽，这绝对是一个功力。诚然，他们的解释是合情合理的：算法就应该是纯净的，任何与算法无关的事前准备之类的，不属于算法内部。解释得很好，我也赞成，那么请麻烦一下，算法都写出来了，你就再写个适配接口吧，就把这部分当成应用，而不是你的算法不就行了吗。　　六、单元测试　　这是极其重要的一环，如果有专职的维护和技术人员的话，一定要建立对已有库的单元测试用例和相关测试程序。Bug修正后，首先要做的是，把原测试用例测试通过，保证修正后不破坏其它功能。然后新添加测试用例测试。　　可重用库，必须以严谨的方式管理，否则基础的东西出了问题，上层的构建将会直接面临崩溃的风险。千万不要等新库一发布，客户的新系统，老程序，产品A，产品B都崩溃了。　　以上谈了些个人对公司建设可重用代码库的一些想法，最后总结一下好处和风险：　　好处：　　１、这是公司的无形资产，是公司的发展日志。员工是公司的，员工创造的思想也是公司的，既然是公司的，公司不去注意收集、管理这些无形的东西，将来造成技术流失，能怪谁呢（只见管理层抱着一堆产品的源码，感叹地说，我们是有技术的，全在这里面，但是却没人用的起来）？　　２、降低以后的项目开发难度和缩短开发速度，提高软件质量。　　３、对公司的产品的架构形式统一管理。也就是说这些可重用的代码不要嵌在各个软件产品中，而是独立成通用的包或库。需要时只要对外发布更新库而不用更新客户程序。　　４、可重用代码库相当于公司的笔记，公司不怕核心员工跳槽，因为他曾努力写下的算法以经整理成可重用的库了。注意，一定要整理成规范易用的接口（算法再复杂也不要影响使用者的使用心态），不整理的随心所欲的源代码禁止入库。　　５、加强团队成员间的交流与和作。因为加强了这方面的意识，开发人员随时会注意这些问题而与周边组员，甚至重用库的管理人员进行沟通。　　风险：　　１、具有高风险，执行前需要一个深远的考虑和计划。否则不易执行及运行长久。　　２、维护库需要花费不少时间和精力，否则一旦发布新库，很有可能，所有产品受影响。不过可以考虑只针对部分产品发布库。但是如果你能确定现有库有一个Bug，而目前所有产品都使用这个库，那么从职业道德上来说，应该通知所有产品更新库，而不能等到客户Bug再现后再做处理。或者我们可以在公司网站上发布库，让客户自由决定是否下载最新的库。　　３、正因为这些库是基础的基础，所以在评定审查以及讨论良好通用的接口是十分重要的，一旦决定将无法随意变更，公司要有这个实力安排这些专业人员，从而增加了成本。只有做好了，才能收回成本，应用于以后的所有开发，做不好就真的是吃力不讨好了。　　４、产品系列具有严重依赖于这些库的特性，所以没有很好的管理，一旦出问题往往不是一个产品出事情，所有产品都会出问题。如果公司没有这种管理能力付不起这种风险，宁可一个产品一个产品分开开发，也不愿做一劳永逸的事，请不要使用这个方案。　　５、这个风险是采用这个方案的一个很大风险。就是人力资源上容易出问题。大学刚毕业的有些人还是很有牛劲的，总希望做些厉害的开发，如果他总是用公司的基础库，甚至代码都看不到，对他来说可能会不爽，觉得学不到东西，造成人才流失。这个只有进行教育了，实际上，在业务逻辑上也是很有用武之地的，不可能练不到人，或者往设计方向走，怎么可能练不到人，不要一味追求写底层的东西，公司能提供给你也是开发人员的福气啊，要学会站在巨人的肩膀上。所以一定要让开发人员理解公司的这种做法。　　说到这里，我又在想自己现在效力的公司，完全不注重“整理”。可重用库的建设我们就不去谈了，这种花成本没收益的事公司决计不做，那也应该注意下最简单的代码整理吧，至少在开发一个很有难度的项目时，管理层不懂得整理资源。以至于其它组开发类似的东西时，往往会听到管理层说这样的话，“好像某某在N年前做过这个东西，去问问他吧！”然后就看到开发人员从一个部跑到另一个部去取经。就算别人N年前做过，别人可不是闲人啊，专门给你解决这问题吗。就算愿意，他自己估计也忘了差不多了吧，还得再重新捡起来。对两个部来说都是降低效率的做法。如果别人已经离职了呢？那就把当年的项目源码翻出来吧，一起啃一起学，先把项目理解了，再找到你要的东西。于是加班开始了，公司还振振有辞，说加班是没有办法的，竞争激烈啊。要知道，良好的管理是不会加班的，加班绝对是哪个环节出问题了。　　自己亲自体会，越发觉得建立可重用库的重要性。不是说公司没有重用的思想，而是觉得不到位。公司的重用思想，就是粘贴拷贝，修修补补，完全没有管理。如果把重用意识上升到管理层次，那么对公司的将来，至少在技术上，我是非常有信心的。

今天下午发梦，做了一些关于淘宝买卖的梦。以物易物的模式，公交车，洒下斑斑点点阳光的路边梧桐，追车……　梦里梦外都是要做淘宝的想法。

看了淘宝上面一篇文章。作为主角的漂亮MM某天忽然决定要开一个店面做生意，然后跑去找人家正在营业的商家分店面，装修、进货、开业。短短两个月净赚2W5大洋。做的是大家到处都可以看到的少女服装，而且还是在淡季。作者觉得：我深深的感到，成大事者真有一种不讲道理的豪情和执着。头头是道的分析大多是马后炮，而成功往往来自莫名其妙的直觉和对直觉的坚决执行！其实我也是这么觉得的。

然后开始盘点自己，才发现原来自己都是没有什么爱好和兴趣的。可能我就不是一个实干派吧。我是实用主义者，但不是一个实干派，所以只是定位于一个信奉实用主义的智囊团比较好。

再多困难，淘宝是一定要做的。但是做什么呢？还是再想一想吧。

第一象限是重要又急迫的事。诸如应付难缠的客户、准时完成工作、住院开刀等等。

第二象限是重要但不紧急的事。比如，包括长期的规划、问题的发掘与预防、参加培训、向上级提出问题处理建议等等。

第三象限属于不紧急也不重要的事。既然不重要也不紧急，那就不值得花时间在这个象限。

第四象限是紧急但不重要的事。表面看似第一象限，因为迫切的呼声会让我们产生“这件事很重要”的错觉──实际上就算重要也是对别人而言。电话、会议、突来访客都属于这一类。我们花很多时间在这个里面打转，自以为是在第一象限，其实只是在第四象限徘徊。

现在我们不妨回顾一下上周的生活与工作，你在哪个象限花的时间最多？请注意，在划分第一和每三象限时要特别小心，急迫的事很容易被误认为重要的事。其实二者的区别就在于这件事是否有助于完成某种重要的目标，如果答案是否定的，便应归入第三象限。

要学会把时间花在第二象限，做重要而不紧迫的事。那样才会减少重要的事进入第一象限，变得紧急。

案例：一个价值2.5万美元的建议
曾经有位效率研究专家艾伊贝•李，他给当时的美国史卡鲁钢铁公司的总裁查鲁斯一个时间管理的建议，结果查鲁斯因为这个建议给了艾伊贝•李一张价值2.5万美元的支票，那是为了感激李给他的这个神奇的建议，那么这个建议是什么？让我们来揭开这个谜底。

原来，查鲁斯每天忙于公司中繁复的事务，他是一个追求完美的人，但是事无巨细，他一个人怎么可能管得过来，于是很多事情最后都不能有效地做下去。

而李的这个建议正是：
1．不要想把所有事情都做完。
2．手边的事情并不一定是最重要的事情。
3．每天晚上写出你明天必须做的事情，按照事情的重要性排列。
4．第二天先做最重要的事情，不必去顾及其他事情。第一件事做完后，再做第二件，依此类推。
5．到了晚上，如果你列出的事情没有做完也没关系，因为你已经把最重要的事情都做完了，剩下的事情明天再做。

于是，查鲁斯按照李给他的建议试了一段时间，谁知效果非常惊人。当然，你也可以试一下李的建议！

时间是永远守恒的，怎样才能在有限的时间里做更多有效的事情？

答案就是，永远做重要而又不紧迫急的事。

这是一篇受密码保护的文章。您需要提供访问密码：

密码：

今天换了博客的主题，带点奇幻色彩的背景，希望自己能渐渐重新振奋起来。

把最近遇到的一些事儿罗列出来吧，口水帐，只是记录。

【一点感动】

4月3日晚20:30看央视新闻频道的东方时空，其中一段是《马路乡抗旱日志之六》，将云南某地马路乡的小村民贾梅梅一家在干旱的气候下如何生活的。其中一段记者问贾梅梅有没有难过的事情，小女孩怯生生地说：吃韭菜的时候难过。一点菜都没得，怎么过哦！买菜的钱都没得。我看到这里的时候，鼻子忽然一酸。8岁的小女孩，在生活的磨砺下，知道最难过的事情是没法吃饱，懂得为碗里的饭菜操心，这是怎样的一种境遇！？两相比较，城里的人还在为卿卿我我烦恼，算不算是无谓增加碳排放，制造环境、心灵的双重污染？！

【两篇文章】

好久没买《读者》，昨天出去的时候买了。只看了寥寥几篇，就有两篇觉得很通俗易懂，把道理讲得白又不俗烂的。

一篇叫《羞耻啊，我们居然没有敌人》。说一个意大利人在纽约打车的时候，和一个巴基斯坦的司机聊天。巴基斯坦司机告诉作者，他们国家的世敌是印度，现在也正在和印度开战。然后他问作者：你们国家的敌人是谁？当作者告诉他，意大利从来没有这样的世敌，司机不相信，觉得作者骗了他。事后作者反思，觉得一个国家没有外敌，必然会有内患，地区与地区、正与邪、政党与政党，都在斗，并不是说当一个国家没有外敌的时候，人民就会和平。对“意大利没有敌人”的这种说法，作者感到很羞愧。

第二篇是一篇小文。一位作家看老农植树，正值春雨绵绵，作家认为这批树赶上了好时候，一定可以长得很好。老农却不这么看，他说这种雨会让树的根长在地面浅表——因为树根在地表就能吸取到养分——以后遇到大风大雨很容易就会被吹到冲走。倒是这个时候遇上几天的干旱，可以让这些树的树根伸到地底更深入的地方，根基更加牢固，以后遇到大风大雨也不会怕。

【一个女人】

昨天下午去了趟超市，打算买三件东西：烧水壶、秋衣和全钢的水杯，结果可惜只买到了烧水壶，秋衣没看到有卖的，而不锈钢水杯恰好又都不是全钢的，杯盖往往都是塑料制品。于是带上水壶、跳绳和一些吃的，悻悻地去收银台结帐。

收银台排在我前面的是一个二十七八的妇女，高挑，卷发过肩，高跟短帮靴，看外表属于比较时尚的类型。拎着四五袋蔬菜生鲜区的食物，其中一袋里面装的两条还在蹦跶的小鲫鱼。收银员帮她扫过价码之后，报了总价：八块三毛三。我一下子被震住了。感觉能在北京这种物欲横流的地方遇到这么精打细算的的女孩子真不容易！

看着她掏钱付帐的时候略显局促的表情，我忽然想，我家亲爱的，会不会也是这样精打细算的呢？哈哈

【潜龙勿用】

一直觉得自己的前途非常光明，就是道路可能理所当然的曲折一些。就像斯托克代尔悖论提到的规律一样。这种心态让我现在看待一些容易让人激动的问题时，显得非常淡然。再说了，我现在也还没有准备好，如果现在真有这样的机会去统领一家过亿资产的公司，结局几乎是肯定的。易经所谓“潜龙勿用”，也是这个意思。

抓住2009年的尾巴恋爱，于是整个2010，注定我是要在甜蜜和癫狂中度过。用尽浑身的力气，去培育一份感情。炽热的情绪总是少不了，一如现在迫不及待想要两个人就开始共同生活一般。虽然也想过要让对方体面地过来，但是理性在此刻大抵注定会统统被感性打败的。

还有好多话，却都说不出，词穷了。留待下次罢

但是我很后悔，因为这个行为破坏了我和很多朋友之间的感情，不少朋友在这两天直接质问我，为什么我没有收到黄段子，难道你不把我当朋友么？其实不是这样的，有可能你本人很黄，但我的黄段子不够黄，被你当成了一个普通笑话，有可能你本人不黄，但我的黄段子足够黄，被中国移动直接屏蔽，并不是每一个朋友我都发，因为很多朋友平时看上去还是比较正经的，没想到你们那么不正经。

除了给男性朋友黄段子以外，从明天开始，我决定双管齐下，对一些女性朋友进行性骚扰。这一切其实都是为了弥补政府的失职。我坚决拥护政府的决策，但是政府没有告诉我们对黄段子和色情短信的界定，相关部门应该在人民日报和新闻联播里刊登朗诵不能通过的黄段子或者淫秽词汇，比如说在新闻联播中，女播音员说，相关部门决定对手机涉黄进行严厉打击，防止手机短信低俗化，出席本次活动的屏蔽词有——“阴道”，男播音员接着说道“阴茎”……这才是负责认真的态度。

其实，黄段子和性骚扰完全不一样，黄段子在人际交往里扮演着重要的角色，黄段子是拉近人与人之间距离的重要手段。我身边的朋友没有人看到有人在手机里给他发了一个黄段子而暴跳如雷的，唯一不爽的可能性只有两种，第一种就是这个黄段子不够好玩，第二个就是这个黄段子是自己刚刚看过并且转发出去的。当然，由于我们经常站在民意的对立面，所以也不排除政府做一个调查，百分之九十的人表示，非常讨厌黄段子，黄段子给他们的生活带来了巨大的困扰，比如导致他学习分心，考不上研究生，当不了公务员。

第二种短信就是性暗示短信或者调情短信，调情短信在人际交往里扮演着重要的角色，调情短信是拉近人与人之间距离的重要手段。既然都能发出这样的短信了，估计已经有着很高的回床率了，无论是情人情侣或者夫妻，这样的短信也是必不可少，合情合理，我又没有在新民晚报上登报表示就喜欢人家什么姿势，这种单对单的消息当事人双方都表示没意见，但是连当事人还没插入，怎么突然间政府就插手了呢。

所以，我相信政府此举的目的其实是要屏蔽一些卖淫嫖娼信息，比如说我收到过的“各地小妹，贴心服务，白领500元，学生妹600元，模特800元，洋妞1200元，破处3000元”，从这条消息里我们得知两个讯息，第一个就是往往这样的短信里并不含有屏蔽词，第二个就是白领真的很可怜，生活工作压力大，连出去卖或者假装这个身份出去卖都卖不出一个好价钱。

另外我又一个疑惑的是，这究竟是怎样的一个审查系统，我从来不把侵犯人权和隐私权用来做文章，这是一个夫妻做爱都有人破门而入命令你拔出的地方。但是我很好奇，比如说你和你女人调情，结果被电脑先屏蔽审查了，然后就是相关部门的人员进行人工审查，最后审查下来没问题，这短信发出去了，你这应该算是一条短信调戏了两个人啊，连组织的女人都被你一并调戏了。另外，这个系统肯定会截停很多各种人的低俗短信，无论是各地领导，社会名流，文体明星，工人农民等等，虽然这些人可能最后没有被停机，但是每天看他们发送的各种短信应该很有意思，说不定还有屏幕前的你你你你你你你。

在二十年前，我国对于要消灭的群体都冠以流氓两字，然后判刑的判刑，枪毙的枪毙，到了今天，这个词汇变成了“低俗”，要消灭你，你就是低俗的。我花了很长时间去想，那些界定别人低俗的人，他们到底高雅在哪里，比如说有人花一百块嫖娼是低俗，有人用一百万去玩艺人就是高雅，有人看黄色图片是低俗，有人看红头文件是高雅，有人买个仿真枪是低俗，有人真枪一暴两个头是高雅，有人玩魔兽就是低俗，有人玩模特就是高雅，当然，这个谁都说不清楚，说清楚了，就不能随心所欲了。为了防止有一天我突然变成一个低俗的人，我率先低俗，并承认

从今天起，做一个低俗的人

劈腿翻墙  周游世界

从今天起，污染粮食和蔬菜

我有一个房子  面向大海  却被强拆