什么才是软件开发的葵花宝典？

中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为"不败"。

但什么才是软件开发的葵花宝典？

让我们先从一些现象出发。我们的前提是，软件开发是一项智力密集型劳动。对于智力密集型劳动，我们观察到的现象是，个体的表现差异很大，团队的表现差异很大，组织的表现差异很大，国家的表现差异很大。这不象体力占主要的劳动，象百米王跑百米的速度也仅比我快50%。但在棋类运动中，一个高手可以车轮战数位低手，而且毫无例外地将他们一一击败！

这些智力运动员表现出的特点是，计算精确而且速度快。其行为很象东方不败。虽然关于葵花宝典的传说很多，但最准确的描述只有一个字"快"。东方不败已经快到了吓人的地步。就象卡斯帕罗夫已快到了深蓝的地步。

有一则关于物理学家玻尔的轶事，有一次玻尔在普林斯顿大学听两个年青教授演讲他们的工作成果。期间玻尔突然发言说，如果照你们的研究算下去，会得到一个很有意思的推论。结果两个年青教授回去计算了两天，果然得出了同样的结论。玻尔是如何做到这样快的？

在软件开发中，我们同样注意到这样一种高手，他们可以每天写出一千行左右的高品质代码。他们可以运用已有的一些软件包，迅速完成一个新的产品。他们可以在很短的时间内，学会一项新的程序语言或是新技术。他们表现出一种神奇的速度。

在武侠小说中，所有的高手都有一些凡人不能企及的表现。象张无忌学太极，用龙爪手击败龙爪手名家；乔峰用太祖长拳击败天下英雄；姑苏慕容以其人之道还治其人之身，令狐冲一剑剌瞎十几双眼睛等等。我认为，之所以他们能做到这样，关键是在于他们快。

快并不意味着不准或品质差。快与品质并不矛盾。

高手的快，其实包含着很高的品质在其中。如果你因为高手的快，就质疑其品质，那就相当于在问：东方不败出手那么快，会不会刺不准？东方不败并不满足于刺死对手，他会在对手身上刺朵花。他把杀人变成了艺术。准确来说，他真正的兴趣不在杀人，而在于艺术。

退一步说，就算东方不败第一击有点偏差，他稍作修正后，马上跟上的第二第三击，也会击中他想击中的地方。在武功差的对手剑还没拨出来的时候，他已杀死对方并刺上了一朵花。

所以真正的软件高手，他并不满足于他的代码能有效地工作了，他认为编程是艺术，并醉心于其中。在低手能写出一个版本的时间里，他已经写出了第十版。其品质当然不可同日而语。就象一个九段棋手，在给定的时间里，他能计算十种可能，并将每种可能计算到100手之后，从中选择一种最有利的下法。低手岂有苟全的机会？

高手写软件总是不停地在重构(refactoring）。高手喜欢迭代式开发。高手说，增量就是打补丁，迭代就是推倒重来。对于软件这种东西，写一遍它可能OK（做到这一点也不容易），写十遍就是一个伟大的产品，再多写一遍它就更伟大些。

高手快的诀窍在于他很熟悉各种东西。高手看书很快，因为每一本新书里，值得他好好看的新技术只有一两章的内容。他能迅速看完，并准确领会这本书的中心思想和价值。而对于一个新手，每句话都是新的，他都需要去理解，每一段例子，他都需要去试。

很少看到一种100%全新的技术或理论。就象Java language specification里说的，Java没有使用任何新技术，用的都是业界久经考验的技术。对于高手来说，那些技术都是他所熟悉的。自然，很快他就从一个C++高手变成了Java高手。如果一个编程新手学Java，学两年也不如一个高手学两个月的。高手学新东西快。

高手写代码速度快。统计结果说，人均每人月的有效代码速度大概是300至400行。但那是业界平均生产效率。对于高手来说，这个数字太低了。每天写300至400行是完全有可能的。因为在写代码时，所有知识都已具备，已经没有任何需要他多花时间的事情了。他甚至很少需要Debug。

高手重用代码的能力很强，熟悉新的API的速度很快。这也是因为，他曾经使用过很多的API，重用过很多的代码。他知道哪些是可用的，哪些有缺陷。他既过用Qt，也用过gtk+，也用过windows API & MFC，也用过AWT & SWING。新的API对他来说，也是老熟人。

高手喜欢用轻量级的工具，象vi，notepad，最多到UltraEdit这样复杂的。高手用这种工具写出很多的东西。这些工具就象东方不败的针。那根针已具有神奇的魔力，有时候它可以当激光枪来用。

对于一些重量级的工具，高手虽不常用，但一经使出也威力大于常人。如果让东方不败用剑，最厉害的剑术名家也会败得很难看。高手其实用过很多的重量级工具，而且深知其优缺点。所以使出来，就会把威力发挥到最大，而把缺陷减少到最小。而低手则不然，总是把缺陷加以大大的发扬而浑不知其精髓何在。就象很多人学用UML、RUP、XP、Design pattern那样。

高手所学博杂且融会贯通。高手做什么都快，当低手还在一愁莫展的时候，高手已经圆满解决问题，去干别的事去了。

在成为高手的路上，要有热情，要循序渐进，要持之以恒。

要逼自己，书要快快地看。要试图迅速理解其主旨。其实你快快看所接受的信息量，与慢慢看接受的差不多。能明白多少很大程度上取决于你的功底。以后用到再回过头来看。一本对你来说新东西太多的书，不要指望看一次就全理解吸收。就象很多功力不够的人看design patterns那本书一样。慢慢看还不如找到多种信息来源，都快快看一遍。对于一个完全陌生的领域，只看一本书很远远不够的。

要逼自已，事要快快做。有一个朋友，几年前我介绍他去玩玩linux，他也表示想玩，但他现在还没碰过。他失去了很多机会。

平时要有意识提高自己写代码的速度，其实你一天写15行有效代码，与你写50行有效代码，其品质是差不多的。你应该把那些业界平均水平抛诸脑后，把超越自己做为唯一目标。等到你写了很多各式各样的代码，你的水平就不一般了。一个老师曾向我介绍他的学英语的决窍，他说你去啃原版小说，啃到50本，就和一般人有很大距离了。就是这个理。如果你写得太慢，怎么能写得多？水平怎么能提高？

要逼自己，学很多别人怕学的东西。低手总会说：这么多东西怎么学得过来啊。于是就少学或不学。这样就成不了高手了。高手有非常广的知识面，有很丰富的经验。知道很多低手不知道的事。玩过很多低手听都没听过的东西。

要逼自己，努力满足客户的各种需求。个人技能是在满足客户的各种需求的过程中提高的。比如你喜欢用Delphi，客户说一定要用VB，那你就答应他，然后把自己培养成为VB的高手。用户的需求看似变态，但对你是一个机会。

怎样才能做到看书快，写代码快，学新东西快，一个显而易见的途径就是将工作并行化。你在一台机器上make时，同时可以在看别的文档和聊天。对于计算机是这样，对人也是这样。如果你只能串行地处理问题，你的速度将提高有限。你的大脑有很大潜力可挖，它应该是一个多任务分时系统。努力减少它idle的时间。搞经济的Samuelson被人称为human brain main frame，可见他的大脑有多快。

让你的思维快起来，你就会区别于那些反应迟钝的人。如果你不能让人生的道路变长，就让它变宽。这世界变化快，需要你变得比它快才行。

这样加快并不会让你短命，相反，你有更多的时间来享受生活和锻炼身体。你的生活将更有品质，更丰富，更有意义。面对变化，你将立于不败之地。我们都是和自己赛跑的人，需要跑得比昨天的自己更快。

 

评论    共 4 条

rain999     2003-09-20 19:38

不懂的时候,写代码飞快, 懂一点点的时候,我写代码很慢.就在那种不好不想写,好的又写不出的之间徘徊. 看了上面的,如提醐灌顶,我首先还是应该先让它运行起来,其次再是不停的迭代提高,一口吃不出个胖子,既然现在写不出高质量的,那么就一步一步提高吧!

jd2bs     2003-09-25 17:53

"你的大脑...，它应该是一个多任务分时系统" 哈哈,笑死我了. 万一死机了,就不妙了.

dlee     2003-09-25 18:01

很多时候，动起来才是最重要的。追求完美是懒人的借口，这样的人等一切条件都满足了才会前进。 宁可犯因为行动快而犯的错误，不要犯因为行动慢而犯的错误。

xiaoyu     2003-10-04 02:57

楼上说得对,特别是在真正的开发环境中,更是这样子,不能有待慢的情况,其实很的软件工程书中都会说到简单/轻便,其实也大概包括了这个方面吧,所以程序我都是让它先运行起来,再进行优化(用模式等),

发表于 @ 2006年09月30日 1:50 PM | 评论 (0)

TortoiseCVS 新手入门

    摘要： TortoiseCVS 新手入门     （全文共5792字）——点击 此处阅读全文

发表于 @ 2006年09月30日 1:37 PM | 评论 (0)

项目开发经验谈！

1，永远不要往延期的项目中添加人手，这个在《人月神话》中说的很清楚，但是在操作上人永远会犯这个错误，公司好几个项目都是这样的，一延期，客户在催了，马上就开始来叫人去帮忙了，结果是越帮越忙。
2，做业务系统，尤其是基于BS的项目，3个熟练的程序员和30个生手，我宁愿要3个熟练的程序员，这种项目，在最快的时间和客户确定需求，在最快的时间把代码编写完，把测试做完，绝对不能拖，要让客户跟着你跑，千万不能让客户有太多的空余时间。否则客户今天说这里颜色不对，明天说你给我在表里加个字段，你会疯的。
3，sales永远是sales，无论是特级还是顶级的，千万不能让sales当PM。
4，无论多小的项目，必须先有需求再设计，千万不能边需求边设计。

在项目开发中引入技术：
1、选择（定义）你想要重新构建的技术特性部分（比如性能提升等）
2、设计一些入门级的程序来增强你所选择的特性部分
3、将客户或者QC部门所反映的新特性部分分类
4、将所有要增强的按照优先级别排序后开始安排人员写测试用例以及代码
5、得到客户或者QC部门的回馈意见
6、当然根据回馈要做大量的分析以及Redo工作
7、返回到第一步继续进行迭代
上述部分是我正在实施并且做试验的部分，抛砖引玉。

----------------------------------------------------------------------------------------
教训：
1、如果页面设计人员对于程序没有一个总体的认识的话，随着时间的推移你会发现你的程序会越来越臃肿，每个模块的外观都不统一，最后交付给客户时候变的苍白无力、无法辩解。无论你的程序将所有的客户要求都满足了也无济于事。人机交互是设计人员一定要考虑的因素。
2、如果你对团队的时间监控仅仅限于一张project的进度表的话，那么你永远无法想到在这个进度表的背后其实隐藏着很多的Bad Smell,也意味着你很快跟团队的进度将很快脱离。当你发现这些Bad Smell开始浮出水面的时候可能已经变的可以让泰坦尼克号都能沉没了。这时候你会发现你的头发又开始稀少了，老板在你的面前的声音也开始尖锐起来了。
3、客户总是在最后才会明白自己之前的想法会有很多问题，毕竟中国的客户对于抽象的思维能力总是很弱。虽然中国人的数学学的都不错，但是仅仅限于在买菜的时候使用。所以再不济你也要将最后展现给客户的时间跟最后交付使用时间要有一定的间隙，否则客户也会怒发冲冠的。
4、如果团队中有人开始落后于进度的时候不要急于将其代码拿过来修改一通甚至直接从团队中让其消失，人员的水平有高有低，这种情况需要结对开发以及频繁的团队交流才能解决本质问题。
5、经常但是持续时间较短的会议对于团队气氛的调节很有好处，毕竟XP的面对面开发对于很多IT公司的老板是一件无法理解的事情。