??xml version="1.0" encoding="utf-8" standalone="yes"?>
只有懒惰的程序员才会ȝ写那些可以最l代替自己工作的自动化工P才不会成天ؓ了实现相似的功能ȝ写大D大D冗余重复的代码 - q种代码往往是Y件后期维护和重构的天敌。通常来说Q由于惰性的׃所产生出来的工具和E序最l极大的提高生开发的速度?/P>
当然Q对于一个程序员来说Q光光具备懒惰这个要素还是不够的。在享受懒惰之前Q他必须以最大的热情和最高的效率ȝI解放自q途径Q比如:扑ֈ最有助于开发的工具Q最能体现“一ơ编写,多次复用”精的代码架构的设计。只有在q些必要的工作之后,才可能真正n受轻杄E的乐趣?/P>
所以“懒”的_N用一句老话来描qͼ那就是磨刀不误砍柴功。如果你不想办法亮手中的柴刀Q就一天二十四时都在砍柴Q效果也不如拿把锋利的斧头一天只砍一时?/P>
从这个角度来_Googlel员工的20%自由旉是完全发挥了“懒”的能动力。ؓ了更好的享受h的乐,员工会更加具有创造力的去高效完成自己的Q务?/P>
夸张一Ҏ(gu)_懒惰才是人类q步的原动力?/P>
W?/STRONG>
q一点似乎比懒更让h不能接受。在解释q里所说的W的具体含义之前Q我们先看看一个聪明hQ或者说认ؓ自己_聪明Q会做什么:
1) 停止学习新的东西 2) 不愿意用批判的眼光去审视自己的工? W?点将使我们很隑֎接受或者主动的ȝI一Ҏ(gu)的技?- 即新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自n工作的问题所在,要对其进行改q或者重构就更加困难?/P>
从这两点来考虑Q作Z个程序员太自以ؓ是不见得是g好事情。由于对自n的过于自信,往往无法客观的看待自己和自己的工作。相反的Q笨一点(切的说Q谦逊一点)有时候倒有助于开发的利q行。D例来_当程序出现bug的时候,最好尽早承认问题是出在自己~写的代码上面而不是在于编译器Q当焉非是字节高低位编码方式之cȝ问题Q这U问题编译器会是错误的根源之一Q。如果你太自负的认ؓ自己的程序没有问题而去猜测可能是编译器或者其他的什么外部因素出问题的话Q那么十有八?ji)你会在调试q程中走上一长段的弯路?/P>
E序员应该笨一些的更ؓ关键的原因在于,当需要思考问题的最佌x案的时候,往往要求我们首先要蟩出思维定式。你对系l了解的多Q积累了多的经验,p难走出已有的局限,可以试的范围就小。相反的Q对于一个什么也不懂的门外汉来说Q因为没有Q何失败的记忆和潜规则的约束,也就没有什么是“不可能”的Q这L大脑所能迸发出来的在专业h士看h愚不可及的想法往往正是解决问题所需要的关键Ҏ(gu)在?BR> 可能很多E序员都会有cM的经历,在面对别人(其是其他部门)对于一个bug的描q的时候,必须把自己摆在一个普通用戯不是程序开发者的角度来分析问题,否则的话可能你永q都惌不到q种错误也会发生。越能让自己变得“笨”v来,能很快的定位到问题所在。我们先看看q么一D关于web开发问题的E序员和客服人员的对话:
“从昨天开始我们的用户q不到我们站点上的Logo了。?/P>
“他试过重启览器么Q?/P>
“是的。?/P>
“他试过重启?sh)脑么??/P>
“是的。?/P>
“他清空q浏览器Cache么??/P>
“是的。?/P>
“他的浏览器版本是IE6么??/P>
“是的。?/P>
“他信是真的看不到Logo了么Q?/P>
“是的。?/P>
“他是在?sh)脑昄器屏q上看我们的站点么??/P>
“什么??/P>
“比如说Q它可能是打印出来看不到Q?/P>
“不。他是在昄器上看的。?/P>
“除了站点Logo之外Q他是不是其他的囄都看不到Q?/P>
“什么?哦。我再问问他。?/P> 从这D对话来_估计用户实际上是止了浏览器昄囄的功能(或者他儿子q的Q。不怎么P如果你不是用q种?c)式的思维方式d扄案的话,可能怎么也找不到问题的根源?/P>
很多时候,问题发现者对于问题的描述往往是非常片面的Qƈ且加上了主观推测的成分在里面。如果你不能透过q些主观的描q去发现问题的实际表象,或者说Ҏ(gu)是你自己根据程序员的经验逻辑来判断问题所在的话,十有八九(ji)会在歧途上走远?/P>
对于白痴U的问题Q只有用白痴的行为方式才能得到答案?/P>
即便同样是程序员Q但对于你的E序q不熟?zhn)Q也会经常有q样的疑问:“ؓ什么我调用你的代码出错了?”这U问题的{案Q很多时候是因ؓ他们的调用方式不对,或者调用了错误的库文gQ或者库文g的版本用不当,或者根本就没有联接到库文g上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候,一般来说希望他对你的系l了解的少好Q只有这样他才会问一些你自己认ؓl对不可能出问题的“笨”问题?/P>
所以“笨”的_N在于你如何去思考问题:不要假设些什么,把自己假讄太完或者把别h假设的很聪明都会使你忽视一些很显的事实。思考的前提必须是完整的事实表象Q思考的q程必须是抛弃成见的问题跟踪。在发现事实之前作太多的主观思考和臆断Q倒不如把自己当作白痴一h行动更好?/P>
当然Q不思考的一个极端是不分情况都直接去做,另一个极端是完全q事实Q用思想办事。一个优U的程序员应该做好权衡?0ơ决定里面的1ơ错误决定不是致命的Q只?ơ正的军_而另?ơ没有Q何决定才更糟p?/P>
最后是一个蜈蚣的故事。蜈蚣本来用自己的几癑֏脚走路走的很快很好,但他从来没有花时间去惌Z么。直到有一天,一只臭虫问他:“你是怎么理好你的几癑֏脚的Q你不觉得这是g很困隄事情吗?”臭虫问完之后就C。只剩下蜈蚣坐在CQ不停的思考这个问题,却一直想不出个究竟。从此以后,q只蜈蚣再也没办法好好的走\?/P>