《梦断代码》-《Dreaming in code》读后感

开发一个软件不是一个简单的事情；开发一个完整的软件更不是一件容易的事情。

首先对于完整的定义都是未知的，如何才能开发出完整的软件。阿兰*图灵已经证明了，不存在这样一个程序，它对所有的输入都会运行结束。如果我们想构建一个对所有输入都保证正确输出的程序，其结果是不可能的。

开发应用程序是存在一些方法的。之前看到kent beck在极限编程中，推崇测试驱动开发（TDD，Test Driven Development），整个开发过程中，测试是先行。我们首先测试用例，然后开始编写程序，当所有程序对设计的测试用例都通过时，则开发的代码是经过测试验证的。虽然经过测试的代码片段在被连接成为一个完整的程序，其并不能保证会正确的执行所有的功能，因为他们不是乐高积木，随便搭搭都会得出一个漂亮的结构。

在coding horror网站上还看到一种程序开发方式Compliant Driven Development，抱怨驱动开发。开发一种功能或者一个软件。首先需要给出一个quick-dirty的实现，然后开放给用户。用户在使用后会抱怨，会指出问题的地方。用户的抱怨就是软件需要改进的地方，当然众口难调，并不会针对每个意见都会去改变。取而代之的是，我们需要寻找一种符合降低大多数人抱怨的实现方法。（突然想起韩寒的一句话：真理是掌握在大多数人手里的，因为真理往往掌握在少数人手里，而少数又必须服从多数）我觉得这种开发方式还是挺有意思的，因为在这种不断的更新过程中，软件的会使得更多的用户抱怨减少，满意度增加，软件的受众会逐渐的增加。现今社会，谁有数据，谁才是真正的主宰者。用户的数据（report）是促使软件下一步继续迭代更新的重要参考。

不管采用哪种软件开发方式，整个软件开发过程从用例收集，软件设计，数据设计，细节设计，代码编写，每一个过程都需要工作，不同过程参与人之间需要沟通和协作。就像《人月神话》中所描述的矛盾：当发现软件进度迟滞后，盲目多增加开发人员不会加快进度，而是适得其反，因为沟通协作的时间，软件开发人员参差不齐等等原因。小的开发团队有时候会更加高效，而且对于决定的确定以及执行都更加的快速。

There is no silver bullet.

本文完。