豆豆的图书主页-查字典图书网

2009-11-24

       今天我看了第19章的内容，主要是讲：一对夫妇创业的项目是“永不终止的游戏”。

      在创业的过程中，通过一些想法+将想法用于实践中，发现游戏中的图片分享能力，比游戏本身还要受到欢迎。它们放弃了游戏项目，转而全心全意去经营“Flickr”公司（图片分享公司）……

      有人说：“创业是要靠运气的。”看到这个创业故事，我觉得是“运气”是靠干出来的。在不断的尝试中，发现这样的“运气”。

      这次访谈的主角是一位女性，有点女强人的味道。她被问到创业的感受的时候说道：“在我看来，人们创业起步时期最大的风险之一，就是他们本身所固有的不稳定性……”

      以上是我看到第19章内容的感受。欢迎看过的朋友也说一些感受。

这本书的中文版快出来啦~~~~

2009-11-11

我们出版社已经拿到这本书的版权，目前翻译工作已经结束，正在修改译文中的错误。

如果，大家有什么想法及建议，欢迎大家提出，谢谢！

此书的翻译体会

2009-07-10

      很多人都知道微软公司，它依靠软件变得非常富有。关于微软是如何从一个只有十来个人的小公司成长起来的故事，很多人都听过。听了后，不少人都觉得它很幸运。那么除了幸运之外，微软还有什么过人之处么？很基本的问题，它是如何开发软件的呢？这个问题容易回答，很多人都能讲上几句。但如果只是讲讲有哪些“工种”，立哪些规矩，也很乏味。要是能从头到尾的讲讲一个很大的产品是怎么从无到有开发出来的，该多有趣。

       微软的软件产品很多，但是在其产品线中，起着中流砥柱作用的当属操作系统，即Windows，中文称视窗。Windows有众多版本，但不论是Windows 2000、Windows XP、Windows Vista，还是即将问世的Windows 7，都是基于经典的Windows NT内核。NT内核从1988年开始酝酿，1989年开始编码，历时将近五年，于1993年7月正式发布，即Windows NT 3.1（在本书中简称NT）。通常，软件的版本号是从1.0开始的，但NT的第一个版本就是3.1。

      NT的最初开发计划是18个月，但实际用了快5年，是计划的好几倍。软件项目延迟是常有的事，但延迟了这么久还没有被枪毙掉也是有些不寻常的。在行业外的人看来，编写软件的人，特别是所谓的高手，大多有些古怪之处。NT团队最初只有几个人，结束时发展到两百多人，其中一定不乏特立独行或者离经叛道之士。这些人聚到一起，吃顿饭都可能争吵起来，何况要像绣花一样合作写软件呢，而且是写操作系统这样的复杂软件。

       弹指一挥间，距NT团队成立的日子差不多20年了。亲历过那段“美好的旧日时光（the good ole days）”的人，都早已声名显赫、腰缠万贯了。请他们讲一下从前的故事，不是一件容易的事。
那么如何满足一下好奇心，或者冠冕堂皇一些，“师夷长技”呢？幸运的是，有一本书很好的记录了开发NT的全过程，它是用英文写的，名字叫《Showstopper》。

       “Showstopper”这个英文单词很有趣，在观看戏剧或者其它演出时，人们使用这个词来形容节目格外精彩，让人拍手叫绝，以至于被观众的掌声和喝彩声所打断，不得不等人们安静下来后才能继续。在日常用语方面，它也是一个很好的词，人们用它来形容超乎寻常的美丽和迷人……
但当这个词被引入到计算机特别是软件领域后，它的含义发生了根本性的变化，它代表的是最严重的问题。因为在软件领域，人们经常使用臭虫（英文为BUG）这个词来称呼软件中的瑕疵或者问题，并根据严重程度，将臭虫分成若干个等级，而“Showstopper”用来指最严重的那类臭虫，它如此严重，以至于影响了产品的核心功能，不解决它产品就不能用。如果是在开发阶段，Showstopper的存在会导致产品就不能发布，其它很多工作也无法进展，整个项目不得不延期……

     《Showstopper》一书以时间为主线，生动了描述了开发NT的整个过程，讲述了5年中的很多精彩故事，特别是NT团队如何解决开发中的Showstopper类问题的动人情节。开发软件不是一件简单的事。分析需求、定义功能、设计架构、编写代码、测试集成……，每个环节都不容易做。但难度最大的，最难以控制进度的，其难度又经常被低估的，就是定位和去除臭虫，也就是所谓的软件调试。如果把计算机系统中的每一个比特位看作是一个水滴，那么今天的典型计算机系统就都是一片海洋，定位臭虫的过程就好像是在这个海洋中捞针。而去除Showstopper类型的臭虫，更是难上加难，因为这样的问题往往关系着整个产品或项目的成败，关系着很多人的事业和命运。

      在介绍紧张的开发过程的同时，作者用简炼的笔法，为我们描绘了一大批个性鲜明的人物，包括他们的学习工作经历、性格、家庭、婚恋，以及他们面对困难和压力时的反应。在作者的妙笔之下，几十个人物跃然纸上。他们有些是公司的管理者，有些是项目经理，有些是团队的技术首领、小组长，有些是普通的程序员、测试员、构建员和技术编辑。他们各司其职，为共同的目标努力，尽管也有争执、摩擦、甚至冲突……

      我在四年前买了这本书，放在案头，有空的时候就拿起来读一读，有些内容读了很多遍，但是每一次都有新的感受，能受到不同的启发，有技术方面的，有项目管理方面的，也有处世和人生方面的。
2005年的时候，我开始写一本软件调试方面的书，旨在帮助人们提高去除软件臭虫的效率。在写作过程中，我还经常拿起

      《Showstopper》，有时是为了小憩一下，有时是为了汲取灵感。有一天，我突然冒出一个想法，为什么不把这么好的一本书翻译成中文，让更多国内的读者可以看到呢？于是我开始想办法联系书的作者。费了些周折后，终于找到了两个邮件地址。于是便写了一封简单的邮件，发了出去，时间是在2007年的5月8日。信写的不是很长，因为担心作者收不到，白费功夫。没想到，第二天一早我就收到了回信。信落款处的署名是Gregg，也就是作者全名G. Pascal Zachary中G的完整形式。Gregg格说，他很高兴收到我的信，愿意让他的书在中国出版，末尾他还说：

     Plus, Chinese readers are keen on books about management of tech projects.（此外，中国的读者很喜欢如何管理科技项目的书。）
是啊，这何尝不是一本软件工程管理方面的好书呢？尽管大多时候我是将其当作报告文学来读的。

       接下来的问题就是找一家国内的出版社。这并不像我预想的那样顺利。前两次尝试都很快就失败了。过了几个月后，又有了第三次机会，为了让这次机会成功的可能性大些，我特意邀请了两位编辑见面来谈。我先是花了些时间告诉他们这不是一本专门介绍技术的书。然后我讲了书中的一些精彩内容和这本书对于程序员、测试员、项目经理、公司老板以及历史爱好者的意义.在我滔滔不绝、激情澎湃的讲了一个多小时后，两位编辑有兴趣了，想看一下这本书，然后推荐给社里的领导来审判。过了几周后，我得到了答复：社里的领导不同意。这时已经是2007年底了。当时，我自己写的书已经完成了大半，在写第5篇——“软件的可调试性”时，我很自然地想到了《Showstopper》中的故事是一个很好的案例，征得了Gregg的同意后，在我的书中有了“Showstopper和未雨绸缪”这一节。

       2008年初，我又向另一家出版社推荐。这次很顺利，出版社很快决定购买版权。2008年3月，Gregg很高兴地发邮件告诉我他已经和中国的一家出版社签约了。之后的一些细节又花了些时间。2008年秋，《Showstopper》的翻译工作开始了。

        翻译难。尽管在打算翻译这本书的时候就预计了这个任务会很难，但是实际感受到的难度还是超出了预料。这本书的作者是《华尔街杂志》的著名记者，也许是因为写惯了针砭时弊的新闻稿，他的文笔很是犀利，用词泼辣，豪放不羁。不管是书中的小人物，还是大人物，作者都不加任何粉饰，直言其原貌，甚至缺点，毫不留情。另外，为了力求生动，作者在很多地方使用了口语化的描述方式，用了很多俚语和固定用法的短语。这些特点，使这本书让人读起来感觉很是过瘾，但是却给翻译带了很大的挑战。很多俚语和短语是词典里查找不到的，有些即使能查到，但是词典上给出的词意看起来也不符。更何况，如果完全照搬词典上的解释，翻译出来的东西就会失去原作的风采。
       就拿书名为例吧。作者使用Showstopper这个词作为书名，是有一语双关之妙的。一方面是使用了这个词在计算机领域的含义，即最严重的臭虫，这是对这本书主要内容的一种直白表达；另一方面当然还是使用了这个词的传统含义，把打造NT的过程比喻成一场“戏”；一场虽没有刀光剑影，但也绝对堪称紧张激烈的戏；一场发生在高科技领域，但也处处彰显人性光芒的戏；一场有欢乐，也有悲伤的戏；一场让人拍手叫绝的戏……
         如何翻译这个书名呢？从打算翻译这本书的时候，我就开始考虑这个问题，也与一些朋友一起探讨过，希望用“头脑风暴”激发出一个好的中文名字。关于这个词在计算机领域的用法，在我们尝试过的词典中，都没有包含这种用法。关于传统用法，词典中一般也只是一句说明，没有给出中文的对应词汇。在想出的很多种译法都被否决后，我们想到了保留这个词不译，这是最省事和稳妥的做法，但还是觉得那样做有些不好，特别是对于那些不太熟悉这个英文单词的人来说。
最近几年，我越来越喜欢阅读古代的文学作品，尤其是当写作或者翻译中遇到困难时，我经常会翻看古人的作品寻找答案或者灵感。这一次，在翻看了几本书都没什么收获后，有一天，当我在书柜中搜索其它可看的书时，我看到了一本小小的书，128开本，大约一寸多厚，是典型的“口袋书”。拿起来一看，是上海古籍出版社出的袖珍本《古文观止》。在我很小的时候，就听说过这本书，但是当时还不知道这个书名的含义。后来慢慢明白，观止是“好到极致”的意思，出自著名的历史典籍《左传》。原文是说，吴国公子季札到鲁国访问，请求观赏一下周朝的音乐，于是鲁国派了乐队为他演奏，季札一边观赏，一边称赞。当看到歌舞《韶箾》时，他发出由衷的赞叹：“德至矣哉，大矣！如天之无不帱也，如地之无不载也！虽有盛德，其蔑以加于此矣。观止矣！若有他乐，吾不敢请已！”成语叹为观止就出自于此。
看来汉语中的观止本来也是用来形容精彩的演出，“观”意为观赏、欣赏，“止”即停止。这与SHOWSTOPPER这个词何其相似，SHOW即表演，STOP即停止，二者加到一起就是令演出停止，后面的ER是英文中名词的常用后缀。看来，中国的古人和西方的圣贤不约而同的使用了同一种方式来表达他们对美好事物的终极赞叹，最由衷的情感和最美丽的语言是跨越地域差异的。想到这里，我如获至宝，决定将“SHOWSTOPPER”翻译为“观止”。

       除了封面上列出的译者外，还有很多人为翻译这本书倾注了智慧和汗水。刘颖翻译了第6章，王宇翻译了第1章的前半部分（初稿）。本书原作者Gregg在百忙中回答了我提出的很多问题。我的英文老师Barry October帮助我消除了很多疑问。高端调试网站（ADVDBG.ORG）的很多网友（KernelPanic、neilshu、dos、applepwc、merryzhao等）为翻译这本书提出了很多宝贵的意见，是与他们讨论后，才决定了本书中人名和地名的翻译方式（译为中文，但是在每章第一次出现时在中文后标注英文）。在此向上面的各位朋友以及曾关心过这本书的引进和翻译工作的所有人表示衷心的感谢！
因为译者的水平有限，书中定有错误和不当之处，敬请读者批评指正。

张银奎
2009年2月

《卓有成效的程序员》读后感（转）

2009-03-07

《卓有成效的程序员》读后感
http://bbs.phpchina.com/thread-107365-1-1.html
绩效考核可以检验一个员工的工作能力如何。优秀的公司对员工绩效考核都有一套严格的标准和程序。当然，考核的结果直接跟奖惩挂勾，做得好的升官发财，达不到要求的淘汰出局。拿到软件开发来说，一个程序员的生产力好坏直接影响软件工程的顺利进行。作为程序员一定要修炼好自己的内功。

虽然在程序设计折腾了很多年，但“卓有成效”始终与我保持绝对遥远的距离，这也是这么多年来我未敢涉足职业程序员的原因之一。一个效率低下的程序员对一个团队的影响是巨大的，足以拖后腿，累坏所有团队成员，导致工程延宕，无法预期交付，造成巨大的经济损失。作为一个低产低效的民间程序爱好者，我把这么多年来失败的教训总结如下：

第一、事预则立。肥同小可老师在他堪称经典的“糟糠之论”博文（http://user.qzone.qq.com/51153204/blog/1231724918）中讲到了“事预则立”，这实在是万事成功的第一步，没有目标那是无头苍蝇，有了目标不作规划那是只糊涂苍蝇，有了目标和规划不去努力实施那是只懒苍蝇。很不幸，对于程序设计这件事我顶多算是第二只。所以至今连个留言本也没写完整。奉劝各位在开始一项工程或接手一个组件之前一定要做好规划，不论这个工程或组件有多小。从留言本开始就要养成良好的规划习惯。好的开头是成功的一半，这开头指的就是规划。

第二、不折腾。胡总书记在改革开放三十周年大会上提到了“不折腾”，实在是包含了万千深意的至理名言。然而我似乎是背道而驰，本着“折腾出真知”的歪理邪说，时时在闭门造车轮。尽管“michelin”——shanji说有AD嫌疑——是那样的圆那样的经久耐用，却一直没有拿来用，直到大街上跑满了车子，才发现自己的独轮车早就跟不上时代。孟岩老师将程序员分成了两大类，一类从事底层研发，一类从事应用开发。就我的理解，研发应属于研制车轮、研制发动机和各种部件，复杂而且精密；而开发则是选择合适的轮子、发动机和各种部件，连接装配来组成汽车。大多数的程序员都属于后者。除非你有能力造一个好车轮，否则千万不要正式生产中等你造好车轮装到汽车上。装配工造轮子，这叫做折腾。后果估计是客户很生气，后果很严重。如果你希望有成套的配件库，那么掌握一个成熟的开发框架是不错的选择。

第三、修炼内功。说到内功的修炼，实在有些枯燥无味。都是一些原理之类的东西，不着边际，不能实用。我一看就开始昏昏欲睡，不久就要去跟周公对弈。所以身在江湖多年，依然只是三脚猫。不要重复发明轮子是相对于软件实际生产来说的，如果要修炼内功，学学轮子的原理和试着造一个车轮，对提高轮子的认识那是大有裨益的。日后在装配中你会明白什么样的轮子可以装在什么样的车子，及如何搭配性能好一些，做起事自然事半功倍，效率非凡。原理理解了，好比打通任任督二脉，内功会大大增强，不日可以成为武林高手。然则内功的修炼非一朝一夕可以达成，也没有立竿见影的成果。如何把持得住就要看各位的定力如何了。

以上是我的一点愚见，或许有误人子弟之嫌。如果你想提高自身的生产力，不妨去读一下NEAL FORD《卓有成效的程序员》。本书从机制（生产力法则）和实践（思想）中对如何提高程序员的生产力作了深入的分析阐述。它会启迪你的心智，告诉你所需要的一切。

《卓有成效的程序员》节选

2009-03-20

《卓有成效的程序员》本书就是讲述如何在开发软件的过程中变得更加高效。本章讲述哲学家是怎么评说代码的，本节为大家介绍奥卡姆剃刀原理。

奥卡姆剃刀原理

奥卡姆的威廉爵士是一个厌恶华美装饰以及复杂解释的修士。他对哲学和科学的贡献是奥卡姆剃刀原理：如果对于一个现象有好几种解释，那么最简单的解释往往是最正确的。显然，这跟我们讨论的事物本质和附属性质理论紧密关联。这个原理对于软件的影响度也是出乎我们意料的。

作为软件工业中的一员，过去十年我们一直在进行着某项实验。这个实验始于上世纪90年代中期，主要是由于开发人员发现其开发进度远远跟不上软件需求的增长而引发的（其实在那时这已经不是一个新问题，这个问题自商业软件的想法出现之后就一直存在）。实验的目的是：创造一些工具和环境来提高那些普通开发人员的生产率，即使一些人比如Fred Brooks（去看他的《人月神话》）已经告诉我们软件开发中的一些混乱事实。此实验试图验证：我们是否可以创造一种能限制程序员破坏力的语言而使人摆脱麻烦；我们是否可以无需支付荒唐的大量金钱给那些令人生厌的软件技工（即使在那时候你可能还为找不到足够的软件技工而发愁），而同样生产出软件呢？这些思考让我们创造出了如dBase, PowerBuilder, Clipper和Access这样的工具，并促成了工具和语言相结合的4GL(第四代语言)的崛起，比如FoxPro和Access。

但问题是，即使有这样的工具和环境你也不能完成所有的工作。我同事Terry Dietzler为Access创建了一个叫做"80-10-10"的准则(而我喜欢把它称之为Dietzler定律)。这个定律说的是：80%的客户需求可以很快完成；下一个10%需要花很大的努力才能完成；而最后的10%却几乎是不可能完成的，因为你不能把所有的工具和框架都"招致麾下"。而用户却希望能满足一切需求，所以作为通用目的语言的4GL（Visual BASIC、Java、Delphi以及C#）应运而生。Java和C#的出现主要是由于C++的复杂性和易错性，语言开发者们为了让一般程序员摆脱这些麻烦而在其内建了一些相当严格的限制。在此之后"80-10-10准则"才发生了改变，无法完成的工作已经微乎其微。这些语言都是通用目的语言，只要付出足够的努力，大多数工作都可以完成。但Java虽然比较易用却常常需要大量编码，所以框架出现了，Aspects出现了，大量其它框架蜂拥而至。

下面有一个例子。这段Java代码是从一个广泛使用的开源框架中提取出来的，试着找出它的用途吧（关于它的名字我只会提示你一点点）：

public static boolean xxXxxxx(String str) {int strLen;if (str == null || (strLen = str.length()) == 0) {return true;}for (int i = 0; i < strLen; i++) {if ((Character.isWhitespace(str.charAt(i)) == false)) {return false;}}return true;}

花了多少时间？这实际上是一个从Jakarta Commons框架（它提供了一些或许本该内置于Java的帮助类和方法）中提取出来的isBlank方法。一个字符串是否为"空白"由两个条件决定：这个字符串是空字符串，或者它只由空格组成。这段代码的计算公式非常复杂，因为要考虑参数是null的情况，而且还要迭代所有的字符。当然，你还要把字符包装成Character类型以确定它是否空白字符（空格、制表符、换行符等）。总之，太麻烦了！

下面是用Ruby实现的版本：

class Stringdef blank?empty? || strip.empty?endend

这个定义跟之前的那个非常相近。在Ruby里，你可以把String类打开并且加入一些新方法。这个blank?方法（Ruby里返回布尔值的方法通常用问号结尾）会检查字符串是否为空，或者在去除所有空格之后是否为空。在Ruby里方法的最后一行就是返回值，所以你可以忽略可选的return关键字。

这段代码在一些预想不到的情况下同样工作。看看这段代码的单元测试吧：

class BlankTest < Test::Unit::TestCasedef test_blankassert "".blank?assert " ".blank?assert nil.to_s.blank? assert ! "x".blank?endend

1. 在Ruby里，nil是NilClass类的一个对象，就是说它也有to_s方法（等价于Java和C#中的toString方法）。

其实我讲这些的主要意旨是：一些在"企业级开发"中非常流行的主流静态类型语言有很多附属复杂性。Java中的基本数据类型就是一个语言附属复杂性的绝佳例子。当Java还是新语言的时候它们确实非常有用，但如今它们只是让代码更加难以看懂而已。自动装箱能起到一些帮助，但是它会引起其它一些异常问题。看看下面这段代码吧，肯定会让你挠头：

public void test_Compiler_is_sane_with_lists() {ArrayList<String> list = new ArrayList<String>();list.add("one");list.add("two");list.add("three");list.remove(0);assertEquals(2, list.size());}

这个测试通过了。再看看下面这个版本，它们之间的区别只有一个单词（ArrayList被换成了Collection）：
public void test_Compiler_is_broken_with_collections() {Collection<String> list = new ArrayList<String>();list.add("one");list.add("two");list.add("three");list.remove(0);assertEquals(2, list.size());}

这个测试失败了，抱怨说list的大小还是3。说明了什么问题？它很好地解释了当使用泛型和自动装箱来改装一些复杂的库（比如集合）时会发生什么事情。测试失败的原因在于：Collection接口虽然也有remove方法，但是它删除的是与其参数内容匹配的项，而不是索引指定的项。在这个例子中，Java把整数0自动装箱成一个Integer类的对象，然后在列表中寻找一个内容是0的项，当然最后没有找到，所以也就不删除任何东西。

现代语言非但没有让程序员摆脱麻烦，而且其附属复杂性还迫使他们艰难地寻找复杂的解决方法。这个趋势影响了构建复杂软件的生产率。我们真正想要的，是4GL作为强大的通用目的语言所具有的通用性和灵活性所带来的高生产率。让我们看看用DSL(领域特定语言)构建的框架，目前一个很好的范例是Ruby on Rails。当编写Rails程序时，你不用写太多"纯"Ruby代码（即使写，大部分也只在处理商业逻辑的模型层）。你主要是在Rails的DSL部分编写代码，这意味着编码工作都投入在最有价值的部分，当然也带来了更大的产出。

validates_presence_of :name, :sales_description, :logo_image_urlvalidates_numericality_of :account_balancevalidates_uniqueness_of :namevalidates_format_of :logo_image_url,:with => %r{.(gif|jpg|png)}i,:message => "must be a URL for a GIF, JPG, or PNG image"

只要小小的一段代码，却实现了大量的功能。DSL构建的框架提供了4GL级别的生产率，但它们有一个关键的差异。用4GL(目前一些主流的静态类型语言)做一些非常强大的东西（比如元编程）是极其困难或者说不可能的，而在一个基于一种超级强大语言的DSL里，你不仅可以用少量的代码完成大量的功能，而且可以跳到底层语言去实现任何你想做的东西。

"强大的语言加上特定领域元层次"提供了目前最好的解决方案。生产率来自DSL跟问题域的紧密相连；能力来自于表层之下的强大语言。基于强大语言并且易于表达的DSL将会成为一个新的标准。框架将会用DSL来编写，而不再是语法拘束且无必要规范过多的静态类型语言。请注意这并不代表只能使用动态语言（比如Ruby），只要有合适的语法，静态类型推断语言也非常有可能从这种设计风格中获益。比方说Jaskell[43]，特别是基于它的DSL：Neptune[44]。Neptune拥有和Ant一样的基本功能，但它是基于Jaskell的领域特定语言。Neptune展示了在一个熟悉的问题域之内，你可以用Jaskell写出多么易读以及简洁的代码。

提示

Dietzler定律：即使是通用目的编程语言也逃不出"80-10-10准则"的魔咒。

最近出版了一本《架构之美》

2009-11-24

《架构之美》汇集全球19位顶尖架构师沉思录，揭示了Emacs到Facebook等大型网站架构秘密，分析了它们的创新性。值得一看http://www.douban.com/subject/4086029/

书评

2009-06-08

“我编写了WinDbg符号处理器、符号服务器以及源文件服务器。即便如此，我仍然无法教会我妻子使用WinDbg。她认为这个工具非常难用，因此并不了解这个工具的强大之处。我买了这本书送给她，这样她就可以知道如何使用WinDbg。本书中关于事后调试（Postmortem Debugging）和内存破坏等方面的内容，有效地揭示了在程序出错时的运行环境和操作系统的内部状态。Mario和Daniel在调试领域积累了丰富经验，因为他们经常被要求解决陌生程序中一些莫名其妙的问题。这也是具有工业强度的调试技术的真正意义所在。” —Pat Styles 就职于Microsoft

调试体会

2009-07-06

记得几年前我们公司对一款核心产品进行升级，测试人员发现了一个会导致整个程序崩溃的BUG。这个BUG在程序的运行过程中随机出现，很难重现。更为棘手的是，当开发人员用VC以调试模式运行该程序，BUG就再也不重现了。根据以往的经验，这种情况多和多线程处理导致缓冲区非法操作有关，调试器引起的“海森堡效应”则会导致程序在这种情况下可能无法重现BUG。开发人员之前常用的LOG定位法在多线程程序中也显得力不从心，线程的交错运行使得LOG根本无法在程序崩溃的时候定位到正确的位置。当时已经是产品发布的前夜，重新检查可疑的相关代码已经不可能了，工作量太大，时间不够用。于是我们只好试图改变调试手段来解决问题。当我们尝试了一种可行的调试方法后，BUG迎刃而解，从定位到代码修复完成总共花了不到十分钟。方法很简单：当程序崩溃的时候，对程序进程附加上调试器，根据调用堆栈分析可能引发缓冲区问题的位置，然后通过在源码中对应的位置加上“__asm int3”语句使程序可以在运行时激发调试器，继而对将要引发异常的内存区域设置读写断点，在激发断点后终于顺藤摸瓜找到了罪魁祸首。而在此之前我们已经在门外摸黑乱撞了两个小时！

正确可行的调试技巧在软件开发中是如此重要，奇怪的是这个事实在多数开发者那里并未引起足够的重视，也许是“Debug”更多时候是和“Reverse Engineering”这个神秘的名词画上等号而显得有些高深莫测，使得一般的开发人员和初学者望而生畏踟蹰不前。前几天收到了机械工业出版社出版的一本《Windows高级调试》，原以为是给分析人员使用的工具用书，仔细翻阅了几章，却发现并非如此。这本书更多的是面向一般的开发人员和测试人员。书中通过融入一个个实际例子当中的调试过程和技巧，由浅入深的讲解操作系统的内部运行机制和调试的基本原理。深入阅读，你会发现Debug不再是hacker 手中的“奇技淫巧”，而是软件开发过程中的有力工具。对于有经验的分析人员，这本书同样值得一读。相信书内清晰的描述和深入的分析能够印证你对操作系统底层构架的理解，在调试技术上给予启发。

2009-02-25

第一本专业讲解EXTJS的图书就要发行了，本书写作和编辑花费了大量的时间，作者是基于大型web开发项目的实际经验来写作的，本书已经印刷完毕了,会在12月中上旬与读者见面，先发出来给读者先睹为快。如果有任何意见和建议，欢迎与本书编辑联系： tasiya@tom.com
发现有不少朋友把我们这本正规出版的图书和其他一个开源组织打印的EXTJS教程相混淆了,为了让大家更好的了解和区别,在此再贴出完整的封面,和相关声明,本书是卫军等国内一线知名企业开发工程师编写的,由机械工业出版社发行的图书,请大家在做评论的时候，千万不要混淆,或者看完样章之后再评价.在评论中,我们听到了大量鼓励的信息,这是我们前进的动力,感谢你们.除了对内容的肯定之外,我们也听到了许多关于封面设计方面,确实有可以改进的地方,因为本书已经印刷出来了,所以封面的问题也就没法改动了,我们只有在以后图书中加强改进的力度,中肯的意见我们会照收的.....

本书完整书名是:《EXTJS WEB应用程序开发指南》
现在可以在下面的网站订阅了,谢谢大家热情的支持与鼓励:
http://www.china-pub.com/43585
http://www.huachu.com.cn/itbook/itbookinfo.asp?lbbh=10097064

本书从ExtJS实现的功能开始讲解RIA Web开发，通过经典的Hello World快速搭建和配置第一个程序。然后详细讲解ExtJS的基本功能、常用的表单、面板和布局、常见的工具类与函数，以及ExtJS对事件的响应。这些基本组件、函数的讲解结合现今流行的Web框架进行改造，将相关技术融合起来应用。随着Ajax逐渐渗透到Web开发的各个方面，增加了ExtJS与数据交互重要的数据模型、ExtJS的JSP标签库ExtTLD、ExtJS高级组件的讲解。考虑到ExtJS与主流服务端框架的整合越来越紧密，本书还特意讲解了Struts和Struts2框架的整合与配置。本书还全面细致地讲解了ExtJS实现的Portal实例，真正实现完全整合应用ExtJS技术。本书还为RIA Web开发设计提供经典的应用解决方案。

本书语言通俗易懂，版式清新，通过大量的实例讲解技术。广大的Web程序员可以从本书中能找到经典的应用解决方案。RIA Web应用开发的爱好者从中也可以找到进步的阶梯。阅读门槛低—不要求读者对ExtJS有所了解，只要熟悉JavaScript编程，就能从头开始领略ExtJS的风采。平台开发的概念—ExtJS是一种软件开发平台，而非一个普通的JavaScript框架，用桌面程序开发思想指导基于ExtJS的Web应用。来自于实践—在大型项目开发中学习并应用ExtJS，大量的案例都是实际项目情景的缩影，在讲解时穿插大量的实践经验提示，实践的指导意义强大。典型场景应用—本书在讲述各章内容中穿插了对常见Web应用框架使用ExtJS进行改造的实例。Web应用框架是最基本的典型场景应用，每个Web开发都会遇到。完整开发实例—本书提供了完整的基于ExtJS实现的Portal实例。该实例完全可以立即投入到火热的Portal风潮的实际应用中。

对常见问题的统一答复

1． Extjs是怎样的技术？它的主要功能是什么？

Extjs是一种用于开发富客户端Web应用程序的javascript技术，它不需要为客户端安装任何插件就可以实现丰富多彩的界面效果，是进行富客户端开发的理想选择之一。Extjs的主要功能包括：对标准信息提示框的扩展、对标准表单组件的扩展、支持面板及各种布局方式、提供了大量的工具类和工具方法、提供了增强的事件机制、提供了对Ajax功能的支持、具有结构完整的数据模型、提供了灵活易用的模板功能、提供了美观实用的各种组件（其中的代表是表格组件Grid和树型自己Tree）。

2．目前国内，程序员使用Extjs技术的多吗？这个技术在国内处于一个怎样的阶段？
就我所了解的情况，目前国内使用Extjs的程序员正在逐步增加，由于客户对程序界面的要求越来越高，不仅要求实现功能还要求操作界面美观实用，在这样的趋势下我相信使用Extjs的程序员会越来越多。
Extjs技术在国内的使用也有一段时间了，从最初的学习研究到真正在大型项目中的广泛应用中间有很多程序员付出了艰辛的努力，就整体而言 Extjs的使用还处于成长期，从Extjs1.1到现在的Extjs2已经有越来越多的人开始关注和使用Extjs技术，在未来出现的Extjs3.0 将迎来Extjs的成熟阶段。

3．请问EXTJS技术应用前景广阔的原因是？
Extjs最大的优势在于它将Web应用程序的操作方式向传统桌面应用程序的操作方式进行转化甚至消除了这种差异，从根本上提高了用户的使用体验，这是Extjs应用前景广阔的主要原因，其次使用Extjs对浏览器没有任何要求可以说是一种绿色的富客户端实现方式，这是它应用前景广阔的第二个原因，另外Extjs提供的各种组件可以用更加标准的方式展示数据降低了开发难度，这可以说是它应用前景广阔的第三点原因。

4． EXTJS与后台技术的联系如何？
Extjs是一个纯前台的javascript框架，他没有提供后台部分的实现，但这并不是说Extjs与后台技术的结合非常困难，恰恰相反 Extjs可以与各种后台技术进行结合，前后台之间通过XML或者JSON实现数据传递，目前后台生成XML或者JSON的技术已经非常成熟因此只要对后台进行很小的修改就可以将Extjs应用于现有项目。

5．很多程序员想学或者正在学Extjs技术，在学习的时候有哪些应该注意什么问题？
对于一个从没有接触过Extjs技术的人来说，在学习的初期会感觉较为困难，原因在于Extjs基本上完全抛弃了直接书写HTML代码来构建页面的方式，取而代之的是使用面板、布局、组件、等等以前只在桌面程序中出现的概念，学习者需要一定的时间和练习来适应这种变化，一旦适应了这种开发方式就会体验到使用Extjs的乐趣。在学习Extjs的过程中以下两点是需要我们经常注意的，首先Extjs组件在很多情况下都是延时渲染的，其次Extjs的很多操作都是异步执行的，这两个特点决定了我们程序的设计方式。