摘要:最近不断有猎头联系我，问我有没有兴趣看看其他的机会，其中包括AutoDesk，Morgan Stanley（软件研发部门），等等。职位都是QA Lead/Manager一类的。不是没有考虑过去微软外面看看。自从2004年秋天离开上海去北京的工程院开始正式作SDE/T（以及现在的测试主管）至今，已经三年了。这三年里面，一直是埋头做公司里面的产品，埋头做自己的事情，埋头学习，从我所在组积累的方法和经验里学习，从接触到的其他组学习。这三年里，再也没有去关心过微软以外的其他地方是怎么做软件的。 2004年秋天之前，我在工作中一直接触到国内各种各样的软件公司：2002年冬天的软件开发管理大会，2003年和全球技术中心的同事在各个软件园讲软件项目管理和软件测试，以及自己的编写培训材料，2004年上半年和微软中国的同事一起配合支持北方区的ISV（独立软件供应商）合作伙伴。那段时间里面，一直感受到微软内和微软外之间的碰撞。当时我总结了在各种对外培训、投标、会议等中收到听到的问题，应该说是当时国内做软件的人的普遍问题： 市场前景与产品功能 如何进行市场预测和用户需求调查 如何平衡市场前景和产品功能 如何得出产品的Feature List 开发流程和团队 如何在资源不足的中小企业中实施开发流程？如何裁剪？做项目时间紧，不能跟着整套流程做，有什么办法可以解决？微软的经验有什么精简的实现方法？ 对用户订制的软件应用系统的开发管理。 怎么解决人员流动带来的问题，怎么在架构、设计中加入人员流动风险控制？如何保证极少数核心技术人员的流失或意外事件不给公司造成严重的损失？关键技术人员以离职要求涨工资怎么办？国营软件企业内无法突破工资与奖励的制度瓶颈怎么办？ 如何形成企业内知识共享环境？如何积累历次项目的经验？微软的“师徒关系”在团队管理中的应用。 十几年以来，微软的开发流程是怎么一步步进化的？微软组织结构是如何一步步从小到大进化的？微软在软件开发管理方面从失败中获得的经验？ 有哪些典型的错误开发方式，并提出可行的解决方案及办法 微软开发流程与CMM的区别？ 怎么做变更管理？开发团队管理组织中的决策模型和流程？一个项目被取消的原因和评判标准？ 开发 开发团队如何划分任务？如何预估和控制进度？ 开发团队的管理，如何科学的评估开发人员的级别、绩效？统计哪些指标？ 是否一定要Daily Build？ 代码库的管理，如何、何时上锁，权限如何控制？ 开发后期发现很多或者还有很多Bug怎么办？ 可扩展性应用程序的设计方法，思路。 测试 测试应从哪些方面考虑？如何选择测试方法与工具（自动化测试/压力测试/性能测试等）？如何进行具体的测试，比如CPU性能？性能测试？有没有测试的实例？ Test Lead怎么考核？Tester的考核与量化管理，数据如何采集？如何培养测试经理？测试经理的培训? 如何提高Test Team的地位？ QA部门何时、何种形式、如何参与到整个项目中？ 希望提供Bug管理工具和测试工具。 文档 微软如何做需求管理？微软做不做、怎么做用户需求文档？软件项目（而非产品）开发初期怎么做需求文档？ 整个项目一共有哪些文档？如何管理文档？文档何时、何种原因可以修改？文档修改后怎么通知所有人？ “需求说明”、“概要设计”、“详细设计”与“Feature List”、“Function Spec”、“Implementation Spec”的区别？其中要定义哪些内容？Function Spec和Implementation Spec要详细到什么程度？希望结合实例讲解文档。 PM PM做不做产品设计？PM是否写代码？PM是否能同时参加多个项目，如果是，有什么成功经验？ PM是否、如何担当产品市场分析、决定产品的技术实现、决定Developer使用的工具和技术路线？ 产品达不到客户需求怎么办？PM夹在客户和Developer之间怎么处理两方面的要求？ 如何培养一个PM？如何考核PM的工作业绩？ 其他 希望了解实际的开发管理案例，以及与其他公司的案例比较；详细的行动指南、Check List等工具。 想获得软件企业的管理软件和工具软件。 希望获得面向不同发展阶段、不同规模大小的企业的更有针对性的培训。 我是带着这些问题去北京的工程院的。当时我给我的经理的邮件是这么写的：“过去一年多我做了很多开发流程、测试、配置管理等的培训，我很热爱培训工作，能够给中国的软件业者解决困惑他们很久的问题让我觉得非常有意义、有价值、有成就感。培训过程中感觉training skill已经不再是做好培训的瓶颈，而是觉得知识不够用。例如，培训中有一些学员很关心的问题（也是很关键的问题）我自己也找不到很好的答案，例如怎么做单元测试、自动化测试、怎么写好Implementation Spec等。我很想能够再多一些实际的锻炼，在开发、项目中寻找这些问题的答案”。 当时我也把这些问题转发给了邹欣。我不敢说这个问题列表对邹欣写《移山之道》有很大帮助，但我看到《移山之道》已经回答了这里面的很多问题。 我不知道今天的中国软件行业，带头的公司里，是不是已经都建立了必要的基础架构，例如：缺陷管理，代码库，文档库，测试自动化，等等。2003年，我接触到的还有很多公司在用Word/Excel填写“缺陷单”，还有很多公司没有做daily build，还有很多做测试的人还停留在把黑盒白盒挂在嘴上的阶段。如果有机会的话，我很想看看现在国内软件企业的项目管理水平是什么样子的。是不是还有很多人在争论到底是CMM好还是RUP好？ 我也很想看看其他的跨国公司是怎么做软件的，比如IBM、GOOGLE、SAP、Adobe、etc。我很想知道EA等是怎么测试他们的游戏的：也用大量的自动化么？怎么自动化？怎么自动化的测试“帝国时代”或Call of Duty 3？Adobe是怎么测试Photoshop的？还有Google呢？ 今年八月份的时候看到这么一封内部邮件： I worked with a Test Architect here at MS a few years ago who is very highly regarded in the software testing industry … very much top of his game.  He left MS about 2.5 years ago for Google to help them create a testing......[阅读全文]

摘要:我们组的code base已经有五六年了，虽然比不上Windows或Office，但也有年头了。经年累月的加功能，一拨拨人走，一拨拨人来。我们平时总是戏称自己是在一个垃圾堆上建一个更大的垃圾堆，而且还要保证这个垃圾堆不会倒掉。像我们做online service的，老的代码是无论如何丢不掉的。一旦第一个版本进了production以后，以后只能incremental的改动。如果要重起炉灶，光是那些数据就让人受不了，都是轮TB来的，单单做一遍replication都不知道要做上几天，如果数据库的schema都改了，再好的dev也不敢保证他的migration code能处理所有的老数据、脏数据，再好的test也不敢保证他的test能把所有的老数据脏数据给cover了。所以，越到后来，越没人敢动数据库。从另一个角度深深的体会到，v1的产品不是那么可以随心所欲做的。v1时候的疏忽或者幼稚，将来是要付出很大代价的。 看以前人的code是一种特别有趣的感觉，好像是在和以前的一个dev在对话，跨越时空的，有点像下围棋的人打古谱，那是一种跨越千年的心灵和心智的交流，我跨得少了点，只跨了五年而已。上半年的时候看了一块多线程的代码，是一个后台console application的，把Mutex、AutoResetEvent、ManualResetEvent、WaitHandle运用的非常华丽。看了那块code以后发现自己对多线程的理解又上了一个台阶。最近在看一段五年前的C++的code，注释相对少一些，不过因为代码写得比较straightforward，所以看起来不吃力。那些注释大部分都是解释code的，但中间有一个地方有这么一行注释：// do I need to close before Open? 看的我大笑，看来真的是没有全能的developer，每个dev都有自己精通的东西，都有自己不懂的东西。很少有dev能够通吃managed code、unmanaged code、network、win32和SQL database的。很好的C#的程序员有可能设计出来的SQL database的性能是很差的。巧的是，我看得这两块代码的两个作者都跑去Google了。 一个online service的系统，做到五年，做v1的dev和test基本上就剩不了几个了。我们组也不例外。现在有很多很老的feature，好好的已经跑了四五年了没人动过，突然需要re-write，就很吃力。文档是肯定找不到的了，就算能找到，也是不up to date的。最让人挠头的是test automation都没有了。当初的很多test都是manual的，等到SDE/T慢慢多起来可以有人有时间做test automation了，那些最老的feature就已经稳定了，所以也就没人去automate那些manual test cases了。现在要re-write，没有test automation做最后一道防线，不免让人非常心里发毛。但也不得不做，只能硬着头皮上，尽量think through一点，实在不行，只能在production里面打hotfix了。希望不要有太多hotfix。//cross fingers 说到文档，大家都在喊文档的重要性，说developer要写implementation spec。其实，坦白说，in practice，文档是一种很昂贵的手段，单写一份spec还好，但要保证这份spec一直和code保持一致，那就是件代价很高昂的事情，很得不偿失的。从我们组现在的开发实践的体会来看，最好的documentation的方式是：一，把代码写得容易读一些，多写注释；二，把test case维护好，并且尽量做到automated。以前曾经看到过这么一种说法：it’s the test case that finally shapes the product。非常有道理的。从这点来说，我很同意scrum/xp里面所说的less document is better。  ...[阅读全文]

摘要:微软的SDE/T（即Software Development Engineer in Test）大致相当于其他很多软件公司里的QA（Quality Assurance），但又有所不同。用比较理论化的语汇来说，SDE/T在微软的工作是负责自动化测试和白盒测试。SDE/T通常需要编写测试计划、测试用例、测试工具和测试代码，需要做debug并尽量在源代码中找到bug发生的位置。SDE/T可以说是测试团队里的dev：从工作职责来说，SDE/T是tester；从日常工作内容和所需要的技能来说，SDE/T是developer。 对SDE/T这么一个特殊的工作存在很多的误解。一个叫David Larson的SDE/T Lead在我们公司内部Blog上写了一篇题为“SDET's wanting to move to SDE”的blog，纠正了一些常见的关于SDE/T的似是而非的认识： As we continue to emphasize CS skills and our sdets become better developers, the issue of people wanting to move from and SDET to an SDE role will become more and more common. People considering moving to dev often have a mixture of fact and misconceptions. I try to address the following common points of view: "I want to move to dev because... 1. "I love to code." Generally SDE's do less coding than SDET's. Many people want to move to dev because they love doing development and want to do......[阅读全文]

摘要:Jim McCarthy（曾经是Visual C++组的Product Unit Manager，《Dynamics of Software Development》的作者）在1994年的一段录像中说过这么一句话：“If there is one thing for which Microsoft should be remembered in software engineering, it's the daily build process”。 Cusumano在《Microsoft Secrets》中提到，最晚在1989年，微软就已经在使用daily build流程了。除了微软，当时也已经在使用或者部分使用daily/weekly/biweekly/monthly build流程的公司还有DEC、IBM、Lotus、Borland等。 根据Garth Wolfendale（现任微软咨询服务的高级顾问及企业架构师）回忆，70年代他在DEC工作时，daily build流程已经在David Cutler领导的VMS项目组里面初露端倪了（"The base-level /frequent/regular/daily build process evolution took root during development of VMS, with Dave Cutler heading the project"）。当David Cutler在八十年代跳槽到微软时，daily build流程也被引入了Windows的开发管理中。...[阅读全文]

摘要:Mark Lucovsky，微软曾经的Distinguished Engineer和Windows架构师，曾经设计了HailStorm（即.NET My Services）但最终失败，在微软工作了十六年以后，去年此时跳槽去了Google。 刚才看了此君在今年二月，即加盟Google三个月以后写的一篇Blog: "Shipping Software"。概括起来说，Mark Lucovsky对Google、Amazon等互联网公司的软件发布方式大加赞扬，他说“They have embraced the network, deeply understand the concept of 'software as a service', and know how to deliver incredible value to their customers efficiently and quickly”。他举例说，当Amazon的工程师修复了网上书店中的一个Bug以后，经过一天的测试，晚上就可以发布到服务器上，第二天顾客就可以用到更新过的代码了。相比之下，MarkL认为微软的软件发布方式太慢、太落后了——“In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM”。 Mark Lucovsky恐怕是太热爱他的新公司了，或者是因为HailStorm最终未能发布而耿耿于怀，在他的这篇题为"Shipping Software"的文章里，他对微软有强烈的反噬情绪。他显然眼里只有Google和互联网。但他不应该一味追捧Release To Web而忘记了软件世界中其他的领域——还有很多“传统”的软件公司（例如Oracle、Adobe、AutoDesk、Apple、IBM）仍然在用和微软类似的软件发布流程：光盘、不定期的补丁在网上供下载、每隔几个月或几年发布一个major release。 并不是所有的软件都适合“Software as Service”的，有些软件可以是Hosted，比如一些LOB系统（Salesforce.com）以及与沟通协作相关的软件等；而有些软件必须是local的，例如Office、Photoshop、Final Cut、DB2、Quake III等——如果强行把他们一一都挪到浏览器里面，浏览器就又会变得像现在的操作系统一样庞大无比。 至于MarkL所提到的"in large corporations, they won't see the software for a year or more post RTM"，这简直太正常了。说到底，Google的所有软件和服务，都不是Business Critical的。...[阅读全文]

摘要:最近在读《毛泽东选集》，读到第一卷里的《中国革命战争的战略问题》，感触良多。这篇洋洋洒洒七十页的长文写于1936年，文章浓缩凝练了毛泽东同志打仗十年来的心得，但有价值的是渗透于整篇文章中的思维方式——如何认识战争规律，如何学习战争规律，如何运用战争规律： “战争的规律——这是任何指导战争的人不能不研究和不能不解决的问题 “中国革命战争的规律——这是任何指导中国革命战争的人不能不研究和不能不解决的问题 “我们应该研究一般战争的规律；也应该研究革命战争的规律；最后，我们还应该研究中国革命战争的规律 “有一种人的意见是不对的，...他们说：只要研究一般战争的规律就得了，具体地说，只要照着...那些军事条令去做就得了 “又有一种人的意见也是不对的，...他们说：只要研究俄国革命战争的经验就得了 “再有一种人的意见也是不对的，...他们说：...北伐战争的经验是最好的，我们应该学习它，具体地说，学北伐战争的长驱直进和夺取大城市。他们不知道：北伐战争的经验是应该学习的，但是不应该刻板地抄用 “战争和战争指导规律都是发展的，各个历史阶段有各个历史阶段的特点 “要求战役指挥员和战术指挥员了解某种程度的战略上的规律，何以成为必要呢？因为懂得了全局性的东西，就更会使用局部性的东西 “作战时选择突击方向和突击点，要按照当前的敌情、地形和自己兵力的情况去规定。在给养丰富的地方要注意不使战士吃得太饱 “学习战争全局的指导规律，是要用心去想一想才行的。...不用心思去想，就不会懂得 “一切带原则性的军事规律，...都是前人或今人做的关于过去战争经验的总结 “反对红军的游击主义，却又承认红军的游击性；反对战役的持久战和战略的速决战，承认战略的持久战和战役的速决战；反对固定的作战线和阵地战，承认非固定的作战线和运动战；反对击溃战，承认歼灭战；...反对绝对的集中指挥，承认相对的集中指挥；... 我们完全可以按照《中国革命战争的战略问题》的框架和线条写一篇《中国软件开发的方法问题》。把战争替换成软件，便直指中国软件开发方法认识诸多误区。 软件开发的规律——这是任何开发软件的人不能不研究和不能解决的问题 中国软件开发的规律——这是任何中国开发软件的人不能不研究和不能不解决的问题； 我们应该研究一般软件开发的规律，也应该研究中国软件开发的规律，最后，我们还应该研究中国商业软件(commercial software)的开发规律； 有一种人的意见是不对的，他们说：只要研究一般软件的开发规律就可以了，具体说，只要按照CMM或RUP说的去做就可以了； 又有一种人的意见也是不对的，他们说：只要研究中国的特殊国情就可以了。 再有一种人的意见也是不对的，他们说：求伯君开发WPS的经验是最好的，我们应该学习他，具体说，就是鼓励编程英雄。他们不知道，求伯君的经验是应该学习的，但不应该照搬。 软件和软件开发方法都是发展的，各个历史阶段有各个历史阶段的特点； 要求基层程序员了解某种程度上的软件开发的方法，何以成为必要呢？因为懂得了全局性的东西，就更会使用局部性的东西； 软件测试选择的方法和重点，要按照当时的项目进度、资源、受众、团队水平、人员能力、人员数量去规定。在测试已经相当充分的领域注意不要过分追求100%自动化； 学习软件开发的方法，是要用心去想一想才行的。不用心思去想，就不会懂得； 一切带原则性的开发方法，都是前人开发过的项目的总结； 反对流程决定论，但也坚持必须先设计后编码；反对理想化的测试驱动，但承认最终定义产品的是测试用例；反对文档中心论，承认文档作为agreement的重要性；反对会山会海，承认沟通的重要性；反对“万般皆下品，唯有编程高”，承认software maker和software breaker的差异；... 每一个关心软件开发方法论的人都值得读一读《中国革命战争的战略问题》，边读边思考如何借鉴毛泽东同志研究中国革命战争战略的眼光、思维方式、态度、基本观念，并用于研究探讨中国软件开发方法。...[阅读全文]

摘要:“六经注我”和“我注六经”是中国古时候研究儒学经典的两种不同方法。这两个方法的含义，基本上字面上就已经可以说明了。 今天在微软（中国）在北京的office里面听一个Microsoft Consulting Service (MCS)的老大讲MSF (Microsoft Solution Framework)，发现他用的就是“六经注我”的讲法：大部分的时间都是在讲他在做项目中的经验、教训、体会、思索，讲得差不多了再把ppt翻一翻，翻过几张去，上面的内容倒也基本上就是他前面讲的项目体会的一个概括。 这是我第二次到北京，上一次是2002年夏天。我是2/6到北京的，昨天和前天(2/7和2/8)，主讲了一天的配置管理研讨会和一天的性能测试研讨会。感觉北京不愧为IT业最发达的城市，从业人员的level可以说是我走过的各个城市中最高的，问的问题也非常tough，非要拿出些浑身解数来不可。 我遇到的最tough的问题都来自于性能测试方面，包括: 1. 除了LoadRunner以外（太贵了），还有其他什么好的、有系统的方法可以做C/S结构的性能测试（Web或者说B/S上已经有很多好工具了）2. ACT（以及其他Web测试工具中），工具所模拟的并发连接数(Simultaneous Browser Connections)与真实的在线用户数(Concurrent User)之间如何换算。 这两个问题我也给不出什么很完善的答案，研讨会上我只是根据自己以前思索的一些体会讲了一些不成体系的方法，对这两个问题的更好的答案仍然在探寻中。 配置管理方面，倒是没遇到什么tough的问题。倒是有一些企业在配置管理方面遇到了一些流程方面的问题（而不单单是source control和daily build技术方面的问题）。对于这种问题，最重要的是大家要用同一种语言来说话，或许还需要跳出现有的思路，退一步，或许会恍然大悟看到一个全新的解决问题的方向。 另外，软件开发中的很多问题，如果用“鱼翅法”来分析原因，最终总会归纳到source control和daily build没有做（或者没有做好）。 btw，前两天偶尔发现在IE里面用SHIFT+Space相当于Page Up的作用。我以前只知道Space相当于Page Down的作用。 btw-2，北京没有我想象中那么冷，但比我预期的干。很不习惯，嘴唇裂、嗓子干，不过还好，带了一个朋友送我润唇膏。...[阅读全文]

摘要:Visual SourceSafe是有编程接口可以automation的，这点本身可能很多人就不知道。其实，装好Visual SourceSafe 6.0以后，就带上了Microsoft SourceSafe 6.0 Type Library。不过这个typelib是COM的，编程起来总觉得不太方便。 前两天在ASP.NET Weblogs上面看到一篇Create your own VSS explorer using IVSS，里面提供了一个.NET版本的IVSSLibrary，把SourceSafe 6.0 TypeLib都用C#包装了一下，编程起来很方便。而且还附带了一个用这个.NET版本的Lib实现的VSS Explorer，功能界面和原厂的VSS Explorer一模一样，有些地方还有所增强，例如“Show History”对话框里面的日期可以通过Calendar控件来选了。 用这个Lib我自己写了一个工具，用来帮助更方便的在VSS里面对多个散落的文件和项目打标签。因为在历次做配置管理的讲座和培训中，很多人提到在VSS自带的图形客户端里面不支持这个功能，觉得很不方便。 这个工具的可执行文件和Source Code可以在这里下载。用的时候可以这样用： 1) 登录，这里土了点，没做Browse按钮，srcsafe.ini的路径就自己手工填吧 2) 填好Label的名称，选好这个标签需要打在哪些文件/项目上，然后点一下Generate。这里的Project Tree就是用IVSSLibrary从VSS服务器上读出来的，Tree View用的是Multi-Select TreeView Control。 3) 谈出来一个notepad，直接把里面的内容拷贝到cmd窗口里面运行就可以了，标签就按照你的选择打上去了 ...[阅读全文]

摘要:今天看到思归的《细节、细节》，同感。因为大道理谁都会讲，但真正做好就是另外一回事情了——真正做好事情的要诀，都是一些很细节的东西，除非有闲人特地去总结，否则就只留在每个人自己的经验中。做人的道理如此，做事的道理如此，编出好程序的道理如此，做好项目的道理也如此。 就说软件过程这方面，经过二三十年的发展，软件过程理论都长得越来越像了：CMM、RUP、XP、TSP、PSP，还有微软自己的一套软件过程方法，都有很大的相似。这说明人们普遍对软件过程的认识和理解都趋于一致，看法都趋于成熟，已经非常接近很多规律性的东西。 但另一方面，光有这些过程理论，是做不好软件的，一做就走样，肯定走样。走样不走样的区别就在于细节！例如和Daily Build有关的就有一些很少被着重提及但非常重要的细节： 1）登记Bug时，一定要指明Bug是在哪个Build里面发现的；2）做Daily Build，如果是Web Application，要把Build号加到首页页面上去，如果是WinForm，要把Build号加到About对话框上；3）每个Build做内部发布的时候（比如build 4605），除了要创建并拷贝到\\release_svr\builds\4605下，还要拷贝一份到\\release_svr\builds\latest下。 类似的例子还有很多，一个项目组的流程和开发管理水平高低就都体现在这种细节中——而这也就是国内SQA现在所存在的问题。 很多企业都有SQA部门（Software Quality Assurance）和SPI部门（Software Process Improvement），这些部门并不作具体的测试工作，而是把自己定位在监督和帮助项目组改进软件开发过程上。从理论上来说，他们的工作的确很重要，因为好的流程能够带来好的质量。但从实际成效来说，他们找问题和提出改进意见的角度大都来自于一些常见的著名软件过程理论，往往还停留在说些“要有测试”、“要有配置管理”、“要有专门的客户文案”、“要有风险管理”等的话的层次。这样的流程改进过于粗放，实施中忽略了很多细节问题，效果大打折扣，还使得那些项目组对流程改进的有效性产生怀疑：“我已经按照你建议的流程做了，为什么还没有效果？你的流程到底有用么？”...[阅读全文]

摘要:今天看到Uestc95的Blog：《OO的目标是什么》。里面看到Booch这么说：“在OO兴起运动之前，编程以过程为中心--例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统--我认为，这才是面向对象编程运动的真正胜利”。 的确是这样的，就像我的前一篇Blog：《SOA: My Understanding》中表达的那样，驱使程序设计/开发中的结构化、面向对象、面向服务等方法相继出现的动力是系统的尺度在变大，老的方法已经达到了处理能力的复杂性极点，必须用新方法提高抽象级别。而这里的“提高抽象级别”通常都是依靠编译器和开发工具来practically实现的。 Bullshit探测器 今天在CSDN上看《Martin Fowler关于MDA的见解》，Martin Fowler是质疑MDA的，主要是两点：1. 他主要是质疑那种过于形式化的方法，质疑Planned Develop；2. 他反对滥用UML，反对迷信UML，建议仅用UML As Sketch。 我是倾向于Martin Fowler的。设计手段应该是很丰富的，真的在做项目的时候，UML有时候很笨拙。例如，有些业务逻辑我会用真值表来描述，两变量也好、三变量也好，都一目了然，以前大学里面的数字逻辑课也都用这种方法。而如果用UML，我不知道该怎么写/画，即便用flow chart，也会很啰嗦。而且我喜欢直接写代码。如果代码已经都在胸口了，却还仍然要先UML，再伪码，再代码，我会大呼“形式主义”的。 CSDN上这篇文章后面有一则jeffyan77的留言非常妙： 我对凡事都以XP为标准并不感兴趣。 XP来自何处？Alexander的城市发展哲学。Alexander认为为一个城市发展建立Master Plan是罪恶的做法，最好的（最人性化的适合人居住的）城市是“自然”发展起来的那种小城镇。他的很多观点和某些道家废弃发展才能反哺归真的观点不谋而合。 纯粹的XP完全放弃长期规划和预测能力，放弃系统的整体设计和架构设计，强调群体的随机活动对整体架构的贡献，认为“自然”形成的架构是最好的架构。 MDA恰好相反，它把软件设计人员分成两种，一种人为架构师，一种人为coder苦力。架构师来自第一世界，苦力来自中国和印度。架构师工资高，最好进行高智商的工作，苦力工资很低，干什么无所谓。类似的思想以不同面目出现过，譬如古代的劳心者治人，现代的软件蓝领之类。 MDA和XP好像是恰好形成两个极端的思想。来自真实世界的实践家都有一个Bullshit探测器，我的这个探测器一接近这两极都会嘟嘟响。 我喜欢哲学，但那必须大家都先把探测器关上才能谈。呵呵 我特别喜欢那个“Bullshit探测器”的说法。生动、形象、跃然纸上。...[阅读全文]