坪溪笔谈

从2004年初（大学二年级第二学期）加入学校就业信息网站，靠写代码获得第一笔收入，迄今已经将近六年。

第一条原则，首先弄清你的问题是什么。这一条规则无论怎么强调都不过分。

在《Programming Pearls》第二版的开篇，Jon Bentley 讲的就是，首先弄清你的问题是什么！ 在你没有详细、明确地定义好你的问题之前，你所做的大部分工作只产出废物。这些年，最头疼的事情，就是经常搞了一大堆东西，累死累活，甚至加班加点，最后总才发现很多事情偏离了目标。但这样的事情，总是在周围一遍一遍地发生。

一个工程师，如果在接到一个问题时首先不是尽可能挖到细致的资料，定义问题，并向了解问题的人去反馈，详细讨论问题的定义。虽然问题定义不是那么容易，但不首先定义好问题，那就是不合格的工程师。

还有很多原则，大抵都是这个原则的派生品。

第二条规则， 弄清你要干什么，以及哪些先干，哪些后干，哪些根本就不需要干。

说白了，就是把问题分解，列个表，排个先后顺序。这是大部分程序员最蹩脚的部分。高效的本质不是捧着ThoughtWorks那本《卓有成效的程序员》，而是我这条原则。我对Joel的书里印象最深刻的就是有关用Excel列任务列表的部分。

这条仍然是如此重要，以致于著名的YAGNI, (You ain’t gonna need it ）仅仅是一条推论而已。

当然，区分的标准是什么？It depends. 但是最重要的参照是，怎么做你能获得最大产出？也许你会在所谓的扩展性、适应需求变化与可工作的代码，用户的需求之间抉择。 最重要的还是可工作的代码，能够按时 ship the beta!

记住，先列出来要干什么；然后分清先后顺序，然后淘汰那些可以不干的。

第三条规则，KISS。 Keep It Simple Stupid。
用郭靖和杨过来比喻，代码要像郭靖一样用最简单直接的方式强壮地工作，不需要太多的波折。你的程序要是像杨过的人生那么复杂、聪明，早死翘翘了。 你的程序要简单强壮地干活，思想越简单越好，功能和特性越少越好。

这一条对于设计是至关重要的，浮躁的程序员们经常要在架构设计中引入模式、分层，又或者是绚丽的Ajax效果之类，完全是无知下的自虐。我也是好些年后才明白这条道理，直到后来开始使用Unix下的那些让无数人着迷的工具，才真真地看到了这条规则的巨大威力。

要特别澄清一下，KISS 与你的程序是否好用，是否易于复用，不但不矛盾，而且是相辅相成的。你要知道的只是你的程序应该做什么，然后努力做好。借用《Programming Pearls》开篇里法国作家兼飞机设计师的话：“设计者确定其设计已经达到了完美的标准不是不能再增加任何东西,而是不能再减少任何东西”。又如Chuck Yeager将军（第一个超音速飞行的人）赞扬一架飞机的机械系统时的用词是“结构简单、部件很少、易于维护、非常坚固”。

第四条规则，一键集成和适当的自动化测试。

这条不多说了，在有条件的情况下做会受益非浅。

其他还有一些很有名的原则，例如 DRY （Don’t Repeat Yourself)， 也许是因为一开始我就懂得了这个道理（尤记得大学的时候把ASP代码提取函数，封装Head和Foot，将写HTML Table的封装成方法来根据不同的数据集打印，好傻。），感触没那么深。

六年了，好快。

(Update 2009-12-23)
第五条： 一定需要且只需要数页简单明了的设计说明书。

这个设计说明最好不用word，最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。当然设计文档也可以放在别的地方。

P.S.
用原则这个词，是为了强调重要性。遣词或有问题，慎自斟酌之。

        今天陪同事去一个项目的投标，我负责技术演示的支持。前两天加班加点赶制投标的演示Demo，昨天晚上甚至加班到晚上2点，终于搞定。今天早上同事熟悉了我们的Demo，一切稳定，还是很正常的。心里觉得有底，自己的负责的部分没有问题。

但是在中午的时候，发现还几次我这个破Vista系统，蓝屏了好几次。但是那时犯困呢，也没有仔细想，继续睡。

下午1点多，跟同事去投标现场，这时候发现机器中午蓝屏后还需要启动。照说我的机器配置也很好了，可是启动的速度就是那么慢。尤其是硬盘，硬盘灯简直是疯了一般地闪，可是速度还是很慢。好不容易把装有数据库的虚拟机打开，启动数据库的时候，忽然，蓝屏了。 可恶的Vista。

接下来又重新启动了一遍，打开虚拟机，启动数据库，打开老慢的Eclipse，打开IE窗口的时候，又蓝屏了！可恶的Vista，我已经进了讲标的会议室，坐在座位上了。天啊，简直要崩溃。

只能在启动一次，这次是先打开虚拟机，然后启动数据库，最后打开老慢的Eclipse，将应用跑起来，再打开了两个演示用的IE窗口。心中一直在祈祷，上帝保佑。 还好，终于合作了一次。将笔记本放到了讲标的讲台上，于是只能来默默祈祷，保佑我的机器能够顺利配合同事完成演示。如果这是蓝屏，那就真要崩溃了。总共十分钟的演示时间，哪有可能再重启机器！ 同事在演示的时候，我的心里可是七上八下，暗自祈祷，偶尔盯下屏幕生怕万一。

最后，终于演示完成了。我看同事也很紧张的，回来的路上，我跟同事说，下次要是投标，一定要准备两个笔记本，两套系统，以防万一。

演示的过程中，专家们提了一些问题，有个专家提问很尖锐，虽然比较刺，但是提的问题的确很到位。看来，我们还是要多准备的。

今天和同事在一起吃饭的时候，聊起了公司里的加班现象。这位同事是刚到公司才三个月的新员工，他说自从来到公司里开始，每天如果能够在七点下班那简直就是高兴不已的事情。在这短短的时间里，明显的感觉到身体有了很大的变化，感受到身体上的损害和痛苦。基本上每天都是紧张的去做事情，但是还是做不完，还是要加班。不仅工作日的晚上要加班，连周末也经常不得不去公司–如果你想正常完成各项工作的话。

除了加不完的班，另外就是经常有突发性的任务忽然需要去处理。该同事讲到有一天六点多，要下班的时候，忽然PM告知他明天要去演示，要求他立即搭建演示环境，因为他明天要去见客户，要给客户演示。这下，搞得他不得不忙到很晚，快十一点时，拖着疲惫的身体回家。

仔细观察我们公司的加班文化，发现同是在一个公司的开发部门，有点行业组加班相对要少一些，有的行业组加班相对要多一些。第一个原因，可能跟领导有关系，有点部门领导很勤奋、是个工作狂，所以开发计划估计也比较紧密。有点部门领导比较重视生活点，正常平衡工作与生活，所以相对来说员工也会轻松一些。第二个原因，可能确实是不同的行业组，其任务量、效率都有不同。任务较重或者效率较低的组自然要加班了。

加班文化的重要原因肯定跟项目经理有关。人都是需要生活的，不只是需要工作。如果长期工作，而忽视了生活，员工怎么能够在公司里愉快的工作呢？ 不能愉快的工作，对公司有怨言（即使不说） ，怎么能够好好的工作呢？怎么心甘情愿地做忠诚负责的员工呢？ 我想有能力的员工，又想要平衡好生活与工作的关系的员工，肯定会对领导的强制或者是项目计划的强制产生内心的逆反（即使没有强烈到激化冲突），并进而去选择一个更好的工作环境。所以，好的项目经理的第一项重要素质就是在重视工作的同时，也应该努力帮助员工愉快地工作。

而项目经理也有自己的难处。

需求多变就是一个关键的难题，但是解决这个问题的方法，有时候也不是项目经理就能够解决的。不过我建议项目经理不应该因为需求多变就把这种多变的需求直接传导到员工头上去。这样，无非是多让员工做一些无意义的事情，最终带来项目成本的增加，还要求员工付出身心牺牲，最终却没有任何意义。管理和控制需求作为降低项目成本提高项目收益的重要内容，是项目经理的本职工作，绝对不应该客户比较刁蛮就丢弃了这部分工作内容。

工作过多而资源紧缺也是一个常见的问题。因此经常导致了在制定计划时不能够客观。有的情况下是忽略了一些在计划中需要处理的潜在工作，有的情况下是尽最大限度地去缩减对任务的资源支出。无论哪种方式，这个计划都没有尽可能地去贴近实际情况，这个项目计划的执行过程怎么能够不出问题呢？项目的计划怎么能够执行呢？掩耳盗铃的方式，并不可取。正确的方法，应该是制定计划时定时不定量，或者争取更多的资源。

突发事件是项目经理的另一个要经常面对的难题。例如上问提到的忽然要求搭建演示环境的事情。这完全是在项目经理的工作表里面没有的事情，忽然跑出来，那徒然疲劳自己的手下。 如果当这项工作确实是需要的，那么项目经理应该要提前通知，让手下有所准备，出来的东西也有保证。你疏忽了，造成了这样的突发事件，那真是不应该。如果感觉这项工作内容较多，需要手下去突击完成，从而采取这种突发事件让手下加班的方法，那更不应该。如果确实内容较多，那么要考虑下是不是值得去做这些任务，是不是可以将这项内容适当删减。即使你让你的手下是加班时间突击完成了这件事情，但这些确实已经是你项目中的成本。他是你的手下，他的加班尽管你不需要付钱，但是确实是项目成本。他是你的手下，尽管你没有付钱，但是他付出了时间和健康。尽管你没有付钱，但是你可能付出了威信，和下属对你的信任的成本。项目经理应该努力让所有的事情都是可控的，对于不可控的事情，也要努力去削弱突发事件的影响。

做一个好的项目经理，要尊重、爱惜自己的手下。 在某一个项目里，你最需要负责的也许不是手下，但是在很多项目构成的长期工作中，你最需要负责的正是你的手下。没有他们，你什么都成不了。