一、自恋型注释

（注：原文为Proud，我觉得“自恋”更好一点）

public class Program
{
    static void Main(string[] args)
    {
        string message = "Hello World!";  // 07/24/2010 Bob
        Console.WriteLine(message); // 07/24/2010 Bob
        message = "I am so proud of this code!"; // 07/24/2010 Bob
        Console.WriteLine(message); // 07/24/2010 Bob
    }
}

原文：这样的程序员对于自己的代码改动非常骄傲和自恋，所以，他觉得需在在这些自己的代码上标上自己的名字。其实，一个版本控制工具（如：CVS或Subversion）可以完整地记录下所有的关于代码的改动的和作者相关的一切信息，只不过不是那么明显罢了。

陈皓：我同意原文的观点。在我的团队里也有这样的事情发生。有段时间我认真思考过这样的事情，是否应该把这样的事情在代码中铲除出去。后来，我觉得，允许这样的行为并不一定是坏事，因为两点：

1. 调动程序员下属的积极性可能更为重要。即然，这种方式可以让程序员有骄傲的感觉，能在写代码中找到成就感，为什么要阻止呢？又不是什么大问题。
2. 调动程序员的负责任的态度。程序员敢把自己的名字放在代码里，说明他对这些代码的信心，是想向大家展示其才能。所以，他当然知道，如果这段他加入的代码有问题的话，他的声誉必然受到损失，所以，他敢这么干，也就表明他敢于对自己的代码全面的负责。这不正是我们所需要的？！

所以，基于上述考虑，我个人认为，从代码的技术角度上来说，这样的注释很不好。但从团队的激励和管理上来说，这样的方式可能也挺好的。所以，我并不阻止也不鼓励这样的注释。关键在于其是否能有更好的结果。

二、废弃代码的注释

public class Program
{
    static void Main(string[] args)
    {
        /* This block of code is no longer needed
         * because we found out that Y2K was a hoax
         * and our systems did not roll over to 1/1/1900 */
        //DateTime today = DateTime.Today;
        //if (today == new DateTime(1900, 1, 1))
        //{
        //    today = today.AddYears(100);
        //    string message = "The date has been fixed for Y2K.";
        //    Console.WriteLine(message);
        //}
    }
}

原文：如果某段代码不再使用了，那就应该直接删除。我们不应该使用注释来标准废弃的代码。同样，我们有版本控制工具来管理我们的源代码，在版本控制工具里，是不可能有代码能被真正的物理删除的。所以，你总是可以从以前的版本上找回你的代码的。

陈皓：我非常同意这样的观点。只要你是废弃的，就应该是删除，而不是注释掉。注释并不是用来删除代码的。也许你会争论到，在迭代开发中，你觉得被注释的代码很有可能在未来会被使用，但现在因为种种问题暂时用不到，所以，你先注释着，然后等到某一天再enable它。所以你注释掉一些未来会有的程序。在这样的情况，你可以注释掉这段代码，但你要明白，这段代码不是“废弃”的，而是“临时”不用的。所以，我在这里提醒你，请不要教条式地在你的程序源码中杜绝这样的注释形式，是否“废弃”是其关键。

三、明显的注释

public class Program
{
    static void Main(string[] args)
    {
        /* This is a for loop that prints the
         * words "I Rule!" to the console screen
         * 1 million times, each on its own line. It
         * accomplishes this by starting at 0 and
         * incrementing by 1. If the value of the
         * counter equals 1 million the for loop
         * stops executing.*/
        for (int i = 0; i < 1000000; i++)
        {
            Console.WriteLine("I Rule!");
        }
    }
}

原文：看看上面的例子，代码比注释还容易读。是的，大家都是程序员，对于一些简单的，显而易见的程序逻辑，不需要注释的。而且，你不需要在你的注释中教别人怎么编程，你这是在浪费时间去解释那些显而易见的东西。你应该用注释去解释你的代码功能，原因，想法，而不是代码本身。

陈皓：非常同意。最理解的情况是你的代码写得直接易读，代码本身就是自解释的，根本不需要注释。这是最高境界。注释应该说明下面的代码主要完成什么样的功能，为什么需要他，其主要算法怎么设计的，等等。而不是解释代码是怎么工作的。这点很多新手程序员都做得不够好。别外，我需要指出的是，代码注释不宜过多，如果太多的话，你应该去写文档，而不是写注释了。

四、故事型注释

public class Program
{
    static void Main(string[] args)
    {
       /* I discussed with Jim from Sales over coffee
        * at the Starbucks on main street one day and he
        * told me that Sales Reps receive commission
        * based upon the following structure.
        * Friday: 25%
        * Wednesday: 15%
        * All Other Days: 5%
        * Did I mention that I ordered the Caramel Latte with
        * a double shot of Espresso?
       */
        double price = 5.00;
        double commissionRate;
        double commission;
        if (DateTime.Today.DayOfWeek == DayOfWeek.Friday)
        {
            commissionRate = .25;
        }
        else if (DateTime.Today.DayOfWeek == DayOfWeek.Wednesday)
        {
            commissionRate = .15;
        }
        else
        {
            commissionRate = .05;
        }
        commission = price * commissionRate;
    }
}

原文：如果你不得不在你的代码注释中提及需求，那也不应该提及人名。在上面的示例中，好像程序想要告诉其它程序员，下面那些代码的典故来自销售部的Jim，如果有不懂的，你可以去问他。其实，这根本没有必要在注释中提到一些和代码不相干的事。

陈皓：太同意了。这里仅仅是代码，不要在代码中掺入别的和代码不相干的事。这里你也许会有以下的争辩：

1. 有时候，那些所谓的“高手”逼着我这么干，所以，我要把他的名字放在这里让所有人看看他有多SB。
2. 有时候，我对需求并不了解，我们应该放一个联系人在在这里，以便你可以去询问之。

对于第一点，我觉得这是一种情绪化。如果你的上级提出一些很SB的想法，我觉得你应该做的是努力去和他沟通，说明你的想法。如果这样都不行的话，你应该让你的经理或是那个高手很正式地把他的想法和方案写在文档里或是电子邮件里，然后，你去执行。这样，当出现问题的时候，你可以用他的文档和邮件作为你的免责证据，而不是在代码里干这些事。

对于第二点，这些需求的联系人应该是在需求文档中，如果有人有一天给你提了一个需求，你应该把其写在你的需求文档中，而不是你的代码里。要学会使用流程来管理你的工作，而不是用注释。

最后，关于故事型的注释，我需要指出也有例外的情况，我们团队中有人写注释喜欢在注释或文档里写一些名人名言（如 22条经典的编程引言，编程引言补充，Linus Torvalds 语录 Top 10 ），甚至写一些小笑话，幽默的短句。我并不鼓励这么做，但如果这样有利于培养团队文化，有利于让大家对工作更感兴趣，有利于大家在一种轻松愉快的环境下读/写代码，那不也是挺好的事吗？

另外，做为一个管理者，有时候我们应该去看看程序员的注释，因为那里面可能会有程序员最直实的想法和情绪（程序员嘴最脏??）。了解了他们的想法有利于你的管理。

五、“TODO”注释

public class Program
{
    static void Main(string[] args)
    {
       //TODO: I need to fix this someday – 07/24/1995 Bob
       /* I know this error message is hard coded and
        * I am relying on a Contains function, but
        * someday I will make this code print a
        * meaningful error message and exit gracefully.
        * I just don’t have the time right now.
       */
       string message = "An error has occurred";
       if(message.Contains("error"))
       {
           throw new Exception(message);
       }
    }
}

原文：当你在初始化一个项目的时候，TODO注释是非常有用的。但是，如果这样的注释在你的产品源码中出现了N多年，那就有问题了。如果有BUG要被fix，那就Fix吧，没有必要整一个TODO。

陈皓：是的，TODO是一个好的标志仅当存在于还未release的项目中，如果你的软件产品都release了，你的代码里还有TODO，这个就不对了。也许你会争辩说，那是你下一个版本要干的事。OK，那你应该使用项目管理，或是需求管理来管理你下一个版本要干的事，而不是使用代码注释。通常，在项目release的前夕，你应该走查一下你代码中的TODO标志，并且做出决定，是马上做，还是以后做。如果是以后做，那么，你应该使用项目管理或需求管理的流程。

上述是你应该避免使用的注释，以及我个人的一些观点，也欢迎你留下你的观点！

二者之间的竞争会演变成为一场“战争”吗？（现在甚至出现了可以把Flash转成Javascript/HTML5的工具）

首先需要弄清楚二者之间最主要的区别，HTML 是一种语言（超文本标记语言 – HyperText Markup Language），而 Flash 是 Adobe（其收购了Macromedia）公司的一个浏览器插件（Plugin）。HTML5 目前还是 W3.org 规范中一个草案，这意味着其还没有最终定案，希望到 2012 年这项工作能够完成。

以下是二者各自的一些特点：

HTML5

这个新的技术更为易学和易用，比较 .FLA 和 .SWF 文件更容易编辑。并且基本上过去所有由 Flash 才能制作的动画效果都能够使用 JS + HTML5 + CSS 3 来完成，不过工作量可能会更大一些，不仅文件尺寸会增大，性能方面也会有影响。

以前为 Web 表单设定风格我们一定需要使用到 JavaScript， 但是 HTML5 中的 contenteditable 属性让我们可以做得更多。一些新的输入类型（Types of Inputs）也被加入到 HTML5 中，如：电子邮件，数字，值范围等等。

用户不仅仅需要一个支持 HTML5 的浏览器，还需要 CCS 3 和新的 JavaScript 引擎的支持。

免费（不包括第三方字体和音频视频等等）

更好地移动设备支持（HTML5 正在被运用于 iPhone，iPod，iPad 和 Android 应用的开发）

拖拽，事实上这不是 HTML5 的一部分，但是在新版本的 GMail 中，从桌面拖拽文件到浏览器能够用 HTML5 很好地实现。对于 Flash 我不知道这是否可以实现？

Flash

文件经过压缩，所以文件尺寸会比 HTML5 + CSS + JavaScript + 图像 + 其他 小。

硬件优化

需要安装 Flash 插件， Android 2.2（代号 FroYo）同样支持 Flash 插件。

Adobe 在它的 Creative Suite 5 中包含了 Flash Builder 4.0。

也许对很多人来说，相对于 HTML + JavaScript + CSS，Flash 应用 更难于“破解”。

以下是一些 Flash 能够实现而 HTML5 + JavaScript + CSS 3 不能的功能：

• 增强现实（Augmented Reality）
• 3D
• 真正的面向对象，而非原型（Prototyping）
• 对麦克风和摄像头的支持（事实上 HTML5 已经宣布要提供这些支持）
• 混色模式（如：渐进色，重叠色等等）
• Action Message Format （AMF）
• 二进制数据（Binary Data）
• 位图数据（BitMapData，HTML5 的画布 Canvas 和矢量标记语言 VML 可以实现近似的功能）
• 图形处理器的利用（Use of GPU）

结论

HTML5 是一项新技术，很多人会想要尝试它，而 Flash 业已存在很久，并且还将会有很长的生命周期。HTML5 短期内无法完全替代 Flash，而 Flash 可以作为 HTML5 的一个很好的补充。

HTML5 相关的一些链接

• HTML5 Browser Compatibility Test
• HTML5 by Apple
• HTML5 Demos
• HTML5 Rocks
• HTML5 Watch, not necessarily HMTL5 but interesting applies of JS like the Google Pacman
• Chrome Experiments
• Learn HTML5: 10 must read lessons

• 英文原版
• 中文翻译版

什么也不说了，直接上图（图片比较大，单击图片看大图）

计算机编程简史图（英文版）

计算机编程简史图（中文版）

• 这个版本不像以往的版本有太多的窗口，其把以前那些窗口督统一起来，只有一个窗口。
• 集成了Interface Builder（以前这个东东和Xcode是两个东西）
• Xcode Assistant 可以让你的设计和代码同时呈现。
• LLVM Compiler 2.0。LLVM是下一代的编译器，其完全支持C，C++和Objective C，而且编译的速度和编译成的执行速度都快于GCC。同时也引入了LLDB做为新的调试器。
• 多版本编译。这个功能可以让你在IDE中编译两个版本的代码，而且可以和Subversion或Git集成。

你可以访问 What’s New 来看看具体的细节。

苹果开发工具Xcode 4 Preview 2

检查素数与否的正则表达式

要使用这个正规则表达式，你需要把自然数转成多个1的字符串，如：2 要写成 “11”， 3 要写成 “111”, 17 要写成“11111111111111111”，这种工作使用一些脚本语言可以轻松的完成。

一开始我对这个表达式持怀疑态度，但仔细研究了一下这个表达式，发现是非常合理的，下面，让我带你来细细剖析一下是这个表达式的工作原理。

首先，我们看到这个表达式中有“|”，也就是说这个表达式可以分成两个部分：/^1?$/ 和 /^(11+?)\1+$/

• 第一部分：/^1?$/， 这个部分相信不用我多说了，其表示匹配“空串”以及字串中只有一个“1”的字符串。
• 第二部分：/^(11+?)\1+$/，这个部分是整个表达式的关键部分。其可以分成两个部分，(11+?) 和\1+$，前半部很简单了，匹配以“11”开头的并重复0或n个1的字符串，后面的部分意思是把前半部分作为一个字串去匹配还剩下的字符串1次或多次（这句话的意思是——剩余的字串的1的个数要是前面字串1个数的整数倍）。

可见这个正规则表达式是取非素数，要得到素数还得要对整个表达式求反。通过上面的分析，我们知道，第二部分是最重要的，对于第二部分，举几个例子，

示例一：判断自然数8。我们可以知道，8转成我们的格式就是“11111111”，对于(11+?)，其匹配了“11”，于是还剩下“111111”，而\1+$正好匹配了剩下的“111111”，因为，“11”这个模式在“111111”出现了三次，符合模式匹配，返回true。所以，匹配成功，于是这个数不是质数。

示例二：判断自然数11。转成我们需要的格式是“11111111111”（十一个1），对于(11+?)，其匹配了“11”（前两个1），还剩下“111111111”（九个1），而\1+$无法为“11”匹配那“九个1”，因为“11”这个模式并没有在“九个1”这个串中正好出现N次。于是，我们的正则表达式引擎会尝试下一种方法，先匹配“111”（前三个1），然后把“111”作为模式去匹配剩下的“11111111”（八个1），很明显，那“八个1”并没有匹配“三个1”多次。所以，引擎会继续向下尝试……直至尝试所有可能都无法匹配成功。所以11是素数。

通过示例二，我们可以得到这样的等价数算算法，正则表达式会匹配这若干个1中有没有出现“二个1”的整数倍，“三个1”的整数倍，“四个1”的整数倍……，而，这正好是我们需要的算素数的算法。现在大家明白了吧。

下面，我们用perl来使用这个正规则表达式不停地输出素数：（关于perl的语法我就不多说了，请注意表达式前的取反操作符）

perl -e'$|++;(1 x$_)!~/^1?$|^(11+?)\1+$/&&print"$_ "while ++$_'

另外，让我们来举一反三，根据上述的这种方法，我们甚至可以用正则表达式来求证某方式是否有解，如：

• 二元方程：17x + 12y = 51   判断其是否有解的正则表达式是：^(.*)\1{16}(.*)\2{11}$
• 三元方程：11x + 2y + 5z = 115 判断其是否有解的正则表达式是：^(.*)\1{10}(.*)\2{1}(.*)\3{4}$

大家不妨自己做做练习，为什么上述的两个正则表达式可以判断方程是否有解。如果无法参透其中的奥妙的话，你可以读读这篇英文文章。

（全文完）

2010年7月2日，Roy Osherove 和 Kent Beck 在 blog.typemock.com 进行了一次对话，话题涉及单元测试（Unit Testing），JUnit Max（Kent 开发的一个单元测试的 Eclipse Plugin，不免费），和面向初创企业的精益方法（Lean Startups）。

单元测试和 JUnit Max
作为软件开发方法学的大师、极限编程XP的创始人、敏捷宣言的创始人之一，Kent Beck 一直在努力最大化地利用单元测试的价值，他说一些程序员仍然认为单元测试并不是他们的工作，但是单元测试确实能够提高软件的质量。目前他正在开发 JUnit Max，这是一个 Eclipse plugin，每当程序员保存一个 Java 源文件的时候，JUnit Max 就会运行测试并报告反馈信息。测试中的错误将会如同编译错误一样被报告给程序员。JUnit Max 的核心思想是测试错误应该和编译错误一样被 IDE 报告给程序员，程序员不需要额外的菜单选项或者运行其他的工具来运行测试。特别是那些经常失败的测试，对于程序员来说是非常有价值的反馈信息。在测试驱动开发（Test Driven Development – TDD）中，我们重复着这样一个循环：“编写一个‘失败’的测试（Failing Test）” – “编码实现功能以便让测试通过”，随着开发的深入，测试越来越丰富，测试能够反馈给程序员的信息也越来越多，它们可以帮助程序员找出那些需要改进的代码。JUnit Max 能够缩短这个循环的周期，因为它更为频繁地运行测试和提供反馈。Roy 问道：“当你一个人编码的时候，你是否严格地遵循 TDD，即一定要先写测试，然后写实现代码。我个人发现这并不是一件容易做到的事情，特别是当一个人编码的时候。” Kent 回答：“视情况而定，有时候并不需要死板地遵循 TDD，比如当我在做一些探索性或者说实验性的编码时，并不需要写测试，因为我只是想尝试一下某些功能和特性。”

Roy： “你在测试驱动开发中见过的最糟糕的错误有哪些？”
Kent：“很多程序员仅仅是拷贝和粘贴测试代码，但并不理解它们。所以我们经常能看到没有断言的测试，同时测试很多逻辑和功能的测试，过于臃肿或者过于短小的测试等等。当然这些错误在学习过程中很普遍，也是我们学习的一部分。”

Roy：“你下一步最想尝试的新概念是什么？”
Kent：“我最近谈论的一个主题是 Software G Forces，是关于软件产品的部署频率（Frequency of Deployment），这里的部署是指面向最终用户的部署或者说发布，是生产环境而非测试环境。从前的软件产品每年（或数年）发布一个新的版本，而现在的软件产品发布频率越来越快，从每季度，每月，每周，每天，直至每小时。Kent 提及有一些非常复杂的软件产品的发布频率甚至是每天 40 到 50 次。此时 Roy 提出了一个非常好的问题：“产品发布得如此频繁，我们如何能够在这么短的时间间隔内获得用户反馈呢？”，Kent 回答道：“持续部署（Continuous Deployment）确实需要一些基础设施建设来支持，比如：自动版本回滚，自动错误检测，系统同时运行多个版本的能力，比如一个服务器集群中不同的服务器上可以运行产品的不同版本。”

Roy 问道：“当你在开发一个产品的时候，你在为客户创造价值，而持续部署创造的则是一种内在的价值，并且实施过程也是非常复杂的，你怎样投入时间去实施它呢？是否需要从产品设计的一开始就考虑这些问题呢？”，Kent 答道：“5 年之内市场上可能会有许多持续部署的产品出现，目前我们可能需要自己来寻求解决方案，因为现在它还是一个较新的领域。持续部署的重点之一是及时捕获系统错误，不仅仅是技术层面上的错误，同时也包括业务层面。以 Amazon.com 为例，他们评价系统运行的良好程度是以业务运营状况为依据的，如果销售额出现不明原因的下降，系统也会发出错误警告。”

注：为了不让文章过长，下半部分的面向初创企业的精益方法（Lean Startups）将在后面发布。

使用这个玩意很简单，下面，让我们看看这个混血儿长啥样？

首先，你需要链接一个js文件：

<script src="http://gestalt.ironpython.net/dlr-latest.js" type="text/javascript"></script>

然后，让我们看看如何写一个按钮事件：

<input id="button" type="button" value="Say, Hello!" />
<script type="text/python">
  def button_onclick(s, e):
      window.Alert("Hello from Python!")
  document.button.events.onclick += button_onclick
</script>

你对此事怎么看？欢迎留下你的看法。

• 把 C# 转成 VB.NET
• 把 C# 转成 Python
• 把 C# 转成Ruby
• 把 VB.NET 转成C#
• 把 VB.NET 转成 Python
• 把 VB.NET 转成 Ruby

老实说，我并不太清楚这些工具有什么用，看似很useless。难道是为了用来学习新的语言？就像Google的Translator的一样？就像一个并不懂中文的老外可以用Google Translator在其Facebook中整点中文耍耍酷一样，难道说，一个C#的程序员可以用这样的工具和一个Python的程序员也耍耍酷？各位看客觉得这个东西有意义吗？

不过，有一点我可以确定，如果有工具把Unix/Linux下的C源码和Windows下的C源码相互自动转换，估计这会是相当划时代的，因为，这应该会让那些什么Wine或Cygwin之类的东西都统统会成为历史了。不过，这样的东西在实现上又将会有多么大的难度（OS系统API的相互转换），这个事会有可行性吗？

1）Firefox：Regular Expressions Tester

Firefox正规则表达式检查插件Regular Expressions Tester

2）Chrome：Regular Expression Checker

Chrome正规则表达式检查插件Regular Expression Checker

1. Groovy。构建在强大的Java语言之上 并添加了从Python，Ruby和Smalltalk等语言中学到的诸多特征，为Java开发者提供了现代最流行的编程语言特性，而且学习成本很低（几乎为零），在开发Web，GUI，数据库或控制台程序时， 通过减少框架性代码 大大提高了开发者的效率。支持单元测试和模拟（对象），可以简化测试。无缝集成 所有已经存在的 Java对象和类库。直接编译成Java字节码，这样可以在任何使用Java的地方 使用Groovy。
2. JRuby。一个纯Java实现的Ruby解释器。通过JRuby，你可以在JVM上直接运行Ruby程序，调用Java的类库。很多Java编写的Ruby IDE都是使用JRuby来解释语法的。
3. Scala。一种多范式的编程语言，设计意图是要整合面向对象编程和函数式编程的各种特性。Scala编程语言近来抓住了很多开发者的眼球。它看起来像是一种纯粹的面向对象编程语言，而又无缝地结合了命令式和函数式的编程风格。Scala的名称表明，它还是一种高度可伸缩的语言。Scala的设计始终贯穿着一个理念：创造一种更好地支持组件的语言。
4. Fantom 。Fantom 前身是 (Fan) 是一个基于 Java 和 .NET 平台的编程脚本引擎，用来在运行时产生 JVM 和 .NET 平台的字节码，该语言是面向对象的，跟 Groovy 和 JRuby 有点类似，可通过特定的接口来集成 Java 的类库。
5. Jython。Jython由于继承了Java和Python二者的特性而显得很独特。其是一种完整的语言，而不是一个Java翻译器或仅仅是一个Python编译器，它是一个Python语言在Java中的完全实现。Jython也有很多从CPython中继承的模块库。最有趣的事情是Jython不像CPython或其他任何高级语言，它提供了对其实现语言的一切存取。所以Jython不仅给你提供了Python的库，同时也提供了所有的Java类。这使其有一个巨大的资源库。

下面是一张表格比较了这五大JVM脚本语言：

其它一些JVM的脚本语言也我们可以关注一下，如：Clojure, JavaFX, 和IBM的 NetRexx。

（全文完）

有很多的书籍讨论敏捷方法是怎样工作的（How it works？），在这个主题演讲中，Martin Fowler 和他的同事 Neal Ford 讨论了敏捷方法能够在软件开发项目中行之有效的原因（Why it works？）。作为敏捷方法的发起人和传道者，Martin Fowler 和 ThoughtWorks 一直试图从理论层面证明敏捷方法的可行性，同时不厌其烦地解答着客户们的各种困惑，正如他们所说，敏捷方法中的很多概念不是特别的直观，除非人们真正实践过一段时间，否则有些概念很难从字面上去完全理解。

Martin Fowler 谈到一个有意思的现象，那就是今天许多人们口中谈论的敏捷方法，和最初的敏捷方法大相径庭，他把这种现象称为“语义扩散（Semantic Diffusion）”，大意是某种思想在传播的过程中，在逐渐扩散的同时，其语义也渐渐变得模糊。在敏捷开发领域里，“语义扩散”导致的一个问题是，在一些使用敏捷方法的项目或者公司中，我们甚至无法辨别出敏捷方法的影子，原因是很多人没有真正地理解敏捷方法，也就不能够正确地运用和实践，从而也就无法真正了解自己是否能够从敏捷方法中获益。

以下是为什么敏捷方法行之有效的原因：

1. 敏捷方法和传统的计划驱动方法的两个主要区别

i. 预测性计划（Predictive Planning）和自适应计划（Adaptive Planning）

计划驱动方法首先计划要做的工作（plan your work），然后着手工作以完成计划（work your plan）。这是一种带有预测性质的方法，其衡量项目成功的标准则是我们是否按计划、按时、按预算完成了工作。这种方法在很多领域里是适用的。但是对于软件开发而言，如果我们的需求没有办法做到不变更的话，我们就无法保证我们的计划以及其后的工作是不会变更的。Martin Fowler 向现场观众提出了一个问题，大意是你们当中有多少人的软件开发项目的需求是一成不变的，结果没有一位观众举手。因此，敏捷方法引入了自适应计划的概念，既然我们无法保证需求不变更，那么就让我们随时准备接受变更，接受挑战吧。自适应计划将计划驱动的流程缩短为以数周为单位的循环周期，在每一个周期中，我们根据当前的情况不断地调整计划以及计划的执行过程，同时不断地产生能够工作的代码，并且不断地将代码部署到应用环境中去。当然要实现这个目标我们需要一些具体方法的支持，如：自测试代码（Self-Testing Code），持续集成（Continuous Integration），重构（Refactoring），和简洁设计（Simple Design）等等这些技术层面上的方法。Martin Fowler 指出，一些公司和项目之所以受困于敏捷方法，原因之一是他们忽略了这些技术层面的方法，而仅仅实施了项目管理层面的方法。

ii. 以流程为本（Process First）和以人为本（People First）

在传统的方法论中，我们总是需要事先定义好工作的方法和流程，然后“工人们”被要求遵照这些方法和流程来工作。在软件开发领域，很多人把软件开发过程等同于软件本身，也就是说，软件开发的过程也如同软件程序般象机器一样运行，组件之间环环相扣，严密地协同工作。问题是软件开发的核心是人，人相对于机器零件和流水线而言，是相对不可预测的和不那么精密的。所以敏捷方法反其道而行之，提倡将“首先定义流程，然后要求软件开发人员遵照流程工作”变为“让参与软件开发的人员自己来定义和选择适合他们的流程”。简单来说就是以人为本，不把人当螺丝钉，发挥人的主观能动性，当然前提是需要团队成员有较高的平均素质。

2. 沟通（Communication）

Neal Ford 让我们回顾或想象一下失败的软件开发项目，它们的失败是由于技术因素还是人的因素呢？《人件》的作者认为都是人的因素。人类的社会性决定了沟通的重要。Neal 举了几个有趣的例子，如：监狱里的犯人宁愿和其他人渣待在一起也不愿被关禁闭。很多国家禁止驾驶员驾驶时打移动电话，那为什么和乘客聊天就没有问题呢？原因是直接对话是最为有效和便捷的沟通方式，信息的传递在对话过程中非常顺畅和完整。虽然现在的移动通讯已经非常先进，信号质量也很高，但是我们的通话过程仍然是有损的，我们的大脑这个时候就需要努力地试图将通话信息拼凑得更完整以便能够理解对方的意思，因此才会分散驾驶的注意力。随后，Martin Fowler 举了另一个例子，拿他做水果蛋糕的方法和他在酒店的浴室中冲凉的方法来进行比较。因为做水果蛋糕的整个流程和配料都是非常固定的，所以他只需要按步照搬地烹饪即可做出味道非常一致（地好或者差）的水果蛋糕。而在酒店中冲凉就有些不同，因为每一个酒店浴室的开关设计几乎都是不一样的，所以他需要不断地调整开关来获得一个理想的水温，也就是需要不断地重复“调整开关”（输入），“用手试温”（输出）这个过程。相对于做水果蛋糕，在酒店浴室冲凉更好地反应了软件开发的特征，这就是在软件开发领域中，如果我们善于根据用户反馈的信息来做出新的判断和调整，就有可能提高产品的质量和用户的满意度。

沟通的确是一个非常重要的环节，它是敏捷方法的核心。在敏捷方法中，单元测试是程序员和代码组件的沟通，功能测试是程序员以及QA和系统的沟通，故事墙（Story Wall）和回顾（Retrospective）是团队和成员之间的沟通，功能演示（Showcase 或者 Demo）是团队通过产品和最终用户的沟通，持续集成（Continuous Integration）是产品和企业计算环境的沟通。沟通好了，什么事情都可以妥善解决，沟通得不好，好事也会变坏事。和广大技术爱好者交流沟通也是酷壳存在的目的和意义。

整个演讲时长一个小时，本文只是节选了我认为比较有意思的观点加上本人的理解写成，如有错误之处欢迎指正，不同看法欢迎交流。

但是，很明显，所有的已经开发出来项目都是在不完美的条件下开发出来的，一般来说，几乎所有的项目都是在最大化程序员软件的开发速度。而且，很多情况下，我们似乎对深度测试和压力测试并不是很关心，所以，我们总是在祈祷并期望那些赶工出来的代码可以正常工作，尤其是在上线的时候，这种唯心主义的价值观更为强烈。  其实，开发速度和软件产品质量并不矛盾。好的程序员并一定是技术强的程序员，而是那些可以在不完美的工作环境下保证软件质量和工作效率的程序员。下面是是五个程序员可以在这种不完美的情况下做得更好的观点（它们都和语言和技术没什么关系，只不过是一种你的工作行为，能够和所有的行业相通），这五个观点也许可以让你成为这样的好程序员。

• 寻找不同观点：程序员好像并不喜欢技术上有异见的人，他们特别喜欢争论各自的技术观点。但是，他们忽略了不同观点的价值。任何事情都有好有坏，我们应该学会在不同观点中学习和平衡。这样才会更多的了解编程和技术。要经常在做事之前问自己和别人，这么做对不对？做完事后问自己，还可不可以改进？努力去寻找别的不同的观点或方法。程序员应该经常上网，经常和同事讨论不同的实现方法，不同的技术观点，这样才能取长补短。然而，在实际工作中，我发现程序员们并不喜欢互相请教，因为请教的人怕别人看不起他，而被请教的人总是先贬低对方的能力，哎……（参看《十个让你变成糟糕的程序员的行为》），如果有这样的文化氛围的话，那也没有关系。上网吧，网上的人谁也不认识谁，可以尽情地问一些愚蠢的问题。呵呵。总之，一定要明白，如果某些事情只有一个观点，那么你一定要怀疑一下了，没有观点和技术方案的比较，没有百花齐放的情况，你就无法知道是否还有更好的东西。真正的和谐不是只有一种声音，真正的和谐而是在不同的观点声音下取长补短，百家争鸣（参看《十条不错的编程观点》）。否则，你永远都不会接受到新的观点，也就无法进步和成长了。

• 千万别信自己的代码: 在任何时候，一定要高度怀疑自己的代码。很多时候，错误总是自己造成的。所以，当出现问题的时候，要学会review代码中所有的可疑点，千万别觉得某段代码很简单，可以略过。事实证明，很多疏忽大意都是在阴沟里翻的船，都是那些很低级的错误。在查错的过程中，切忌过早下结论，切忌四处乱改（参看《各种流行的编程风格》），停下来，想一想，会是哪儿的代码有重大嫌疑，然后查看一下代码，捋一捋程序的逻辑（参看《橡皮鸭程序调试法》），调试并验证一下程序的逻辑和变量在运行时是否是正确的。很多时候，对于那些难缠的问题，最后解决了总是因为我们开始认真回头审视所有的代码。只有对自己的代码保持着高度的怀疑，这样我们才会想着如何让其运行得更好更稳定，也会让我们在单元测试中下更多的功夫，这样才能更能在那忙碌的环境中节省时间。相信我，在集成测试中fix bug的成本要比在单元测试Fix bug的成本大得多的多。一个简单的例子就是memory leak。程序员对自己的程序需要有忧患意识，这样才会越来越成熟，而自己的能力也会越来越强。

• 思考和放松: 做事前多想一想，这样做事的时候就不会不顾此失彼，手忙脚乱，一旦事情一乱，你的心情也会更乱，于是，事情也就会更乱。最后，你只得重写，这种事情太多了。而且，在工作中要学会享受，要学会放松心情，我并不是让你工作的时候聊QQ，我只是说，有时候，心态过于紧张，压力过大，你的工作成果反而更不好，从而又反过来造成新一轮的焦虑和紧张。我个人认为，思考和放松是可以完美统一的，思考其实就是一种放松，停下来，休息一下，回头看看走过的路，喝口水，登个高，看看过去走的对不对？总体是个什么样？总结一下，然后看看前路怎么样好走，这会你才会越走越好，越走越快。好的程序员都不是那种埋头苦干的人，好的程序员总是那些善于总结成败得失，善于思考，善于调整，善于放松的人（参看《优秀程序员的十个习惯》）。不然，我能看到的情形是，你很快地把事干完，回到家刚坐下来，老板或是客户就打电话来告诉你你的程序出问题了。总之，深思熟虑，动作会很慢，但是你可以保证你工作成果的质量，反而能让你更多的节约时间。

• 学习历史，跟上时代: 如果你是从十年前开始编程的，那么，今天的这门语言或是技术会有很多很多的改进和改善。你以前开发一个功能或函数，今天早已被集成时了语言中，而且做得比你的版本要好得多。以前你需要100行代码完成的事情，今天只需要1行代码。这样的事情在未来还会发生，所以，今天的你一定要学会如何跟上时代。但是，你也不要放弃历史，我现在看到很多程序员对一些现代的语言和技术使用的非常好，他们可以很容易地跟上时代。但不要忘了，计算机世界的技术更新和技术淘汰也是非常猛的。所以，你一定要学习历史，这些历史不是产商的历史，而是整个计算机文化的历史（参见《Unix传奇》）。只有通过历史，你才能明白历史上出现的问题，新技术出来的原因，这样才能够对今天的这些新的技术更了解，也才能明白明天的方向在哪里。学习历史和跟上时代都是相当重要的。使用新型的技术，停下来接受培训，可以让你工作得更快，更高效（参看《未来五年程序员需要掌握的10项技能》）。而学习和总结历史，才会让你在纷乱的世界中找到方向。

• 积极推动测试活动: 只有测试才能证明软件可以正常工作，只有测试才能保证软件的质量。无论什么产品，都需要经过或多或少的测试。测试地充分的产品或模块，你会发现其质量总是那么好，测试的不充的产品，质量总是那么次。德系汽车，日系汽车质量怎么样，关键还是在于怎么去测试的，测试的是否充分。所以，在你开发软件的过程中，如果你说你的程序写地好，质量高，那么请你拿出实实在在的测试报告。在整个软件开发过程中，做为一个好的程序员，你应该积极地在各个环节推动项目组进行测试活动。不要以为技术需求阶段和设计阶段不需要测试，一样的，只要你要release什么，release的这个东西都需要进行测试。技术需求怎么做测试？用户案例就是测试案例。在软件开发的整个过程中，保证产品质量有时候比实现需求更重要，尤其是那些非常重要甚至人命关天的产品。

上面这些五个观点都是可能让你在不完美的工作环境中可以工作得更好，更快，更高效，希望能够对你有用。另外，也欢迎你留下你的观点！

（全文完）

这篇文章试图收集最重要的编程语言的设计错误，以便让那些程序语言设计者们在设计新型的编程语言时避免。我避免了一些纠缠不清的有好有坏的问题，如：动态类型或是静态类型。我也省略了那些看起来并不严重，很容易被修改的错误。例如，加入“参量”（Parametric Type），这在Java中已经有了。Sun在发布Java 1.0版后的第八年才加入了这一功能。还有一个最近的例子是 Google Go Language Design FAQ 中说到的：: “Generics may well be added at some point. We don’t feel an urgency for them, although we understand some programmers do.”

0. Null 指针

几乎在所有的主流编程语言中，对一个对像的引用可能会是一个空指针，这个错误会引发运行时错误。 C.A.R. Hoare 最近声明向这一“发明”负责，尽管如此，其它许多的设计者们都应该对这样的设计受到批评。下面是 C.A.R Hoare 的“忏悔”：

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. [...] More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965. - C.A.R. Hoare

我把它叫做“亿万美元错误”。这个空指针的发明创造来自1965年。…… 现在的编程语言引入了“非空引用”的声明规格。这个方案被我在1965年给拒绝了。

其它语言，如 C/C++ 更夸张，它们在运到这样的错误时，直接Crash掉，而 Java， Python 和其它语言会抛出一NullPointerException异常，但问题是，这个 RuntimeException 可能会被几乎所有的语句抛出。其实，只需要一个静态类型的语言就可以保证不会出现空指针或空引用。例如： Cyclone 是一个安全的C变种，其引入了非空指针和指针运算的限制。

一些语言甚至让你根本不可能创建空指针，虽然这使得明确的指针不能行进行运算。Haskell 就是这样的一个语言，其提供了Maybe Monad，其强制程序员考虑“Null”的情形。

1. 很难解析的语法

编程语言的语法应该来自 LALR 或是更好的 LL(1)。今天的程序员需要适当的工具来支持其开发语言，也就是我们常说的IDE，编译器或是其它可以帮你解析程序语言的编程工具。这并不会出现在一个单一的前端。也许，多重编译器已经被实现出来了。这可能让我们的开始变得更容易一些。然而，我们现实中的一个反例是 C++，几乎没有哪个C++的编译器可以把C++这个语言完美地正确地解释出来，而且不同C++的编译器的行为如此的诡异。编程语法的开销是微不足道的，程序员应该在编写程序中享有更快速和高效的回报。

2. 未定义的语义

别在语言规格中说“实现规范”！尽可能的少使用“未定义”这样的术语来描述语言的行为（C/C++中出现了很多undefined的行为）！黄金准则是StandardML，其是一个完整地正式的语义。C 语言是这样一个反例，其规则中有太多太多的未定义的情况。然而，由于其广泛使用，所以某些行为的定义已经成为了世界的共识（江湖的行规，或，潜规则）。 举个例子，在C中，整型 overflow 的行为是未定义的，而编译器也是有能力推断出“ x < x+1 ”是否总是为真。不幸的是，这个本来是编译器应该干的事，交给了程序员，于是在C的世界里，出现了大量的整型溢出的代码。而当整型溢出的时候，几乎所有的行为都是像x86处理器一样（如： maxint+1 == minint）。

明确的语义可以让验证和错误检查更容易。虽然，软件校验来得比缓慢，但一定会来。我可以想像，编程语言的下一个机会将会是更容易地校验，这可能需要十到二十年的时间，但今天开始这样做的语言将会在那天成为世界的主流。

3. 坏的Unicode 支持

程序中几乎都要处理字符串，但别忘了并不是所有人都会使用英语来编程。今天，几乎所有的编程语言都不支持Unicode，所以，我们只能使用ANSI的英语来编程。这个时代， 程序员应该使用Unicode 来编程，所以，源代码也可以声明其用什么来编码。

在文本和字节序间的转换和区分在的标准库方面会比语言方面更是一个问题，当然，这也影响了语法。读一读 Python 3 是怎么解决这个问题可能会更有一些帮助。

4. 预处理器

像C++和MP4的预处理器已经被广泛地使用着，使用预处理器更像是一种hack而不是一个干净的解决方案。 他们被用来，使用外部文件（如头文件，但确没有正确地模块机制），使用条件编译，宏替换，等。把这些功能与编程语言集成起来一起使用可以增加程序的性能和开发效率，并没有什么不好的地方。

如果要举一个反例，那么就是预编译器的模块化系统。C使用#include 而 C++ 更痛苦，因为模板需要写一个大的头文件，而且其会被包含在几乎所有的其它文件中。而一个真正的模块化的系统是不需要使用 extern 关键字，也不需要程序的链接，而应该是直接使用。

文章：来源

Google Android App Inventor

注意，Google说的是任何人，也就是包括那些不会编程的人。这个工具可以将枯燥的代码变成了一块一块的拼图，你需要做的只是把这些零散的拼图按照你自己的意思组合在一起，点击生成，你的第一个 Android 程序就诞生了。这里有一篇来自 纽约时代的报道，《纽约时代》报道称，App Inventor已经在六年级的孩子们中完成测试，他们能够使用App Inventor制作简单的应用。如果你可以访问Youtube的话，你可以看看这个视频。

这个想法，这会让 Android 市场不仅对程序开放，而且我们可能看到还有一大批很有创意但不懂编程的人为这个平台添砖加瓦，当然，这也可能会出现很多垃圾应用，正如不会做网页的人用所见即所得的编辑器做出的那些相当ugly劣质网页一样。瑕不蔽玉，就算是有大量的劣质应用的出现，我也相信，同样会涌现出更多更好的应用，那些都是技术人员无法做到的。

当然，这种想法以前也有，不过仅仅是当玩具玩玩，这回，做这个事的是Google，我不知道他能把这个事情做成什么样？但觉得可能会比较专业。如果只是整成另一个VB的翻版嘛，那就很囧了。

让我们看看，最终这个玩意，会成为像Dreamweaver或Flash那样把网页开发变成傻瓜化，还是会像VB那样把程序员变成傻瓜。

Grinder –  Grinder是一个开源的JVM负载测试框架，它通过很多负载注射器来为分布式测试提供了便利。 支持用于执行测试脚本的Jython脚本引擎HTTP测试可通过HTTP代理进行管理。根据项目网站的说法，Grinder的 主要目标用户是“理解他们所测代码的人——Grinder不仅仅是带有一组相关响应时间的‘黑盒’测试。由于测试过程可以进行编码——而不是简单地脚本 化，所以程序员能测试应用中内部的各个层次，而不仅仅是通过用户界面测试响应时间。

Pylot -Pylot是一款开源的测试web service性能和扩展性的工具，它运行HTTP 负载测试，这对容量计划，确定基准点，分析以及系统调优都很有用处。Pylot产生并发负载（HTTP Requests），检验服务器响应，以及产生带有metrics的报表。通过GUI或者shell/console来执行和监视test suites。

Web Capacity Analysis Tool (WCAT) – 这是一种轻量级负载生成实用工具，不仅能够重现对 Web 服务器（或负载平衡服务器场）的脚本 HTTP 请求，同时还可以收集性能统计数据供日后分析之用。WCAT 是多线程应用程序，并且支持从单个源控制多个负载测试客户端，因此您可以模拟数千个并发用户。该实用工具利用您的旧机器作为测试客户端，其中每个测试客户端又可以产生多个虚拟客户端（最大数量取决于客户端机器的网络适配器和其他硬件）。您可以选择使用 HTTP 1.0 还是 HTTP 1.1 请求，以及是否使用 SSL。并且，如果测试方案需要，您还可以使用脚本执行的基本或 NTLM 身份验证来访问站点的受限部分。（如果您的站点使用 cookie、表单或基于会话的身份验证，那您可以创建正确的 GET 或 POST 请求来对测试用户进行身份验证。）WCAT 还可管理您站点可能设置的任何 cookie，所以配置文件和会话信息将永久保存。

fwptt – fwptt 也是一个用来进行WEB应用负载测试的工具。它可以记录一般的请求，也可以记录Ajax请求。它可以用来测试 asp.net， jsp， php 或是其它的Web应用。

JCrawler – JCrawler是一个开源( CPL) 的WEB应用压力测试工具。通过其名字，你就可以知道这是一个用Java写的像网页爬虫一样的工具。只要你给其几个URL，它就可以开始爬过去了，它用一种特殊的方式来产生你WEB应用的负载。这个工具可以用来测试搜索引擎对你站点产生的负载。当然，其还有另一功能，你可以建立你的网站地图和再点击一下，将自动提交Sitemap给前5名的搜索引擎！

Apache JMeter – Apache JMeter是一个专门为运行和服务器装载测试而设计的、100％的纯Java桌面运行程序。原先它是为Web/HTTP测试而设计的，但是它已经扩展以支持各种各样的测试模块。它和用于HTTP和SQL数据库（使用JDBC）的模块一起运送。它可以用来测试静止资料库或者活动资料库中的服务器的运行情况，可以用来模拟对服务器或者网络系统加以重负荷以测试它的抵抗力，或者用来分析不同负荷类型下的所有运行情况。它也提供了一个可替换的界面用来定制数据显示，测试同步及测试的创建和执行。

Siege -Siege（英文意思是围攻）是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。 Siege 支持基本的认证，cookies， HTTP 和 HTTPS 协议。

http_load – http_load 以并行复用的方式运行，用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。可以可以测试HTTPS类的网站请求。

Web Polygraph – Web Polygraph这个软件也是一个用于测试WEB性能的工具，这个工具是很多公司的标准测试工具，包括微软在分析其软件性能的时候，也是使用这个工具做为基准工具的。很多招聘测试员的广告中都注明需要熟练掌握这个测试工具。

OpenSTA – OpenSTA是一个免费的、开放源代码的web性能测试工具，能录制功能非常强大的脚本过程，执行性能测试。例如虚拟多个不同的用户同时登陆被测试网站。其还能对录制的测试脚本进行,按指定的语法进行编辑。在录制完测试脚本后，可以对测试脚本进行编辑，以便进行特定的性能指标分析。其较为丰富的图形化测试结果大大提高了测试报告的可阅读性。OpenSTA 基于CORBA 的结构体系，它通过虚拟一个proxy，使用其专用的脚本控制语言，记录通过proxy 的一切HTTP/S traffic。通过分析OpenSTA的性能指标收集器收集的各项性能指标，以及HTTP 数据，对系统的性能进行分析。

欢迎您留下你认为不错的WEB应用性能测试的工具。