考虑使用UberNote代替Google Notebook

刚刚发现一款新的Web应用：Ubernote

• 展现方式同Google Notebook非常相似
• 采用了不分层的Tag方式进行管理
• 可以对Note进行所见即所得的富文本编辑
• 可以多人合作共享Note
• 有浏览器插件，可以直接抓取网页。而且插件很丰富：Toolbar, Clip, Bookmark, Snap
• 居然能够直接从Atom导入现有的Google Notebook内容。
• 缺点是对于每一个Note不能折叠显示。
  

所以真的可以考虑切换过去？

另一个可选的替代方案是：TiddlyWiki + Clipmarks，只是Clipmarks的速度比较慢。

Google Notebook的备选替代品

Google Notebook停止开发了。虽然现在还能够使用，但是还是需要准备一些备选产品了。另外，Google Notebook的功能一切都好，唯一的问题是，不能存储网页篇幅很大的文章。
替代品列表：

1. Office OneNote 2007：非常好的产品，文字编辑非常灵活方便，支持表格。分类清晰，功能强大，能够直接抓取网页。不能支持在线同步，但是只需要配合Dropbox就可以完美解决。唯一的问题是商业产品，需要收费。另外只能基于Windows平台。
2. Evernote：也是业界很出名的产品。Tag方式的管理，支持全文搜索，能够直接抓取网页。有在线同步功能，同时还有桌面客户端。
   缺点是：体积庞大，免费版本每月有数据量的限制。并且不支持表格，编辑功能稍弱，不够灵活。
3. TiddlyWiki：体积小巧，功能灵活。基于Tag方式管理，可以安装第三方插件。开源。支持UBB方式的自定义格式，非常方便。配合Dropbox可以实现在线同步。单一的HTML文件，所以跨平台。
   缺点是：不支持直接抓取网页。

现在看，TiddlyWiki的方式很好。所以正在寻找能够直接抓取网页并能够在线同步的工具进行配合使用。

对面向对象以及极限编程新的理解

传统的面向过程的开发是自顶向下逐步细化的过程。这是非常符合人们习惯的思维方式的。所以自然由需求分析->概要设计->详细设计->编码->测试->发布的瀑布模式成为了最规范的软件过程。
而面向对象的开发是自底向上的过程。在这样的过程中，往往是先实现已经了解的局部。逐渐的随着过程的推进，系统的全貌浮出水面。而基于面向对象开发的特点，在这个过程中，前面的工作成果往往能够很好的进行复用，重构的成本也很低。自然而然的，开发的过程会形成多次的迭代。但是，在这个过程中，最重要的是需要按照面向对象的思维方式进行设计与开发。

基于上面的认识，在回顾XP的各项原则会发现，以前认为不现实的内容其实都是顺理成章的事情了。唯一的问题仅仅是现场客户的问题，不过这个在一定的程度上 面也能够克服。由此可见，当深入了解了面向对象的开发的精髓之后，XP的各项原则实际上都是面向对象过程的一些内在的需求而已。

极限编程的12个原则：

1. 计划的制定
2. 小版本
3. 简单设计
4. 测试驱动
5. 持续整合
6. 重构
7. 配对编程
8. 代码共享
9. 每周只工作40小时
10. 现场客户
11. 隐喻
12. 编码标准

关于OOD的一点点总结

很多成熟的设计过程摆在面前：用例驱动、XP用户故事、特征驱动FDD、模型驱动MDD、敏捷模型驱动、领域驱动、测试驱动等等等等……到底应该怎么设计呢？
简单的讲，过程内容会分为需求分析和设计。
需求驱动是最根本的，所以在需求阶段，所谓的各种驱动方法其实都是对需求的功能分解，以便日后进行分治的设计以及管理跟踪。
由Use Case -> User Story -> Feature其实是由粗到细对需求分解的不同粒度。
有了需求条目之后，针对每一个条目可以继续进行设计工作。
设计过程的目标其实很简单：

• 类的识别
• 类的结构（例如：继承、关联、聚合、依赖等等）
• 类的属性
• 类的方法
• 系统运行是类之间的消息传递关系。

前三项是在整个设计过程中不断进行更新的，是个逐步细化的过程。分析的早期就可以识别大部分实体类，而在模拟需求条目的场景的过程中，逐步识别边界类（主要来自于页面流程分析）和控制类。主要的工具就是UML类图。
后两项则是通过模拟每一个需求条目所描述的场景来设计类之间的消息传递关系。在这个过程中，自然的完成对类分配方法。主要使用的工具如顺序图、协作图或者CRC分析。

对于MDD, AMDD以及DDD来讲，感觉上是针对非常熟悉的业务需求或者非常有经验的分析设计人员，因此采用了更新颖的设计路径。

而TDD应该理解为一种辅助设计手段。

在Iconix过程中使用协作图

ICONIX过程步骤如下

1. 系统界面原型，初步的领域分析（识别实体类，分析类之间关系，但不添加属性和方法），用例分析（仅关注用例内部的主干流程与分支流程，而忽略诸如前置条件、后置条件等细节）。
2. 健壮性分析（分析用户与系统类之间的关系，在此期间识别边界类与控制类），更新用例，更新领域模型（添加部分类属性）。
3. 详细设计（根据健壮性分析图而细化成顺序图，在此过程中给类分配方法），细化领域模型成为类图（静态模型）。

查阅了一些资料之后，有一个想法：
可以尝试使用UML协作图来代替顺序图。
因为协作图的样子本来就与健壮性分析图非常相似。这样，第2、3步仍然保留，但是产出物可以合并，即直接在健壮性分析图上面进行更新而成为协作图。
协作图中主要表现的是在一个场景中对象所拥有的职责（即所用到的对象的方法）以及对象之间的关联。这样看来，协作图所起到的作用与XP过程中所推荐的CRC分析是完全吻合的。
另外，对于普通的业务系统来讲，系统对时间的敏感程度并不高，这就增加的忽略顺序图的可能性。

如上，系统分析与设计的产物则为：

• 页面流程图与页面布局原型
• 用例分析
• UML类图
• UML协作图
• 部署图与组件图（可选）
  

在哪一个阶段画出操作界面

今天上午项目组内部开了一个会议，讨论需求文档的模板。大部分内容大家都比较一致，比如分成功能性需求和非功能性需求。功能性需求中主要以用例分析为主线，辅助以各个层次的工作流程图以及系统流程图。另外加入业务实体的各种信息等等。
但是在一个问题上面，项目组成员与我的引导无法达成一致：多数项目组成员认为系统操作界面不是需求阶段的产物。而应该是系统概要设计甚至详细设计阶段的产品。理由如下：需求的主要内容应该集中于业务分析，而系统界面更接近于设计的工作。而且在需求阶段需要画出页面的话，需求文档的工作量过大，需求评审阶段如果包括界面的话，那么需求阶段的时间会过长。
我无法说服大家的固有习惯，甚至无法说服大家仅仅写一些重要业务的操作界面。最终只能以大家的多数意见为准了。

这种情况显然是项目组内部对当前的OOAD技术缺乏经验所导致的。我的观点与大家相反，确认操作页面的工作越早越好！

• 需求分析需要分为三个层次：战略目标需求（高层访谈），业务逻辑需求（中层访谈）以及操作需求（一线操作层访谈）。
• 操作页面的确认工作应该是在需求访谈过程中同步进行的，而不是项目组内部闭门想出界面，然后拿给客户进行评审。
• 画界面的工作不会因为推后而减少。
• 需求访谈中对界面的访谈与分析有可能比用例分析还要早一步。示意图方式的界面会很大的消除需求的歧义。会给用户最直观的感受，是我们认识系统的第一个门户。
• 更早的对操作页面进行确认会减少项目的风险。如果在概要设计评审的时候发现有一些界面设计的不合适，然后发现修改这些页面居然还会导致上一阶段的需求分析结果进行改动的话，这样的返工成本就要大很多了。时间压力也会更大。
  

现在公司的项目管理方式

由于手头的项目非常庞大（基本上是50人的团队，1500万的合同），对公司有战略意义，又是新老板来了之后的第一个大项目，因此，管理层对项目非常重视，老板会亲自关注细节。因此，该项目需要做的非常“规范”！当然，如何规范是针对现有公司的标准来讲的。具体特征表现在：

1. 严格按照需求->概要设计->详细设计->编码->测试->发布的模式对项目进行计划。
   （听起来是严格的瀑布模式，呵呵，连一次迭代也没有。不过对于现在的公司来讲，能做到已经不错了。以前是基本没有设计阶段的，而且这次也会基本忽略测试阶段。）
2. 设计过程要求严格，例如一定要先搞出来物理模型并进行评审。然后再对各个模块的输入输出进行严格的定义。
   （典型的面向过程的设计方式。我了解了一下，公司的整个软件部门似乎没有几个人使用过UML进行系统分析与设计，更不用说更加激进的CRC分析之类的了。所以，理所当然，技术人员多数觉得JAVA框架中的ORM一层基本没有什么作用。当你告诉他们OOAD的过程中，物理模型有可能是最后一步时，很多人难以接受。）
   （我想主要的原因很可能是：现在公司的管理层和技术骨干主要都是在90年代末期参加工作的，那时候国内正是面向过程的流行时期。所以大家都已经习惯于这样的设计方式。然后就是这样一代一代的延续下来……）
   
3. 对文档的要求非常严格：包括在项目的第一周就需要提交细化到半年后的某一天的详细项目计划。而且各种文档名目繁多。
   （大家都听说过滚动式规划，但是做起事来还是如此。最后都变成了交差。）
4. 项目计划的全部意义就是那个*.MPP文档。而且一般需要维护1000～2000行吧。
   （既然老板是这样认为的，所以也就没有人敢质疑该如何维护2000行的project文档。）
   
5. 项目管理制度中规定：项目组内部沟通以正式的书面沟通为主，口头沟通作为辅助。
   （学过PMP或者对敏捷开发有兴趣的人会很吃惊是吧？）
6. 加班将作为项目组工作的一种常态。加班的目的是为了营造紧张的项目组内部的气氛。
   （为了加班而加班！当然也有一部分原因是客户造成的。客户是国家机构，嘴里高喊“深入实践科学发展观”，做起事儿来完全“人有多大胆，地有多大产”。）
   
7. 项目经理每天会忙于收发EMAIL，制定各种管理制度，以及制作各种报告等等。
   

不过似乎也不是一无是处，例如：

1. 公司里面有一些强人自己包装了SPRING，开发了很好用的MDA框架。
2. 老板亲自拍板，调集了公司最强的开发资源进入项目组。
3. 暂时不用考虑项目成本问题。
   

当面临的问题是生存时，任何承诺都是骗人的。

Google宣布：停止Notebook应用的开发，并停止其接纳新用户。

这让我想起了上一次的互联网泡沫破裂时的情况：263的老板在前一天还在信誓旦旦说要保留免费服务，转天就开始全面收费。

那一次事件之后，我对国内互联网服务提供商的信用彻底失望，虽然我不是受害者。从那以后我尽量会选用国外的服务提供商。

现在，在全球金融危机的影响下，大若Google都要出现类似的问题了。只不过，比起263，Google采用了很道德的方式。可以理解，当公司面临的问题是生存时，很可能别无选择。

我其实是非常依赖网络服务的：

• Gmail
• Google Bookmark
• Google Docs
• Google Reader
• Google Site
• Google Calendar
• Google Notebook
• Clipperz
• Dropbox
• Meebo
• 等等

这一次，我可有些害怕了。正在考虑一些desktop替代品。例如：

MS OneNote, Firefox, Keepass, Pidgin等等。还是自己的硬盘上的东东可靠啊。

项目才刚刚开始，就收获了不少教训！

CNPL项目才刚刚开始第一周，就收获了不少教训。

上周一的时候项目刚刚启动，PMO的人找我谈话，希望我能配合工作。我当然满口答应。

周二的时候，收到PMO发来的邮件，让我周四就需要提交：人力资源管理计划以及项目实施方案两个文档。这两个文档我在之前都没有听说过，仔细看了看PMO发过来的例子，才发现项目实施方案其实就相当于PMP中所说的完整的项目管理计划了。

于是加班加点写了所有能写的内容，周四的时候发了出去。其实这个时候需求访谈才刚刚开始，项目组内所有的人全都整天在客户方进行需求访谈。所以现在只能有需求访谈计划。我在发出去的邮件中还详细的注明了所有无法填写的内容的说明。

很快PMO就回了邮件，找出了很多问题。而且最郁闷的是，老板也回了邮件，针对我所注明的无法填写的内容一一批驳。话里话外好像是在说我的工作态度有问题。

于是我在周五的时候找我的二老板抱怨了一下。看来是传到老板耳朵里了，老板马上打电话过来安抚。而且，我看了一下老板批驳的邮件，还好，仅仅是发送给了我和二老板，并没有发送给PMO。所以心里也还好过了些。

由此事件，得出了以下一些教训：

1. 我本来真的很重视PMO的工作，因为我有8年项目管理经验，我是PMP，而且我也曾经是上一个公司的PMO部门经理。但是，现在在这一家公司，PMO的需求的优先级并不高，是很有协调余地的。前几个月我还在感慨这个公司对项目管理不重视，PMO的人地位也很低。现在看，可怜之人必有可恨之处啊。只给我两天的时间让我完成庞大文档，而且时机也很是不对，这让我不可能保证质量完成工作。
2. 我犯了一个错误：在项目初期就应该非常重视如何将工作分配到下属手中。
3. 我犯了另一个错误，在分析干系人需求时，非常重视客户方面的满意度，反而忽视了老板的需求。我本不该犯这样的低级错误的，可能是因为在这个公司当前的管理能力下，我对自己的管理经验过分自信了，以后一定需要注意。
4. 现在的客户的习惯是，一旦项目启动，就会立刻需要所有相关的文档。现在的公司也受其影响，老板养成相同的习惯。所以为了应对这样的特殊情况，需要在项目早期就写出非常详细的项目计划（甚至需要计划到9个月之后的某以前需要干什么）。当然，这样的文档没有任何实际意义，仅仅为了交差。而随着需求访谈的进行，项目范围渐渐明确了之后，才需要真正用功编写能够实际应用的项目管理计划。
5. 现在的环境下，项目经理管理工作还有更多的内容，甚至包括长期出差人员的住宿问题、办公场地的桌椅等等细节问题。这些在书本上是找不到的。

关于软件过程的比较

关于软件管理过程，目前敏捷过程最为热门。主要的敏捷过程有以下几种：XP 极限编程, SCRUM, FDD 特征驱动开发, DDD 领域建模驱动开发, ICONIX, ASD 自适应, CRYSTAL 水晶, DSDM, TDD 测试驱动开发, AMDD 敏捷建模。再加上“传统”的RUP。
浏览这些过程会发现这些敏捷过程所涉及的领域还是有所区别的。简单来讲，可以粗略的划分为管理过程和设计过程。例如：

• SCRUM：很明显是管理过程。在实践框架中提供了一些可以明确执行的实践指南。而其中对于设计方法或者过程基本没有什么要求。
• FDD：应该属于管理过程。其中明确了对项目的进行如何规划。而对设计方法所述比较少。
• ASD, CRYSTAL：属于管理过程，其中重点讨论对人的管理理念。管理框架具有很大的灵活性。
• DDD：属于设计过程，重点描述如何从业务需求导出到系统设计编码的过程。
• AMDD：属于设计过程。
• XP：比较特殊，不是完整的管理体系。而对设计过程也很少描述，仅仅提供了一些最佳实践。由于其要求非常明确，所以我觉得更接近与设计过程。
• TDD：应该不算是过程，仅仅是一种辅助设计的方法。所以经常被其它敏捷过程所引用。
• ICONIX：对管理过程与设计过程都有所涉及。不过更加接近于设计过程。
• DSDM：不太了解，无法分类。
  

基于此原因，所以经常可以看到将两种或者以上的敏捷过程组合进行应用的现象。如：SCRUM+XP, FDD+DDD等等。而AMDD和TDD更是经常被其他过程所引用。
不过这也侧面说明，这些敏捷过程往往内容都不够完整，或者说是针对性比较强。

现 在看来，敏捷过程的宣传者针对的往往是一些传统的重型过程，如CMM, ISO等等。而由于RUP内容比较复杂，所以往往也被算进来。这其实是由于对RUP的误解造成的。RUP被设计为统一过程，所以必然包罗万象，以便适应于 更多类型的项目。这就造成了RUP的复杂性，其实也说明了RUP内容的丰富。但是，当具体到某一个项目的时候，必然会根据项目特点或者企业环境因素对 RUP过程进行裁剪，以形成特色的过程。所以针对小型项目，RUP完全可能变成为非常“敏捷”的过程。
不过这也属于一个矛盾：1. 对于小型项目的项目经理来讲基本没有精力或者经验对整个RUP体系进行完整的研究。2. 如果缺乏对RUP体系的研究，就不可能对RUP体系进行恰当的裁剪。
基于这个矛盾，出现了很多伪RUP过程实践。
这样的现象是因为RUP中缺乏对一些比较典型的项目类型的具体指导和模版，来使项目经理可以快速的对RUP开始实践。而在这方面敏捷过程往往做得更好。例如XP过程，提出了明确的原则和实践指南，使得人可以非常简单清晰的学习和实践练习。
基于此，例如XP这样的过程就在程序员中很受欢迎，因为程序员多数项目管理经验不够充足，所有如果有简单而明确的实践规则的话，当然更容易付诸实施。
但 反过来讲，这些敏捷过程对项目类型的要求往往非常严格，例如，XP过程就会要求：项目组规模、办公地点、用户现场、合同类型等等。所以当人们将它应用与不 同的领域时又不得不对它进行改良或者采用其它的软件过程。在这方面RUP就会好很多，深入研究RUP可以使你用一种软件过程应对更多类型的项目。
ICONIX是所以受欢迎，就是因为它延续了RUP的思路而有提供了可明确参考的工作步骤。

当然反过来，对敏捷过程的误解也是存在的，例如：RUP的支持者往往认为XP过程没有设计。实际情况是XP过程也是相当重视设计的，只不过方式不同。XP过程不建议进行预先设计，而是使用其它的一些辅助手段保证软件设计的优化，例如TDD、重构等等。

再看看思维方式。新兴的敏捷过程往往宣传自己基于小型迭代，并以此来对应变更，使项目满足客户业务需求。但所谓迭代一词应该更加细分成：“增量开发”与“迭代开发”，之间的区别如图所示。

由此看来，如XP, SCRUM, FDD等过程其实都属于增量开发。而RUP和ICONIX过程属于迭代开发。所以，对此概念模糊的人就会误解RUP更像瀑布模式。
其实增量与迭代无所谓优劣，仅仅是思维方式的不同。

关于系统设计的文章摘抄

模型（Model）代表应用程序的数据（data）和用于控制访问和修改这些数据的业务规则（business rule）。通常模型被用来作为对现实世界中一个处理过程的软件近似。
视图（View）被用来组织模型的内容，它从模型那里获得数据并指定这些数据如何表现。
控制器（Controller）定义了应用程序的行为；它负责对来自视图的用户要求进行解释，并把这些要求映射成相应的行为，这些行为由模型负责实现。

有人提到MVC模式时说MVC代表了模型层、视图层、控制层，我觉得这是不对的。在经典的J2EE三层架构中，三层是分为Web层、业务层、持久化层；这个经典分层是基于分布式应用（EJB）的，也就说，Web层物理上是在Web服务器中， 业务层和持久化层物理上是在应用服务器中。在这种情况下，MVC只是属于Web层这一层的，而不是分为三层。在这种分布式应用中，视图就是JSP（如果采用的话），控制器就是Servlet（如果采用的话），而模型就是就是调用业务层的在Web层中的桩子。假如我们采用轻量级的SSH技术架构，视图还是JSP，控制器是Struts，而模型就是Spring＋Hibernate。这里最难理解的就是模型的概念。我觉得模型是有状态和行为的，那么Struts中的Action调用的Servcie方法就是模型的行为，而返回给JSP的DTO（DO）就是模型的状态。

对于一个页面请求，总要有个地方负责处理和页面跳转的地方，这个地方就是页面控制器。页面控制器有两种，一种是如Servlet的脚本文件，一种是如JSP的服务器页面。对于Java来说，JSP就是只应该用来显示动态的或静态的信息，而不是用来负责处理Request并Redirect页面，否则Servlet就要失业了。尽管一个Web程序可以全由JSP文件组成，但将控制甚至业务脚本杂乱的穿插在Tag中真的是太糟糕的实践了。

贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。
优点是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。当然Business Logic是依赖Domain Object的。似乎现在流行的架构就是这样，当然层次还可以细分。
该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，所以就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处理所有的业务逻辑，在POEAA(企业应用架构模式)一书中被称为Transaction Script模式。

充血模型：层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
它的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。
缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，因为Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。

贫血模型是对OO的 非常经典的诠释！数据交给s/g，业务全部交给业务对象来完成。耦合度很低，逻辑清晰，重构空间大！而且在业务逻辑上事务控制的关注点也小！但是也很明 显，业务对象做的事情实在太多了，在领域对象上这个叫做超职责。s/g和业务对象分工虽然明确但工作量截然不同， 也就是说这个对象的职责过于复杂，在一定程度上背离了细力度的OO模型原则。

网友: 对某一个实体信息的管理维护，是分出增加、删除、修改还是只看作一个维护用例？
UMLchina_潘加宇：关键是要找出CRUD背后可能隐藏的业务。
网友: 到底要画哪些图？序列图是必须的吗？
UMLchina_潘加宇：如果不是面向对象开发，只有用例文档是必须的，然后直接编代码都可以。如果是面向对象开发，需要用类图描述结构，顺序图分配责任。

Martin: 关于这些项目中不写文档的说法是荒诞的。文档和计划当然要做，不过他们不再是过程的一部分，而是过程中的一个任务。在敏捷项目中，会有很多任务，有些任务会包含文档化、项目计划等这些管理团队需要做的规范操作。但它们不再是过程的一部分，这句话的意思是说，它们的秩序不是固定的，我们不是一定要先写文档，也不是一定最后写文档，我们在写文档这个工作变得重要的时候来做它，它会和其它任务一样在日程中进行安排。

Martin: 对.NET开发者而言，在学习敏捷开发的过程中最大的挑战就是测试驱动开发。敏捷开发对单元测试和自动化接受测试的要求很高。TDD现在已经被全行业所接受了，就算你是微软，也是一样的。

那么测试代码是否可以完全取代自然语言形式的设计文档呢？我看还不行，原因有三：
其一，测试代码虽然比源代码容易理解，但它仍然是代码，不是所有人都能理解的；
其二，测试代码的宏观表达能力还是不如自然语言或图表；
其三，很多人习惯看文字而不是看代码，彻底改变人的习惯很难。
所以在TDD开发过程中，比较好的形式是自然语言的文档和测试代码相结合，用自然语言的文档做一个够用的设计就行了，这个设计只要详细到模块关系这一级别就足够了，各个模块的详细设计就由测试代码充当。

Q: 单元测试怎么能反映/代替需求 ?

A: 单元测试未必能直接反映宏观上的需求, 但

1. 功能测试和集成测试能够反映宏观需求.

2. 单元测试能够反映系统的其它部分对当前单元的需求.

而从文本的角度, 测试用例的名字就是需求的描述. 换句话说, 你从传统的需求文档中把描述抠出来, 放到测试代码中作为测试用例的名字, 你便拥有了可执行的需求文档

当你试图测试一个单元时, 却发现需要创建大量的其它对象, 而且按照你脑海中的实现, 有些对象是在单元内部创建的, 根本无法在测试环境中假冒它们. 这时候, 你即使只是为了减少测试的难度, 也会逼迫自己思考:

1. 这个单元是否做了太多的事, 承担了额外的职责, 违反了单一职责原则?

2. 是否应该把依赖让外界设置进来, 而不是自己在内部创建, 这样测试时就能把依赖设置为假冒的实现?

是的, 单元测试警示你思考一下自己的设计

业务流程建模与软件项目需求

在软件开发的阶段定义中，以前一直不太分得清需求阶段内部的子阶段划分。
在以前的项目中，我们仅仅出具软件功能需求文档，并且认为这份文档就是全部的项目需求文档。文档的内容主要包括：功能性需求的用例分析，用例内部的流程图（活动图），用例内部的系统原型，如果需要的话，还要加入模块以及的流程图和系统的WHOLE PICTURE，其他内容（包括：非功能性需求，项目业务目标，名词解释，设计人员等等）。

到新的公司之后，刚刚进入了物流项目组大约一个月，发现软件需求中的业务需求和功能需求还是有所区别。
在项目的早期，我们需要对客户的应用系统所涉及的业务逻辑和业务流程进行分析，并形成业务需求文档。这一份文档的目的是能够是项目组的相关成员对客户的业务有更好的理解，或者是新进入项目组的成员能够对项目的业务背景有一个比较完整的认识。准确的定义客户的业务需求对后面的软件需求分析具有指导性的意义。在这份文档中，将主要使用业务流程建模工具，如数据流图、工作流程图、UML活动图等等。
在分析的业务需求之后，进入到软件功能需求阶段。在这个阶段，将根据将来的系统建设需要对业务需求中所涉及到的功能进行重新的拆分组合排序，并进行一些补充。使之更加贴近设计人员的需要。在这个阶段的产物软件功能需求文档中，将会更多的将用户业务的语言翻译成为软件开发专业的业务描述。这份文档的目的是直接作为系统设计的输入，并能够指导开发工作，所以其还需要能够比较容易的进行任务分解。在这份文档中，将会更多的使用用例分析和业务领域分析、原型设计等工具。

目前新公司的物流项目正处于早期的业务调研阶段。在这一段时间内，我目前正在了解有关业务流程建模的工具。以前一直是在使用UML的活动图，但是总觉的其表现力还是不够丰富，所以也经常在使用跨职能的流程图进行辅助。最近查阅了相关的资料发现，UML在业务流程建模领域的确是弱项。在这个领域现在有很多成熟的工具和理论。最典型的是BPMN和EPC。
BPMN图是官方组织发布的专门用于业务流程建模的规范。目前的版本大约是2.0。图例非常丰富——不下50多个。也有很多专门的绘图工具，其中包括免费的产品BizAgi Process Modeler和很多基于Visio的图例插件。不过，对于如何规范的规制业务模型的资料，网上却少得可怜。
EPC图不是行业标准或者规范。但是由于能够绘制EPC图的软件ARIS被内嵌在了者名的SAP软件中，所以EPC图基本上是事实上的行业标准。EPC图例并不复杂，但却能组合起来清晰的表现业务流程。
所以在现在的项目中，我尝试的使用EPC图的方式进行了一些业务流程的说明。当然，在使用的过程中，我对EPC的图例进行了微小的扩展。
下面是我做的一个EPC图的例子。

关于业务模型分析的绘图需求

在业务模型分析过程中，发现有以下的一些绘图需求：

• 需要能够表达工作流程。
• 需要能够表达系统的功能。
• 需要能够表达工作流程中的动作。其中最好能够区分关联到系统功能的动作和系统外部的动作。
• （系统功能和流程中的动作或许可以等同对待）
• 需要能够表达系统功能的输入和输出，可能是：纸质的单据，电子数据或者业务对象。
• 需要能够表达操作系统功能的系统角色以及其所属的组织结构。
• 需要能够表示出发系统功能的事件。或者系统功能完成之后的流程状态。
• 需要能够表达流程分支的情况，例如：and, or, xor，并行等等。
• 需要能够对某一个系统功能或者动作进行扩展。例如某一个系统功能中可能会有其子流程。
• 需要能够对上述的业务对象以及系统角色进行“引用”方式的绘图，以便统一管理。
• 可以对业务对象进行详细设计（类图）。
• 最好能够附带对某一节点关联系统页面原型的设计功能。

目前正在参考以下一些工具，但似乎都不能完全满足需求。当然也有可能是没有完全发掘以下一些工具的全部功能。

• UML活动图+UML类图
• EPC图（Event-drive Process Chain）
• Serena Prototype Composer工具

Google Chat可以Video

今天一早打开GMAIL主页，在左上角发现了一个新的链接：New! Video chat
点击之。
发现被自动引导至www.google.cn主页，奇怪。
于是重来一遍，在浏览器刷新的过程中使用ESC，遂看到video chat页面。再次使用该方法，终于下载了google video chat插件。

OK，现在在gmail主页中发现了video chat设置，成功。

应用软件设计需要原型设计工具

依据ICONIX过程与AMDD方法，敏捷设计的过程可以大致总结为以下的几个步骤：

1. 进行用例分析（或者用户故事），同时设计初步的域（domain）模型。
   输出：初步用例、领域模型
   
2. 同时参照用例和领域模型进行系统健壮性分析（robust）。
   输出：健壮性分析图、更新的用例、初步细化的系统类图（由领域模型而来）。
3. 参照健壮性分析图，进行系统详细设计——画出UML顺序图。
   输出：顺序图（针对每一个用例至少一个顺序图）、最终细化的系统类图。

以上过程比较清晰，其中robust分析过程是为了弥补用例分析用顺序图之间的GAP而加入的过程。
不过，在第二步与第三步之间，如果能够加入原型分析（界面草图与页面流程），则其输出文档显然比系统顺序图更加直观。系统原型分析的结果能够更加有助于编程人员对与系统需求的理解，而这一步也是AMDD方法建议的步骤。
所以建议加入一步：
2.5. 依据用例分析文档，健壮性分析进行系统原型设计
输出：原型分析文档（页面流程图、系统界面草稿）

你现在在使用什么工具进行系统原型设计？MS Visio, Powerpoint, yEd, Dreamwaver, Flash还是纸和笔？（Sparx EA中虽然集成了界面设计工具，但是毕竟太过简单了）
其实现在已经有很多专业的原型设计工具了，主要的有以下几种：

1. Axure RP
   
2. Caretta GUI Design Studio
3. iRise Studio
4. Elegance Lucid Spec
5. Mockup Screens
6. OmniGraffle (only for MAC)
   
7. Balsamiq Mockups
   有免费版本，但是有功能限制（不能保存，只能其他工具进行抓图了）。但是画出来的图是手写风格的，真的非常漂亮。
   
8. Serena Prototype Composer (free)
   免费版本，功能非常齐全（建立项目、多层次的流程设计、界面设计、数据流转设计等等）。
   
9. Pencil (firefox addon)
   居然是作为firefox插件形式的产品。免费。虽然只有界面设计功能，但是已经足够令人惊奇的了。

以上产品功能各具特色，都是很成熟的产品，而且非常容易使用。但是值得提到的是Serena Prototype Composer，使我们可以免费的使用到高品质的产品，强烈建议使用。

完美To-do List: Toodledo

使用很多年to do list工具了。但是越来越发现难以找到能够完全满足要求的。

结合GTD理论以及柯维的First Things First理论，现在总结需求如下：

1. 需要能对任务的内容（context）进行分类
   
2. 需要能对任务的状态（status）进行分类（next action, action, waiting for, sometimes, finish...）
   
3. 另外，各种任务有以下区别：
   

a. 某一阶段的目标Goal
b. 日常工作
c. 特定日期需要完成的任务Task
d. 某段时间需要不停关注，例如：项目（project），一般有起止时间。
e. 仅仅是某些想法，记录以备参考。Reference

1. 任务管理需要能够集成日程表（calendar）
   
2. 结合日历，可以每天记一些工作日志（相比BLOG应该更加偏向于一些机械性的工作内容）。
   
3. 任务（task）不等于日程（appointment）
   

可用的软件中：

• outlook理念落后（outlook2007还可以，但也不完全匹配）
  
• GTD类软件普遍功能简单，而且不能集成日程表
  
• Google Calendar只有日程，没有任务。
  
• PlanPlus过于笨重，而且价格不菲。
  

直到最近看到了www.toodledo.com，发现其可以完全满足上述需求。而且还有额外的功能：

• 集成Google Calendar
  
• 合作与共享
  
• 其他功能还在摸索中。
  

不过强烈建议使用。

新款密码管理工具： LastPass

经常上网的人，有许多username和password需要记住，例如：电子邮箱，网上银行，网上购物，论坛，求职网站，BLOG，社区网站，同学录等等等等。

想全部记住不同的密码，很难；全部使用相同的密码，极不安全。于是乎出现了很多密码管理的软件来帮助人们记住密码。流行的软件有以下一些种：

1. AIRoboForm：这个领域最著名的产品。功能十分强大，使用方便，能够集成多种浏览器。能够自动识别网站切进行登录，能够管理注册表单，还能够记录一些与网站无关的个人保密数据。唯一的不足是无法进行网络存储且同步。虽然是收费的软件，但物有所值。
   
2. KeePass / ALPass：免费产品。KeePass的缺点是操作比较繁琐。ALPass的缺点是仅仅支持IE浏览器。而且两款软件的数据也都是本地存储。
   
3. Firefox插件，如Magic Password：免费产品，使用方便。这类软件多是利用网站的关键字和用户设置的主密码来自动计算网站登录的密码。优点是生成的密码非常规范，不易破解，而且没有任何数据进行本地或网络存储，非常安全。缺点是仅仅支持Firefox浏览器，且对插件的依赖性很大。
   
4. 密码管理网站：优点是对本地系统没有任何要求，只要有浏览器即可，网络存储，所以随时可以使用。缺点是操作非常不便，基本上需要手工维护。典型的如：豌豆网, PassPack, Clipzz等等。
   
5. 浏览器自带的密码管理功能，如IE, Firefox, Opera。功能往往很弱且不完整。
   
6. Google Browser Sync：现已停止下载，主要是将Firefox的各种数据（包括书签、密码、Cookie等）同步到GMAIL帐号中。非常方便，缺点是只支持Firefox浏览器。
   

新产品LastPass与众不同：

• 集成不同的浏览器，包括IE和Firefox。
  
• 帐号密码网络加密存储，所以不需要进行备份。
  
• 能够进行自动识别与自动填充，操作方便。
  
• 能够自动生成密码，也可以手动输入密码，所以对软件本身没有很强的依赖。
  
• 能够导入流行的密码管理软件的导出数据，包括：AIRoboForm，KeePass等。
  

结论：强烈推荐使用。

Redmine试用

由于project server庞大而且安装使用复杂，所以正在考虑使用一些轻量级的项目管理软件。暂时选中Redmine。

1. 安装

• 安装instantrails
• 启动instantrails服务
• 使用phpmyadmin在mysql中建立数据库
• 配置database.yaml
• 启动webrick

1. 特色

• 建立项目
• 建立子项目
• 自定义项目角色
• 自定义角色的权限
• 自定义问题状态流程
• 自定义问题状态
• 自定义跟踪标签
• 自定义版本（相当于里程碑）
• 自定义问题类型
• 分配任务
• 任务日历
• 任务甘特图
• 项目成员根据问题（相当于任务）填报工时
• 灵活的工作量统计报表
• 基于项目的wiki
• 基于项目的文档管理
• 基于项目的论坛
• 上传文件
• 新闻/公告
• 系统活动跟踪
• 里程碑状态报告
• 个人的dashboard
• 缺陷跟踪（问题跟踪）
• 多语言支持，多时区支持
• email自动发送
• 导出到csv/pdf…
• 版本控制支持（包括subversion, cvs等等）

1. 没有的功能

• 人员成本
• 项目预算
• 问题不能有子问题（问题不能分层）
• 问题只能分配给一个成员
• 版本控制不支持：vss, clearcase, starteam
• 甘特图的显示细节无法进行自定义
• 没有pert图
• 无法定义项目流程规范（模板）
• 虽然可以进行缺陷跟踪，但是很遗憾无法同时集成test case管理（如果testlink能够集成redmine就好了）

结论：

• 基于项目组级别的项目管理软件，轻量级的，足以应付一般的软件管理。
• 不具备企业级的功能，但是如果能够配合一些管理手段的话，也足够用了。
• 对于一款开源的产品来讲，Redmine已经非常出色了！

谈谈人员素质

在国内的现状就是这样的：由于IT行业人员需求量大，而且平均工资水平也还过得去，所以有大批的人才虽然从性格、爱好、综合素质等多方面来看并不适合这一行业，但是出于就业的考虑，也加入了这一行。
在上一家软件外包公司，我参与了3年的毕业生招聘工作，就是说，招聘部门负责面试综合能力，我来负责面试技术。中国的高校发展参差不齐，所以我明白我不能过分苛求应届的毕业生要有某某项目的实战经验。于是乎，我对毕业生的考察以课内的基本功为主。

数据结构：
第一题：没有指针机制的情况下，如何实现链表结构？（只有20%左右的人能够回答出使用数组，其中又有一半的人是蒙的而不知道如何实现。）
第二题：哈夫曼编码的作用是什么？（大约60%的学生能够提供正确的答案。）
第三题：列举出你所知道的排序算法的名称，仅仅是名称就可以？（大约90%的学生回答出了冒泡排序；有70%的学生同时回答出了插入排序；又有20%的学生同时答出了快速排序；在我的印象里，几乎没有人能够提及谢尔排序、归并排序和堆排序等等。）
操作系统：
第一题：请解释一下什么是进程死锁？（令我吃惊的是，大约只有40%的学生能够让我确认他正确理解了进程死锁。）
第二题（如果你正确回答了第一题的话）：最常用的避免进程死锁的方法是什么（提示：教材中所讲解过的）？（只有10%的人能够想起来PV信号灯）
第三题（如果前两道都答对的话）：请解释一下操作系统的内存分页管理机制？（要求不高，能够提及局部性原理即可，但是只有零星几个人能够通过）
数据库原理：
第一题：请列举出数据库表设计原则中，都有哪几种范式？（大约60%的人能够说出第一到第四范式）
第二题（如果答出第一题的话）：其中那一种范式又叫做正规范式？（只有20%的人回答是第三范式，其实说第三范式也不准确，不过马马虎虎就算过了）
C语言：
第一题：在struct中可以定义属性，但能否同时定义函数？（当然不可以，否则不成了class？这道题难住了40%的学生）
第二题：函数能否作为另一函数的参数？（呵呵，我相信很多人听到这个问题的时候都蒙了）

其实我从心里最想问的问题是：你们大学4年都学什么了？

我在上大学期间绝对不是什么好学生，在班里排名中等，逃课作弊不在话下，所以对不用功的学生绝对没有仇视心态。不过，我的同学当中，就算最不用功的学生也会非常用心的去听数据结构课程，因为我们都知道：我将来想干这个行业，就得指着这个吃饭啊。我们公司的生源学校也不全是二三流的学校，也包括了几个211工程中的国家重点院校。
不过，在面试的学生中，有两类人回答问题的结果不错：一是考研失败的学生，因为这些内容他刚刚复习过的（课程年了两遍，效果当然不同）；二是工作几年之后又读了硕士的研究生毕业生，因为这些人在读研的时候更清楚自己想要学些什么。

我曾经面试过这样一个研究生毕业生，上面的所有问题对答如流，于是，我稍稍来了一点比较邪恶的：
问：C语言，现在有a, b两个变量，想把它们的值交换过来，有什么方法？
答：比较通常的做法是使用第三个临时变量，不过使用“异或”更有效率。

回答完这个问题之后，我告诉人力资源部门：这个人应该高于普通研究生入职标准2000元的水平进行招聘。后来我就再没有见过这个学生，很遗憾，可能多给2000还是少了点，要不然就是老板没有批准我的建议。

再说说在职人员的招聘。
由于以前的公司是做业务应用系统的，所以程序员需要天天和数据库打交道，SQL语句经常使用。所以在招聘的时候，我可以不太看重程序员对编程语言的熟悉程度，但是SQL语句必须熟练。针对这点，我编了两道SQL语言的笔试题。题目不太复杂，第一道主要是考group by 和case when，第二道主要是考union。我准备给候选人们半个小时的时间来完成这两道题。但是这两道题可是难住了一大部分前来面试的候选人。以至于我在怀疑这两道题是不是太难了？
于是我将这两道题发给了两个同事来做测试，其中一个是项目经理，另外一个是作为初级程序员的一个小女生。5分钟之后项目经理交卷。15分钟之后初级程序员交卷。两个人提供的答案和我的参考答案几乎完全相同。

有意思的是，后来我通过MSN MESSENGER将这两道题发给了我一个正在读研的师妹。大约半小时之后，答案发送回来。其中第二道题的答案思路非常奇特，我仔细的看了之后，发现不仅能够得到正确结果而且比我提供的算法效率还要高一些！非常遗憾，我最终没能说服她毕业之后来到我们公司。当然，这对她个人来讲不是坏事。

说到算法效率，还有一个有意思的故事：
我们曾经有一次给客户开发一个业务应用系统。系统的报表功能中，有一个关于返修率的报表。在系统试运行期间，发现该报表无法得出结果。后来，我发现，程序员在生成报表的后台SQL语句中使用了函数，在当时的数据量情况下，粗略的估计这条SQL语句执行完毕需要80几个小时！I am shocked by the result!
我只得亲自出手在客户现场进行优化。2个小时之后，将报表的生成时间控制在了5分钟之内。
后来，其他的项目组在对该客户进行别的项目时，也用到了返修率报表。当时那个项目组的人员并不太清楚返修率报表以前的故事，所以委派他们组里的一个小女生来开发这个报表。结果呢？新开发的报表平均生成时间在15秒之内！I am shocked by the result again!

很遗憾，最终我没能在我的部门中留住这个小姑娘——她后来被人力资源的人偷偷的卖到客户现场去了。为了此事，我和人力资源的经理直吵到了副总经理办公室。但是木已成舟，也无可奈何了。

极限编程是否符合中国国情？

XP为什么不适合国内的现状？下面是我个人的一些看法。

针对极限编程的准则：

1. 用户故事
   先说说XP的描述：不需要在一开始完全了解需求，因为以后很可能会变化。不需要一开始就了解详细的需求，只需要到可以估算的程度就可以了，可以一边实现一边详细了解，因为有现场客户在。不需要详细的需求文档，代之以用户故事，因为沟通胜过文档，而且用户故事简单又容易编写。
   我的想法：用户故事体现了将需求分解为条目的思想，在这点上来说，是可取的。但是其他的说法就有问题了。
   首先是不需要一开始就完全了解需求的说法。对于互联网项目来讲，这种说法可能是正确的，因为需求变化非常快速。但是对于一般的业务应用系统来讲呢？需求会变化，但是关键的业务流程是相对比较稳定的。当你明明可以掌握全局的时候如果还要偏激的从局部开始着眼的话，岂不是有些钻牛角尖了？就好比要盖一座房子，在初期我可以不清楚将来的卫生间如何装修，但是总是需要在一开始的时候就了解需要打多深的地基吧？全面了解需求肯定有助于在项目开始时候建立正确的系统架构方案。
   其次是关于需求文档的问题。不可否认，在一定的项目规模内，有现场客户在，再加上充分的沟通，能够达到比文档更好的效果。但是，限定条件是不是太多了一点啊？大一点的项目，如果需要40个成员都需要和现场客户进行沟通怎么办？另外，我们知道，很多项目都会一期一期的做下去，铁打的营盘流水的兵，几期项目做下来，项目组成员甚至现场客户早就不是原来的人了，这些人靠什么来对项目进行了解呢？是不是项目组的老员工每个人都能够知道项目的所有细节呢？有很多情况，如果想要比较透彻的理解需求和业务，则需要对该业务的发展背景以及生成原因有所了解，程序员和测试人员当然有权了解这些。而这些当然都需要有文档来进行传承，仅靠用户故事显然不能胜任。有很多情况，我们需要从更高的层面来观察客户的业务，需要看到一张客户业务的全局性视图，而从用户故事那里我们能够得到什么呢，全部都是局部的片段。有很多时候，一些非常复杂的业务流程是技术人员和客户进行艰苦的讨论得出的成果，这些讨论的过程和结果如果不能够记录下来的话，早晚有一天，你会发现艰苦的讨论经常会重复的出现。
   第三，我们需要在项目初期就明确项目的business goal，明确项目边界，我们还需要明确项目的非功能需求，这些都是用户故事所无法承担的工作。
   最后，用户故事代替需求需要有一个非常严格的配合条件：必须要有现场客户，并且进行结对编程。
2. 紧急设计过程
   XP的原则：对于每个故事做少于15分钟的预先设计，主要设计工具是白板和CRC卡片，使用最简单的方式来实现眼前的问题。对于系统中出现的问题，使用重构来解决。
   我的看法：XP承认这样会带来一些问题，所以必须严格执行配合条件：持续的重构。
   同样，对于互联网项目来讲，有一定的道理，但也是局部的。而对于业务应用系统来讲呢？对于相对比较稳定的需求，我们仍然需要走到哪里设计到哪里并且修改的哪里吗？设计阶段多花些时间能够避免的问题依靠编码之后的重构来进行解决吗？重构的工作量会比预先设计的工作量小吗？（按照教科书的说法应该是被放大10倍了吧？）这不是人为的造成的浪费吗？你的客户除非就是你某个uncle，能够允许你如此糟蹋他的资金。
   中国古人扁鹊曾经介绍：真正的医术高手其实是他的师兄，但是他的师兄为什么没有他的名气大呢？因为扁鹊的师兄总是在别人的健康又出现问题的前兆的时候，就已经出手化解了。（这才是高手中的高手啊！）亡羊补牢虽不算晚，但是防患于未然岂不是更好？
   事无巨细的预先设计是不现实的，但是完全省略也不是个办法。
   设计文档需要吗？显然非常需要。还是那句话，很多项目是需要进行延续的。对于一个新的项目组成员来讲，源代码就算再规范，其可读性也比不上设计文档。做人真的不能只想着自己方便……
   说的更远一些，你的项目组中的经验丰富的有设计能力的成员将无法充分发挥他的聪明才智。他将经常看到别的一些经验不够多的程序员对子写的低水平代码，然后对他们进行重构。这种感觉就像经常需要给别人擦屁股。
3. 现场客户
   XP的原则：客户长期与开发人员在同一间办公室办公，随时解决开发人员关于需求的问题。现场客户负责编写用户故事，负责决定用户故事的优先级以及实现顺序。现场客户负责编写验收测试用例。
   说说实话吧，你见过这样的客户吗？
   哪个客户的公司能够安排一个全职的客户代表来参与到项目中呢？如果真的安排了一个客户代表的话，他真的能够全面了解需求并对之进行把握吗？
   哪个客户公司的客户代表有能力完成这些任务呢？如果有的话，我看其他的XP原则就算都不坚持，项目结果也不会差到哪里去，因为你的客户代表本身就应该是一个很有经验的项目经理了。
   我们对客户的要求过高了一点点吧？
   而且，如果你所负责的项目的业务在客户公司是跨部门的，那该怎么办？每个部门派一个客户代表来吗？
   我看最有希望实施现场客户原则的项目应该是那种为公司内部开发的业务系统。即便如此，也很玄。
4. 小型发布
   XP的原则：每隔一到两个月对客户进行一次系统发布，尽量早的让客户看到可执行的系统。
   我的看法：非常好。但是发布规模小到什么程度不能一概而论，只能说是尽量小。要做到小型发布，则必须先实现持续集成，否则很难承担多次的发布成本。
5. 规划
   XP强调了对每个迭代进行规划。
   我的看法：XP的说法并没有错，只是还缺了一些东西。我们需要对整个项目进行规划，虽然越远期的计划可能越粗略，但是还是很有必要的。
   软件开发的合同不仅仅只是要求“我限定你这些时间，你看你能完成什么？”，还会要求“我需要完成这些功能，你看看你需要多长时间？”所以，做到哪里算哪里的想法似乎只能存在于政府或高校的研发部门吧。
6. 隐喻
   在XP中，隐喻用来使项目成员对于系统的实现方式达成共识，但是似乎XP的教科书中对隐喻也没有进行很透彻的讲解。
   在我看来：隐喻是设计和沟通的辅助手段，适当的应用效果理想。但是也仅仅就是一种辅助手段而已。
7. 简单设计
   XP的原则：力求使用最简单的方式实现当前的需求。简单的就是最好的。
   我的看法：这个说法本身就非常模糊，无法度量。简单与复杂都是相对的，仅仅存在于人们的头脑中，我觉得简单的问题可能你就觉得非常复杂。现实当中无法一概而论。
   另外，所有的时候最简单的就是最好的吗？典型的如8皇后问题，8重循环是最简单的解决方案……
   其实我们所追求的应该是不做不必要的复杂设计。
   同样，如果需要保持简单设计原则有效，则必须配合重构原则。
8. 结对编程
   XP的原则：结对编程的优势在于：代码会被100%review，有效地降低代码缺陷率，提供了很好的机会进行知识传递，使每个成员都有机会了解系统的全貌，提高生产效率。更换结对的周期从半天到3天不等。
   我的看法：结对编程优点与缺点都很明显。
   每个项目组的成员都是有自己的特长和喜好的。最成功的管理是充分发挥每个人的优势，而不是将每个人编程一模一样的编程机器。有的人一边讨论一边工作时思维会更加活跃，而有的人则是喜欢独自安静的思考。同样，遇到不解的问题时，有的人喜欢立刻向别人请教，有的人喜欢现场是自己解决。我们必须面对这些差异性，而不是试图将它们消除。从这个方面来讲，XP显得不那么以人为本。
   开发人员作为技术人员群体，其中有相当一部分人个性很强但主动沟通能力不足。在国内，这样的情况则更为夸张一些。而往往这些技术强人在项目组成员当中有很有影响力。在这样的情况下，如果我们不得不强迫进行结对编程的话，我想，管理层后面将面临非常棘手的问题。
   结论：结对编程是好东西，但需要根据具体情况适度运用。要想进行结对编程，必须具备项目组统一的编码标准。
9. 代码集体拥有
   XP原则：项目组的所有开发人员有权更改所有的代码。每个人都对所有的代码负有责任。
   我的看法：容易落入的陷阱是：没有人对代码负有责任。
   代码集体拥有的前提是结对编程。否则的话，这就是一句空话。
   编程有时候和体育竞技有些类似的地方：高手的某个出招（实现技巧）在庸手看来是非常愚蠢的。在这样的情况下，庸手会根据代码集体所有权理直气壮的对高手的精品代码进行重构……
   结论：代码集体拥有可以实施，但是不能简单处理，需要进行更多的沟通和一些技巧。
10. 持续集成
    XP原则：开发人员坚持随时进行提交，系统每天一次集成。
    我的想法：这是很好的原则。但愿我们能够做到。
11. 编码标准
    XP原则：实行项目组统一的编码标准，严格执行。
    我的看法：这是最基本的。而且越严格越好。我们时刻需要提醒自己：软件项目的产出是产品而不是艺术品。开发人员的想象力不需要浪费在这样的地方。每个人写的代码不仅仅是给自己看的。
12. 测试先行
    XP原则：对于每一个用户故事，在开始代码之前，现场客户就需要编写验收用例，而开发人员需要先编写单元测试。这样能够保证每一个用户故事是可测的而且是自动化测试。
    我的看法：这是个非常令人憧憬的奋斗目标。但是，理想很美好，现实很残酷。
    作为一个典型的国内软件公司来讲，你所处的项目小组是什么样的人员素质呢？如果项目组有10个人的话，那么其中3 个有经验的开发人员，具有一定的设计能力。3个经验稍差的熟练工，另外大约还会有2个应届的毕业生。2个专职的测试人员，大约1-2年的工作经验。这应该算是平均水平了吧，很多团队连这个水平也达不到。这样一个团队存在什么问题呢？
    开发人员不会做测试，更加不会写测试用例。个别开发人员甚至不太清楚单元测试是程序员的责任之一。测试人员不会写代码，多数都是高校it专业能力不足的毕业生，接收单位经考察认为无法胜任开发工作，所以就去做测试吧。并不夸张，现状就是如此。
    在这样一个团队中强制执行测试先行，简直就是自虐。
    要实现这样的目标需要循序渐进：第一步要求编码人员自己完成单元测试并养成习惯，要求测试人员能够撰写全面的系统测试案例；第二步要求编码人员能够编写单元测试代码，要求测试人员能够运用自动化测试工具进行回归测试；第三步要求编码人员将单元测试编码工作提前到编程之前进行，要求测试人员提前根据需求编写自动化测试脚本。
13. 重构
    XP的原则：随时对代码进行重构，要进行残忍的重构。
    我的看法：有时候重构是必需的，但是重构不能代替预先设计。
    进行重构时也需要小心，基于两个因素：
    第一，你的项目组成员有没有能力进行正确的重构？中国的开发人员有百分之多少充分理解了设计模式呢？而耐心学习过重构的人会更少一些吧？我看你还是现在项目组内部做一些技术培训再说吧。
    第二，你的老板或客户能否允许你这样做？重构是一件需要消耗成本、不产生利润又需要冒很大风险的活动，至少表面看上去是这样的。去说服你的老板支持你的做法对每个人来讲都是挑战。
    实施重构原则的前提是：必须实施代码集体拥有原则。
14. 每周工作40小时
    XP原则：加班只会造成质量低下，要坚持每周工作40小时。
    我的看法：这个不难，我所管理的项目没有实施XP，也都轻松实现了这个原则。

上面就是我对极限编程的一些看法，极限编程并非一无是处，而是不适合中国国情。而且极限编程的各个实施原则之间是紧密耦合互相补充的，所以很难进行裁剪。

在我看来，极限编程的最大问题就在于“极限”二字。“水满则溢，月盈而亏”是国人都明白的道理，所以对于极限编程而言，我们都需要问一句：“把所有的事情都做到极端就好吗？”

最后，推荐ICONIX过程，一个相对比较中庸的敏捷过程，实施起来也不困难，指导明确，效果明显。