程序员的历程(转)

    先借一个故事:

    从前，有一个A型血的程序员和一个B型血的程序员去登山。显然A和B有着不同的登山方法。

    A 到了山脚下，总是先停下来，仔细打量山势。接着，围着山脚转转，看看哪些是小山包，哪个是主峰。然后，设计几条不同的登山线路，并选择出最好的登山线路作为首选计划。同时，他还考虑到如果首选计划出现问题，则可以启用第二计划或第三计划... 

　　而此时的B几经爬上了第一个小山包。B登上小山包的时候，发现这个小山包不是去主峰的路。B并没有气馁，稍微打量一下环境，立即从小山包上下来，往更高的一个山峰进发...　就这样，B无时无刻不在后退中前进，在下坡中上山，已经将A远远的甩在后面。 

　　后来，当B成功地登上梧桐山(深圳)主峰的时候，而A还在半山腰艰难地攀登。 

　　最后，当A也终于登上主峰之后，B说了一句很有很有意思的话：你现在知道极限编程和敏捷开发的威力了吧！ 

　　A默然不语...

    一位想学登山的新手来向A和B请教登山的方法。A把他的线路图和计划全部给了新手，没有说一句话。 

　　新手看都没看，就跑去问B。B意味深长地说：努力，努力，再努力，当你到达山顶的时候，就知道了登山的方法！新手由衷敬佩。 

　　... 

　　多年以后，A成功地登上了珠穆朗玛峰。 

　　据说B倒下的地方离一号营地只有一百米远... 

　　当那位新手千辛万苦再次找到A求教的时候，A还是将所有的登山线路和计划交给了他，依然没有说一句话。

    但新手明白,这就是设计.

    如果我再讲什么极限编程,设计架构,那么朋友们都不会看下去,我想问一个问题,选手A为什么会在第一次的比试中输给选手B,或者生活中的点点滴滴可以给我启示.

      软件开发的学问很深，学一点可以开拓思路，学透了可以成为专家，而学得半透不透的时候，感觉就会像一种病，一种“设计病”。

得了“设计病”的程序员干活很慢。你看那些刚学习编程的年轻同志，拿到任务后立刻打开开发工具，又是点又是敲的，一会儿就能看到界面，程序功能一个一个地不断被实现，速度快的很。得了“设计病”的程序员就不能这样。拿到任务后左思右想，总觉得这样也行，那样也不错，一个小程序他能想出几百种方法来，光权衡就得半天。写程序通常也不从界面开始做，闷着头在键盘上狂按了好久，程序还是不能运行，搞得项目经理直冒汗。

 

“设计病”的程序员写的程序，写着费劲，看起来劳神。通常别人写一个函数的，“设计病”人非要写成好几个。使用面向对象开发语言的更是如此。“设计病”人写的程序里，类特别多。人家用两三个类就可以实现的功能，“设计病”人要用五六个类，甚至更多。还弄一些个类，一堆虚函数，一个成员变量也没有。稍大一点的程序就有几十上百的类挤在一起，关系也很复杂，一般人还真看不懂。

 

和“设计病”人讨论问题也不容易。通常大家都在谈这是个什么功能，某个功能怎么样才能实现，而“设计病”人常常不讨论这个，嘴上总挂着什么“复用”、“耦合”、“模式”等一类莫名其妙的词汇。就算“设计病”人在讨论功能的时候，听起来也和程序的实际功能相差很远。比如当大家在讨论使用多线程实现的时候，他就讨论线程管理类的接口；当大家讨论发送数据要缓冲的时候，“设计病”人却在研究如何实现一个快速的数据队列。

 

事实上“设计病”人自己也很痛苦。他们对现有的方案总是不满意，甚至昨天他自己写的方案，今天再看时也觉得不满。自己费尽心机设计出来的可复用的类，却从来都没有被复用过。自己好不容易设计出的松耦合的模块结构，在增加新功能时，却不得不在很多层次的类上做修改。

 

“设计病”也很难治好。“设计病”人总是不由自主地做设计，不愿意用直接的方式实现程序，总想把程序一点点剥开、分解。怎么劝都不会有用。他们相信迟早有一天自己的设计会发挥作用。

 

“设计病”人写出过很多烂程序。要么设计失败，考虑不周，程序结构有问题，要么过度设计，简单的功能，大堆的类，还不如不做设计。

 

不由自主地去设计，努力去写出烂程序，不是一种病又是什么？

 

如果您觉得也得了“设计病”了，也别太着急，办法有一个，就是继续“病”下去，努力做设计。直到有一天，能平衡完美和实用了，这病也就好了。

    登山: http://www.cnblogs.com/leadzen/archive/2008/02/12/1067471.html
    设计病: http://blog.csdn.net/Slin000/archive/2008/02/25/2119287.aspx

***********************************转载的分割线*****************************************

      目前是在企业内部做企业开发,他有一个很显著的特点就是需求变化不定,用户没有也不可能给出固顶的想法,只能在需求和开发中不停的迭代从而达到完美,因此用极限编程的思想,用单元测试组合开发(就好比登山选手B,一个一个山峰的尝试) 

     在项目不大的情况下,显然选手B的策略更加高效,但是同时,另一个值得思考的地方就是---设计架构就一定慢吗?选手A在有了多次的登山经历后(经历"设计病"),平衡了完美和实用,就不但能顺利凳上珠穆朗玛峰,也能更快的速度凳上普通的一座山峰.(因为A可以根据山峰的不同简化设计的步骤)

    我个人更加承认后者,选手A会输给选手B,是因为他正处于学习的第二阶段.学习分3阶段.兴奋期--困惑期--升华期.兴奋期是初生牛犊不怕虎,思想也很简单.困惑期,学得多了,问题也更多,想要总结,但是又不熟练,因此就得了设计病.最后升华期就是媳妇熬成婆了.

    生活的例子很多,很久不打球,手感会很不错,人很兴奋,但打多了,会感觉越打越差.考试上,通常最后一星期打突击的人可以超水平发挥,而平时勤勤恳恳的人通常总觉得自己很多不会,越想越深,最后成绩往往不理想.

    我现在还没有病,但我渴望快点进入设计病的程度,因为只有通过这次考验,以后的道路才能越走越宽.