编程的切入点
2005年8月4日
以前在大学一年级学软件工程的时候，老师主要教的是瀑布式开发模型。瀑布式开发模型是一种通用的、简易的开发模型。它的流程是顺序的，这使得它很容易掌握。缺点则是太简单，没有考虑到实际情况中需要回溯的特点。
瀑布模型一开始要求我们从可行性分析开始，然后需求分析，概要设计，详细设计，编码，测试，运行，维护。其中需求分析是关键，用户有什么样的需求，就有什么样的设计和程序。当然，在同一需求情况下也有可能有多种不同的设计。但是，需求如果不同，设计一般也有所不同。
而这需求，抽象地来说是什么呢？
众所周知，计算机是工具。在人类的历史上，工具的作用是弥补人类手工劳动能力的不足。计算机系统是软件加硬件，而软件的作用也是工具。于是，软件也是为了弥补人类手工劳动能力的不足而设计的。
而无论什么工具，包括软件，都有其固定不变的特性，否则就不成为工具了。于是，软件这样一种以逻辑流程为固定特性的工具，就是为了简化人们对此逻辑过程的掌握而让人们能应用这种逻辑过程进行其他的工作。
于是，当人们在做一件例程化的事情时，其中不变的逻辑，就可以作为软件来实现出来。而会改变的参数，则是软件设计时应该处理的数据。
以命令行上拷贝分卷文件的程序为例：当每个分卷压缩的文件大小是 1325 KB 时，如果文件分为 xxx.001、xxx.002、xxx.003、……，这样就需要有一个程序来自动寻找这分卷的文件。由于文件的主名 xxx 是可变的，因此这个主名应当作为参数。
而在设计时，要对 001 等扩展名进行匹配，并且需要速度足够快。有几各方案：一、从 1 开始枚举，并化为 001 这样的形式，然后与目录中的文件进行匹配。这种方案明显有问题：当文件名扩展名到 090 时，需要进行 90 次枚举。当这种扩展名的文件不存在时，要进行 1000 次匹配。二、把所有目录中的文件找出来，然后对其扩展名进行排序，然后再对其主名进行匹配，取扩展名顺序最前的（如果是从小到大排序）文件即可。显然这个方案相对较合理，因为一般人工管理的文件夹中不会有太多文件。对这个方案有一个改进：先对主名进行过滤，然后再进行排序。
从上面的讨论可见，编程本身要考虑设计的两个方面：一是参数是什么，这是很必要的，因为每个有用的程序都是拿来用的。如果没有考虑好参数是什么，很有可能在实际使用的时候不能提供应有的功能。二是应该怎么实现，这也是考验人的技巧和实际经验的时候。比如这次在东方宽频做音乐网站的时候微软的王浩就帮助我对某些比较难以定性的问题上作了实现上的确定。当时我在考虑，每张专辑中可能有多个艺术家的名字，而每个单曲中也可能有多个艺术家的名字，很有可能重复，因此如何让程序来自动解决这个重复的问题，是一个比较关键的问题。后来，和王浩讨论了以后，我们决定：在程序实现的时候，对于同一张专辑中的同名艺术家就认为是同一个。