« January 2004 | Main | March 2004 »
February 27, 2004
[转]我的大学书架（按学习先后）----给同学们
我的大学书架（按学习先后）----给同学们
作者：jaminwm 2004-2-27 10:29:25
出处：博客中国(Blogchina.com) 原始出处： CSDN b24259c
仿效 中国地质大学·连华于CSDN所著同名文章，有感于计算机专业的博大精深，霄汉之飞我所读图书的比比节轮，特著此文
读万卷书，行万里路，便是今生的两个愿望吧。
读书，算是旧习；大学已至尾声，一回首，除了师友欢颜，东湖碧波，便是那一册册的书了。可是计算机专业，比不得其他，书也颇是个花费。所以收拾收拾，列个单子，给痴书的伙伴一个参考；然而，我可不是在做广告呀~得说明如下：
（1）比起电子书，我更喜欢这些。但我不固执，如果您有一个书一般的计算机，能放在膝上，抱在怀中，且读之有味儿，大概也无须买。
（2）我所列的，只是在自己的书中挑选的，挑中的，我以个人信誉保证，不会让您白花银子，而且，有若干本，我加重了标志，那些书就可以用性命担保了 ：）。但是，囿于个人时间精力财力，没有买过的好书就不提了。您要知道，作为学生，问我书钱何所来，身上衣裳口中食呀。
快毕业了，作为一个学长，大概没有机会能像北京工业大学曾毅那样做一个新人激扬的“大师兄”，想想自己的确没有什么真工夫，好本领教给大家，与其这样不如为常常不知所学为何用的初学者们推介一些好书，以次聊表毕业心愿。
*****************勿在浮沙筑高台****************
大凡计算机系的同学学习基础理论的时候，并不知道所学的东西究竟有什么用，自己在书摊，网络上看到了一些流行技术的新鲜词汇，于是乎，每天嘴巴里挂着不少的“行话”，既而养成了浮躁的学习态度，最终什么都还不会（又好象什么都懂一点）。我所认识的朋友中不乏这样的夸夸其谈者，这样的后果自不必说--惨惨惨！所以在开谈之前，引用侯SIR的一句忠告：勿在浮沙筑高台（参见《深入浅出MFC》）。
我是中专毕业而后读的大学，中专所学财会电算化，会计没有学好，却让我深深的爱上了计算机。在2000年毕业的时候，拿到了计算机等级考试三级B类证书，说到这里不得不说说我的痛苦经历，我考计算机等级考试由于刚新起不久，又没有经验，我是一级一级的考过来的，郁闷啊！一级考打字（五笔，现在忘干净了，只记得口诀了），WPS（一种文字处理软件，用的是求伯君，李明写的），CCED（国产制表软件），DOS6。22的命令使用，二级考的FOXBASE 2。1就是他让我开始了程序之旅，当时只记得用他做了个同学录的小程序，连软盘一起在学校卖8块，还真卖了几块列，：），考三级才让我深深感到计算机的难！从这里 开始我认识了C！---1999/12，我不会忘记。
想想我走了不少的弯路，什么东西的学习似乎只停留在语言阶段，始终没有一个质的飞跃，但是现在向来未必是坏事：凡走过必留下足迹，弯路也不例外。
在这个阶段我向大家推介3本好书，作为语言的学习和计算机理论的基础。
~~~~~~《DOS磁盘操作系统》----中国商业出版社。 这本书我扎扎实实的看了几遍，上面讲了很多其他常用书中没有讲到的命令和系统原理 ，现在仍然记忆深刻的有“高端内存，扩展内存，CONFIG.SYS的配置”尤其是“DEBUG”那一章，我一直不懂直到大三学习汇编才明白 这本书讲的真透测。后来看到了清华出版的《DOS6.22大全》和大二学习了《DOS操作系统原理》（后面有介绍）我才知道这本书居然 是参考书目之一，作为中专学校，当时就用本书来讲授DOS命令（虽然只讲了前5章）但是却让我深深爱上了DOS。
~~~~~~《NOVELL 4技术手册》----清华大学出版社。 由于常常爱在机房捣鼓，偷偷的看了我们机房老师的这本“案头必备”，虽然不知所云 ，但是却让我知道了原来计算机还可以连网的。现在看看，我这个年龄的程序员自己用过NOVELL网的，可能已经是古董了吧：）
~~~~~~《QBASIC程序设计》-------谭浩强/电子工业出版社。由于在书店里看到了其中用QBASIC编音乐程序的一章而深深的爱上了这个语言， 后来看了盖茨的《未来之路》，我才晓得他就是靠BASIC起家的啊！……悻悻然。后来我用他琢磨了一首《风一样的男子》的音乐程序 装在一张软盘里送给了我一个一见钟情的女孩当生日礼物，呵呵，她现在还和我在一起哦！……晕！是不是很老土啊。
***************大学之道，在明明德****************
~~~~~~《计算机文化》-------机械工业出版社
真正的计算机学习从大学开始了，大一出于惊叹“武汉的书（洪山商场5楼书城）居然可以打8折”的心理，漫卷了一天书店，觉得什么都看不懂，有一位老者也在看书（估计是某退休教授），眼瞅着我不知所措的样子，向我推介了这本书，还嘱托我好好读。我细细一看，明白了很多以前不懂的东西，只有一种感觉：原来计算机是这样的。后来结识曾毅，才知道他也是读的这本书启蒙，不同的是他读英文版（顺便练习了英语），真是幸运。
~~~~~~《编码的奥秘》-------机械工业出版社
读了上面的那本，感觉还不过瘾，似乎学计算机用文科的东西来教授更合乎我的胃口。这本书从一个小孩用手电打暗语来和同伴对答案的故事开始，把程序，编码等一系列深的知识娓娓道来。我喜欢，可能对于爱好“故事教授法”的你有帮助。大三学习WIN32，我认识原来大名鼎鼎的《WINDOWS程序设计》就是这本书的作者，此君是微软获得最高成就奖的7人之一，号称WINDOWS编程祖师爷啊。
~~~~~~《C语言程序设计》------谭浩强/清华大学出版社
我的是第一版，感觉比第2版还好些，第2版增加的C++部分似乎有些蛇足之嫌。为了好好的理解编程非C不可，也就是这个时候，LIUNX在我们学校风靡起来，听说是用C写的，我深深的扎进了C里面，学C不管你是过2级还是做工程，入门我推介它。
~~~~~~《TURBO C实用大全》------徐金梧/清华大学出版社
学习C语言时候，我把老谭的书当课本，课后我用这本书，这本书我看的是第一版，从武大叔叔家借的，真是“书非借不能读也”，我细细的看了一学期，受用之极。本书讲了TURBO C 2.0的各个菜单功能用法，以及编译器的一些话题，记忆尤新的是“TCINST.EXE”等一些TC实用工具，让我对现代软件组件，控件等有了一些自己的理解，书中“井字游戏”的源代码我手抄了2遍，对数组算是有了质的了解。
~~~~~~《乐者为王》-----LIUNX
爱上了LIUNX系统，为此买了这本小说，看完了半懂不懂，生平买了第一套正版软件“蓝点LIUNX 2.0豪华版”。对于这本书，我知道了LIUNX系统的发展过程，了解了开源的威力，知道了这个系统源于MINUX（一种教学用的操作系统）的点点思想，促使我大三学习操作系统原理的时候，用上了liunx当年的教材《操作系统：设计与实现》，这本书的作者Andrew S.Tanenbaum就是MINUX的发明者，本书的下册就是MINUX源代码。
~~~~~~《C++程序设计》---钱能/清华大学出版社
~~~~~~《面向对象程序设计》---刘正林/华中科技大学出版社
我学习C++的入门书目，它有着良好的口碑，配套上机指导和习题集，让我在C++的漫游中照准了方向，当时很多同学用的是清华大学董渊老师的教材，看了后由于配套书籍太少，考虑到打一个良好的基础，我选择了它，感觉很好，美中不足：部分程序实现不够好，把C++比喻为带类的C不好。其他的章节讲的深入浅出，很适合初学。从这个时候开始，我到华中理工大学去旁听了，也是这个时候，认识了我尊敬的教授：刘正林。它举贤不必亲，介绍我看了他写的《面向对象程序设计》---华中科技大学出版社，并让我和大三的同学旁听，作为一个才大二的我，深知机会难得，学完一个学期后，我体会到了面向对象的真正含义，推介这两本书一起看，钱能的偏语法，细节，刘正林的偏面向对象，两者相辅相成，基础打的就很扎实了。
在学习计算机理论基础的时候，一定要沉沉稳稳，认真对待，由于这是基础，各个学校的教材一般都是经过多年实际教学实践的，所以认真阅读教材是很必要的，在这里说明一点，对于希望考研究生的同学，这个时候注意了，对你向往的学校专业不妨看看他们用的什么参考书目，配合阅读，这样培养一个好的第一印象是很有益处的。在这里我推介《计算机操作系统》--汤子瀛·电子科技大学出版社，《微型计算机接口技术及应用》--刘乐善·华中科技大学出版社，《计算机组成原理（第3版）》--白中英·科学出版社，《数据库系统概论（第3版）》--萨师煊、王珊·高等教育出版社，《数据结构（C语言版）》--严蔚敏、吴伟民·清华大学出版社，《计算机网络（第4版）》--谢希仁·电子工业出版社。
C++和JAVA是我大学学习、实践的主要语言，虽然其间使用VB和FOXPRO也做过一些项目，但是一般都是用的导师的书，自己没有好好的看过，故，在这里我不作推介。
~~~~~~~《windows程序设计（第5版）》----北京大学出版社
本书号称经典，看看对得起160大洋，在CSDN的网友上也有本书的勘误表，是WIN32的标准读本，好书，不敢评价，作为C向C++的实用过渡，这是NO.1。可以说，没有读过它的C++程序员肯定不是个优秀的程序员。--WINDOWS的祖师爷-的书都不看，看谁的。既是教本又是N好的工具书，案头必备。
~~~~~~~《BORLAND C++ 3.1高级编程》----学苑出版社
这是我在旧书店里面掏到的一本好书，由于钱能的入门书的原因，我喜欢上了Borland c++ 3.1后来听到北京大学潘爱民老师的回忆，它说BC31是他最喜欢的编译器。使用这本书我对面向对象和OWL库有了更深刻的了解。难以想象，我对框架技术的理解居然是从OWL这个早就被淘汰的古董开始的，不过这对我在学习MFC，VCL的时候有了更加深刻的理解。
~~~~~~~~《Visual C++ 技术内幕（第4版）》----潘爱民/清华大学出版社
当时为了学习VC，我选择了这本书，很多人反映：潘SIR是高手，精通COM，而第5版由于北京希望出版社翻译的太差，考虑到两者相差1元钱，还是买了这本，是基于VC5的，虽然我上机使用VC6但是并没有什么问题，后来看《深入浅出MFC》才了解也是用的VC5，真是巧合啊。这本书让我爱上了VC，爱上了潘SIR，以至后来看到潘SIR的东西我就收藏。这本书贵在熟练，我就看了2遍，真是温故而知新啊。那个暑假，电脑里我初了VC啥也没有碰（对于我这样一个游戏迷真是头一回）。
~~~~~~~~《深入浅出MFC（第2版）》-----侯捷/华中科技大学出版社
学习了VC++不懂MFC等于没有学，刚开始的时候我在书店看了看，就决定要买下。MFC如此庞大复杂，侯捷既然能模拟一遍，深入的如此之深，汗颜！当时想，MFC究竟是怎么实现的？原理是什么？组织结构如何？就算看不懂，也要鼓起勇气敢于深究。的确，看到第4章就要命了，啃不懂啊！发觉了自己知识体系的薄弱。多线程不懂啊！先搁下，饿补多线程！
~~~~~~~~《WIN32多线程程序设计》-----侯捷/华中科技大学出版社
看惯了侯SIR的台湾术语，于是找了这本饿补一番，还好，理解了很多然后和《深入浅出MFC》再配合交叉的看，总算从MFC的丛林里找到北了。
大三下学期，流行考证热，我也不示弱，再MCSD和SCJP中反复权衡了一下，觉得JAVA以后MONEY更多，抱了SCJP一把，自此JAVA便来到了我的生活中，我的讲师是SUN的优秀讲师，华工的博士，叫宋庭新，牛人也，在他的推介下（他说有C++基础的同学看的书）我又啃了本大埠头，著名的：《JAVA编程思想（第2版）》----侯捷/机械工业出版社。从这里我看到了原来技术图书还能这样写，而THINKING IN 则让我体会到编程不但是CODE还应是PROGRAM、设计，模式。
顺利拿到SCJP证书后，意识到考这样的证就是炸钱！于是也暂时打消了考JD的想法，其间去了回上海，受了点交大牛人的打击，在美罗大厦21楼（微软全球技术服务中心）流连了1小时，吃了回交大的食堂套餐，在复旦的毛爷爷像前留了影，来到三教听了“博雅节”的华东师范大学教授谢维迎讲了“中国古代文学史的研究意义”…………从此爱上了上海！--相比武汉，这才是人呆的地方！
~~~~~~~~《高质量程序设计指南—C++/C语言》-------林 锐·电子工业出版社
喜欢这个书原因有2：一、有程序员的面试题目（新鲜啊）二、附录：作者大学十年。看完了才知道，西电是个程序员的培养地，C++的高质量是建立在程序的设计和良好的编程习惯上的，好的风格应早早养成。我这个时候开始了对编程习惯的注意中。文档的编写也开始重视了，博士的这本书真是棒醒梦中人啊！我对自己的水平有了更深刻的理解：我才入门。这本书好好的让我矫正了一下心态，相比编程技术，这一点更是受益终身。感谢林锐！
~~~~~~~~《INTEL微处理器：结构，编程与接口》-------电子工业出版社
在大四期间，考虑到硬件学习几乎为0，为了使我对以往的计算机专业技术有了系统的认识，达到了知识的“原道”。我学习了这本书，虽然没有看懂什么，但是对于8255有了很直接的理解，同时补习了一下汇编程序设计。这本书是我看到的第一本硬件书籍，真的很枯燥，但是我挺过来了，没有什么心得，只为自己有了硬件的学习经历感到安慰。
转机在大四！刚考高程的我在叔叔的介绍下，在武汉大学软件工程国家重点实验室做了2个月的暑期项目实践，有幸得到了武汉大学软件高手们的垂青，其中在计算机学院研究生课程《面向组件软件架构实施》中我学习了当今最前沿的程序开发技术.NET并对曾经学习过的OOP（面向对象编程）有了全面的补充。作为一个本科生，能够在研究生群体中感受学习是我的荣幸，我会珍惜这样的机会，好好的挖掘学长们的技术为我所学！感谢老大：电子工程系研二余智欣（这位老大是我看到的真正的编程高手，用C的时候，几乎就是指针）
~~~~~~~~~《C陷阱与缺陷》《C和指针》《C专家编程》《C++实践之路》《C++沉思录》-------C/C++实务系列/人民邮电出版社
这一套我全买了，足足让我勒紧裤腰带了2个月，真是“衣带渐宽终不悔”。这一套书真的对于有了项目开发经验的人和那种一边作项目一边需要补充知识量的人来说，太适合了！一套中，我看了上面5本就已经感觉自己的编程能力有了很大的提高，作为一种饭后的补充最恰当不过。我用前三本作为考研的辅导感觉很好，而后两本让我体会到了工业级的强度的编程是什么样子，站在一个开发者的角度，从设计的角度来理解和审视了C++语言本身，学到了很多的东西。
~~~~~~~~~《WINDOWS核心编程》------机械工业出版社
要深入，要深入！我选择了它。真的博大艰深，这个时候的基础来读它简直就是雪中送碳。不敢多言，正在学习中……
~~~~~~~~~《莱昂氏UNIX源代码分析》--John Lions 著，尤晋元 译，机械工业出版社
我对这本流行了20年的著作一直很敬畏，对于我，现在读它不合适，容易把心态高坏，但是我依然把它供在案头，时刻鞭策我：我的水平还很菜，内力不够练习这种绝世神功！
~~~~~~~~~《软件工程 Java语言实现》---Stephen R.Schach 著，袁兆山等 译，机械工业出版社
我阅读软件工程的第一本书籍，经典！研习中！
~~~~~~~~~《设计模式》---------- Erich Gamma 等著，李英军等 译，机械工业出版社
为了它，我真的体会到了自己编程的瓶颈！自己的设计学习大概需要很长时间了，于是我报考了“软件复用与构件技术”方向的研究生，我想以后我会征服它的。同时，老师推介了几本模式方面的好书，没有看，在这里给有兴趣的读者：《STL源码剖析》《JAVA与模式》电子工业出版社《重构》《分析模式》，一本比一本难！我想你要是都通了，就应该有能力去读博了。
~~~~~~~~~《计算机程序设计艺术》-----苏运霖 译/国防工业出版社
这是圣经！我没有读！不敢，觉得自己数学底子太差了，不过记住：算法是程序设计的灵魂！该书和《莱昂氏UNIX源代码分析》一样20年来光芒犹在，盖茨说：你懂该书，可以给他投简历：）
以上4本是我的未来几年的NEXT BOOK，技术瞬息发展，.net的领域我还是0，我想：一步一个脚印，认真的聚焦你所学过的知识，是在大学期间应该作的一件事情！我这4年全部给我计算机！没有女朋友，没有认真的学习电子商务（我的专业）！我是一个失败的信息管理系学生！但是我相信我的努力会让我成为一个合格的程序员！快毕业了，我体会到了时间的不够，体会到了《乐者为王》中的“JUST FOR FUN”的意义！真的，我学习计算机就是因为我喜欢，我的执著，我已经爱它并且钟一了7年！我还能继续爱着这份技术吗？不知道！但是我相信，程序员是最真实的人！因为机器最真实！只要我保持着这份真实的本性，我就会深爱着这分真实的职业！快离开桂子山了，有些舍不得！为自己的总结，也是为新生的开始，写下了这些文字！
真的，我爱编程！没有原因，我就是喜欢！你呢？
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
February 17, 2004
Who is the best website?
下面的blog引用了 ▂▃▄『风语者』 中的 Who is the best?.
有名的未必就是好的，无名的未必就是差的，无论是有名、无名，无论是老的还是新的，我们更关注那些乐于创新的。来看看PCWorld的评选结果吧，也许你会有新的发现。
（资料来源：PCWorld.com - Web Stars: Best of the Web）
搜索引擎：
Google：www.google.com
Dogpile：www.dogpile.com
AllTheWeb：www.alltheweb.com
驱动与补丁：
Windows Update：windowsupdate.microsoft.com
Version Tracker：www.versiontracker.com
The Driver Guide：www.driverguide.com
浏览器工具条：
Dogpile Search Toolbar：www.dogpile.com/info.dogpl/tbar
AltaVista Toolbar：www.altavista.com/toolbar/default
Google Deskbar：toolbar.google.com/deskbar
拍卖站点：
EBay：www.ebay.com
Auction Sniper：www.auctionsniper.com
Bidz.com：www.bidz.com
BLOG站点与聚合工具：
Feedster：owww.feedster.com
Memigo：www.memigo.com
SharpReader：www.sharpreader.net
技术支持与帮助站点：
AVS Forum：www.avsforum.com
Annoyances.org：www.annoyances.org
Hoaxbusters：hoaxbusters.ciac.org
Tech Support Guy：www.helponthe.net
旅行服务：
Expedia：www.expedia.com
Orbitz：www.orbitz.com
Travelocity：www.travelocity.com
TripAdvisor：www.tripadvisor.com
媒体播放器：
Quintessential Player：www.quinnware.com
JetAudio：www.jetaudio.com
桌面参考：
Your Library's Web Site：New York Public Library
Acronym Finder: [url=http://www.acronymfinder.com]www.acronymfinder.com[/url]
OneLook: [url=http://www.onelook.com]www.onelook.com[/url]
技术爱好者：
Tom's Hardware Guide：www.tomshardware.com
Slashdot: [url=http://www.slashdot.org]www.slashdot.org[/url]
AnandTech: [url=http://www.anandtech.com]www.anandtech.com[/url]
地图与交通指南：
MapQuest ：www.mapquest.com
MSN Maps and Directions：mappoint.msn.com
AccuTraffic：www.accutraffic.com
网络会议：
WebEx：www.webex.com
Centra：www.centra.com
Live Meeting：www.placeware.com
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
什么是trackback ping(引用通告)？
以下文字来自cnblog.org
TrackBack最早是Movable Type上的一个小功能。可以说就是这个小功能在blog界却掀起了一场革命。
TrackBack为将全世界无数个blog连接起来的功能。例如，当你读了某个网站的文章，想对此写下自己的感想。这个时候利用网站准备的讨论功能进行投稿是很最常见的做法。但这样只是把自己的评论意见写下来向别人的网站投稿，而你自己手里却什么也没留下。
TrackBack则与之有很大的区别。可以把评论写到自己网站上。然后向刊载原始文章的服务器发送该网页的URL及标题、部分正文、网站名称等信息（注）。尽管这一过程只是称之为“发送TrackBack Ping”，但通过这种办法，在原始文章的地方就留下了你的评论的URL、标题等部分信息。当然别人也可以向原始文章发送TrackBack Ping，所以在原始文章中就将包括你的TrackBack Ping在内的所有评论都记录了下来。
此外，如果你在自己网站上也设置了TrackBack Ping功能的话，那么谁都可以通过TrackBack Ping来发表针对你的意见了。这样，多家网站就通过相关话题而联接起来。各种评论在因特网上就像网眼一样联接起来。这样就创造出了与日记网站完全不同的文化。
注：发送地址采用原始文章指定的URL，这一URL就称为“TrackBack Ping URL”。最后的“128”为原始文章的专用数字，称为“TrackBack ID”。另外，TrackBack的技术标准刊登在“LowLife.jp”的blog网站上。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
February 13, 2004
走出新车磨合的误区
大家认为新车的磨合只是针对于发动机方面，其实不然，发动机磨合只是汽车磨合的一部分，因为发动机在出厂前都进行了一定程度的冷磨。真正磨合是使机体各部件机能适应环境的能力得以调整提升，而且还是人与汽车之间的磨合。 电喷车在磨合期间，应让车速反复在低速和高速之间变化。磨合时车速应该在每小时２０－９０公里之间变化，偶尔超过９０公里，但时间不要过长，对发动机也有好处。这样做的目的是让发动机在各种车速下能得到磨合，使之各零部件能够充分的舒展，以均衡的性能表现。在城市道路或环路有条件的情况下车速不要太保守，一些车出于安全考虑，最高车速很少超过９０公里，这样车速不快，特别是夏季，车头进风口的风量不够大，不能充分冷却水箱，导致水温偏高，从而使电子扇强制启动。启动一段时间后，水温下降，电子扇停转，之后水温又会重新上升，从而导致电子扇反复启动，这样会使发动机负荷加大，增加油耗又缩短电子扇的使用寿命。正确的办法是保持一定车速，更多地利用自然风来冷却，降低电子扇的启动频率。低排量的车在夏季应少使用空调系统，车注意尽量不要满载，遇上坡路段时应用较低的挡位，行驶途中不要急加速，尽量避免紧急制动等不好的习惯。 另外还要专门提一下汽车的“预热”。首先电喷车启动时，应先将钥匙转到第二挡后等５－１０秒，再起动，因为钥匙门打开后，汽油泵开使工作，使油压及喷油量进行调整，所以几秒钟后再起动，对汽车的马达及发动机都是有好处的。着车后，大多数人都习惯让发动机怠速运转，等水温达到正常温度后再把车开走。这种预热的方法其实是非常错误的，因为电喷发动机不像化油器发动机，在达到工作温度之前，供油系统不能正常工作，这时如果勉强行驶自然会出现转速不稳、熄火等现象，所以化油器发动机用怠速预热是迫不得已的办法。而电喷发动机如果采用长时间预热，不仅没有必要而且还是有害的。缩短预热时间可以延长三元催化器的使用寿命，还可以提高尾气中污染物的转化率，另外还能节省燃油。所以正确的做法是，发动机起动后，只要能维持稳定的转速就可以起步走车，在水温未升高前，适当控制一下车速，等水温正常后就可以正常驾驶了。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
知识共享者维客：听维客之父细述Wiki前世今生
作者：尚进 2004-2-12 17:00:34
出处：博客中国(Blogchina.com) b23142c
维客：知识共享者与第二个博客
尚进/三联生活周刊
导语：当新创刊的《商业》在第一期封面上醒目的写道，“大前研一：Google是最好的图书馆”，大多数人似乎会认同这位因为在1975年撰写《战略家的思想》而知名的学者，但是当维客的技术概念悄悄露头之时，大前研一的话很有可能显得过时了。
就如同没有3D游戏，太平洋土著词汇Voodoo也不会被人熟知一样，原自夏威夷语wee kee wee kee的缩减化英语wiki，如果没有沃德·坎宁安(Ward Cunningham)1995年的突发奇想，也不会被人为的创造出来。wee kee wee kee的原意是“快点，快点”，在1995年沃德·坎宁安(Ward Cunningham)为了方便社区群落方式的内部交流，开发了一套名为波特兰模式知识库(Portland Pattern Repository)的工具，在建立这个系统的过程中，沃德·坎宁安突发奇想的创造了wiki技术。当wiki在2003年8月传入国内时，wiki被习惯性的译成了维客。
“木子美让博客概念在国内一夜走红，而维客很有可能是第二个博客”，独立网络开发者李安科喃喃道。实际上维客并不是一套复杂的系统，它与博客在思路上大有殊途同归的意味。博客完全是个人式的文字收集，博客的阅读者仍旧是被动的接收信息，如果对博客主人的某个观点不满，最多也只能在文后附上几句话抵触的评论，而在维客中，每个人既是阅读者，同时又是书写者。从技术角度上看维客不过是一套可以任意编辑的网络白纸，任何人都可以在一段别人写过的内容上编辑加工，也能够按照一定技术规则和文化脉络组合模仿。《商业2.0》将维客形容为社群协作式写作，在他们看来维客必将是群体性知识总结归纳的最优化模式。台湾地区维客组织管理员凌信路接受采访时介绍说：“在维客上任何人都可以自由编辑别人的东西，自由开放的气氛保持的很好，所有那些喜好搞恶作剧在维客上都很规矩，他们生怕任何言辞冒犯了维客群体的开放共享氛围”。所以在维客上你见不到刺刀见红的争论，也见不到任何网络世界常见的尔虞我诈。
“维客简直是天然的百科全书模式”，日本维客龄木久色在接受NHK采访时说。实际上仿照国外Wikipedia的中文维客百科刚刚开张，整个维客百科系统完全就是一套百科全书的架构，任何人都可以对自己了解和感兴趣的领域开新百科分支，并且把自己收集的资料书写上去。维客李安科说道：“我作为骨灰级玩家在中文维客百科上添加了电子游戏的部分，并且书写了不少的内容，但却阴错阳差把名称对应错了，两天后后悔不迭去修正时，却发现已经被别人修改过了。”而在维客百科上，对于“导演”一词的解释就前前后后被改了多次，最初的维客还按照《中国大百科全书》的说法：“把文学剧本搬上银幕使其成为影片的主要艺术家”，但是没过几天，导演的解释就被改成了“导演都是大流氓”。这就是维客的本色，是一个共同创作各抒己见的社区，在维客的技术架构里面并没有等级分明的权限设置，不会让你注册然后输用户名和密码，也不会记录你的IP。因为维客们都信奉没有锁的门是最不怕被撬的门，这句英国古代谚语。
正是因为维客能够坚持自由、共享、信任和免费的原始精神信条，从2001年开始，英文维客百科已经有了超过18万个词条，维客借助普通民众的力量，还在不断的扩增，信息词条越来越接近6张CD容量的微软电子百科全书了。而且维客对于新兴词语的反应速度也很快，正如杨百翰大学语言学教授赛弗·恰克在接受《商业2.0》采访时说的，“维客对于语言词汇的积累是空前的，被维客们归纳的知识在彼此间不停的共享”。除了在百科全书的成功之外，维客技术也被引入到商业领域，即将纳斯达克上市，且预估市值高达400亿美元Google内部就是用维客系统沟通，甚至摩托罗拉公司也把维客引入到公司内部的知识管理中来，《商业2.0》引述Google创始人拉里·佩奇的说法：“维客上涂涂改改的便捷非常适合现代管理制度下的职员交流，维客可以打破企业内部各层隔阂，让那些靠压制手段来管理的主管们被群体智慧淹没”。
对话专访：听Ward Cunningham细述Wiki之前世今生
记者/Bill Venners
在软件社区中，Ward Cunningham享有思想源泉的美誉。他发明了CRC Cards，这是改进对象发现的一种技术。为了促进软件模式的发现和编档，他发明了世界上第一个wiki，一种基于web的协同编写工具。最近，许多极限编程（Extreme Programming）技术背后的主要灵感也被归功于Cunningham。
在2003年9月23日于丹麦Aarhus召开的JDOO大会上，Bill Venners遇到了Ward Cunningham。在这次访谈中，Cunningham深刻剖析了使用wiki协同探索和极限编程的几个方面。
在第I部分“使用Wiki探索”中，Cunningham讨论了使用wiki协同探索以及wiki作者和读者之间的权衡。
在第II部分，Cunningham讨论了他如何把wiki设计成这样一种模型：集体代码所有权、以所有权而自豪的集体激励以及通过消除犯错的代价来解决纷争。
在第III部分中，Cunningham讨论了变更成本曲线的扁平化、预测未来的问题以及像艺术家手中的泥巴那样塑造程序。
第I部分 使用Wiki进行探索
为什么需要Wiki？
Bill Venners：您发明wiki的最初目的是什么？
Ward Cunningham：我创建wiki要完成几件事。第一个wiki的初衷是要建立一种环境，我们能够交流彼此的经验，从而发现编程的模式语言。我以前曾经使用过HyperCard组，它基本上也是为了类似的目标。我知道人们喜欢使用那种HyperCard组来阅读和创作，但它是单用户的。当开始PLoP（编程模式语言）系列讨论会的时候，我们认识到我们真正想要做的是开始编写一部新的作品，我认为我需要使用HyperCard组，并希望能找到一种应用于web的等价物。
对于wiki，我还有更多通用的目标。首先，人们常说“人人喜欢讲话”，我认为这里面有一种令人信服的人类本性。在创建wiki时，我希望激发每个人喜欢讲故事的天性。其次，也许是最重要的一点，我希望不经常创作的人们会发现创作非常轻松，这样就有机会发现创作的结构和方法。
Bill Venners：wiki如何使创作变得轻松？
Ward Cunningham：不熟悉写作的某个人可能有一个想法，这个想法值得写成一段。他们本来可以为杂志写一篇评论，但是一段文字太短了。为了给杂志撰写文章，他们不得不介绍一下背景，讲述某些重要的东西，而且要以多数人都能理解的方式讲述，然后结束文章。太复杂了，多数人都不愿意花费那么多的精力。
但是如果您正在阅读别人的作品，并想到“是的，但是还有一点”可以放在一段中这样说，“啊，不错，但实际上还有……”在wiki上有很多这种类似于“对，但是……”的对比想法。讨论组也作了同样的事情，但是在讨论组中这些对比都丢失了。
Bill Venners：为何在讨论组中丢失了？
Ward Cunningham：因为没有上下文，无法持续下去。讨论组往往反复围绕着同一个话题，但是人们忘记了以前说过什么。我认为，常见问题解答（FAQ）的发明就是针对这个问题的。很多时候，读一读FAQ要比参加讨论组更有意义。在一开始做wiki的时候，有一个系统叫FAQ-O-Matic，它和wiki的想法一样，只不过其真正的目的是制作FAQ。我看到它的时候就想“哦，英雄所见略同”。不过我接下来又想，“不，我更喜欢面向文档的形式而不是问答形式。”在我们的作品中想要创建的模式是某种类似FAQ的东西，但应该不止如此。现在，wiki上可能有10,000到15,000种模式，25,000页文档。
Bill Venners：您认为wiki适合做什么？wiki的高明之处在哪里？
Ward Cunningham：如果您试图回答一个不容易阐述的问题，事先不了解某种应该知道的自然结构，wiki会非常有用。对于像“项目进展如何”之类的问题，我们可以设计一个数据库。但是数据库中要放哪些字段还要归结到对项目进展问题什么是重要的。关于项目的哪方面重要这些资料是不可预见的。
Wiki页面的格式非常自由。在整个wiki中有一个超文本结构，但是在一个给定的页面上，在自然语言灵活性的许可范围之内，您可以讲任何想要述说的东西。因此，wiki是跟踪项目进展状态的一种良好方式。比方说，您可以把我的模式作品看成是一个长期进行的项目。我们不知道终点在那里，但是我们希望在进展中发现它。
此外，wiki也非常适合于想要把控制权交给系统用户的环境。在wiki中并没有多少何人何时可以做何事的逻辑，因为wiki并不真正理解您在做什么。它只是为您保留页面。关于什么是适当的用法什么是不好的用法，已经建立了大量的惯例，但这些都存在于用户的头脑中，而不是在应用程序的业务逻辑中。如果您有一个可靠的团体，不谋求通过计算机强制某种行为，wiki就可以很好地工作。比如，有人曾经问我wiki是否适用于协同环境。我认为某些公司对它们的雇员完全具备这种信赖，某些公司则没有。不信赖雇员的公司可以根据某些需要维护一个web站点而不是wiki。
把握大局
Bill Venners：读者如何把握wiki上的总体内容？
Ward Cunningham：首先要理解，因为我们使wiki更方便作者，实际上就增加了读者使用的难度。里边有某种组织方式，这种组织方式还可以改进，但它不是组织严密的。因此读者就会感到仿佛是在茫茫的一片信息片段中搜寻。偶然发现一段很好的信息，于是就想，“好极了，为什么没有人哪怕只是把那些好的片段作一个清单，我就不用再搜索其他的部分了。”换句话说，“为何没有人组织一下，让我迅速找到问题的答案？”早晚他们的想法会得到实现，“哎呀，行了！”他们花了一个月或者两个月查找所关心的东西，然后做一个页面，wiki组织成什么样子由他们自己承担。
我不是一个分类的痴迷者。如果感兴趣的事物不符合需求或者不是预期的，定义一个有用的分类方案非常困难。不过有些人认为每个页面都应该带有分类。他们带着一个分类方案，根据页面的名称，为wiki建立分类结构。这些注重分类的人负责维护它。如果某人创作了一个不能归类的页面，其他的人就会说，“哦，这应该归为wiki保留页面或者设计模式。”
Bill Venners：如何把一个页面归类为wiki保留页？
Ward Cunningham：只需对一个叫做WikiMaintenanceCategory的页面进行引用。单击该链接时，就会转到那一页，对这种分类进行解释以及为何有这一类。因此把页面归到某一类，习惯上是增加到该类别描述页的链接。这样标记了该页。如果要了解这一类是什么，可以沿着链接到类别描述页。如果要看看这一类中有什么页面，可以搜索引用该类别页的所有页面。
Bill Venners：我猜想搜索也许是研究新wiki的一种方式。从一定意义上讲，wiki类似于一种小型的internet。 一切都分散在各处。如何发现正在寻找的内容呢？我可以从搜索关键字开始。
Ward Cunningham：是的。任何名称以“Category”结尾的wiki页都是一个值得搜索的条目。可以通过Google搜索小说，但是如果有人不把作品标记为小说，就找不到它。分类系统是一组页面，解释分类的基本原理，可以读读这些页面。它们使用了名称空间的一小部分——所有这些词都以“Category”结束——并建立了这些页面涉及其他页面分类的实例。非常棒。还在发展中。如果我要做一个解决方案，可能会非常简单，甚至同样好。我最喜欢的一点是，有一个非常积极的社区在管理这些分类。有时他们把分类搞错了，但很快就会纠正过来。
Wiki中的时间要素
Bill Venners：您所说的有点让我想起“自由讨论”。您把一些人集合起来充实那些您还不完全清楚的事物。
Ward Cunningham：Wiki有点像“自由讨论”，尽管不是交互式的。您可以做10分钟的自由讨论，用30分钟分析自由讨论的成果，然后在45分钟之内完成某件事。Wiki的脚步要慢一些。您可以就某个观点写一个页面，或者就很多想法写一个页面。然后在一周之内回来看看页面上有什么进展。但是如果在15分钟之内回来，不会发生太多的变化。Wiki上的事情是以天或者周为周期的，因为人们往往每天或每周浏览一次。
Wiki中有一个有趣的时间特性。读新闻组或者邮件列表时，会有一种感觉，当前就是您在列表中的位置。我不希望wiki中有一个时间表。当在读wiki上的某些内容时，我不希望时间会影响您，不论它是一年前写的还是一天或者一分钟前写的。这意味着我们需要通过某种方式得到上下文。
如果您正在编写一个页面，那个页面必然和其他某个页面有关。因此所要做的就是，在一个段落中说明其他页面中哪一些是关于这个上下文的。人们逐渐熟悉这些页面的名称。他们遇到一个新的页面，阅读包含对上下文页面链接的段落。如果已经度过这些页，就继续读下去。如果不知道这些页，他们就会说，“哦，这一页没有什么意思。我还得读一读其他的页。”这样如果您了解上下文的话，就不必再去看了。但是如果不了解上下文，您可以去看一看。上下文不会变。
Bill Venners：听起来似乎您必须了解wiki站点。过一段时间后您就会熟悉它了。一开始可能会令人感到困惑，也没有多少提示，您进来发现到处都是这样的内容，但不一定是根据读者的需要组织的。
Ward Cunningham：对，wiki总是在不断地组织中。每花费一个小时组织，都要花费另外两个小时来增加新的材料。因此wiki的总是处于半组织化状态。
Wiki 和可读性
Bill Venners：我确实非常喜欢wiki的思想，但是我发现阅读许多wiki页非常困难。可读性的问题是我一直没有在Artima.com上增加wiki的主要原因。Artima.com也是一种基于web的协作文档，但是更加结构化。在wiki中没有专职编辑为读者组织材料。所有的页面都是协作性的。结构是协作性的。编辑是协作性的。从wiki的协作性中有什么足以抵消可读性的损失？
Ward Cunningham：作为wiki读者，您能够获得以前没有发言的那些人的观点。听我们发言的人对于怎样编写和发布计算机程序有直觉的想法。我们这一行在发表过程中对传统保留了某些尊重。比如，如果您想为一本科学杂志投稿，应该经过同行评审。同行评审的一部分是你应该熟悉所有其他作品。而其他作品可能纠缠进某些细枝末节。关于编程的作品有时并不符合程序员的实际感触。有了wiki，没有时间学习写作并在杂志上开辟专栏的实践程序员，就有机会讲出那些对于他们来说是重要的事情。Wiki提供了一个不同的视角。事实上，您可以分辨出一个人是在wiki上根据自己的经验创作，还是转述刚刚读到的东西。
Bill Venners：那么您怎么分辨呢？
Ward Cunningham：您可以根据他们谈论事情的方式来区分，比如“Mary Ann就是做不好这一部分。”这不符合科学传统。如果有人引述某位作者的话，“某某怎么说，你这家伙怎么听不明白”，有人在赞美他所读的书。另一方面，如果有人说，“您知道，在以前的三个项目中我们都尝试过，但一次也没成功，我们只能用别的办法摆平它。”有个家伙解决了这个问题，他正在跟我谈一些深刻的问题。如何解释要靠我自己。这只是他的经验。然后您可能还会看到其他几段文字，“是的，我也遇到过，我用这种方法搞定了。”那么现在就有两种方法了。突然之间，您开始与解决了软件问题的人交流了，而不是和谈论解决软件问题的人交流，这有很大的不同。
第II部分 代码和文本集体所有权
集体的代码和文本
Bill Venners：极限编程（XP）的集体代码所有权特点让我想到了wiki，在wiki中，每个人对所有一切负责。
Ward Cunningham：这样做完全是有意的。在设计wiki前的几个月中，我们有过一次争论。我认为Kent Beck和我站在一边。坚信主流软件工程教条的那些人站在另一边。我们说“集体代码所有权很好。”他们则说“太荒谬了。没有职责划分，而没有责任就决不会有质量。让他们避免制造缺陷，就必须把缺陷和某个人挂钩。”我说，“完全不对。”
我设计wiki的决定，很大程度上受到建立一种协同过程模型的渴望所启发，我认为在大型代码库中应该有这种协作。我希望wiki能够模拟这种情况。比方说在一堆代码中有一个问题。您知道怎么解决问题，但是解决需要涉及到大量模块。重构需要大量艰苦的工作，如果要同每个最初的作者协商就更加困难。你只是希望改正问题。
困难在于代码可能是按层次结构组织的，但是解决方案可以从多方面来考虑，而不止是某种层次结构。因此当您在某一方面发现一种贯穿整个层次结构的解决办法时，您只能随着解决方案的要求，在适当的地方加入解决方案。我们经常发现自己处于这样一种境地，人们了解这个程序，但是他们不能将这些知识应用于程序。为什么？因为知识的发展和在拥有这些知识之前做出的某些组织决策相冲突。换句话说，程序抗拒知识的积累。
Bill Venners：抗拒？
Ward Cunningham：程序对某种类型的知识有抵抗力——没有预计到的知识——因为很难在一开始就设立的结构内表达这些知识。很难把不符合这种结构的任何东西加进去。
Wiki中也有一点对预料之外思想的抗拒，但这种抗拒主要在人们的实践中。Wiki中写进去的东西越多，对自身权利的要求越严格，但是如果有人要修改而且到第25页去修改，他们就可以去25页。
比如，在wiki中，发生的某个过程是页面从讨论发展成短文。许多人愿意阅读讨论。那些每天访问wiki的人希望看看昨天又说了什么，因此需要按时间组织的页面。但是对学习而言，投稿先后顺序并不是一种很好的组织原则。因此页面总是保持某种讨论之中的感觉，直到这个讨论结束。后来，有人又回来阅读了这些讨论，把您可能称之为线性模式的页面重新组织成文档模式的页面。
如果在注解之间转来转去，而且有许多类似的彼此相邻的注解，您经常会发现可以去掉一大半篇幅。因为只要位置适当，一句话可能就说明白了。在Ward的wiki上，这个过程被称为“重构（refactoring）”，就像我们在软件中那样称呼这个过程。Ward的wiki是关于软件的，其中有许多从事软件的人，因此称为重构。在其他地方可能就会称为“编辑”了。在Ward的wiki上，重构是一个持续的过程。设想如果某些地方被证明不很合适，就要再次进行重构。一切都是重构的目标。这也是我们愿意在软件中所看到的。
软件的优势是它有明确的解释。因为软件是为机器编写的，我们可以依靠精确的解释编写测试。在重构程序时，我们可以测试没有破坏或者丢失的任何东西。但wiki是为人类编写的，没有精确的解释。我可以说，“哎呀，我可以把这个句子放在这儿，并砍掉一半，因为在这个上下文中很容易理解。”但是我可能错了。对于我容易理解，但可能对其他人很难，我也没法做测试。因此在重构过程中，我们可能会丢失wiki上的某些信息。Wiki像一个信息漏桶。它每天都在丢失信息。但是有更多的信息加进来，因此净结果是正的。即使丢失了某些东西，wiki总是比昨天有更多的内容。
高质量代码的集体激励
Bill Venners：从您的描述中我了解了集体代码所有权的好处。但代价是什么？集体代码所有权的缺陷是什么？
Ward Cunningham：我相信有一些缺陷，但是现在还没有想到。
Bill Venners：所有权的自豪感又如何？人类适应集体自豪感吗？在您自己创建什么时，总是希望把它做好。
Ward Cunningham：我认为集体所有权实际上更好一些。是的，我对自己所做的事情感到自豪。对于我而言，自豪感是一种激励。通过集体所有权，我们基本上建立了一种小型的社区，训练他们自我肯定所做的工作。但如果归我所有，人们就会说，“那是Ward的模块，我不想看Ward的模块。”如果必须调用Ward的模块，他们可能会喜欢该模块的API。我的模块缺陷率很低也许会给他们留下印象。不过他们可能会说，“他的模块很简单。他有一个容易编写的模块，这就是为何他的缺陷率这么低。”他们不会知道真正的原因。
当人们使用我提供的材料时，他们会感觉到是否容易使用。所谓使用材料，我是指拿来代码调整，以便做更多一点工作或者稍微改变其功能——这些代码应该做的任何事情。当人们使用代码时，他们会看到我努力完成的一些事情，否则的话他们永远也不会注意到。不需要迫使他们说“Ward你很了不起”，但有时候他们会说，“Ward你很了不起。”这就满足了我的自负感。所有权的自豪感？的确如此。
现在，不需要在每一行上写上我的名字。事实上，这证明如果它确实很好，可能是因为他们做得好，而不是我。我可能只是做了一个计划，然后他们完成了而且完成得很好。我可能会受到不应得到的荣誉，不过他们也可能把赞誉送给别人。一个想法来自谁，荣誉应归谁，这种观点是弹性的。但我认为人们在知道谁参与其中的时候，可以很好地解决这种弹性，承认每个人的贡献。通过集体所有权，我们建立了一种社会环境，通过源代码语句中迸发的智慧可以了解一个人。
Bill Venners：集体所有代码的这种特点为何不能出现在wiki页面上，wiki页面上的内容有时候显得有点乱？
Ward Cunningham：我肯定也会这样。
Bill Venners：您刚才谈到某一行代码是谁编写的并不总是很明显。对于wiki页面也是如此。谁写了某一行文本也并不总是很明显的。有时候一个人在wiki页面上写了一些东西，“我有这样的经验”，而作为读者我并不知道这个“我”到底是谁。集体代码所有权和集体文本所有权相比有什么不同，您刚才只谈到了代码而没有涉及文本？
Ward Cunningham：我认为不可预料的代码是很常见的。代码可能能够工作，但如何工作本质上是秘密的，不可能阅读。事实上，这也可能是一种常见情况。因此混乱可能不够确切，应该是不可读。我有与他人长期结对编程的经验，在读到他们的代码时，甚至认为是自己的代码。但在wiki上还没有出现这种情况，我读到某人的文字而认为是自己写的。这可能是因为代码具有更高的组织性，但我认为更可能是因为代码交流的范围更狭窄。代码交流的范围仅限于某种过程的计算机化，而谈话的最佳方式是相当广泛的。这样就会导致和英语相比，代码会更快地具有稳定的组织性。
解决纷争
Bill Venners：在“Extreme Programming Explained”一书中， Kent Beck写道，“集体所有权增强了在项目中对个人能力的认知。您不会永远钉住别人的蠢事不放。您在途中发现了某些东西，然后把它排除掉。”对于什么是蠢事如果不同人的看法互相矛盾时该怎么办？所谓蠢事不是一种主观的评价吗？
Ward Cunningham：啊，我决不会这样说。当我认识到不需要赢得每一次争论的时候，这是我编程生涯中的一个转折点。我正在和别人讨论代码，我说“我认为最好的做法是A”，他们则说“我认为最好用B”。我说“不，应该是A”，他们则坚持说“我们想用B”。当我能够这样回答的时候，对我而言这是一个转折点：“好吧，用B办法。如果我错了这样就不会损害我们。如果我对了，而您用B办法也不会造成多少损害，因为我们可以改正错误。让我们看看这样做是否错了。”
我们不要把自己看成非常幸运的预言者，要求自己预测未来。最好是建立一种环境，这样您就能够试一试B并看看发生什么。现在证明争吵通常是无益的。无论谁编程，都可以自由选择编程的方式，这样就足够了。当然有时候也可能会证明争论是有用的。我们正在做别的事情，看了看说，“您知道，用在那里并不合适，因为B确实不符合。”而这个问题可能是我在宣传A方法时正好考虑到的，也可能不是。它可能是开发人员在方法B的上下文中硬塞进去的。但有时候您了解这些缺陷或者难以改进的地方。于是开发人员说，“你知道，这些代码令我感觉不舒服。”我说“好吧，我可以解决这个问题”。他们问道“您行吗？”我说，“当然，我可以解决这个问题。您做了B，我就使用B。”然后我就可以开始处理它，只要可能就尽量使用B。但是因为承担了职责，我就有机会使它实现需要的功能。
Bill Venners：您是说再回到A。
Ward Cunningham：如果需要的话。
Bill Venners：也可能是到C。
Ward Cunningham：通常会变成C。对于我们双方这都是一种学习的经历。如果没有这种经历，我们就都没有学到什么。Ward赢了，其他人输了。或者相反。这和一场战争差不多。为什么不说，“好吧，让我们编码看看怎么样。如果不行的话我们再改变。”
我无法告诉你我花费了多少时间担心无关紧要的决策。如果能够做一项决策，然后看看结果如何，当然会大大减少这种担忧，但是这意味着您必须建立一种环境，当确实出问题时可以修正。如果某些事情确实出了问题，不会浪费您和您的客户过多的成本。这不是一种可笑的花费。如果您处于不能承受错误的情况下，就很难做正确的事情。因此如果尝试做正确的事情，正确的事情可以抵消犯错误所造成的代价，要远比猜测什么是正确的好。
比如，在一个项目中我们通过经常升级抵消了错误成本。我们是通过建立一个相当精细的数据库模式演化机制实现的。。我们曾经每周发布一次，每周都修改模式。我们可以为不同的客户根据不同的要求对模式作不同的修改，把这一切结合起来最终得到正确的结果。因为我们每周都在做，大约六周或八周以后，我们就确信我们可以完成它了。我们从没有担心过。多数人都说，“无论做什么，千万不要做模式演化除非你已经做了。”但在项目结束的时候，他们说，“天哪，我们真的做到了。”因此在从来没有做过之前，他们说，“只要我们去做，就让我们做完它吧。”他们做了一个巨型项目，以前从未有这样的经验。你猜怎么样？他们错了。相反，我们每周都在做。每周做一点。我们确实从中受益了。我们永远不会害怕它。它也从来没有出现问题。
因此我们不是通过说“我们要做的工作性质就是这样”，从而通过抹去问题来解决问题。要是这么简单的话才是真的奇怪了。实际上更多的是提问的方法，“您希望擅长什么？”，如果您希望擅长它，就找出一种方法来每天应用它。如果每天都要应用，那么就只能熟练掌握了。因此，选择您希望擅长什么。您应该擅长您所害怕的东西，这样您就不会再害怕它了。
第III部分 塑造程序
变更的成本
Bill Venners：在“Extreme Programming Explained”一书中，Kent Beck写道，“软件工程中一个普遍的假设是程序修改的成本随着时间呈指数级增长。”并建议说，“通过技术和编程实践的结合，有可能得到一条方向相反的曲线。”怎么能够实现变更成本曲线的扁平化呢？
Ward Cunningham：传统上来说，变更成本曲线告诉我们，早发现变更的需要与晚发现这种需要相比，进行变更所花费的代价越小。我批判了这种曲线，因为根据这种理论，我们差不多可以故意犯错，然后在实践中改正错误，这样有助于减少以后变更的成本。
我们认为，任何变更的决定因素不是何时进行变更，而是需要做多少思考。如果我们每周做一次变更，而理解我们的真正需要花费了两天，那么做这种变更就需要两天。如果我们每21周变更一次，理解我们的真正需要也花费两天时间，那么这个变更也用了两天。
在每周一次的变更中，我们可能要写20条语句。在21周变更一次时，我们可能需要写20条语句并修改4条语句。但是如果您习惯于变更，修改4条语句也花不了多少时间。只需要找到那些语句并修改它，可能只需要1分钟。
因此理解变更的需要是决定性因素。编程实现变更并不重要。只要我们理解了变更，我们就可以编程实现，或早或迟。修改代码的实际成本并不在编程中占有主导地位。主要的成本是理解所花费的时间，这就给出了一条趋向平缓的变更成本曲线。
许多人害怕变更，是因为尽管在编写的时候还理解代码，但这种理解很快就消失了。他们对你说，“我们为这些语句费尽了心血，无论如何不要改变这些语句！”他们并不想回到原来的代码，因为重新理解太费劲了。因此使变更成本曲线扁平的另一种方法，即以后变更的成本不会比现在更大，就是确定人们必须能够看到他们将要改变什么并理解它。因此，当你在编写代码时，你就会更多地为将要阅读代码的人编写，而不是为运行它的机器编写。
同样，你也不愿意编写大量的注释，告诉别人如何进行他们所需要的修改，因为您并不知道他们要进行何种修改。最好抱有这样一种观点，您不能帮助将来的程序员进行修改。您所能做到的就是使他们容易理解您努力去做的事。如果您非常小心，避免做太多的事情，这样最有助于他们理解您的努力。您试图完成的功能越多，将来的程序员要理解您的代码就越困难。
比方说，如果您明显地忽略了一种情形，以后的程序员需要解决它，他们打开代码发现您显然是忽略了这种情形。这意味着他们可以自由实现需要的任何功能。但是如果您试图应付这种情形，他们来了首先要确定哪里不工作。他们将看到您试图解决这种情况，因此他们首先要尝试理解您在做什么。一旦理解了您要做什么，他们就可以指出如何修改以实现需要的功能。他们更愿意接手的时候发现您甚至没有考虑到这一点。也许您想到了，但完全没有对此编程。
对未来的预测
Bill Venners：每个人都同意预测未来是很困难的，但预测总是这么糟吗？
Ward Cunningham：在科学中预言未来很简单。科学建立在对物理系统行为研究的基础上，被证明具有惊人的可预言性——可能天气除外。我们已经能够向太空发射火箭并使它沿轨道运行，这是预测的一个范例。但是当开始谈及对未来的期望时，我们可能有某些直觉，这些直觉也许是对的，但不会总是对的。我们必须考虑到不正确的情况。
当一个新的需求出现时，我们看了看说，“好的，这不难。这个程序就是为它而作的。”我们在程序中加入一些代码，然后就成了——我喜欢这样。我讨厌这种情况，新需求的出现不能很好地满足，仿佛程序的设计就是为了和需求作对。这种情况下，我们有大量的工作要做。但是这项工作的性质要求首先修改程序使它更容易适应新的需求，然后把新的需求包含进来就很容易了。换句话说，不是为新的需求在并不适合这种需求的结构上打补丁，而是全力以赴做艰难的任务修改结构，使它能够很容易实现这种需求。打补丁的办法意味着，后来者不但要理解并非为这种需求设计的系统，还要理解试图弥补但不改变系统的那些补丁。最好是修改系统以便很容易适应新的特性。
有人也许会说，“为什么不向前看一看，了解我们必须做到的所有工作呢？为什么不从一开始就把系统设计成使所有工作更方便呢？”如果您能够实现这样一个系统，那真是太好了。正是这样，人们一次又一次地试图设计系统使明天的工作更容易。但是当明天到来时，却发现他们并没有很好地理解明天的工作，实际上他们使明天的工作更难了。
意外的体系结构
Bill Venners：为了批驳变更成本曲线，您发现了一种方法可以在项目的整个生命期中进行变更。这就使得对将来的计划不那么重要了，因为可以在以后真正需要展开的时候进行变更。整个体系结构仅仅是在每次只关注一小步的过程中逐渐浮现出来的吗？
Ward Cunningham：我喜欢塑造程序这种说法，就象艺术家塑造一团泥巴一样。艺术家想做一个雕塑，但是在开始雕塑之前，她只是把泥巴揉来揉去。她开始逐渐塑造成形，并看到泥巴要成为什么样子。揉捏得越多，泥巴就越像她希望的样子，最终变得完全符合她的想法。
一个开发小组用了数月编写一段代码。最初，他们做了一段代码，有点僵硬。代码很短，但仍然有点僵硬。他们搅动这些代码，代码稍微变软了点。在上面提到的一个项目[第II部分]中，我们向数据库增加了模式演化功能。它软化了程序，变更容易多了。每次变更模式时，我们都作一点改进。程序员和代码——作为一个整体——都软化了。我们塑造程序并保持它的柔软性。
在项目结束时您已经完成了需要做的所有事情——有人为之付钱的所有功能——您看了看代码问道，“这一堆东西中的核心是什么呢？这是怎么完成的？我们日复一日地编写程序，它是怎么结束的呢？”通常程序的结束都是令人惊诧的。您会说，“这是一种优美的结构。”那么体系结构又从何而来呢？
在这里，体系结构意味着我们处理不同需求的系统化方式。当我们根据需要塑造程序时，体系结构使我们能够发现进展到哪里了。融入程序的是一个系统，包括我们所做的每一个小决策——正确的小决策，错误但改正了的小决策。从某种意义上讲我们得到的这个体系结构并没有经过尝试。在其他决策上下文中的所有决策凝结成了一种体系结构。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack