大道至简——软件工程实践者的思想 附 录

>>>  讀書—連接古今充實信仰  >>> 簡體     傳統

 附 录
 
一、Jiangtao, Aimingoo 关于序言的对谈(2005.11.06)
 
Jiangtao说:
 
    大部分的人都希望看到招术,而不是学习其中之道。 但每个人碰到的情况是不同的,不通“道”,招数就不灵了。
 
Aimingoo 说:
 
    是啊。明白道理,明白原理,即知变化之道,知变通之道。 
    亦步亦趋学不好编程,同理,也学不好工程啊。
 
Aimingoo 说:
 
    正如你说所"道理归到底是相通的",不同的人只是在换着不同的方式在说而已。
 
Aimingoo 说:
 
    像GoF这样深彻的理解,并不多。而我们看到GoF对他们的理解的解释,文字量并不大。而更多的是别的人的、种种不同的说法。—— 其实,根源在哪里呢?在GoF的思考,以及他们对既有事物的观察方法。
 
Jiang Tao 说:
 
    易经,论语也很短,却可以解释世界万物之理,当然其中任何一个话题展开也可以写成长篇大论。
 
 
Aimingoo 说:
 
    从写作手法上,看作散文集亦无妨。但我是有大纲然后逐一先成 
的,也就是说,在思想上是有中心并渐次展开的。
 
后语
 
Aimingoo 说:
 
    《程序员》选了6,7,8三章发表,其实很正确。因为6,7两章的确 
讲述了中心思想。但如果没有前面的,就有骨无肉,不丰满了。
 
Jiang Tao 说:
 
    我知道,你有一个逻辑关系组织,不过每一篇其实是散着谈的。
 
Jiang Tao 说:
 
    你是从根上谈起,一篇篇往后。
 
Aimingoo 说:
 
    对对,每一篇与其它的段落,并没有直接关系。
 
 
 
Jiang Tao 说:
 
    前面的道理大家觉得自己都明白,其实只是知道道理,却没有体 
会上身。 
    所以会不断地犯错误,而不知道错误的根源。
 
Aimingoo 说:
 
    是的。“知道”和“理解”,以及“理解”和“领悟”,都是不 
同的境界。
 
Jiang Tao 说:
 
    我们和这些专家正相反,专家是从根上来的,我们是从道理往后 
寻找根源。 
    大部分人还根本不找。只是用这个结果,却不知道根在哪里。
 
Aimingoo 说:
 
    对。我们做事,总是做到后来才发现道理与专家们说的是一样的。 
我读书的时候,以及在Coder的一个很长的阶段,也是很排斥“专家” 
和“理论”的。但现在我却在思考理论的东西。
 
Aimingoo 说:
 
    因为我发现,这些理论,以及其背后的思想,是一切演化的根源。
 
 
    如果不想沦为代码工人,甚或代码机器,那么就需要思考并领会 
这些背后的道理。
 
Aimingoo 说:
 
    我在脚注里面,有一些文字是很值得关注的,例如:“其实所谓 
‘经典’也是对既有知识的总结。大师们所知的,与你所思考的未必 
就有天壤之别。” 
    再如“《三十六计》更多的时候是被当成方法论来读的。其根源 
在于‘计谋’本身只是方法,而不是战略。”
 
Jiang Tao 说:
 
    就是这个理,不过这一关不好过。 
    围棋的学习有四个阶段:记住定式 应用定式 忘掉定式 创造定 
式。
 
Aimingoo 说:
 
    大多数时候,“文字”只是思想的结果的描述。我希望更多的人 
看到思考的过程,并知道其价值。如你所说,我也希望人们忘掉我所 
说的,并创造自己的“定式”,乃至达到“法无定法”的境界。
 
Aimingoo 说:
 
    所以我在甚至希望大家最终将这本书束之高阁,“思想已经领悟, 
文字的、纸质的东西还有什么价值吗?”
 
Jiang Tao 说:
 
    等电子版发表后,我们可以组织感兴趣的人延伸讨论讨论,很多主 
题是可以展开讨论的. 
    对照自己的问题,再看这些思考,就会有感觉了,这样就有案例出 
来了。
 
Aimingoo 说:
 
    好啊。非常不错的主意。
 
 
                  后 语
 
前言后语
 
    你现在读到的文字,原本应该是这本书的前言的。然
 
而如今,它变成了后语。
 
    如果读者是客户,那么我就应该是这本书的工程管理
 
人员了。与第一次着书不同,这一次我已经尝试参与整个
 
“做书”的过程。我必须要考虑客户问题,必须要知道作
 
为客户或者读者这个角色的你,在想些什么,或关注些什
 
么。
 
    在这本书的最最最初的时间里,我把书稿给了我的老
 
朋友王寒松。然而我很失望地听到他的意见:这个前言没
 
法读。——我想了又想,是的,因为有了玄而又玄的观点
 
以及曲折旁引的论述,所以的确不是太容易读。
 
    从我的角度上讲:
 
        这个前言总括地讲述了我的观点
 
    从读者的角度上讲:
 
        读者关注的是细节的文字
 
        读者享受的是阅读的快乐
 
    发现我在“做书”的这件事中扮演的是工程管理人员
 
的角色的同时,我就决定了这篇前言应该改成后语。原因
 
很简单,客户并不关注我对观点的总括,至少一开始他们
 
不会关注。如果要客户做结论,或者要他们与技术人员讨
 
论结论,那就让他们在看完演示之后,在最最后的阶段去
 
 
                                            -112- 
 
                                           『大道至简』
 
做。
 
    读者的阅读行为决定了我将这篇文字放在这个位置:
 
这篇前言既不是细节的文字,又不能给读者以阅读的快
 
乐,因此它就应该放在后面。至于它是叫前言,还是改名
 
叫后语,那只是形式的问题。
 
    如果你觉得你的项目中还有一个模块不是用户所关
 
注的,那么,En,建议调整一下明天的客户演示,把这一
 
部分放到幻灯的最后一页的后面,只有客户提及时,才拿
 
出来跟他们解说。
 
    否则,如果他们不感兴趣,那么他们将永远看不到这
 
张幻灯。一如这一篇前言。
 
软件工程
 
    如果做一份软件工程中的经典书目,决不会有人漏掉
 
Roger S.Pressman 着的《软件工程》。这本书有第四、五版
 
梅宏教授译着的中译本。然而相信读这本书的人不会太多
 
的注意到它的副标题是“实践者的研究方法”。——从根
 
源上说,它是讲述软件工程方法的书,而不是软件工程思
 
想。
 
    这有什么区别呢?拿这本书来作为软件工程活动的
 
参考时,绝大多数的人不能明白类似如下的问题:
 
        为什么要这样做呢?
 
        我们这里应该这样做,但是接下去呢?
 
        这个环节很重要,但是如果不做会有怎样的风
 
        险?
 
        我们在做这件事的时候,其它的人在做什么?
 
        为什么失败了?
 
    相关的问题很多,但总而言之,这本经典教材更多的
 
是在描述“怎样实做”,而绝少讲述“为什么这样做”。以
 
致于行为失去了思想的引领,能“完成”工程,而不能“做
 
成”工程便是可以想见的事了。
 
    任何人在实施软件工程的过程中,或者处于工程过程
 
的某一个阶段的时候,都会有自己的思想或思考(哪怕是
 
劳骚),那么为什么没有人写“软件工程思想”这样的书
 
呢?
 
 
 
我与软件工程
 
    我始终认为无论是哪家公司实施软件工程,都将是一
 
部成功者的血泪史。然而不实施软件工程,则将是一部失
 
败者的血泪史。换而言之,做软件工程可能流血流泪,但
 
终究可能成功;而不实施软件工程,那就是抛头颅洒热血
 
的失败了。
 
    我所遇见的却是不打算实施软件工程的公司。在“誓
 
死不做软件工程”的思想的引领下,一家堪称河南省最具
 
资本实力的软件公司于 2003-2004 年间倒掉了。我在这家
 
公司前后工作了 7 年。在 2003 年 2 月的时候,我开始请
 
假在家写书,以一个绝对 Coder 的身份完成了《Delphi
 
源代码分析》。用这一年的写书时间,完成了我对这些年
 
的程序生涯的回顾和反思,我看到了我在做 Develope
 
Manager 和 Project Manager 过程中的得失,也透析了那家
 
公司几年来的成败与沉浮。
 
    我再次与总经理 P&J 对坐的时候,我们又讨论到公
 
司的问题。他依旧固执地认为“最重要的是人的问题”。
 
我看不到他对管理、工程和决策上的任何反思,于是我终
 
于辞职了。
 
    2004 年 3 月,我开始应职于一家新的软件公司。因
 
为规模小,所以实施软件工程的风险也就小。在一次公司
 
内的软件工程培训中,我突然意识到工程实践与工程思想
 
之间的差异与关系,也同时看到《软件工程——实践者的
 
研究方法》一书的根本性的不足。时值我那本《Delphi
 
源代码分析》将近完成之时,于是我匆匆记下当时的想法,
 
并确定了这本新书的名字《大道至简——软件工程实践者
 
的思想》。
 
 
 
大道至简
 
    直到现在①,这本书的基本目标仍旧与它最初定名时
 
一样:
 
        这是一本小书
 
        只用读与思考,没有实作
 
    所谓“小书”,是我不想做成教材或者宏论。思想应
 
该简明,阐释应该清晰,而读者应该更多地去思考,而不
 
是跟随这本书去完成什么。
 
 
 
① 我写书的习惯是先写前言,这相当于大纲。因此所谓“现在”, 
是指我写下前言的这个时候:2004.11.01 凌晨 5 时。
 
    老子说“道之为物,惟恍惟惚”。道是要体悟的,而
 
不是象做木工活那样是“会与不会”的问题。道是什么呢?
 
“道是本体,是规律,是自然”,简而言之,道是既存在
 
的事实和影响事物发展的规律。
 
    这里需要说明的是,道并不人为的规则,而是事物本
 
身特质的规律。因此,本书中所要讲述重点是这种规律。
 
即使提及到一些“实践规则”,也是在对规律讨论之后。
 
读者应该发现这些“人为规则”是那样的遵从于“本质规
 
律”。
 
    经常听到的一句话是“规矩是人定的”,因此也要“靠
 
人来推翻”。但是(初级的)软件工程实施者经常抱着一些
 
经典的教材一步一趋,此谓之曰“知其然而不知其所以
 
然”。无僭越便无建树,无大成者。
 
画眉深浅入时无
 
    我不是太喜欢写很“入时”的东西。“入时”的往往
 
是新的,因而也就乏有研究。这样的东西流于口头的讨论
 
是可以的。然而着书立说,是要将心得之见或谨严之论呈
 
现给读者,不是把自己想说的话说出来就可以的了。
 
    在写《Delphi 源代码分析》的时候,Delphi 8 都已经
 
发布了,Win32 的时代也已近末路。促使我写那本书的原
 
因,在于没有人用 Delphi 来研究操作系统的内核机制,
 
而 Delphi 的源码中对这些的实现细节实在是宝藏。绝大
 
多数用过 Delphi 的开发人员,入源代码之宝山而空回,
 
实在令人痛惜的。因此那本书能否买得了钱我是不在乎
 
的,我在乎的是读过那本书的朋友,能从编译器的角度上
 
对 Win32 体系增加多少的了解。
 
    从 Delphi 7 的时代我就开始接触.NET Framework。
 
2003 年的时候给 BorCon China 做演讲时,我已经对
 
Borland 在底层上为 Delphi .NET 的实现非常了解了。因
 
此如果以“入时”(以及“适时”)而论,在《Delphi 源代
 
码分析》完成之后,我应该写的书是《Delphi .NET 源代
 
码分析》,来全面讲述 Delphi7、Delphi8 和 Delphi9(Delphi
 
2005)中对.NET 下开发的实现。
 
    这个计划被我搁置了。
 
    在我如今看来,语言其实是开发的细微未节,而在大
 
学时代、在课桌上令人昏昏欲睡的《软件工程》才是软件
 
开发中的髓质与灵魂。十年的软件开发实践中,其实在很
 
多时间里我都落入了细节陷阱。
 
    “实现”的欲望是从程序员出身的管理者的通病。因
 
此如果你仍然在思考选择什么语言、如何重构,以及在开
 
发部里争论一段代码有没有或应不应该采用某种模式,那
 
么请你暂时沉寂下来,听我说:那是细节。
 
    真正的问题是:你的老板要求你下周二就给客户演示
 
这个系统;而客户并不关注你的实现细节,他关注的是你
 
本月月底是否能 Close Project。
 
    软件工程首先关注的是以客户为对象的、整个工程的
 
成败和质量。根本上说,技术性、重用性等等,只是保障
 
工程成败与质量的手段而已。
 
    重要的东西往往并不入时①。例如你的ThinkPad还在
 
工作,仅仅是因为电池还没有用光。
 
知之、好之、乐之
 
    从读者的角度上来讲,是“知之不如好之,好之不如
 
乐之”的,因此作为作者,则希望自己的作品使人“以之
 
为知,以之为好,以之为乐”。在写《Delphi 源代码分析》
 
时,我的书稿的第一页就写着“知之、好之、乐之”,然
 
而那本书仅能给人以知识,让人“知道”就很不错了,况
 
乎乐哉?
 
    读书给人以痛苦之感是有可能的。如果读《Delphi
 
源代码分析》不感到痛苦,那是没认真读。然而我毕竟不
 
是想让人(或者想授人)痛苦的,将《Delphi 源代码分析》
 
写到那般地步,非我所愿。
 
    读《大道至简》的话,就用不着这样了。我虽然做不
 
到让读者“以之为乐”,但“以之为好”还是可以的。我
 
希望读者可以轻松地将这本小书读完,然后便可以束之高
 
阁了。毕竟这本书不是理论,也不是方法论,只是思想。
 
    思想已经领悟,文字的、纸质的东西还有什么价值
 
吗?
 
① 你当然也可以由此反推出第 7 章的部分内容并不重要。的确,
 
那只是我思考事物的一种方式,我希望你看到本书中讲的思想是
 
如何被实例化的。但对于本书来说,如同我一再强调的那样:这
 
是枝节。
 
致谢
 
    首先感谢我的老朋友,程序员杂志社社长蒋涛先生。
 
在我看来,他所作的序,既是对本书的赞许,也是对他本人十余年来从程序员进入管理和经营角色的经历的感言。
 
    感谢 P&J 和 Danny.Chou。他们给了我七年的从业经验,看着一个小公司做大,又从一个大公司做到消亡。这些经历深深地影响了我如今思考问题的方式,以及决策的方法。P&J 的知人善任和用人不疑成就了我的用人观,而以 Danny.Chou 为鉴,则同时形成了我对技术的执着与背离的两种态度(用于不同的思考场景)。
 
    再次感谢 P&J 在 1997 年成功地说服我留任西南区市场经理一职。如果没有那时的转变,我想我至今仍然会困宥于程序员的这一个角色。
 
    感谢我的朋友小邵(colorme)和明明,你在这本书上看到的插图漫画出自这对小夫妻的手绘。尽管 colorme 是我所见过的最好的平面设计人员,然而他只为本书画过一辆坦克。——然后他把它藏在了某幅漫画里面。
 
    感谢我的父亲母亲。父亲在我 12 岁之后的教育上是成功的,他留给了我足够的、独立的思考空间,以及面对事物的决策权。我至今记得我的第一封信是写于 9 岁那年的一封家书,这是我第一次用笔写课本之外的东西。这是母亲的功劳,她成就了我对文学和文字的喜好。没有他们,我不会有今日的观点和表达这些观点的能力。
 
    感谢 Joy。En,我还活着,是因为她无微不至的照顾。 谢上帝把她给了我,成了我的厨师、司机、保姆、听众、苦力工、开心果,以及,我最爱的妻。

周爱民(Aimingoo) 2013-08-24 22:48:17

[新一篇] 大道至簡——軟件工程實踐者的思想 第8章 是思考還是思想

[舊一篇] O'Reilly:黑客(計算機革命的英雄)黑客文化和倫理的奠基之作,計算機專業人士必讀
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表