Reading 1

这是国外的老程序员 Joel Spolsky 在2000年写的文章。

更详尽的带图表的分析:

Why You Should (Almost) Never Rewrite Code – A Graphical Guide

Avram Joel Spolsky生于1965年，他是一位软件工程师和作家。他是“Joel on Software”博客的作者。他从1991年到1994年间担任Microsoft Excel团队的项目经理。在2000年，他创立了Fog Creek软件并开启了“Joel on Software”博客。2008年，他和Jeff Atwood一起启动了如今极为成功的Stack Overflow程序员问答网站。他们用Stack Exchange软件产品作为Stack Overflow的引擎。现如今Stack Exchange网络已经包含了91个站点。

他在这篇文章的论点来源于一个简单的事实：
It’s harder to read code than to write it.
写代码容易，读代码难。

在开头，他批评网景公司犯了的最严重的战略错误——他们决定从头开始重写代码

由于网景当时的极度成功，公司规模扩展很快，为了应对开发的需求而收购了一家大型软件开发公司。但这家被收购公司的高层以及开发人员做了一系列愚蠢决定，包括使用当时如麻花一般的 C++ 代替 C，削减支持平台，优先发布 Windows 版本浏览器等，最后造成了新版本发布遥遥无期，程序质量不高等一系列问题，失去了对其他浏览器（包括IE）功能上和性能上的绝对优势，而结果就是被用户抛弃。

作者的观点主要有：

重写的代码即便能完全达到旧代码的所有功能、性能需求，为产品带来的竞争力也只有边际提升。（这个很好理解，因为代码的规范性和清晰度对产品的功能性没有直接帮助，只能降低远期的维护成本）
由于重写代码过程中需要花费额外的钱和时间，可能会出现一些意外状况，比如预算不够了，核心程序员离职了，或是重写的产品没有达到原有产品的所有功能和性能需求，那么这个结果可能是灾难性的，重写的产品要么胎死腹中，要么市场竞争力反而更低了。
在重写期间，由于竞争对手不会停滞不前并且您无法开发新功能，因此产品的竞争力通常会下降。而且重写花费的时间比预期的要长得多，连锁效应使产品竞争力下降的时间更长。对于小公司来说，这可能是致命的。

上面三个中的任何一个都可能致命，但是所有三个问题肯定都是致命的，产品的竞争力可能永远不会恢复。

如果公司的项目或产品代码混乱到无法再加入新功能或提升性能，跟时代严重脱节怎么办，那么应用以上原则，这时候既然这个项目已经快死了，那么放到新项目里重写显然是最合理的选择。

Reading 2

同样是 Joel Spolsky 在2000年写的文章。

The Joel Test: 12 Steps to Better Code

他用这十二条来评估软件团队的质量，大多数软件组织的运行得分为2或3，像 Microsoft 这样的公司的得分为12。

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

1.您是否使用源代码管理？

如果您没有源代码控制，那么您将不得不尝试使程序员们一起工作。程序员无法知道其他人做了什么。错误不能轻易回滚。

在源代码层面使其易于管理、维护，同时降低核心技术泄密风险。

2.你们可以把整个系统从源码到CD映像文件一步建成吗？

这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。

3.您是否进行日常构建？

在微软软件开发中，每日构建是最重要的过程之一，被称为微软产品开发的“心跳”。简单来看，每天构建系统将整个产品解决方案完整构建一遍，生成的目标文件和安装文件被放置在一个共享位置。接着，安装文件被自动部署到release server上，随后可以自动运行BVT（build verification test），并将所有结果寄送每个team member的信箱。

4.您是否有 bug 数据库？

如果您正在开发代码，即使是一个团队，也没有列出代码中所有已知错误的有组织的数据库，那么您将交付低质量的代码。

5.在编写新代码之前，您是否修复了 bug？

要立即修复 bug 的原因之一：因为它花费的时间更少。还有另一个原因，这与以下事实有关：预测编写新代码要比修复现有 bug 要花多长时间。例如，如果我要求您预测编写代码以对列表进行排序所需的时间，那么您可以给我一个很好的估计。但是，如果我问你如何预测这将需要多长时间来修复 bug：如果安装Internet Explorer 5.5您的代码不工作，你甚至无法猜测的，因为你不知道（定义）是什么导致 bug。跟踪可能需要3天，或者可能需要2分钟。

这意味着如果您的日程安排中有许多尚待修复的 bug，则该日程安排是不可靠的。但是，如果您已经解决了所有已知的 bug，而剩下的只是新代码，那么您的日程安排将更加准确。

将 bug 计数保持为零的另一个很棒的事情是，您可以更快地响应竞争。一些程序员认为这是使产品随时准备就的准备*。然后，如果您的竞争对手推出了一种吸引用户的杀手级新功能，则您可以实施该功能并当场发货，而无需修复大量累积的 bug。

6.您有最新的时间表吗？

这使我们按计划进行。如果您的代码对企业至关重要，则有很多原因说明知道何时完成代码对企业很重要。

制定时间表的另一个关键之处在于，它迫使您决定要执行的功能，然后迫使您选择最不重要的功能并将其剪切掉，而不是陷入特征成熟度（又称范围蠕动）。

7.您有写软件规格说明书（SPEC）吗？

在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了。

没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。

不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。

8.程序员有安静的工作条件吗？

通过为知识工作者提供空间，安静和私密性，可以广泛地记录生产率的提高。

9.您是否使用金钱可以买到的最好的工具？

要给予程序员尽可能好的条件

10.您有测试员吗？

需要有测试员来检测产品的漏洞

11.新候选人在面试中是否写代码？

通过写代码了解程序员的能力，而不是看似漂亮的简历和问几个简单的问题（如CreateDialog()和DialogBox()有什么区别？这种问题，查一下帮助文件就知道了）

12.您是否进行走廊可用性测试？

也就是随便抓一个人来，进行测试。

走廊实用性测试对于企业产品测试来讲提供的反馈比招募来做测试得出的结论要好很多，而且很多时候是完全相反的结论。

但现在很多企业都不做走廊测试了，而改用poll这种电子方式在Social Media发布，让用户选择。原因是走廊测试这种方法的效率不高。