博客园_你听海是不是在笑

2011再见，2012我不怕你

2011-12-31T18:52:00Z

好久好久没写点什么了，2011年最后一天，写点东西纪念下吧，谁知道2012的故事真的假的呢。
工作：
2011春节拿了不少奖金，算是对10年低工资的补偿，总体算来虽然不算满意，但有钱拿还是高兴的，所以年过得还是挺愉快，年后，做了三年的产品终于要见客户了，一遍一遍的测试，一轮一轮的演示，紧张而有序，看着自己的努力就要创造价值了，当时还真是挺兴奋的，一直盼着呢。
先说说这个产品的背景吧，三年前我来到了这家公司，整个公司规模不小，大概六百来人吧，但软件部门不大，三十来人，而且原来的开发人员都转做技术支持了，其实不能算是软件部了，叫支持部更合适。我用了三个月的时间从一个人开始拉起了一只能干点活的小团队（1个负责产品设计，3个程序员，1个美工，1个测试，敏捷开发流程）同时搭了个产品技术架构，人员基本整齐后我们把原架构扔了重新做了个，大概08年9月吧开始了第一版产品的征程，开始做的时候总经理就告诉我，这第一版就是给你们练练手，当时真觉得太幸福了，这回真让我逮着了，可以大展宏图了，这是让我们做精品啊，这不是我们开发人员一直想要的么，按照我们的想法慢慢去打磨产品，优秀的架构去承载灵活的系统，去创造伟大的产品。当时的我也并不认为真的只是练练手，我幼稚的认为只要我们把产品做好了没道理不卖的，这一帮子人光工资也不少钱啊，我们很努力把心血与汗水洒在产品中，但事实证明，地主家果然是有余粮的。一年多得时间我们终于完成了第一版，各方反馈都不错，总经理就是不让卖，总结回顾搞了三个月，结论还是要重新做，而且要拉着长沙的一个团队一起做，我当时真有点迷糊啊，现在看来其实就是不信任，根本不看你项目做的怎样，一句话我们没有成功经验，而长沙那边的团队做了一个公司正在卖的产品，算挺成功吧，而且他们有个干了快20年没脱离写码的开发经理，说实话我还是挺尊敬他得，快20来年不离一线，这需要怎样的精神啊（不过反过来说20年都没脱离一线也是有问题的，7，8个人的团队连版本控制系统能够都不上，全部是拷贝来拷贝去，真佩服），但毕竟不在一个城市沟通成本实在太高了，而且我并不认可他们的架构，感觉实现的东西都怪怪的，他自己说不清楚好处的东西就说这是经验，不这么实现就有问题（比如说日期型必须用字符串实现，争了半天干脆说我这样干了这么多年了都没问题，唉，挺崩溃的）。后来我们用了个中间层把他们的实现全部包装了起来，只留一个人跟他接口，算是基本解决了沟通的问题，但总经理对我们的包装很是不满，他更希望把长沙全面引进来，他希望长沙做底层设计，我们只做表层实现，我们只关注业务，听起来挺有道理，但基本上无法实施。毕竟东西是我们做的他也扭不过我，只好先这样了，但总经理居然说我是学院派，太侮辱了，我的意思是太侮辱学院派了。大概今年的4月份吧，第二版终于基本完成了，上层架构比第一版好了很多，但底层架构感觉还不如第一版，而且偶尔会出一些我们不可控的问题。不过不管怎么说终于要做完了，5月份开始演示，开始有了第一个客户，当时的反馈还是不错的。

对我来讲这时应该算是收获的时刻了，但忽然我的身份开始变得尴尬了，我最大的优势是懂点管理，懂点技术，懂点产品，但这时候因为产品开始为公司赚钱了，总经理开始亲自过问我团队的管理事务，技术有技术负责人，产品有产品负责人，我变得不重要了。原本工资就不太满意，跟总经理还有点理念冲突，而且公司这种慢节奏感觉有点不太适合自己，最大的问题是总经理缺乏上进心，导致我短期内根本就没有上升空间，想想真可怕，于是就开始接猎头的电话了，谈了两家公司，有一家还不错，待遇够好，公司够大，敏捷搞的风生水起的，挺合我胃口，缺点是离家有点远，带的是delphi团队，业务完全不熟悉，综合了一下，决定跟总经理谈判，意料之中的是大幅提高了待遇，意料之外的是年底一起发而不是按月发，平衡后我决定留下来。但人心散了就比较容易被诱惑，8月份受猎头蛊惑，去了一家大型互联网公司面试，经过层层筛选居然被录取了。再一次需要权衡。
原公司优点：
1、离家近，真得很近，走路20分钟，每天睡觉睡到自然醒，在北京难道这不是奢侈么。
2、熟悉的团队，熟悉的领导，熟悉的业务。
3、二线经理，带两个团队。
4、轻松，真得很轻松。
原公司缺点：
1、大公司的壳，小作坊的心。没什么公司文化，几乎没啥娱乐活动，太注重成本，弄个年会都不管饱。
2、领导的问题，喜欢以偏概全（有一次我有个兄弟公司门卡丢了，他给了个结论说开发人员都是喜欢丢三落四的），有点井底之蛙（老是觉得自己公司的技术在全行业数一数二了），不太懂管理（喜欢做技术支持，太关注与细节，很少会利用管理手段），不太懂如何激励员工（奖励应该及时，当你承诺奖金的时候，别人已经把这钱当成自己的了，而你迟迟不发，这就相当于欠钱不还，不但没起到激励作用还惹下诸多不满），有点高高在上的感觉（40来人的公司，公司总经理居然一次都没请大家吃过饭），丢了西瓜捡芝麻（给公司办事要自己掏钱坐公交车，5,6个人一年多好几十万的工资根本不放在眼里。），太没上进心（十几年就固守着两个产品，其他产品只让研究不让做），太小气（买个书都不让），目光短浅（公然告诉我不要让我的兄弟在公司看书学习，告诉我教他们技术要分开教不要只教一个人，你以为你是雄霸那）
3、上升空间有限，跟总公司几乎没什么接触，所以唯一能成长的地方就是把自己的团队做大，但由于老板没啥追求，你团队做大了也没啥活干。
新公司优点：
1、公司够大，够强，够分量，说出去有面子
2、足够的上升空间
3、nb的同事
4、产品可以帮助上亿的人
新公司缺点：
1、离家太远
2、离开原公司损失大笔年底奖金，期权也没了（现在看来这个期权有点扯了）
3、未知东西太多
4、一线经理

我们不该后悔我们干了什么，我们后悔的应该是我们没干什么，钱没了可以再挣，离家远可以克服，我是个贱骨头，我不喜欢轻松我喜欢挑战，平台不好二线一样没啥机会的，果断离职。
9月底新公司入职，比想象的还要好，
一、公司够大气，
1、试用期与正式工资一样。
2、入职就发近一万块的笔记本。
3、各种报销
4、每月团队建设费用，买书费用
二、团队氛围很好，大家互相信任，工作可以很快上手。
三、直接经理管理很到位，有很强的气场，看问题一针见血。
四、虽然很累，但很有成就感。
五、同事们真得很nb，无论技术还是软素质。

生活：

一年下来12次摇号，从1比10几到1比40几，我都没摇上，本来买车不算啥梦想，现在却变成了梦想，感谢国家，感谢党，想出了这么坑爹的招儿，tmd如果明年再让老子摇不上号，我就......，好吧那我就再等一年。明年老婆也跟着一起摇号了，机会翻了一番。

换了工作，离家远了，大部分是9点以后才能到家，陪孩子的时间少了，买房子是明年的首要目标。

我闺女，越来越懂事了，三岁不到嗑唠的是一套一套的。
某天，我问笑笑，你是不是美女啊
笑笑：我是美女。（回头拍拍妈妈，说），当然你也是美女，你是大美女，我是小美女。
我说：那我呢。
笑笑：爸爸是，爸爸是更大更大的...（思考状），懒哥
懒哥！！！崩溃啊!

我的小情人儿：

学习（2011年读书记录）:

彪悍的人，彪悍的人生，同为70后，居然有跟老罗有很多可以共鸣的地方，生长在民风彪悍的东北，打架是少年时代的文化，被无知的老师蹂躏，喝酒要把人喝死为乐.....，但相比老罗，我太守规矩，太缺乏冒险精神，做事不够坚持，这就注定了我庸庸碌碌的过了30多年的结果。

这是一本读起来让我汗毛只竖的书，绝对绝对是激动的。一个人想成功首先要清楚自己到底想要什么，梦想很重要，坚持梦想更重要。

常常束缚我们的就是那些我们已经拥有的但又舍不得失去的东西

每篇独立，很多可以发人深思，但是很多并没有给出具体的解决方案，常常深思完了就完了... ..

炒股的道理比具体技术更有意义，这书让我收获很大，成功的人生并不仅仅是取得财富，截断亏损，让利润奔跑

以讲故事的方式让你学到管理知识，很容易理解，比较适合新到一个公司的经理

老毛同志在驭人这方面几乎做到了极致，非常值得学习学习。这本书薄是薄点，但也算讲清楚了些道理。

角度不同得到的结果往往就不同，从有点神经的人的角度来认识世界，你会发现原来世界有另外的一种精彩... ...。很好看的一本书，能促进我们思考。生命可能有很多形式，女人从基因上来说优于男人，恶魔其实是为了帮助证明光明的存在，把人看成动物也不错，释放颅压真的能使大脑继续生长么？如果有一天你回到了古代，你并不一定能成为超人，多半情况下你会被认为是疯子。细菌进化的时间远远超过人类。如果有一天你看到我疯了，其实是你疯了。孤独很可怕，做先知好像很吸引人，但先知可能很痛苦。你相信有一天我们可以瞬间移动么，你相信有很多宇宙么，我有点相信了。原来不停的想一个问题，真的会让人神经分裂，可怕。

一个来小时读了40多页，并不是自己阅读速度提升了很多，完全是因为内容安排的过于松散，当然这也是有好处的，就是读起来比较有成就感，另外就是可以在空白部分写写画画。虽然并不赞成书中的一些观点，但启发还是有的，这种书本身就是争议，能启发我们思考就有意义继续读下去，所以我希望清明节假期可以把它读完。

1、追求完美是心灵缺陷，是一切心理问题的根源
2、不完美的人一味的追求完美，这就是很多人痛苦和焦虑的根源
人只能做人的事，而不能去做神的事
3、只有学会包容自己的缺点，才能求得内心的安宁
4、面对别人的错误，我们不要轻易地去指责，指责别人的错误容易掩饰自己的错误，这样，我们就不能从错误中获得提升。
真诚是竖起的一面镜子，让我们能从中看清自己，显示出本来面目。
5、有缺点并不可怕，可怕的是不承认。
6、完整的心灵应该是回归简单，专注于此时此刻，活在现当下。
7、每个人看见的都是他希望看见的
8、不要想得太多，敞开心灵去做，去感受，我们就会明白一切

一直向往有激情的工作，销售就是个永远需要激情的职业，可惜我似乎一直没机会，而且随着年龄的增长越来越没胆了，估计以后也没啥机会了，唉！等有一天我能财务自由了，一定要去体验下。这部书会让你觉得干销售真的很过瘾。

一口气读了三分之一，大部分理论没啥新意，案例倒还有些价值，卖其CD的目的比较明显

其实我没怎么读过李敖的书，只是听过一些他的访谈，以前不是太喜欢他，傲气太重，自视太高，看了这本回忆录对其印象有些改观。原来李敖是个战士，喜欢跟人斗，喜欢跟天斗，喜欢跟一切看不顺眼的事情斗，我的判断如果他在大陆一定不止是坐牢，他会被迫害死的，也许连名都来不及出。

本来不太喜欢蔡康永，因为对同性恋充满了误解，无法调和得误解，女的同下似乎可以接受，男的就觉得恶心。看这本书完全是因为推荐的人多，加上为了花掉当当送的卷。看完了觉得还行，不算太失望，每篇讲的道理很实用，可操作性很强。

页字数不多，所以显得读的很快。故事框架比较简单，但有点灰暗，其中穿插讲的故事还挺有趣。整体来说没我想象的有趣

重温一下经典，91年版，有些错字，想再买本新的，可惜当当没货。

我喜欢这种用讲故事的方式来解读知识。本书核心讲的是现场观察，改善，这说起来容易，做的话要付出极大的努力才成

读读能有些启发，有不少比较实用的东西，但知识不是很系统，比较适合初学者。

2012展望：

1、为了孩子而奋斗

2、为了房子而奋斗

3、为了票子而奋斗

4、为了车子而奋斗

5、为了事业而奋斗

我没有船票

本文链接

演讲集合

2011-10-31T02:52:00Z

本文链接

常见程序的算法(转)

2011-08-30T04:12:00Z

 主要收集一些常见程序的练习题目，您可以借这些题目培养
一些程序设计逻辑的感觉，对题目的分类只是个大概，方便索引而已，用 C  C#  Java    Python    Scala实现。



老掉牙

数、运算

关于赌博

集合問題

排序

搜寻

矩阵

堆栈、队列

其它

自产生程序（quine）

本文链接

提高 web 应用性能之 JavaScript 性能调优(转)

2011-08-22T13:52:00Z

简介

Web 开发中经常会遇到性能的问题，尤其是针对当今的 Web2.0 应用。JavaScript 是当今使用最为广泛的 Web 开发语言，Web 应用的性能问题很大一部分都是由程序员写的 JavaScript 脚本性能不佳所造成的，里面包括了 JavaScript 语言本身的性能问题，以及其与 DOM 交互时的性能问题。本文主要来探讨一下如何尽可能多的避免这类问题，从而最大限度的提高 Web 应用的性能。

回页首

JavaScript 性能调优

JavaScript 语言由于它的单线程和解释执行的两个特点，决定了它本身有很多地方有性能问题，所以可改进的地方有不少。

eval 的问题：

比较下述代码：

清单 1. eval 的问题

var reference = {}, props = “p1”; 
 eval(“reference.” + props + “=5”) 

 var reference = {}, props = “p1”; 
 reference[props] = 5

有“eval”的代码比没有“eval”的代码要慢上 100 倍以上。

主要原因是：JavaScript 代码在执行前会进行类似“预编译”的操作：首先会创建一个当前执行环境下的活动对象，并将那些用 var 申明的变量设置为活动对象的属性，但是此时这些变量的赋值都是 undefined，并将那些以 function 定义的函数也添加为活动对象的属性，而且它们的值正是函数的定义。但是，如果你使用了“eval”，则“eval”中的代码（实际上为字符串）无法预先识别其上下文，无法被提前解析和优化，即无法进行预编译的操作。所以，其性能也会大幅度降低。

Function 的用法：

比较下述代码：

清单 2. function 的用法

var func1 = new Function(“return arguments[0] + arguments[1]”);
 func1(10, 20); 

 var func2 = function(){ return arguments[0] + arguments[1] };
 func2(10, 20);

这里类似之前提到的“eval”方法，这里“func1”的效率会比“func2”的效率差很多，所以推荐使用第二种方式。

函数的作用域链（scope chain）：

JavaScript 代码解释执行，在进入函数内部时，它会预先分析当前的变量，并将这些变量归入不同的层级（level），一般情况下：

局部变量放入层级 1（浅），全局变量放入层级 2（深）。如果进入“with”或“try – catch”代码块，则会增加新的层级，即将“with”或“catch”里的变量放入最浅层（层 1），并将之前的层级依次加深。

参考如下代码：

清单 3. 函数作用域链

var myObj = … .. 
… .. 
 function process(){ 
 var images = document.getElementsByTagName("img"), 
 widget = document.getElementsByTagName("input"), 
 combination = []; 
 for(var i = 0; i < images.length; i++){ 
 combination.push(combine(images[i], widget[2*i])); 
 } 
 myObj.container.property1 = combination[0]; 
 myObj.container.property2 = combination[combination.length-1]; 
 }

这里我们可以看到，“images”，“widget”，“combination”属于局部变量，在层 1。“document”，“myObj”属于全局变量，在层 2。

变量所在的层越浅，访问（读取或修改）速度越快，层越深，访问速度越慢。所以这里对“images”，“widget”，“combination”的访问速度比“document”，“myObj”要快一些。所以推荐尽量使用局部变量，可见如下代码：

清单 4. 使用局部变量

var myObj = … .. 
… .. 
 function process(){ 
 var doc = document;
 var images = doc.getElementsByTagName("img"), 
 widget = doc.getElementsByTagName("input"), 
 combination = []; 
 for(var i = 0; i < images.length; i++){ 
 combination.push(combine(images[i], widget[2*i])); 
 } 
 myObj.container.property1 = combination[0]; 
 myObj.container.property2 = combination[combination.length-1]; 
 }

我们用局部变量“doc”取代全局变量“document”，这样可以改进性能，尤其是对于大量使用全局变量的函数里面。

再看如下代码：

清单 5. 慎用 with

var myObj = … .. 
… .. 
 function process(){ 
 var doc = document; 
    var images = doc.getElementsByTagName("img"), 
 widget = doc.getElementsByTagName("input"), 
 combination = []; 
 for(var i = 0; i < images.length; i++){ 
 combination.push(combine(images[i], widget[2*i])); 
 } 
 with (myObj.container) {
 property1 = combination[0];
 property2 = combination[combination.length-1];
				 }
 }

加上“with”关键字，我们让代码更加简洁清晰了，但是这样做性能会受影响。正如之前说的，当我们进入“with”代码块时，“combination”便从原来的层 1 变到了层 2，这样，效率会大打折扣。所以比较一下，还是使用原来的代码：

清单 6. 改进 with

var myObj = … .. 
… .. 
 function process(){ 
 var doc = document; 
 var images = doc.getElementsByTagName("img"), 
 widget = doc.getElementsByTagName("input"), 
 combination = []; 
 for(var i = 0; i < images.length; i++){ 
 combination.push(combine(images[i], widget[2*i])); 
 } 
 myObj.container.property1 = combination[0];
 myObj.container.property2 = combination[combination.length-1];
      }

但是这样并不是最好的方式，JavaScript 有个特点，对于 object 对象来说，其属性访问层级越深，效率越低，比如这里的“myObj”已经访问到了第 3 层，我们可以这样改进一下：

清单 7. 缩小对象访问层级

var myObj = … .. 
… .. 
 function process(){ 
 var doc = document; 
    var images = doc.getElementsByTagName("img"), 
 widget = doc.getElementsByTagName("input"), 
 combination = []; 
 for(var i = 0; i < images.length; i++){ 
 combination.push(combine(images[i], widget[2*i])); 
 } 
 var ctn = myObj.container;
 ctn.property1 = combination[0];
 ctn.property2 = combination[combination.length-1];
      }

我们用局部变量来代替“myObj”的第 2 层的“container”对象。如果有大量的这种对对象深层属性的访问，可以参照以上方式提高性能。

字符串（String）相关

字符串拼接

经常看到这样的代码：

清单 8. 字符串简单拼接

str += “str1” + “str2”

这是我们拼接字符串常用的方式，但是这种方式会有一些临时变量的创建和销毁，影响性能，所以推荐使用如下方式拼接：

清单 9. 字符串数组方式拼接

var str_array = []; 
 str_array.push(“str1”); 
 str_array.push(“str2”); 
 str = str_array.join(“”);

这里我们利用数组（array）的“join”方法实现字符串的拼接，尤其是程序的老版本的 Internet Explore（IE6）上运行时，会有非常明显的性能上的改进。

当然，最新的浏览器（如火狐 Firefox3+，IE8+ 等等）对字符串的拼接做了优化，我们也可以这样写：

清单 10. 字符串快速拼接

str +=“str1”
 str +=“str2”

新的浏览器对“+=”做了优化，性能略快于数组的“join”方法。在不久的将来更新版本浏览器可能对“+”也会做优化，所以那时我们可以直接写：str += “str1” + “str2”。

隐式类型转换

参考如下代码：

清单 11. 隐式类型转换

var str = “12345678”, arr = []; 
 for(var i = 0; i <= s.length; i++){ 
 arr.push( str.charAt(i)); 
 }

这里我们在每个循环时都会调用字符串的“charAt”方法，但是由于我们是将常量“12345678”赋值给“str”，所以“str”这里事实上并不是一个字符串对象，当它每次调用“charAt”函数时，都会临时构造值为“12345678”的字符串对象，然后调用“charAt”方法，最后再释放这个字符串临时对象。我们可以做一些改进：

清单 12. 避免隐式类型转换

var str = new Stirng(“12345678”), arr = []; 
 for(var i = 0; i <= s.length; i++){ 
 arr.push( str.charAt(i)); 
 }

这样一来，变量“str”作为一个字符串对象，就不会有这种隐式类型转换的过程了，这样一来，效率会显著提高。

字符串匹配

JavaScript 有 RegExp 对象，支持对字符串的正则表达式匹配。是一个很好的工具，但是它的性能并不是非常理想。相反，字符串对象（String）本身的一些基本方法的效率是非常高的，比如“substring”，“indexOf”，“charAt”等等，在我们需要用正则表达式匹配字符串时，可以考虑一下：

是否能够通过字符串对象本身支持的基本方法解决问题。
是否可以通过“substring”来缩小需要用正则表达式的范围。

这些方式都能够有效的提高程序的效率。

关于正则表达式对象，还有一点需要注意，参考如下代码：

清单 13. 正则表达式

for(var i = 0; i <= str_array.length; i++){ 
 if(str_array[i].match(/^s*extra\s/)){ 
……………………
 } 
 }

这里，我们往“match”方法传入“/^s*extra\s/”是会影响效率的，它会构建临时值为“/^s*extra\s/”的正则表达式对象，执行“match”方法，然后销毁临时的正则表达式对象。我们可以这样做：

清单 14. 利用变量

var sExpr = /^s*extra\s/;
 for(var i = 0; i <= str_array.length; i++){ 
 if(str_array[i].match(sExpr)){ 
……………………
 } 
 }

这样就不会有临时对象了。

setTimeout 和 setInterval

“setTimeout”和“setInterval”这两个函数可以接受字符串变量，但是会带来和之前谈到的“eval”类似的性能问题，所以建议还是直接传入函数对象本身。

利用提前退出

参考如下两段代码：

清单 15. 利用提前退出

// 代码 1
 var name = … .; 
 var source = …… ; 
 if(source.match(/ …… /)){ 
……………………………
 } 


 // 代码 2
 var name = … .; 
 var source = …… ; 
 if(name.indexOf( … ) &&source.match(/ …… /)){ 
……………………………
 }

代码 2 多了一个对“name.indexOf( … )”的判断，这使得程序每次走到这一段时会先执行“indexOf”的判断，再执行后面的“match”，在“indexOf”比“match”效率高很多的前提下，这样做会减少“match”的执行次数，从而一定程度的提高效率。

回页首

DOM 操作性能调优

JavaScript 的开发离不开 DOM 的操作，所以对 DOM 操作的性能调优在 Web 开发中也是非常重要的。

Repaint 和 Reflow

Repaint 也叫 Redraw，它指的是一种不会影响当前 DOM 的结构和布局的一种重绘动作。如下动作会产生 Repaint 动作：

不可见到可见（visibility 样式属性）
颜色或图片变化（background, border-color, color 样式属性）
不改变页面元素大小，形状和位置，但改变其外观的变化

Reflow 比起 Repaint 来讲就是一种更加显著的变化了。它主要发生在 DOM 树被操作的时候，任何改变 DOM 的结构和布局都会产生 Reflow。但一个元素的 Reflow 操作发生时，它的所有父元素和子元素都会放生 Reflow，最后 Reflow 必然会导致 Repaint 的产生。举例说明，如下动作会产生 Repaint 动作：

浏览器窗口的变化
DOM 节点的添加删除操作
一些改变页面元素大小，形状和位置的操作的触发

减少 Reflow

通过 Reflow 和 Repaint 的介绍可知，每次 Reflow 比其 Repaint 会带来更多的资源消耗，我们应该尽量减少 Reflow 的发生，或者将其转化为只会触发 Repaint 操作的代码。

参考如下代码：

清单 16. reflow 介绍

var pDiv = document.createElement(“div”); 
 document.body.appendChild(pDiv);----- reflow
 var cDiv1 = document.createElement(“div”); 
 var cDiv2 = document.createElement(“div”); 
 pDiv.appendChild(cDiv1);----- reflow
 pDiv.appendChild(cDiv2);----- reflow

这是我们经常接触的代码了，但是这段代码会产生 3 次 reflow。再看如下代码：

清单 17. 减少 reflow

var pDiv = document.createElement(“div”); 
 var cDiv1 = document.createElement(“div”); 
 var cDiv2 = document.createElement(“div”); 
 pDiv.appendChild(cDiv1); 
 pDiv.appendChild(cDiv2); 
 document.body.appendChild(pDiv);----- reflow

这里便只有一次 reflow，所以我们推荐这种 DOM 节点操作的方式。

关于上述较少 Reflow 操作的解决方案，还有一种可以参考的模式：

清单 18. 利用 display 减少 reflow

var pDiv = document.getElementById(“parent”); 
 pDiv.style.display = “none”----- reflow

 pDiv.appendChild(cDiv1); 
 pDiv.appendChild(cDiv2); 
 pDiv.appendChild(cDiv3); 
 pDiv.appendChild(cDiv4); 
 pDiv.appendChild(cDiv5); 
 pDiv.style.width = “100px”; 
 pDiv.style.height = “100px”; 

 pDiv.style.display = “block”----- reflow

先隐藏 pDiv，再显示，这样，隐藏和显示之间的操作便不会产生任何的 Reflow，提高了效率。

特殊测量属性和方法

DOM 元素里面有一些特殊的测量属性的访问和方法的调用，也会触发 Reflow，比较典型的就是“offsetWidth”属性和“getComputedStyle”方法。

图 1. 特殊测量属性和方法

这些测量属性和方法大致有这些：

offsetLeft
offsetTop
offsetHeight
offsetWidth
scrollTop/Left/Width/Height
clientTop/Left/Width/Height
getComputedStyle()
currentStyle(in IE))

这些属性和方法的访问和调用，都会触发 Reflow 的产生，我们应该尽量减少对这些属性和方法的访问和调用，参考如下代码：

清单 19. 特殊测量属性

var pe = document.getElementById(“pos_element”); 
 var result = document.getElementById(“result_element”); 
 var pOffsetWidth = pe.offsetWidth;
 result.children[0].style.width  = pOffsetWidth; 
 result.children[1].style.width  = pOffsetWidth; 
 result.children[2].style.width  = pOffsetWidth; 
…………其他修改…………

这里我们可以用临时变量将“offsetWidth”的值缓存起来，这样就不用每次访问“offsetWidth”属性。这种方式在循环里面非常适用，可以极大地提高性能。

样式相关

我们肯定经常见到如下的代码：

清单 20. 样式相关

var sElement = document.getElementById(“pos_element”); 
 sElement.style.border = ‘ 1px solid red ’
 sElement.style.backgroundColor = ‘ silver ’
 sElement.style.padding = ‘ 2px 3px ’
 sElement.style.marginLeft = ‘ 5px ’

但是可以看到，这里的每一个样式的改变，都会产生 Reflow。需要减少这种情况的发生，我们可以这样做：

解决方案 1：

清单 21. className 解决方案

.class1 { 
 border: ‘ 1px solid red ’
 background-color: ‘ silver ’
 padding: ‘ 2px 3px ’
 margin-left: ‘ 5px ’
 } 
 document.getElementById(“pos_element”).className = ‘class1’ ;

用 class 替代 style，可以将原有的所有 Reflow 或 Repaint 的次数都缩减到一个。

解决方案 2：

清单 22. cssText 解决方案

var sElement = document.getElementById(“pos_element”); 
 var newStyle = ‘ border: 1px solid red; ’ + ‘ background-color: silver; ’ + 
                                 ‘ padding: 2px 3px; ’ + “margin-left: 5px;”
 sElement.style.cssText += newStyle;

一次性设置所有样式，也是减少 Reflow 提高性能的方法。

XPath

一个页面上往往包含 1000 多页面元素，在定位具体元素的时候，往往需要一定的时间。如果用 id 或 name 定位可能效率不会太慢，如果用元素的一些其他属性（比如 className 等等）定位，可能效率有不理想了。有的可能只能通过遍历所有元素（getElementsByTagName）然后过滤才能找到相应元素，这就更加低效了，这里我们推荐使用 XPath 查找元素，这是很多浏览器本身支持的功能。

清单 23. XPath 解决方案

if(document.evaluate){ 
 var tblHeaders = document.evaluate(“//body/div/table//th”);
 var result = tblHeaders.iterateNext(); 
 while(result) { 
 result.style.border = “1px dotted blue”; 
 result ………………
 result = xpathResult.iterateNext(); 
 } 
 } else{ //getElementsByTagName() ……
 // 处理浏览器不支持 XPath 的情况
………………………………
 }

浏览器 XPath 的搜索引擎会优化搜索效率，大大缩短结果返回时间。

HTMLCollection 对象

这是一类特殊的对象，它们有点像数组，但不完全是数组。下述方法的返回值一般都是 HTMLCollection 对象：

document.images, document.forms
getElementsByTagName()
getElementsByClassName()

这些 HTMLCollection 对象并不是一个固定的值，而是一个动态的结果。它们是一些比较特殊的查询的返回值，在如下情况下，它们会重新执行之前的查询而得到新的返回值（查询结果），虽然多数情况下会和前一次或几次的返回值都一样：

Length 属性
具体的某个成员

所以，HTMLCollection 对象对这些属性和成员的访问，比起数组来要慢很多。当然也有例外，Opera 和 Safari 对这种情况就处理的很好，不会有太大性能问题。

参考如下代码：

清单 24. HTMLConnection 对象

var items = [“test1”, “test2”, “test3”, ……………… ];
 for(var i = 0; i < items.length; i++){ 
………………………………
 } 

 var items = document.getElementsByTagName(“div”);
 for(var i = 0; i < items.length; i++){ 
…………………………………… . 
 }

上述两端代码，下面的效率比起上面一段要慢很多，因为每一个循环都会有“items.length”的触发，也就会导致“document.getElementsByTagName(..)”方法的再次调用，这便是效率便会大幅度下降的原因。我们可以这样解决：

清单 25. HTMLConnection 对象解决方案

var items = document.getElementsByTagName(“div”); 
 var len = items.length
 for(var i = 0; i < len; i++){ 
…………………………………… . 
 }

这样一来，效率基本与普通数组一样。

动态创建 script 标签

加载并执行一段 JavaScript 脚本是需要一定时间的，在我们的程序中，有时候有些 JavaScript 脚本被加载后基本没有被使用过（比如：脚本里的函数从来没有被调用等等）。加载这些脚本只会占用 CPU 时间和增加内存消耗，降低 Web 应用的性能。所以推荐动态的加载 JavaScript 脚本文件，尤其是那些内容较多，消耗资源较大的脚本文件。

清单 26. 创建 script 标签

if(needXHR){ 
 document.write(“<script type= ’ test\/JavaScript ’ src= 'dojo_xhr.js' >”); 
 } 
 if(dojo.isIE){ 
 document.write(“<script type= ’ test\/JavaScript ’ src= 'vml.js' >”); 
 }

回页首

结束语

这篇文章介绍了 Web 开发中关于性能方面需要注意的一些小细节，从 JavaScript 本身着手，介绍了 JavaScript 中需要避免的一些函数的使用和编程规则，比如 eval 的弊端，function scope chain 以及 String 的用法等等，也分享了一些比较推荐的做法，并扩展到 JavaScript 对 DOM 操作的性能调优，比如利用 Repaint 和 Reflow 的机制，如何使用特殊测量属性，样式相关的性能调优以及 HTMLCollection 对象的原理和使用小技巧。这些小细节我们可以在开发过程中尽量注意一下，以尽可能多的提高我们 Web 应用的性能。

参考资料

学习

JavaScript wiki：一个共享 JavaScript 开发知识的网站，提供很多 JavaScript 的实例和解释。
JavsScript 资源网站：提供了很多 JavaScript 的开发相关资源，许多不错的文章以及一些经典实例。
“JavaScript 开发工具包”（developerWorks，2010 年 3 月）：JavaScript 开发工具包
“编写更加通用的 JavaScript”（developerWorks，2011 年 2 月）：作者以网页中常见的下拉列表的实现为例，介绍了一种让 JavaScript 变得更加通用的方法：编写 JavaScript 组件。
“使用 JSLint 保证 JavaScript 代码质量”（developerWorks，2011 年 5 月）：随着富 Web 前端应用的出现，开发人员不得不重新审视并重视 JavaScript 语言的能力和使用，抛弃过去那种只靠“复制 / 粘贴”常用脚本完成简单前端任务的模式。JavaScript 语言本身是一种弱类型脚本语言，具有相对于 C++ 或 Java 语言更为松散的限制，一切以函数为中心的函数式编程思想也为开发人员提供了更加灵活的语法实现。然而，这种灵活性在带来高效的同时，也成为初学或者经验不足的 JavaScript 开发人员的噩梦。形式各异的代码风格、隐含错误的代码行为，严重影响了整体代码的可读性和稳定性，成为 Web 项目中最为常见问题之一。
“JavaScript 工作线程实现方式”（developerWorks，2011 年 5 月）：随着 Ajax 应用的流行，浏览器所承担的职责也越来越多。一些原来由服务器端执行的计算操作也被迁移到浏览器端来执行。通过 JavaScript 工作线程，可以在不影响页面本身运行的情况下，在后台运行耗时的任务。本文详细了 JavaScript 工作线程的三种实现方式：使用 setTimeout()、Google Gears 和 Web Worker。
developerWorks Web development 专区：通过专门关于 Web 技术的文章和教程，扩展您在网站开发方面的技能。
developerWorks Ajax 资源中心：这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。
developerWorks Web 2.0 资源中心，这是有关 Web 2.0 相关信息的一站式中心，包括大量 Web 2.0 技术文章、教程、下载和相关技术资源。您还可以通过 Web 2.0 新手入门栏目，迅速了解 Web 2.0 的相关概念。
查看 HTML5 专题，了解更多和 HTML5 相关的知识和动向。

讨论

加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。

关于作者

周翔是 IBM 中国上海 UT / Dojo 部门的一名软件工程师，之前在 IBM Lotus Mashups 部门和 UT / Click Track 部门工作，现在是 FIT / Dojo 部门的一员，主要从事 Dojo 控件库的研发工作，包括 Dojo 的claro主题的开发，dojox的可视化组件的开发。

本文链接

最隐晦的程序设计指引(转)

2011-07-27T07:13:00Z

转自：http://blog.csdn.net/nightmare/article/details/6629724

一、百家争鸣

    俗话说，程序员半年不学新东西，就变奥特曼（out man，过时之人）了。IT行业可以说是变化最快的行业，每年都有大量的新概念、新术语、新技术被创造出来，在多数人还在一头雾水时，“更好的”替代品又被创造出来。别的不说了，单说设计方法。

    想当年静态类型系统是王道，谁要是搞点运行时动态绑定、用点VB什么的，经常会被鄙视。而今动态类型语言大热，常有人高呼Python万岁，JavaScript身价百倍，C#也加入了动态类型支持。当年面向对象与过程式编程争吵不休，如今大家都在盯着函数式模式，C#和C++0x都加入了函数式语言特性。当我们学面向对象时，Gang of Four（据证实，这个书名确实是四人帮的英文翻译，故意调侃四位作者为坏家伙之意。）的设计模式流行起来了，当我们学Gang of Four时，其中一些模式被批为重复、过时、不宜的，一批表达新观点的书籍出版了（如Agile Modeling with Patterns)。当我们开始尝试敏捷方法时，模型驱动开发（Model Driven Development）遍布书刊封面和新闻头条，而当我们学用Rose、Visio画UML时，测试驱动开发（Test Driven Development）被提出来了。

    当然，历史的发展也常常会出人意料。人们曾经认为，动态的web必定需要Flash这样的新解决方案，而今HTML5+JavaScript不但可以取代Flash，还可以做3D应用。人们曾经认为，WebService需要一套新的行业标准，于是指定了SOAP等一系列协议，并历时数年时间开发了大量WebService平台和相关工具，而如今大家更喜欢基于基本的HTTP协议的REST方式和JavaScript本身的JSON数据协议，而且要简单高效得多。

    但究竟什么才是好的设计呢？如果静态类型系统才算好，那么大量优秀的动态类型语言程序算什么？如果面向对象才算好，那么大量优秀个过程式、函数式程序算什么？当年不知道匈牙利表示法的程序员就不是好coder，如今微软的态度是，别再提了。曾经OLE的程序员可以拿到高一倍的薪水，如今谁还会提OLE。Java阵营前些年喜欢嘲笑微软不懂Pattern，以致微软这些年有事没事地把Pattern挂在嘴边，但是如今被批评得一无是处的COM（1993）却是在Java诞生（1995）前就完美地实现了大多数的Java常用Pattern。既然COM被评价得这么烂，业界却搞出了一个和DCOM/COM+非常类似的CORBA。

    学过的人会说，低耦合、高内聚，如是等等。没错，这是一般原则，但也有情况下必须违背这些原则才是好的设计，典型的如性能优先的情况。再比如，一般原则有说状态查询和修改要分开，不要写在一个函数里，但是远程调用时却经常要合并，因为设计成网络往返通信两次不如一次解决。再比如，Java上有个著名的Spring Framework，可以利用反射功能，把程序中的动态选择性初始化问题转变成配置文件的设置，从而避免if语句（有个反if语句运动），Java程序员为此自豪。而同样的方法对主要用于桌面开发的.NET并不太适用，因为没有专业部署人员为桌面程序用户修改配置文件、填写正确的类名，而且桌面程序通常要做代码混淆（Obfuscation），会导致基于类名的反射失效。

    代码质量管理也是近些年的新热点，除了FxCop等传统检查分析工具外，计算复杂度的Cyclomatic Complexity方法和Test Coverage等量化分析得到了非常多的关注。这些工具对源码宏观分析提供了有效的手段。但分数高就代表代码质量一定高吗？尤其是对不懂技术的管理层，这些统计结果很容易成为财务报表一样的存在。

二、事有本末

    退一步想，当我们学自己的母语时，我们是先会说话还是先学语法呢？当我们学外语时，是先学说话还是先学语法呢？当我们读一首诗时，我们是先感觉到好还是先用各种规则去衡量它呢？当被要求说明哪里好时，是直接就说得出来还是要去借用各种规则来描述它的好？你是否隐约感觉到，有某种先于规则、方法存在的东西，但又难以言表，而必须用各种规则来间接地去描述它？

    有个春秋时期的故事，说齐桓公在堂上读书，工匠轮扁在堂下干活。轮扁问桓公说，敢问公读的什么书？桓公答，圣人之言。轮扁问，圣人还在吗？桓公答，已经死了。轮扁于是说，那么您读的就是古人的糟粕了。桓公大怒，说，寡人读书，轮得到你个车轮匠议论吗！说得出道理则罢，说不出就去死！轮扁答，用臣砍造车轮来说，慢了会甘滑而不牢固，快了会苦涩而难以敲入。唯有不快不慢，得于手而应于心。其中门道我也表达不出来，也无法传授给我儿子，所以如今七十岁了还在造轮子。圣人和他不可传的东西都已经消失了，那么您所读的，不就是剩下来的糟粕了吗？

    回到程序设计上，我们不断创造各种各样的方法、原则，到底是为了什么呢？当然是为了写出好程序。但到底什么是好？说不清。但可以肯定的是，都是为了好的性价比。性价比可以分成收益和代价。收益可以分成功能、性能、易用性、稳定性、安全性等等。代价可以分为开发时间成本、人力成本、可维护性等等。可维护性可以分为可读性、可扩展性、可复用性，如是等等，以指数级细化下去。然后有各种各样的方法，来解决各种具体的问题。如果开发时间不确定性大而却有严格的deadline，那么敏捷方法可以保证总是有个可用的发布版本，即使可能牺牲一些功能。如果代码只是短暂使用，或是被替代、重写的概率很大，那么可以完全不在乎可维护性，直接写抛弃型代码。如果代码面临高度频繁更改的可能性，那么用脚本语言吧。如果有个较大的开发团队，模型设计将有效提高交流沟通的效率。如果一个程序员在一个面向对象的系统中加入了一个处理算法，他的思路和实现都是过程式的，那么完全没必要把它改成面向对象的，因为那样只会增加额外的复杂度和理解困难，而且很难说日后算法修改后这个对象设计还能适用。如是等等。

    但是，因为这个精髓的东西难以说明，我们要么得在不断实践中慢慢领悟，要么学习别人总结出的方法来接近它。但是，人们经常纠结于方法本身。

    心都子讲过一个故事，说兄弟三人在齐鲁学儒术，学成回家，父亲问他们，仁义之道是什么？老大答，仁义使我爱身而后名。老二答，仁义使我杀身以成名。老三答，仁义使我身名并全。三个回答相反，却又同出于儒，谁是谁非？你纠结了吗？

    有句经常被引用的话：Any software problem can be solved by adding another layer of indirection. ——Steven M. Bellovin 其实原文后面还有半句：But that usually creates another problem.

    有个Java程序员写过一篇很有趣的blog。大意说，有个人要钉个钉子挂画框，于是去工具店买个锤子。店主说，No，我们已经不卖锤子了。锤子有很多种，大锤、拔钉锤、圆头锤等等，如果你买了一个，之后又发现你还需要另一个怎么办？多数人只想要一把锤子，所以我们推出了万能锤，可以当各种锤子使用。买者想想也是，那就买一把万能锤吧。店主说，No，万能锤已经被淘汰了。你想，万能锤虽然可以当各种锤子用，但它做什么活都没有专门用途的锤子好使。所以，我们开始卖锤子工厂，这样你可以随时制造最合适的锤子。买者说，但我并不想买个工厂……店主说，没错，所以它已经被淘汰了。我们研究发现，不是所有的用户都需要生产所有类型的锤子，所以我们开始卖锤子工厂设计图，这样用户可以根据自己的需要定制工厂。买者说，我猜这个也淘汰了吧？店主说，没错，我们研究发现，用户并不想自己建造一个工厂。于是我们推出了建造锤子工厂的工厂，来帮助用户建造锤子工厂……

三、殊途同归

    我们可以回想，在我们知道设计模式之前，难道我们就没有在用这些方法吗？之所以叫Pattern，就是因为它至少已经被重复运用三次以上，所以我们把它单独拿出来，赋予一个名字。所谓“新Pattern”就是一个悖论。Pattern的最大作用不是教人怎么做，因为面临同样问题时，大家多少会想出类似的解决方案；Pattern最大的作用，在于提供了一种共识、一套共通的术语，使开发人员间可以方便的交流一些复杂的系统概念。当然，有的人学了设计模式后会有眼前一亮的感觉，这是因为切身体验诸多问题的苦恼，突然得到解决之道，于是豁然开朗。而对有的人，没有体验过痛苦，只是听说Pattern是好的，于是就开始在代码里罗列Pattern。

    同理的，云计算是什么全新的东西吗？WebService是什么全新的东西吗？之前就没有类似的问题需要解决，就没有类似的解决方案吗？如果让你穿越到它们诞生前，从头解决这些分布式计算的问题，你会不会做出一个类似的解决方案？那么，又是什么使你能够发明这些新东西呢？是不是基本技能在特定问题下的一次应用呢？

    不管用哪种途径，用这套方法也好，那套方法也好，只靠自己琢磨也好，走对的话，都是通往同一条大道。不要把自己圈在一个小圈子里，圈子越小，越容易偏执。站得越高，看得越远，眼前的景色越壮丽，所谓的是非对错，不过是远处的一点而已。

    但是但是，现实中，不是所有的问题都是能由开发人员解决的，也不是所有的人都想要解决问题。流程、方法、思想、工具等，不管看起来再好，在不想解决问题的人面前，连个屁都不算。一个项目决定时的天时地利人和，已经八九成决定了项目的结局。当然，怨天尤人也没用，上天总是会给人几次机会的，机会到来时能不能抓得住，就看个人修为了。

本文链接

[SQL基础]统计信息解释

2011-06-02T08:51:00Z

在平时优化SQL的时候，最长用的就是：SET STATISTICS ON，它可以用来查看我们写的查询语句到底性能如何，不过，究竟这个性能的指标是怎么样的呢？首先需要明白的，就是各项数据的意义。

以下解释来自MSDN（点击查看）

输出项	含义
Table	表的名称。
scan count	执行的扫描次数。
logical reads	从数据缓存读取的页数。
physical reads	从磁盘读取的页数。
read-ahead reads	为进行查询而放入缓存的页数。
lob logical reads	从数据缓存读取的 text、ntext、image 或大值类型 (varchar(max)、nvarchar(max)、varbinary(max)) 页的数目。
lob physical reads	从磁盘读取的 text、ntext、image 或大值类型页的数目。
lob read-ahead reads	为进行查询而放入缓存的 text、ntext、image 或大值类型页的数目。

以下解释来自园子里面的一位大师，嘿嘿（点击查看原文）

扫描计数(Scan Count)：在查询中涉及到的表被访问的次数。在我们的例子中，其中的表只被访问了1次，由于查询中不包括连接命令，这一信息并不是十分有用，但如果查询中包含有一个或多个连接，则这一信息是十分有用的。（一个循环外部的表的Scan Count值为1，但对于一个循环内的表而言，其值为循环的次数。可以想象得到，对于一个循环内的表而言，其Scan Count值越小，它所使用的资源越少，查询的性能也就越高。因此在调节一个带连接的查询的性能时，需要关注Scan Count的值，在进行调节时，注意观察它是增加还是减少了。）

逻辑读取(Logical Reads)：这是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的数据。我们知道，SQL Server在可以对任何数据进行操作前，必须首先把数据读取到其数据缓冲区中。此外，我们也知道SQL Server何时会从数据缓冲区中读取数据，并把数据读取到大小为8K字节的页中。那么Logical Reads的意义是什么呢？Logical Reads是指SQL Server为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时，SQL Server不会读取比实际需求多或少的数据，因此，当在相同的数据集上执行同一个查询，得到的Logical Reads的数字总是相同的。（SQL Server执行查询时的Logical Reads值每一次这个数值是不会变化的。因此，在进行查询性能的调节时，这是一个可以用来衡量你的调节措施是否成功的一个很好的标准。如果 Logical Reads值下降，就表明查询使用的服务器资源减少，查询的性能有所提高。如果Logical Reads值增加，则表示调节措施降低了查询的性能。在其他条件不变的情况下，一个查询使用的逻辑读越少，其效率就越高，查询的速度就越快。）

物理读取(Physical Reads)：物理读，在执行真正的查询操作前，SQL Server必须从磁盘上向数据缓冲区中读取它所需要的数据。在SQL Server开始执行查询前，它要作的第一件事就是检查它所需要的数据是否在数据缓冲区中，如果在，就从中读取，如果不在，SQL Server必须首先将它需要的数据从磁盘上读到数据缓冲区中。我们可以想象得到，SQL Server在执行物理读时比执行逻辑读需要更多的服务器资源。因此，在理想情况下，我们应当尽量避免物理读操作。下面的这一部分听起来让人容易感到糊涂了。在对查询的性能进行调节时，可以忽略物理读而只专注于逻辑读。你一定会纳闷儿，刚才不是还说物理读比逻辑读需要更多的服务器资源吗？情况确实是这样， SQL Server在执行查询时所需要的物理读次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作，但它涉及到整个服务器性能的调节，而不仅仅是查询性能的调节。在进行查询性能调节时，我们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所需要的数据是在数据缓冲区中还是在磁盘上，唯一我们能够控制的数据是得到查询结果所需要执行的逻辑读的次数。因此，在查询性能的调节中，我们可以心安理得地不理会SET STATISTICS IO命令提供的Physical Read的值。（减少物理读次数、加快SQL Server运行速度的一种方式是确保服务器的物理内存足够多。）

预计(Read-Ahead Reads)：与Physical Reads一样，这个值在查询性能调节中也没有什么用。Read-Ahead Reads表示SQL Server在执行预读机制时读取的物理页。为了优化其性能，SQL Server在认为它需要数据之前预先读取一部分数据，根据SQL Server对数据需求预测的准确程度，预读的数据页可能有用，也可能没用。

本文链接

幽默的经济学+组织领导学

2011-05-18T14:20:00Z

A. 一农户在杀鸡前的晚上喂鸡，不经意地说：快吃吧，这是你最后一顿！第二日，见鸡已躺倒并留遗书：爷已吃老鼠药，你们别想吃爷了，爷他妈也不是好惹的。
　　当对手知道了你的决定之后，就能做出对自己最有利的决定。——纳什均衡理论
　　所以保密、信息安全很重要

　　B. 鱼说：我时时刻刻睁开眼睛，就是为了能让你永远在我眼中！水说：我时时刻刻流淌不息，就是为了能永远把你拥抱！！　　锅说：都他妈快熟了，还这么贫！！！
　　约束条件变了，原来的收益，一下子都变为成本。生命如果架在锅上，成本自然也就很高了。

　　C. 男人为什么喜新厌旧？
　　经济学上有个著名的戈森法则可以解释——同一享乐不断重复，其带来的满足感会不断递减；同一享乐不断重复，第一次和第二次所获得的满足感最大。　

        D. 男人和女人,谁更容易在感情上受伤？
　　所谓受伤，应该就是投入太多，收获太少，也就是产生了亏损。一个企业亏损，最主要的原因应该是没有竞争力，如果绝对优势不足的话，发掘一下自己的优势。比如说，中国企业往欧美国家卖纺织品，自然是手到擒来，如果非要往欧美卖汽车，肯定要受伤了。　　如果一个人能够不计亏损的话，应该就不会受伤了。当然，要达到这样的境界实在困难，只有我们的某些国有企业可以做到。

        E. 为什么不能一夫多妻或者一妻多夫？
　　一夫多妻或者一妻多夫会打破市场的均衡，有些又帅又有钱的王老五可能会形成市场垄断，从而像电信、铁路一样，成天被人骂娘。轻则引起内分泌失调，重则引起和谐社会失调。　　一夫一妻制已经形成了帕累托最优。

　　F. 飞机上，乌鸦对乘务员说：给爷来杯水！　　猪听后也学道：给爷也来杯水！　　乘务员把猪和乌鸦扔出机舱，乌鸦笑着对猪说：傻了吧？爷会飞！
外界因素是一种约束条件，自身能力也是一种约束条件,往往更重要。所以，别人能成功的事，未必自己就能成功。

　　G. 黑猩猩不小心踩了长臂猿拉的大便，长臂猿温柔细心地帮她擦洗干净后他们相爱了，别人问起他们是怎么走到一起的，黑猩猩感慨地说：猿粪！都是猿粪那！
　　你当下的选择是被你的前一个选择决定的，如果你要改变路径，成本将会高到你不愿意改变。
　　
一、有关素养~~~
　　

蓝斯登原则
　　在你往上爬的时候，一定要保持梯子的整洁，否则你下来时可能会滑倒。
　　提出者：美国管理学家蓝斯登
　　点评：进退有度，才不至进退维谷；宠辱皆忘，方可以宠辱不惊。
　　

卢维斯定理
　　谦虚不是把自己想得很糟，而是完全不想自己。
　　提出者：美国心理学家h·卢维斯
　　点评：如果把自己想得太好，就很容易将别人想得很糟。

托利得定理
　　测验一个人的智力是否属于上乘，只看脑子里能否同时容纳两种相反的思想，而无碍于其处世行事。
　　提出者：法国社会心理学家h·m·托利得
　　点评：思可相反，得须相成。

二、统御

刺猬理论
　　刺猬在天冷时彼此靠拢取暖，但保持一定距离，以免互相刺伤。
　　点评：保持亲密的重要方法，乃是保持适当的距离。

鲦鱼效应
　　鲦鱼因个体弱小而常常群居，并以强健者为自然首领。将一只稍强的鲦鱼脑后控制行为的部分割除后，此鱼便失去自制力，行动也发生紊乱，但其他鲦鱼却仍像从前一样盲目追随。
　　提出者：德国动物学家霍斯特
　　点评：1、下属的悲剧总是领导一手造成的。2、下属觉得最没劲的事，是他们跟着一位最差劲的领导。
　　

雷鲍夫法则
　　在你着手建立合作和信任时要牢记我们语言中：
　　1、最重要的八个字是：我承认我犯过错误
　　2、最重要的七个字是：你干了一件好事
　　3、最重要的六个字是：你的看法如何
　　4、最重要的五个字是：咱们一起干
　　5、最重要的三个字是：谢谢您
　　6、最重要的两个字是：咱们
　　提出者：美国管理学家雷鲍夫
　　点评：1、最重要的四个字是：不妨试试；2、最重要的一个字是：您
　　

洛伯定理
　　对于一个经理人来说，最要紧的不是你在场时的情况，而是你不在场时发生了什么。
　　提出者：美国管理学家r·洛伯
　　点评：如果只想让下属听你的，那么当你不在身边时他们就不知道应该听谁的了。

三、沟通
　　斯坦纳定理
　　在哪里说得愈少，在哪里听到的就愈多。
　　提出者：美国心理学家s·t·斯坦纳
　　点评：只有很好听取别人的，才能更好说出自己的。
　　

费斯诺定理
　　人有两只耳朵却只有一张嘴巴，这意味着人应该多听少讲。
　　提出者：英国联合航空公司总裁兼总经理l·费斯诺
　　点评：说得过多了，说的就会成为做的障碍。
　　

牢骚效应
　　凡是公司中有对工作发牢骚的人，那家公司或老板一定比没有这种人或有这种人而把牢骚埋在肚子里的公司要成功得多。
　　提出者：美国密歇根大学社会研究院
　　点评：1、牢骚是改变不合理现状的催化剂。2、牢骚虽不总是正确的，但认真对待牢骚却总是正确的。
　　

避雷针效应
　　在高大建筑物顶端安装一个金属棒，用金属线与埋在地下的一块金属板连接起来，利用金属棒的尖端放电，使云层所带的电和地上的电逐渐中和，从而保护建筑物等避免雷击。
　　点评：善疏则通，能导必安
　　

四、协调
　　

氨基酸组合效应
　　组**体蛋白的八种氨基酸，只要有一种含量不足，其他七种就无法合成蛋白质。
　　点评：当缺一不可时，" 一" 就是一切。
　　

米格-25效应
　　前苏联研制的米格-25喷气式战斗机的许多零部件与美国的相比都落后，但因设计者考虑了整体性能，故能在升降、速度、应急反应等方面成为当时世界一流。
　　点评：所谓最佳整体，乃是个体的最佳组合。
　　

磨合效应
　　新组装的机器，通过一定时期的使用，把磨擦面上的加工痕迹磨光而变得更加密合。
　　点评：要想达到完整的契合，须双方都作出必要的割舍。
　　

五、指导
　　

波特定理
　　当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。
　　提出者：英国行为科学家l·w·波特
　　点评：总盯着下属的失误，是一个领导者的最大失误。
　　

蓝斯登定律
　　跟一位朋友一起工作，远较在" 父亲" 之下工作有趣得多。
　　提出者：美国管理学家蓝斯登
　　点评：可敬不可亲，终难敬；有权没有威，常失权。
　　

吉尔伯特法则
　　工作危机最确凿的信号，是没有人跟你说该怎样作。
　　提出者：英国人力培训专家b·吉尔伯特
　　点评：真正危险的事，是没人跟你谈危险。
　　

权威暗示效应
一化学家称，他将测验一瓶臭气的传播速度，他打开瓶盖15秒后，前排学生即举手，称自己闻到臭气，而后排的人则陆续举手，纷纷称自己也已闻到，其实瓶中什么也没有。
　　点评：迷信则轻信，盲目必盲从。
　　没走过的路。2、特色不特，优势无优。
　　

古特雷定理
　　每一处出口都是另一处的入口。
　　提出者：美国管理学家W·古特雷
　　点评：上一个目标是下一个目标的基础，下一个目标是上一个目标的延续。
　　

六、计划
　　

列文定理
　　那些犹豫着迟迟不能作出计划的人，通常是因为对自己的能力没有把握。
　　提出者：法国管理学家P·列文
　　点评：如果没有能力去筹划，就只有时间去后悔了。
　　

弗洛斯特法则
　　在筑墙之前应该知道把什么圈出去，把什么圈进来。
　　提出者：美国思想家W·P·弗洛斯特
　　点评：开始就明确了界限，最终就不会作出超越界限的事来。
　　

七、参谋
　　

波克定理
　　只有在争辩中，才可能诞生最好的主意和最好的决定。
　　提出者：美国庄臣公司总经理詹姆士·波克
　　点评：无磨擦便无磨合，有争论才有高论。
　　

韦奇定理
　　即使你已有了主见，但如果有十个朋友看法和你相反，你就很难不动摇。
　　提出者：美国洛杉矶加州大学经济学家伊渥·韦奇
　　点评：1、未听之时不应有成见，既听之后不可无主见。2、不怕开始众说纷纭，只怕最后莫衷一是。

八、决策
　　

福克兰定律
　　没有必要作出决定时，就有必要不作决定。
　　提出者：法国管理学家D·L·福克兰
　　点评：当不知如何行动时，最好的行动就是不采取任何行动。
　　

王安论断
　　犹豫不决固然可以免去一些作错事的机会，但也失去了成功的机遇。
　　提出者：美籍华裔企业家王安博士
　　点评：寡断能使好事由好变坏，果断可将危机转危为安。
　　

九、执行
　　

格瑞斯特定理
　　杰出的策略必须加上杰出的执行才能奏效。
　　提出者：美国企业家H·格瑞斯特
　　点评：好事干实更好，实事办好愈实。
　　

吉德林法则
　　把难题清清楚楚地写出来，便已经解决了一半。
　　提出者：美国通用汽车公司管理顾问查尔斯·吉德林
　　点评：杂乱无章的思维，不可能产生有条有理的行动
　　

十、信息
　　

沃尔森法则
　　把信息和情报放在第一位，金钱就会滚滚而来。
　　提出者：美国企业家s·m·沃尔森
　　点评：你能得到多少，往往取决于你能知道多少。
　　

塔马拉效应
　　塔马拉是捷克雷达专家弗·佩赫发明的一种雷达，它与其他雷达的最大不同是不发射信号而只接收信号，故不会被敌方反雷达装置发现。
　　点评：善藏者人不可知，能知者人无以藏。
　　

十一、监督
　　

小池定理
　　越是沉醉，就越是抓住眼前的东西不放。
　　提出者：日本管理学家小池敬
　　点评：自我陶醉不易清醒，自以为是不喜批评。
　　

赫勒法则
　　当人们知道自己的工作成绩有人检查的时候会加倍努力。
　　提出者：英国管理学家h·赫勒
　　点评：只有在相互信任的情况下，监督才会成为动力。

十二、控制
　　

横山法则
　　最有效并持续不断的控制不是强制，而是触发个人内在的自发控制。
　　提出者：日本社会学家横山宁夫
　　点评：有自觉性才有积极性，无自决权便无主动权。
　　

蝴蝶效应
　　" 紊乱学" 研究者称，南半球某地的一只蝴蝶偶尔扇动一下翅膀所引起的微弱气流，几星期后可变成席卷北半球某地的一场龙卷风。他们将这种由一个极小起因，经过一定的时间，在其他因素的参与作用下，发展成极为巨大和复杂后果的现象称为" 蝴蝶效应" 。
　　点评：善终者慎始，谨小者慎微。
　　

阿什法则
　　承认问题是解决问题的第一步。
　　提出者：美国企业家m·k·阿什
　　点评：你愈是躲着问题，问题愈会揪住你不放。
　　

十三、法纪
　　

洛克忠告
　　规定应该少定，一旦定下之后，便得严格遵守。
　　提出者：英国教育家洛克
　　点评：简则易循，严则必行。
　　

热炉法则
　　当人用手去碰烧热的火炉时，就会受到" 烫" 的惩罚，其有以下三个特点：即时性、预警性、平等性。
　　点评：罪与罚能相符，法与治可相期。
　　

十四、改革
　　

柯美雅定律
　　世上没有十全十美的东西，所以任何东西都有改革的余地。
　　提出者：美国社会心理学家m·r·柯美雅
　　点评：不拘于常规，才能激发出创造力。
　　

达维多夫定律
　　没有创新精神的人永远也只能是一个执行者。
　　提出者：前苏联心理学家达维多夫
　　点评：只有敢为人先的人，才最有资格成为真正的先驱者。
　　

自吃幼崽效应
　　美国硅谷企业竞争十分激烈，以至于各公司都积极寻找自己的致命弱点，所有公司共同的生存之道是：拿出更好看产品来击败自己的原有产品。有人将这种行为戏称为" 自吃幼崽" 。
　　点评：1、自己不逼自己，别人迟早会逼你。2、敢于对过去告一个段落，才有信心掀开新的一章。

　　

十五、创新
　　

舍恩定理
　　新思想只有落到真正相信它，对它着迷的人手里才能开花结果。
　　提出者：美国麻省理工学院教授舍恩
　　点评：只有信之不疑，才能持之以恒。
　　

吉宁定理
　　真正的错误是害怕犯错误。
　　提出者：美国管理学家h·吉宁
　　点评：不怕错误的人，错误往往也离他最远。
　　

卡贝定理
　　放弃是创新的钥匙。
　　提出者：美国电话电报公司前总经理卡贝
　　点评：在未学会放弃之前，你将很难懂得什么是争取。
　　

十六、考评
　　

吉普林忠告
　　将成败同等看待。
　　提出者：英国作家、诺贝尔文学奖获得者吉普林
　　点评：如果不明白失败是什么，那么对成功的理解也是片面的。
　　

史华兹论断
　　所有" 不幸事件" ，都只有在我们认为它不幸的情况下，才会真正成为不幸事件。
　　提出者：美国管理心理学家d·克华兹
　　点评：若能坏中看好，终会好上加好。
　　

e、绩效
　　

十七、竞争
　　

廷克定律
　　如果你处在第二的位置，你就总想努力去争作第一。
　　提出者：英国管理学家哈罗德·廷克
　　点评：欲往高处走，须向高处看。
　　

鲁尼恩定律
　　赛跑时不一定快的赢，打架时不一定弱的输。
　　提出者：奥地利经济学家r·h·鲁尼恩
　　点评：无备，强不抵弱，出奇，弱可胜强。
　　

史密斯原则
　　如果你不能战胜他们，你就加入到他们之中去。
　　提出者：美国通用汽车公司前董事长r·史密斯
　　点评：竞争使人进步最快，合作让人得到最多。

　

十八、营销
　　

阿尔巴德定理一个企业经营成功与否，全靠对顾客的要求了解到什么程度。
　　提出者：匈牙利全面质量管理国际有限公司顾问波尔加·韦雷什·阿尔巴德
　　点评：看到了别人的需要，你就成功了一半；满足了别人的需求，你就成功了全部。
　　

冰淇淋哲学
　　卖冰淇淋必须从冬天开始，因为冬天顾客少，会逼迫你降低成本，改善服务。如果能在冬天的逆境中生存，就再也不会害怕夏天的竞争。
　　提出者：台湾著名企业家王永庆
　　点评：逆境不错，顺境更好。
　　

十九、广告
　　

布里特定理
　　商品不作广告，就像姑娘在暗处向小伙子递送秋波，脉脉此情只有她自己知道。
　　提出者：英国广告学专家s·布里特
　　点评：要推而广之，先广而告之。
　　

伯内特定理
　　只有占领头脑，才会占有市场。
　　提出者：美国广告专家利奥·伯内特
　　点评：脍炙人口才会耐人寻味，深得人心方可引人入胜。
　　

拉图尔定律
　　一个好品名可能无助于劣质产品的销售，但是一个坏品名则会使好产品滞销。
　　提出者：法国诺门公司德国分公司负责人苏珊·拉图尔
　　点评：取名的艺术，亦是取得成功的艺术。
　　

赫斯定律
　　广告超过12个字，读者的记忆力要降低50%。
　　提出者：澳大利亚广告家h·赫斯
　　点评：忘却即等于抛弃。
　　

二十、**
　　

玛丽法则
　　假如还没有破，就不要去修它，免得弄巧成拙。
　　提出者：美国著名企业家玛丽·凯·阿什
　　点评：弄巧之所以成拙，往往是因为本来就无巧可弄。
　　

弗里施定理
　　没有满意的工作人员，就没有满意的顾客。
　　提出者：德国慕尼黑企业咨询顾问弗里施
　　点评：协调内外关系，从协调内部关系开始。
　　

反哺效应
　　动物学家将某些动物长大后把觅到的食物给予其父母的行为称为反哺。
　　点评：给别人好处的人，往往也是得到好处最多的人。
　　

史崔维兹定理
　　如果你为获得好处而帮助他人，就不算帮助他人。
　　提出者：美国社会心理学家g·史崔维兹
　　点评：动机不纯，行为失真。
　　

二十一、谈判
　　

奥狄思法则
　　在每一次谈判中，你都应准备向对方作出让步。
　　提出者：美国谈判专家j·s·奥狄思
　　点评：争，丈不足；让，寸有余。
　　

居家效应
　　一个人在家里或自己最熟悉的环境中，言谈举止表现得最为自信和从容。
　　点评：没有实力垫底，自信永远是苍白的。
　　

尼伦伯格原则
　　一场圆满的、成功的谈判，每一方都应是胜利者。
　　提出者：美国著名谈判学家尼伦伯格
　　点评：总想自己得势，必然势不两立。
　　

比林定律
　　一生中的麻烦有一半是由于太快说" 是" ，太慢说" 不" 造成的。
　　提出者：美国幽默作家比林
　　点评：1、没有否决权，发言权也很容易被剥夺。2、对不该让步的事不让步，别人反而更容易给你让步。
　　

二十二、交往
　　

克林纳德法则
　　与人相处得好坏，在很大程度上取决于我们用什么方式与人打交道。
　　提出者：美国人际关系学家h·h·克林纳德
　　点评：交之有道，能打好交道；来而无往，难有常来往。
　　

忌讳效应
　　因风俗习惯或个人理由等，对某些言语或举动有所顾忌，积久成为禁忌。
　　点评：知道别人不喜欢什么，比知道别人喜欢什么更重要。
　　

弗里德曼定律
　　当一个人的需要可以满足另一个人的需要时，两人就趋于互相喜欢。
　　提出者：美国心理学家n·w·弗里德曼
　　点评：有利益与利益的相互补充，才会有需要与需要的相互满足。

本文链接

程序员，你应该知道(转)

2011-04-25T09:38:00Z

作者: 李瑞宽来源: 博客园发布时间: 2011-04-24 11:40 阅读: 2682 次原文链接全屏阅读　 [收藏]

（说明：本文转自公司知识库的一篇原创文章，作者：李瑞宽)

想象你是一个初出茅庐的小菜鸟，上头交代你做任务，你对其中的一项任务有那么一小点疑问，你怯生生地问：“我觉得这项任务说得不是很清楚，那样做行吗？为什么呢？我觉得应该这样做更好。”项目很紧，上头头大着呢，他很不耐烦地对你说：“不要问那么多！我都考虑清楚了，只要照着做就行！”你应该怎么办呢？你是就这样屁颠屁颠地去做了，还是还是觉得你应该知道为什么要按照他说的做，而不是按照你说的做吗？你应该知道。而且你要一直坚持“我应该知道”这种想法，因为这种想法，会带领你走进一片新天地。你可能还意识不到，你现在的是否坚持和你后续的发展休戚相关。坚持了，你会向着更深的层次迈进；放弃了，你就一直呆在原地，没有办法进步。

依我看来，技术人员的发展，不外乎往深度发展或者往广度发展。

什么是深度呢？就是你对技术的掌握程度，你一套扎进去，对技术有自己越来越深的理解，你从不会到会，从会到精，你会显著感觉到自己能力的提升，等到精通了技术之后，使用这项技术自然是挥洒自如，易如反掌。

什么是广度呢？就是十八般武艺，刀枪剑戟棍，.NET, JAVA, Silverlight，逮着什么就是什么，都去参上那么一腿，这个就是广度。你学习了N多技术，每次见到一种新技术新语言你就两眼放光四肢冒汗，你都要根据它们的入门指南操作那么一次，好吧你是很踏实的人，所以你多操作了那么两次，之后你就能够很NB地在简历上面吹牛逼：“本人精通C#、C++、JAVA、PHP、HTML、C、汇编、Python 不拉不拉不拉，神马技术神马语言对于我都是浮云！”说出去唬的别人一愣一愣的，当然，他们并不知道，你只写过这一堆语言的Hello world。

深度很奥妙，广度很有趣，你应该怎么选？

如果是二选一，毋庸置疑，你应该选择深度！为啥呢？深度是一个技术人员的核心竞争力。在这个IT从业人员多如过江之鲫的今天，IT民工、码农到处都是；本科如狗，硕士满街走，只有博士还能抖一抖；街边随便哪个修钥匙档上面都贴着广告“200元企业建站！立等可取！”技术人员如何安身立命？

这个时候，你应该靠你的深度，你也只能靠你的深度了。道理很简单，技术人员靠什么吃饭？靠自己的脑子。从你人生到现在的经历中，你早早就依靠脑子跟别人竞争了。从小学到初中到高中到大学，哪一次升学考试你不是靠自己的脑子将别人PK下去？你知识掌握的越牢固，学得越深入，对那一堆公式定理理解的越深刻，你就越能够在竞争中占据有势，最终赢得求学阶段的胜利。不管现在学校扩招多厉害，名牌大学还是高质量的金字招牌，在普罗大众的眼中熠熠生辉，阿弥陀佛。进入了社会，这样的竞争其实还是很类似的，只要你比人功夫深，你就比人香喷喷。

深度就是你的内功，它带来效率，它能够让你非常稳健地向前进。我们来看看倚天屠龙记里面对乾坤大挪移的描述：“正如要一个七八岁的小孩去挥舞百斤重的大铁锤，锤法越是精微奥妙，越会将他自己打得头破血流，脑浆迸裂，但若舞锤者是个大力士，那便得其所哉了”。你的深度，就是你自己的力量，你要使用的技术，就一把大铁锤，你要掌控好这把铁锤，没有深度，就等着自己被砸伤吧！深刻地掌握一样东西，不单明白了它什么时候非常适合使用，什么时候能够使用，也能明白它什么时候最好不用。在平时的生活中你是否经常听到这样的话：“微软/Java/etc的XXX技术太难用了！我想要XXX它XXX就是搞不定！”很显然，你碰到了大铁锤的受害者。不排除微软的确是有难用的东西，臭名昭著的就有MSN，但依据我粗浅的技术眼光，至少在开发技术这块，微软还是相当有想法的，而且构建的东西只要摸清它的底，用起来还是颇为畅快的。

说到深度，就要提到境界。从你选择了深度这条路开始，你已经开始踏入了境界之旅。

境界是分层次的，学拳的说“招熟，懂劲，神明”，孔子说“三十而立，四十不惑，五十知天命，六十耳顺，七十为所欲为不守规矩！哦，是从心所欲不逾矩”。这两家说的都是不同的境界层次。你在开始境界之旅中的某一个时刻，将会处在某一个特定的境界层次中。不同的境界的认识是不同的，同样的话，境界低的人会看不到什么东西，境界高的人就能一眼看到其中的道理。即使大家都能看到其中有东西，看到的东西本身往往是不一样的。你平时有没有试过在一个问题上面困扰很久，旁边一个人过来一句话就将它解决了？这是因为他的境界比你高出一层不止。

站在地上往下看，能看见直径1m的范围，有蚂蚁、落叶和浮土；站在4层楼顶上往下看，能看见直径100m的范围，有汽车、马路和绿化带；站在50层楼顶上往下看，能看见直径10000m的范围，有成片的楼群，飘过的直升机和绵延的山岭。境界不同，看到的东西就不同。

境界不同，有时候交流起来是比较困难的，同样的概念，大家的理解是不一样的，虽然可能在不同的境界中他们都正确。好多东西你觉得很新奇很给力，在更上一层的人看来，那不过是常识罢了。有人说人民日报是最真的媒体，从上面获益良多；有些老板什么电视都不看，天天就看新闻联播；而这些在愤青眼中，只不过是党欺骗P民的谎言，令人作呕。你说谁才是对的？老板看完了，能够摸到政策的动向，赚到实实在在的money；而在同样的愤青群体眼中，他们就会觉得这位受到喉舌毒害的愤青是正确的，就应该呕吐，唾弃它们，鄙视这些五毛党！慈禧年间，有个农妇和别人吹水：“老佛爷吃的煎饼，那可真不得了啊！至少一定得有锅盖那么大！”殊不知连低慈禧N个档次的人，可能都已经不知道煎饼是何物了。这就是境界不同的缘故了。我现在回想起中学学习的思想政治课，开始觉得它们不再如当初的枯燥，变得非常有道理。

技术的境界和学拳的是非常类似的，一开始你只要学会怎么用，用熟练就好，然后你开始好奇它内在是怎么实现的，开始研究它实现的机制，等你学会了这些机制，你就懂得怎么发力了，你能够将这些机制用到其他地方，招招见血啊！再然后你通过不断的思索总结，你窥到了其中的概念和原理，你悟到了它存在的理由，于是你就神明了，你悟到的这些道理，不单可以用到类似的应用场景中，还可以用到更深远的地方，甚至日常生活之中。譬如事务这个玩意，一开始你只知道它是数据库里面的一个东西，你不知道它是啥，但是上头就是要求你用它。后来你知道它怎么用了，再然后你可以搞定死锁，将它用得很帅。终于有一天，你悟到了事务原来并不是只有一种实现，它是一个概念，是一个协议，它能够达到概念和实现的分离，它可以通过二阶段提交，也可以通过补偿等方式实现，更要命的是它不单可以通过计算机搞，还可以通过手工来搞。事务协调器可以不单只是一段代码，还可以是一封Email，一张贴在墙上的纸……那你才真正明白了事务这个玩意可以怎么玩，然后再明白了怎么去根据这种思路去探索其他的东西。想象你去超市买东西，你先给了钱给收银的美女，然后你还没有踏出大门，你就后悔了——TMD怎么又买了这么多用不着的东西？你对收银MM说：“不好意思咱不买了，你退钱给我吧！”收银MM又PP又通情达理，她在POS机里面将你的消费记录XX掉，将钱退回给你，顺便还送给你一盒益达——是你的益达！这中间，就体现了一种事务的思想。你体会了这种思想，就可以一下子老了四五十岁，达到七十岁的境界，为所欲为。计算机相关的这些东西，集人类智慧之大成，研究这个而能有所感悟，真真正正能达到境界上的提高。

境界到了最高妙之处，就会由实入虚，从术而道，这时你就悟到了如何将事物的本源跟事物的存在区分开来，你能够看清楚什么是本质，什么是表象，什么是要做到的目标，而什么是具体的行为。你从本质的角度看过去，你就具有了一双慧眼，将这纷扰看得清清楚楚明明白白真真切切，这双慧眼就是做洞察力。

什么是本质呢？本质就是事物赖以存在的根本原因，若然没有这个原因，这个事物就没有存在的意义，就会消亡。所谓存在即合理，这个合理不是说的合乎情理，而是说存在都是具有它深层次的根本原因的，也就是都是有本质的。不知道你有没有注意到，很多技术书籍第一章都是介绍技术出现的历史的，之前我觉得这些罗里啰嗦，都是废话，直接翻过去直奔技术本身而去也，其实它是全书的总纲（天之道，损有余而补不足，是故虚胜实，不足胜有余……），它论述的是这种技术的存在理由，如果没有这种理由，这种技术都没必要存在了，我们还学它干毛啊。

我们来说一个普通的项目，它的本质是什么？是它复杂纠结的需求吗？是它深奥精妙的设计吗？是它完全符合CMMI5滴水不漏的流程吗？都不是，它存在的意义，就是为了能为客户产生价值，真真正正消除客户的痛处。本质和表象是很容易混杂的，要将东西乱七八糟混杂在一起很容易，要清清楚楚区分它们，将它们有条有理摆放得整整齐齐是很困难的，这里快刀斩乱麻行不通，你得抽丝剥茧，一条条分得清清楚楚，不然你永远达不到透彻的境界。

本质是虚的，表象是实的。我们很难捉摸得到虚的东西，而实实在在的东西一直围绕在我们周围，所以我们很容易就能够接受它们，然后我们很容易就被这些东西迷惑，看不到背后还存在深刻的东西。我们需要透过现象看到本质，找到它们。本质坚如磐石，相对不变，只要有存在的理由，它就一直都存在，而表象如行云流水，花开花落，一直都在改变。就如用兵，目标是求胜，这是断然不会改变的，而行军就是兵无常势，水无常形，因时制宜，随机应变。倘若我们混淆了本质和表象，追求的是表象的东西，由于表象千变万化，到头来疲于奔命，却又两手空空，最后郁闷得对天大骂：“TMD这技术变得太快了！老子跟不上不玩了！”。你应该知道，凡是觉得乱的，都是因为没有得到本质。当你具有了深邃的洞察力，你得到了本质，你就能够不役于物，你就能看清变以不变，你就不会再去盲目追求具体的行为。

当你做项目，你强调的不再是符合某个规范来做，你深深知道规范只是一种具体的行为，你关注你的目标，你能够带给客户的价值，你团队的效率。当现在的规范不符合你的项目，你就大胆裁剪它，甚至抛弃它，而不是盲目将项目往规范上靠——只因为它是CMMI的建议，你所作的一切，都是为了你的这个目标而努力。

具有洞察力，通晓变与不变，你不但能看清现在的情形，你还能看清今后的趋势，然后针对趋势采取措施。我们可以清楚地看到，技术日新月异，但人们的思想变化却不大，一部道德经，几千年下来我们的思想仍然无法突破它论述的范畴，所以我们可以利用将来可能出现的新技术，结合人们不怎么改变的思想需求，做一些东西出来——不要问我是什么东西，我想到也不会告诉你。

是不是觉得上面的这些东西都很虚很哲学？虚实只是相对的，当你达到这样的境界，你自然就会明白我说的是什么，当然，当你觉得已经知道我在说什么了，我觉得你还是可以继续再想想，后面再来看，感觉又不一样。张三丰教张无忌太极剑的时候，连续两次教招，却无一式相同。张无忌“细细体会其中圆转如意，绵绵无尽之意”，杨逍殷天正“粗略窥到这个层次”，而周颠则是“大为担心，两遍都不一样，咱们教主怎么记得住？”道理不在于讲，而是在于悟，否则讲得再多也没用，不深刻，没效果。一阵风吹过，吹过松散的茅草屋，那就是一场灾难；吹过石壁，最多也只能带走几颗细沙；吹过水面，能荡起了一圈圈的波浪；吹过风车，则产生了源源不断的电力。苹果掉到牛顿头上，就诞生了万有引力，掉到你我头上，只能产生一个包和一颗苹果核。好吧我们就不讨论假如掉的不是苹果而是椰子的事情了。上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之，不笑，不足以为道。邓小平之所以喜欢看金庸的小说，称呼金庸为大师，他必然是看到了小说里面的这些道理。

虚到九天之上，还是得落地。让我们看看一些稍微实际点的东西。你水平提高了，开始做设计了，开始写设计文档，你应该写些什么？在你记录下你做出来的东西（你搞出了CDM、PDM）的时候，我觉得你还需要记录下你这样做的原因，因为随着时间推移，你设计的东西很可能不适用，但你的想法还是很有用很有参考意义的，你的想法是你CDM存在的原因。别人看你的设计文档，不单能看到死的结果，还能看到活生生的你的思想，然后延续这种思想，让设计具有生命力，能够延续下去。平时我们做需求，也要很清楚地知道什么才是真正的需求。我们来研究一下手机铃声，它表示了一种什么样的需求呢？你写下需求“我们的手机需要一种铃声”，于是，设计就产生了蜂鸣声铃声、十六和弦铃声、MP3铃声，但这就是我们的需求吗？不是的，其实你想说的是“我们需要一种提醒方式，这样在短信、或者电话到来的时候就能提醒使用者注意了”，这样就能设计出各种铃声，还有震动，还有铃声混合震动，在极端情况下，假如用户处于一个高度紧张的环境之下，很难注意到这种提醒，我们还能设计出让手机弹出一根刺，刺他一下的方式，一下不行？来多几下。记得之前看到一个闹钟的笑话：推销员对一个职员说，我们这种闹钟非常好用！它一开始放轻柔的音乐，如果还不醒，那它改放嘈杂的音乐，如果还不醒，它就往你头上洒水，再不醒，它就开始刺你。如果这样都还不醒，它就会打电话给你老板，告诉他你生病了，请假一天。这个闹钟深刻把握了自己的本质啊。

具有洞察力，我们就能根据行为和目标的契合程度，评价行为是否合理。作为技术人员，我们身边的争论随处可见，语言之争，框架之争，各种流派，各种山寨，比比皆是。“{”到底放在方法定义的最右边，还是放在方法定义的下一行呢，这可不是一件小事，这是一件很严肃的大事情，关乎信仰！从我了解的历史开始，我还没有见到任何一方说服了另外一方。面对这这样疯狂的一个世界，你怎样选择加入哪一方呢？李开复说：“Follow your heart！”我说，你首先看看你的目标，你就知道选择那一方了。譬如说开发语言，我们用它的目标是什么？假如我们需要能够很自然地去面对复杂的问题，而且开发过程中，我们需要能够飞快地利用语言的特性，构建我们的软件，那么C#就是很好的选择，用了汇编你就死翘翘，至少干十年才能把一个增删改查Web系统搞出来；假如我们需要进行很底层的开发，逻辑不复杂，但要做到精确的控制，性能是第一要义，那么你要选择汇编，甚至用刀子在硬盘上刻程序也在所不惜啊。语言之争之混乱，在于大家将目标和选择两者混为一谈，从而成功地将它们捣成了一桶浆糊。框架也是如此，我们现在的目标是什么？我们要自然，要快速开发，而且我们还需要能够扩展，那么我们评价框架的标准就很清楚了。你框架里头技术含量多么深厚，都到地核了，你用了三层架构，你共使用了23种不同的模式，你使用了微软到目前为止出现的所有技术，这些都没有意义。你做不到让我用起来那种如臂使指的感觉，你甚至阻碍我整体流的思考方式，你就说服不了我，你的框架是适用的。

到达了虚的境界之后，是不是实就没有用了呢？不是的，年轻人，看问题不能那么片面。虚和实，就相当于战略和战术，你看清楚了目标，只能说明你最高能去到什么地方，这只是一种可能。而实实在在你能够达到什么高度，是由你的战术来决定的。眼界只能决定你看到的高度，而实操才真正决定了你达到的高度。虚实到头来要结合到一起，用虚指导实，用实来实现虚，相得益彰，互为阴阳。

这个世界规律是虚的，推动世界发展实实在在的力量是实的。我们想想电灯，电脑，抽水马桶，哪一个不是实在的术创造出来的？我们看看下图的这张凳子，它就是传说中的“Aeron chair”，它具有出众的外观，具有领衔的人体工学设计，它能根据就座者不同的体重、姿势和动作进行精准的调节，与你的身体自然贴合，让你感受一整天不会疲倦的轻松自如，更有一小撮份子宣称，由于坐起来太舒服了，他们经常不知不觉加了好多次班还不知道！（广告！广告！赶快Cut掉！）对比一下我们平时坐的电脑椅呢？这就是术的差距，术的力量！当然，也在于他们把握了椅子不单只是用来坐的，而是要用来坐得非常舒服的这个道有关系。

说了那么久深度，让我们也来聊聊广度。广度也是人认识中很重要的一部分。你只有掌握了很多东西，你才能够了解到什么时候应该用什么技术。有这么一句话：“假如你是一把锤子，那么所有东西在你眼中都是钉子”。假如你只会铁锤这项技能，你只能打桩用锤，砍树用锤，连吃饭你都用锤盛着吃。好吧，你锤子练到了最高境界，达到了刚极而柔的化境，你用来吃饭一点问题都没有，可是，你真……没觉得吃相有那么一点难看么？打桩用铁锤，砍树用斧头，吃饭用筷子，耶！这样就温文尔雅得多了。

对广度的关注，也会促成转化为深度的思考，考虑不同东西的相同之处。对广度的探寻，常常会引出创新的主意，将不同的东西混合起来解决问题，是一种创新的做法；综合多种不同的思想，产生一种新的技术，就是创新的领域。近亲繁殖多产生怪胎，相距越远，就越能产生优良的品种。所以我们也要追求广度，不过要留意要达到创新的地步的话，至少在深度上面是要达到一定境界的。

你看我扯了这么多方外之言，内心在颤抖，这个行业水太深了！我是不是应该转行？你这样想。完全不必要，假如你朝着深度这条路走下去，你最终也能有这样的感悟。而且即使是其他行业，也是要有深度的，我们最终走向的将会是同一条路。

要往深度走下去，你应该怎么做呢？假如你抓住我，让我尽快提升你的境界，锤炼你的深度，我是做不到的。要做到这件事，只能靠你自己的不断思考，思考一切后面的原因。想象一个胖子需要减肥，有什么万试万灵的方式吗？假如他一天需要减十斤，我认为是搞不定的，我们只能从他身上切下一块肉，称一下——十斤！真正有效的办法是他自己运动起来，注意健康的饮食，然后长期下来，才能达到一个健康的体魄，才能有真正的精气神。

所以你的思考，就是这么一个过程，只有你自己不断思考不断突破，最终才能达到一个较高的境界。别人说的再多，你没有经过思考消化吸收，最后也没能转化为你的肌肉，提供给你力量，只会变成你的脂肪，增加你的负担，阻碍你的行动，最后还影响你对其他营养的吸收。看书本怎么说，看我怎么说，然后教条主义去运用，是行不通的，你需要将这些东西真真正正变成你自己的东西。知难行易，你可能轻易就开始行动了，却惨不透其中的道理；知易行难，知道了跑步有益身心，你却很难去坚持它。这些都是你的障碍，只能靠你自己去突破。

我们什么时候会思考？就我自己而言，我通常在看书的时候思考，在和人讨论的时候思考，在遇到困难的时候思考，在独处的时候，有时候也会发呆思考。基本上，都是思想遇到冲击的时候进行思考。所以，你如果要往更深的地方发展，要做的是从现在开始，珍惜看书的机会，珍惜和别人讨论的机会，创造机会和别人讨论（听君一席话，胜读十年书啊，八卦除外），去完成具有挑战性的任务。平时也要注意一些你觉得有思想的文章的微言大义，琢磨一下，都是能够对你思想进行冲击的，比如我之前推荐的《火星人的耳机》、《一百年后人类怎么编程》等貌似不着边际的文章。普通的解决问题的文章，讲究的是头痛医头脚痛医脚，违反中医之道，通常是很难促进你体质的提高的。书要挑经典的书，否则它说不定将你带进歧途深处，积重难返。眼中看着《***》，脑中想着世界运转的道理，人间色相，尽是脂粉骷髅，这种境界，小弟目前修炼尚浅，是万万达不到的。

最重要的是你认识到这一点，从今天开始觉得，你应该知道。上头再跟你说“你TMD不需要知道，你只需要做就行了”，你应该认识到他说这句话，他的意思其可能是：他很忙，没空跟你说；他自己也不知道。而绝对不是你不需要知道的意思。你需要知道，从现在开始思考，开始寻找为什么吧。

本文链接

凭什么跟你走(转)

2010-10-15T15:09:00Z

一、用户凭什么跟你走

[故事]

从前有个山沟，住着一群村民；山沟缺水，村民到处打井。

第一个人出现了，他帮助村民打井总能又快又好，村民都很信任他，但是水仍然越来越少，井越打越深，难度越来越大，村民越来越辛劳。

第二个人住在山顶，他每天都在远眺，有一天他跑下来对忙碌的村民说，你们跟我走吧，离开这个地方去外面的世界。村民放下工具问他，我们为什么跟你走？他说，外面有落日余晖，有大片的草场，有漂亮的花朵和成群奔跑的羚羊。村民说，干我球事，于是拿起工具继续挖井。这个人只好离开，喃喃自语，愚蠢的人们啊。

第三个人出现了，他也帮村民打过井，也在干渴中煎熬过，但是有一天，他走到了山顶，远眺了一下，他的眼镜放出了光芒；他匆匆的跑下山，走到村民中，大声喊。收拾自己的东西，赶紧跟我走，我们现在就出发，离开这里！村民放下工具问他，我们为什么跟你走？他说，山外有条大河！我们再也不用打井了！！

[分析]

第一个人，他是我们常说的合格的产品经理，他理解体会用户的需求，并为此努力着，他奉行绝对跟随用户的原则，这种人，每个公司其实都需要。

第二个人，高端，精英，他看的比别人远，知道的比别人多，他们一厢情愿的以为自己描绘的蓝图可以吸引用户，很抱歉，他们不了解用户真正的饥渴，用户凭什么跟他走？这种人在现实中经常是评论家。

第三个人，是真正的大师，领袖。第一，他知道用户的饥渴，也就是本质需求，用户告诉你他需要一口井，其实他需要的是水；第二，看到的比用户更远；第三，有更好的解决用户本质需求的方法和路线。

二、分工

[故事]

一位年轻的炮兵军官上任后，到下属部队视察操练情况，发现有几个部队操练时有一个共同的情况：在操练中，总有一个士兵自始至终站在大炮的炮筒下，纹丝不动。经过询问，得到的答案是：操练条例就是这样规定的。原来，条例因循的是用马拉大炮时代的规则，当时站在炮筒下的士兵的任务是拉住马的缰绳，防止大炮发射后因后座力产生的距离偏差，减少再次瞄准的时间。现在大炮不再需要这一角色了，但条例没有及时调整，出现了不拉马的士兵，这位军官的发现使他受到了国防部的表彰。

[分析]

管理的首要工作就是科学分工。只有每个员工都明确自己的岗位职责，才不会产生推委、扯皮等不良现象。如果公司象一个庞大的机器，那么每个员工就是一个个零件，只有他们爱岗敬业，公司的机器才能得以良性运转。公司是发展的，管理者应当根据实际动态情况对人员数量和分工及时做出相应调整。否则，队伍中就会出现“不拉马的士兵”。如果队伍中有人滥竽充数，给企业带来的不仅仅是工资的损失，而且会导致其他人员的心理不平衡，最终导致公司工作效率整体下降。

三、标准

[故事]

有一个小和尚担任撞钟一职，半年下来，觉得无聊之极，“做一天和尚撞一天钟”而已。有一天，主持宣布调他到后院劈柴挑水，原因是他不能胜任撞钟一职。小和尚很不服气地问：“我撞的钟难道不准时、不响亮？”老主持耐心地告诉他：“你撞的钟虽然很准时、也很响亮，但钟声空泛、疲软，没有感召力。钟声是要唤醒沉迷的众生，因此，撞出的钟声不仅要洪亮，而且要圆润、浑厚、深沉、悠远。”

[分析]

本故事中的主持犯了一个常识性管理错误，“做一天和尚撞一天钟”是由于主持没有提前公布工作标准造成的。如果小和尚进入寺院的当天就明白撞钟的标准和重要性，我想他也不会因怠工而被撤职。工作标准是员工的行为指南和考核依据。缺乏工作标准，往往导致员工的努力方向与公司整体发展方向不统一，造成大量的人力和物力资源浪费。因为缺乏参照物，时间久了员工容易形成自满情绪，导致工作懈怠。制定工作标准尽量做到数字化，要与考核联系起来，注意可操作性。

四、体制

[故事]

有七个人住在一起，每天共喝一桶粥，显然粥每天都不够。一开始，他们抓阄决定谁来分粥，每天轮一个。于是乎每周下来，他们只有一天是饱的，就是自己分粥的那一天。后来他们开始推选出一个道德高尚的人出来分粥。强权就会产生腐败，大家开始挖空心思去讨好他，贿赂他，搞得整个小团体乌烟障气。然后大家开始组成三人的分粥委员会及四人的评选委员会，互相攻击扯皮下来，粥吃到嘴里全是凉的。最后想出来一个方法：轮流分粥，但分粥的人要等其它人都挑完后拿剩下的最后一碗。为了不让自己吃到最少的，每人都尽量分得平均，就算不平，也只能认了。大家快快乐乐，和和气气，日子越过越好。

[分析]

管理的真谛在“理”不在“管”。管理者的主要职责就是建立一个象“轮流分粥，分者后取”那样合理的游戏规则，让每个员工按照游戏规则自我管理。游戏规则要兼顾公司利益和个人利益，并且要让个人利益与公司整体利益统一起来。责任、权利和利益是管理平台的三根支柱，缺一不可。缺乏责任，公司就会产生腐败，进而衰退；缺乏权利，管理者的执行就变成废纸；缺乏利益，员工就会积极性下降，消极怠工。只有管理者把“责、权、利”的平台搭建好，员工才能“八仙过海，各显其能”。

五、表率

[故事]

春秋晋国有一名叫李离的狱官，他在审理一件案子时，由于听从了下属的一面之辞，致使一个人冤死。真相大白后，李离准备以死赎罪，晋文公说：官有贵贱，罚有轻重，况且这件案子主要错在下面的办事人员，又不是你的罪过。李离说：“我平常没有跟下面的人说我们一起来当这个官，拿的俸禄也没有与下面的人一起分享。现在犯了错误，如果将责任推到下面的办事人员身上，我又怎么做得出来”。他拒绝听从晋文公的劝说，伏剑而死。

[分析]

正人先正己，做事先做人。管理者要想管好下属必须以身作则。示范的力量是惊人的。不但要象先人李离那样勇于替下属承担责任，而且要事事为先、严格要求自己，做到“己所不欲，勿施于人”。一旦通过表率树立起在员工中的威望，将会上下同心，大大提高团队的整体战斗力。得人心者得天下，做下属敬佩的领导将使管理事半功倍。

六、竞争

[故事]

国外一家森林公园曾养殖几百只梅花鹿，尽管环境幽静，水草丰美，又没有天敌，而几年以后，鹿群非但没有发展，反而病的病，死的死，竟然出现了负增长。后来他们买回几只狼放置在公园里，在狼的追赶捕食下，鹿群只得紧张地奔跑以逃命。这样一来，除了那些老弱病残者被狼捕食外，其它鹿的体质日益增强，数量也迅速地增长着。

[分析]

流水不腐，户枢不蠹。人天生有种惰性，没有竞争就会固步自封，躺在功劳簿上睡大觉。竞争对手就是追赶梅花鹿的狼，时刻让梅花鹿清楚狼的位置和同伴的位置。跑在前面的梅花鹿可以得到更好的食物，跑在最后的梅花鹿就成了狼的食物。按照市场规则，给予“头鹿”奖励，让“末鹿”被市场淘汰。

七、沟通

[故事]

美国知名主持人“林克莱特”一天访问一名小朋友，问他说：“你长大后想要当什么呀？”小朋友天真的回答：“我要当飞机的驾驶员！”林克莱特接着问：“如果有一天，你的飞机飞到太平洋上空所有引擎都熄火了，你会怎么办？”小朋友想了说：“我会先告诉坐在飞机上的人绑好安全带，然后我挂上我的降落伞跳出去。” 当在现场的观众笑的东倒西歪时，林克莱特继续注视这孩子，想看他是不是自作聪明的家伙。没想到，接著孩子的两行热泪夺眶而出，这才使得林克莱特发觉这孩子的悲悯之情远非笔墨所能形容。于是林克莱特问他说：“为甚么要这么做？”小孩的答案透露出一个孩子真挚的想法：“我要去拿燃料，我还要回来！！”。

[分析]

你真的听懂了手下的话了吗？你是不是也习惯性地用自己的权威打断手下的语言？我们经常犯这样的错误：在手下还没有来得及讲完自己的事情前，就按照我们的经验大加评论和指挥。反过头来想一下，如果你不是领导，你还会这么做吗？打断手下的语言，一方面容易做出片面的决策，另一方面使员工缺乏被尊重的感觉。时间久了，手下将再也没有兴趣向上级反馈真实的信息。反馈信息系统被切断，领导就成了“孤家寡人”，在决策上就成了“睁眼瞎”。与手下保持畅通的信息交流，将会使你的管理如鱼得水，以便及时纠正管理中的错误，制定更加切实可行的方案和制度。

八、指导

[故事]

有一回，日本歌舞伎大师勘弥扮演古代一位徒步旅行的百姓，他要上场之前故意解开自己的鞋带，试图表现这个百姓长途旅行的疲态。正巧那天有位记者到后台采访，看见了这一幕。等演完戏后，记者问勘弥：“你为什么不当时指教学生呢，他们并没有松散自己的鞋带呀。”勘弥回答说：“要教导学生演戏的技能，机会多的是，在今天的场合，最重要的是要让他们保持热情。”

[分析]

提高员工素质和能力是提高管理水准的有效方式。学习有利于提高团队执行力，便于增强团队凝聚力。手把手的现场指导可以及时纠正员工的错误，是提高员工素质的重要形式之一。但是指导必须注重技巧，就象勘弥大师那样要保护员工的热情。管理者必须避免教训式指导，应当语重心长的激励员工提高自身业务素质。除了现场指导外，还可以综合运用培训、交流会、内部刊物、业务竞赛等多种形式，激发员工不断提高自身素质和业务水平，形成一个积极向上的学习型团队。

九、锻炼

[故事]

一个人在高山之巅的鹰巢里，抓到了一只幼鹰，他把幼鹰带回家，养在鸡笼里。这只幼鹰和鸡一起啄食、嬉闹和休息。它以为自己是一只鸡。这只鹰渐渐长大，羽翼丰满了，主人想把它训练成猎鹰，可是由于终日和鸡混在一起，它已经变得和鸡完全一样，根本没有飞的愿望了。主人试了各种办法，都毫无效果，最后把它带到山顶上，一把将它扔了出去。这只鹰像块石头似的，直掉下去，慌乱之中它拼命地扑打翅膀，就这样，它终于飞了起来！

[分析]

每个人都希望用自己的能力来证明自身价值，手下也不例外。给他们更大的空间去施展自己的才华，是对他们最大的尊重和支持。不要害怕他们失败，给予适当的扶持和指点，放开你手中的“雄鹰”，让他们翱翔于更宽阔的天空。是个猴子就给他们座山折腾折腾，是条龙就给他们条大江大河扑腾扑腾。他们的成长，将为你的工作带来更大的贡献。他们的成长，将促使你更进一步。

十、发挥

[故事]

一位著名企业家在做报告。当听众咨询他最成功的做法时，他拿起粉笔在黑板上画了一个圈，只是并没有画圆满，留下一个缺口。他反问道：“这是什么？” “零”、“圈” 、“未完成的事业”、“成功”，台下的听众七嘴八舌地答道。他对这些回答未置可否：“其实，这只是一个未画完整的句号。你们问我为什么会取得辉煌的业绩，道理很简单：我不会把事情做得很圆满，就像画个句号，一定要留个缺口，让我的下属去填满它。”

[分析]

事必躬亲，是对员工智慧的扼杀，往往事与愿违。长此以往，员工容易形成惰性，责任心大大降低，把责任全推给管理者。情况严重者，会导致员工产生腻烦心理，即便工作出现错误也不情愿向管理者提出。何况人无完人，个人的智慧毕竟是有限而且片面的。为员工画好蓝图，给员工留下空间，发挥他们的智慧，他们会画的更好。多让员工参与公司的决策事务，是对他们的肯定，也是满足员工自我价值实现的精神需要。赋予员工更多的责任和权利，他们会取得让你意想不到的成绩。

十一、鞭策

[故事]

拿破仑一次打猎的时候，看到一个落水男孩，一边拼命挣扎，一边高呼救命。这河面并不宽，拿破仑不但没有跳水救人，反而端起猎枪，对准落水者，大声喊到：你若不自己爬上来，我就把你打死在水中。那男孩见求救无用，反而增添了一层危险，便更加拼命地奋力自救，终于游上岸。

[分析]

对待自觉性比较差的员工，一味的为他创造良好的软环境、去帮助他，并不一定让他感受到“萝卜”的重要，有时还离不开“大棒”的威胁。偶尔利用你的权威对他们进行威胁，会及时制止他们消极散漫的心态，激发他们发挥出自身的潜力。自觉性强的员工也有满足、停滞、消沉的时候，也有依赖性，适当的批评和惩罚能够帮助他们认清自我，重新激发新的工作斗志。

本文链接

人生思维指南（转）

2010-09-19T02:24:00Z

给予别人超乎他们的期待，并且很乐意去做。

记住你喜欢的诗。

当你说“我爱你”时要当真。

当你说“对不起”时要看着对方的眼睛。

相信一见钟情。

永远不要嘲笑别人的梦想。

全身心地去爱，你可能会受到伤害，但这是完整人生的惟一方式。

意见相左时，不要怒目相向，也不要指名道姓争吵。

说话可以慢，但思维要快。

当有人问你一个并不想回答的问题时，要微笑着问，“为什么你想知道？”

记住真正的爱和伟大的成功都需要冒巨大的风险。

记着给妈妈打电话。

看到别人打喷嚏时要说“噢，上帝保佑你”。

当你失败时，不要忘了这个教训。

尊重自己，尊重别人，对自己的行为负责。

不要让小争吵伤害了伟大的友谊。

意识到犯了错误，立即改正。

接电话时要微笑，对方从你的声音里能感觉到它。

和一个你爱跟她（他）说话的人结婚。

花点时间独处。

积极接受改变，但不违背你的原则。

记住有时沉默是金。

多看书，少看电视。

努力过一种好的生活。当你老了回忆时，你会第二次享受它。

相信上帝，但要锁好你的车。

对家而言，爱的氛围是非常重要的。你要做的一切就是创造一个安静和谐的家。

和爱人争吵，要就事论事，不要翻老帐。

读书要读透。

善待脚下的地球。

祈祷有时有无比的力量。

当别人奉承你时永远也不要打断。

关心你的投资。

不能相信当你吻她（他）时不闭上眼睛的人。

一年一次，到一个你以前从未去过的地方。

要是你赚了很多钱，要物尽其用，趁你活着时帮助别人。

记住有时得不到也是一种幸运。

学会规则然后打破一些。

记住真正的感情不是相互需要，而是相互爱恋。

性格决定命运。

判断你的成功在于你为了得到它而在这一过程中失去了多少。

本文链接