流程方法 | 酷壳 - CoolShell

预发布环境,Tag发布机制和可重复的部署过程

2011年02月20日陈皓评论 8 条评论 12,333 人阅读

下面文章由网友吕毅投递，源文是：http://blog.lvscar.info/?p=427

—————————————————————————————————————————————

周末聚会，无意间聊起建筑行业。自己是搞软件开发的，我们的行业从建筑设计/施工过程中借鉴了大量的概念，隐喻，名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题，这次友人又再次提起，“为什么建筑设计过程中没有普遍性的采用版本控制呢？” 瞎扯了一干各种原因后，我们几乎同时想到一个名字”Joel”，建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日，把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情，但对Joel整理出的12条写出更好软件的”最佳实践”，大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇

这12条测试如下:

1. 是否启用版本控制？

2. 是否可以一步构建?

3. 是否进行每日构建？

4. 是否有bug跟踪列表？

5. 是否在修改bug后，才开始写新代码？

6. 是否及时更新工作计划？

7. 是否在开发前编写了大家一致认可的功能文档？

8. 是否有安静的工作环境？

9. 是否在使用最好的软件开发工具？

10.是否有专职测试人员？

11.是否在面试时以实际编写代码来检查求职者？

12.是否利用陌生人进行可用性测试？

你所在的团队符合其中的几条呢？觉得这些条目太一般，软件开发原本就该如此？ Joel Test写于十年前，一个Windows XP，Mac OS X,Ubuntu都还没有面世的年代。如果你觉得这些条目有些过时了，Google中搜索“Joel Test”，你可以看到这十年内很多对此进行更新的尝试, 比如这两个页面“The Joel Test Update for 2010″,“Joel Test for web dev”.

…

阅读全文 Read More

(9 人打了分，平均分： 3.11 )

TDD并不是看上去的那么美

2011年02月12日陈皓评论 102 条评论 69,956 人阅读

春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议，也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们，意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过，我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多，所以，我想不妨讨论一下Agile方法论中的具体的实践（以前本站也讨论过结对编程的利与弊）。

那么，这次就说说TDD吧，这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中，我把TDD从过度炒作的技术剔除了出去，因为我还是觉得TDD有些道理的，不过，回顾我的经验，我也并不是很喜欢TDD。我这篇文章是想告诉大家，TDD并没有看上去的那么美，而且非常难以掌控，并且，这个方法是有悖论之处的。

TDD简介

TDD全称Test Driven Development，是一种软件开发的流程，其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始，先添加一个test case，然后运行所有的test case看看有没有问题，再实现test case所要测试的功能，然后再运行test case，查看是否有case失败，然后重构代码，再重复以上步骤。其理念主要是确保两件事：

确保所有的需求都能被照顾到。
在代码不断增加和重构的过程中，可以检查所有的功能是否正确。

我不否认TDD的一些有用的地方，如果我们以Test Case 开始，那么，我们就可以立刻知道我们的代码运行的情况是什么样的，这样可以让我们更早地得到我们实现思路的反馈，于是我们更会有信心去重构，去重新设计，从而可以让我们的代码更为正确。

不过，我想提醒的是，TDD和Unit Test是两码子事儿。有很多人可能混淆了自动化的Unit Test（如：XUnit系例）和TDD的软件开发过程。另外，可能还会有人向鼓吹“TDD让你进行自顶向下的设计方式”，对此，请参阅本站的《Richard Feynman, 挑战者号, 软件工程》——NASA的挑战者号告诉你自顶向下设计的危险性。

TDD的困难之处

下面是几个我认为TDD不容易掌控的地方，甚至就有些不可能（如果有某某TDD的Fans或是ThoughtWorks的咨询师和你鼓吹TDD，你可以问问他们下面这些问题）

测试范围的确定。TDD开发流程，一般是先写Test Case。Test Case有很多种，有Functional的，有Unit的，有Integration的……，最难的是Test Case要写成什么样的程度呢。
…

阅读全文 Read More

(34 人打了分，平均分： 4.15 )

那些炒作过度的技术和概念

2011年01月28日陈皓评论 278 条评论 103,619 人阅读

StackExchange.com上有一个贴子在评论着最近20年来被炒作过度的技术，对于出现的结果，大多数赞同，也有一些不赞同。下面我从前15名挑了10个（Java的WORE我去掉了，TDD我也去掉了，因为我觉得他们应该没有炒作过度，而且都不错），按原贴的顺序罗列如下：（后面的一些评论是我加的，欢迎大家讨论）

Top 10 过度炒作的技术和概念

Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具，但是他离程序员真正需要的设计工具还差得很远，比如：设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。

Sharepoint – 现在N多的公司都在用微软的这个东西做公司内部的Intranet。不过安装和维护起来，代价相当的大。但是其市场做的很成功，不对技术上来说对技术人员来说，相当的蹩脚。Sharepoint的设计没有认真地分析过业务流程，仅仅是一个文档存储地。看上去我们似乎可以做任何的事，但是如果你要用其来管理你的项目和track你的项目问题，你会发现其是无比的难用。

eXtensible Mark-up Language (XML) – XML嘛，以前说过很多了（XML1， XML2）我们用他来做和程序数据封装，用来做配置文件，用来做网络传输格式。我们的程序处理起XML来，又慢，又不经济，没有工具，几乎无法维护XML文件。XML用来做数据封包真是很不经济，Yaml和JSON那个不比它简单？用XML来做程序配置文件不知道是谁想出来的主意，相当的愚蠢，看看Unix/Linux下的配置文件，简单易读，相当容易维护。真是高科技啊。

SOAP, XML-RPC, WSDL 的 Web Services – 这个东西前几年炒的很凶。所有人都相信，这是程序员的未来。可惜的，其中的复杂和不一致，相当的令人恶心。SOAP的那个S居然还是Simple！看来，扯上XML的都不会是什么好的东东。不过，个人认为，CORBA比他更恶。

…

阅读全文 Read More

(34 人打了分，平均分： 3.91 )

代码重构的一个示例

2010年09月25日陈皓评论 79 条评论 50,963 人阅读

还记得以前和大家提到过的《各种流行的编程风格》吗？有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例，让我们看看那个流行的编程风格是实践是什么样的。下面的这个实践不是虚构，如有雷同，请对号入座。

首先，我们有一个表达式如下所示：

s = 7;

很明显，这个表达式的变量名太没意义了，很不利于程序的可读性，所以，我们需要取一个有意义的变量名：

slots = 7;

很好，不过，那个常量7是hard-code或是一个Magic number，而且，这常量没有名字也不利于代码的可读性啊。再改：

…

阅读全文 Read More

(25 人打了分，平均分： 4.04 )

代码优化概要

2010年09月20日陈皓评论 64 条评论 48,583 人阅读

本文译自Dr. Dobb’s Blogger的Walter Bright写的《Overlooked Essentials For Optimizing Code

》

我编写程序至今有35年了，我做了很多关于程序执行速度方面优化的工(一个示例)，我也看过其它人做的优化。我发现有两个最基本的优化技术总是被人所忽略。注意，这两个技术并不是避免时机不成熟的优化。并不是把冒泡排序变成快速排序（算法优化）。也不是语言或是编译器的优化。也不是把 i*4写成i<<2 的优化。这两个技术是：

使用一个profiler。
查看程序执行时的汇编码。

使用这两个技术的人将会成功地写出运行快的代码，不会使用这两个技术的人则不行。下面让我为你细细道来。

使用一个 Profiler

我们知道，程序运行时的90%的时间是用在了10%的代码上。我发现这并不准确。一次又一次地，我发现，几乎所有的程序会在1%的代码上花了99%的运行时间。但是，是哪个1%？一个好的Profiler可以告诉你这个答案。就算我们需要使用100个小时在这1%的代码上进行优化，也比使用100个小时在其它99%的代码上优化产生的效益要高得多得多。 …

阅读全文 Read More

(14 人打了分，平均分： 3.79 )

Waterfall 软件工程

2010年09月15日陈皓评论 17 条评论 14,077 人阅读

《Royce, Winston (1970), “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9. 》，这篇文章向你说明了软件工程鼻祖“Waterfall”的工程模型，这是40年前的论文，其中的十张插图很有强大，抽出来，让我们来看看什么叫Waterfall软件工程。

首先，让我先看一下小的程序是怎么做的，呵呵，很简单，两步。

接下来，就是我们最经典的Waterfall软件工程模型了，用户需求，软件需求，需求分析，设计，编码，测试，运维。

…

阅读全文 Read More

(14 人打了分，平均分： 3.14 )

一些鲜为人知的编程事实

2010年09月03日陈皓评论 23 条评论 25,856 人阅读

文章来源：http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

我的程序员经历让我明白了一些关于软件开发的事情。下面是一些在编程中可能会让人感到诧异的事情：

一个程序员用了大约只用了10%-20%的时间来编码，而且大多数程序员，无论他的水平如何，其平均每天只有10-12行的代码最终会进入最终的软件产品中。这是因为，优秀的程序员会花费90%的时间来思考、调查、研究最佳的设计。而糟糕的程序员则会花费90%的时间来调试代码，并随意地改动代码并尝试让代码工作起来。

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

“一个优秀的车工其工资是一个普通车工的好几倍，但是一个优秀程序员写出来的代码比一个普通程序员要值钱一万倍。——比尔盖茨”

一个好的程序员比一个普通的程序员多十倍的生产率。而一个优秀的程序员的生产率则比普通程序员多20-100倍。这并不是夸张（自从上世纪60年代的研究一直表明这是一个事实）。一个糟糕的程序员并不只是没有产出的——他们并不仅是完成不不工作，而且还会制造出大量的让别人头痛并要去解决的麻烦。

…

阅读全文 Read More

(21 人打了分，平均分： 3.86 )

五种应该避免的代码注释

2010年07月28日陈皓评论 55 条评论 51,653 人阅读

在酷壳，有很多文章都提到了代码注释，如：《十条不错的编程观点》、《优质代码的十诫》、《整洁代码的4个提示》、《惹恼程序员的十件事》等等。今天，某国外的程序员在这里列举五种应该避免的程序注释，我觉得比较有道理，但我觉得有少数几个观点也并不绝对。所以，我把原文的这五种应该避免的程序注释罗列在下面，并放上原作者和我的个人观点作为比较。希望对大家有用。

一、自恋型注释

（注：原文为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）可以完整地记录下所有的关于代码的改动的和作者相关的一切信息，只不过不是那么明显罢了。

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

…

阅读全文 Read More

(28 人打了分，平均分： 4.14 )

Kent Beck 谈单元测试和持续部署

2010年07月22日 jnj 评论 1 条评论 7,739 人阅读

文章来源

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，比如当我在做一些探索性或者说实验性的编码时，并不需要写测试，因为我只是想尝试一下某些功能和特性。”

…

阅读全文 Read More

(12 人打了分，平均分： 3.50 )

为什么敏捷方法能在软件开发中行之有效？

2010年07月18日 jnj 评论 7 条评论 10,712 人阅读

文章来源 – Martin Fowler 和 Neal Ford 在 Paris – USI 2010 的演讲

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

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

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

…

阅读全文 Read More

(18 人打了分，平均分： 3.89 )

酷壳 – CoolShell

享受编程和技术所带来的快乐 – Coding Your Ambition

Browsed by
分类：流程方法

预发布环境,Tag发布机制和可重复的部署过程

2011年02月20日陈皓评论 8 条评论 12,333 人阅读

TDD并不是看上去的那么美

2011年02月12日陈皓评论 102 条评论 69,956 人阅读

TDD简介

TDD的困难之处

那些炒作过度的技术和概念

2011年01月28日陈皓评论 278 条评论 103,619 人阅读

Top 10 过度炒作的技术和概念

代码重构的一个示例

2010年09月25日陈皓评论 79 条评论 50,963 人阅读

代码优化概要

2010年09月20日陈皓评论 64 条评论 48,583 人阅读

使用一个 Profiler

Waterfall 软件工程

2010年09月15日陈皓评论 17 条评论 14,077 人阅读

一些鲜为人知的编程事实

2010年09月03日陈皓评论 23 条评论 25,856 人阅读

五种应该避免的代码注释

2010年07月28日陈皓评论 55 条评论 51,653 人阅读

一、自恋型注释

Kent Beck 谈单元测试和持续部署

2010年07月22日 jnj 评论 1 条评论 7,739 人阅读

为什么敏捷方法能在软件开发中行之有效？

2010年07月18日 jnj 评论 7 条评论 10,712 人阅读