编程本质论

编程本质论<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

by leezy_2000

这几年各种新的技术井喷一样的涌现出来。身处这样一个时代的我们，难免就有一种拔剑四顾，心下茫然的感觉。在某一方面的做到精专已属不易，全才似不可能，那么究竟又该何去何从？这篇文章目的是探讨编程过程中一些本质的东西，已期对大家的学习有所帮助。

个人以为，从编程这一职业诞生开始一直至今，其本质就没有改变过。对概念的抽象对逻辑的描述始终都是编程过程中最核心的东西。

程序为解决某一问题而存在。而问题可拆分成某些概念和逻辑关系。而结构化程序设计和面向对象程序设计不过是对概念和逻辑进行表达的不同方式。而程序中逻辑关系的复杂程度随程序的规模而增加。

程序的本质不是各种技巧。就算你把Effective C++，More Effective C++中的每一条款都应用到了你的C++程序中，如果没有对逻辑关系的良好组织，你的程序也可能糟不可言。可能高耦合低内聚，可能不可扩充―――。

上面这段文字提到了四个概念，他们分别是：问题、概念、逻辑和技巧。

我来举个例子来说明这四个概念都代表些什么。

现在假设我们需要根据已知的一个文件名产生一个临时文件名。如果输入为prog.dat,mydir,hello.,oops.tmp,end.dat那么相应的输出为

prog.dat=>prog.tmp

mydir=> mydir.tmp

hello.=>hello.tmp

oops.tmp=>oops.xxx

end.dat=>end.tmp

（这里使用了The C++ Standard Library中第11章的例子）

什么都不做的程序是不存在的，程序总要解决客观世界中的某些问题。这里的问题就是要为一个已知的文件名产生相应的临时文件名。

解决这个问题时涉及的概念主要有两个：字符串和扩展名。扩展名可以用字符串进行表示。

解决这个问题的逻辑之一可用下面的伪代码来表述：

if(输入文件名没有扩展名)

{

用输入文件名、'.'号和"tmp"生成临时文件名；

}

else

{

得到输入文件名的扩展名；

if(扩展名为空)

{

用输入文件名和"tmp"生成临时文件名；

}

else if(扩展名为"tmp")

{

把"tmp"替换为"xxx";

}

else

{

把文件名'.'以后的部分替换为"tmp";

}

}

当然你还可以有其他的实现逻辑，而这种逻辑总是可以独立于语言、操作系统的。

至于你是用C++标准库、还是MFC的Cstring类或者.net中的相应类或者不依靠类库自己用某种语言来表述这种逻辑那就是技巧。

上面虽然是个小例子，但我认为完成任何程序：从上层应用直到底层驱动，都会涉及到这四个概念，。

上面所说编程时必须的四个要素中，我个人认为逻辑和概念是编程中更本质的东西，直接的原因是他们在更大的程度上决定着程序的质量。不要忘了评价软件质量的几个指标：

健壮性、可重用性、易扩充性、容错性等。

而这些指标并不是你选择了某个语言或者某个框架他们就达到了。而要通过对解决的问题的逻辑进行提炼和精化才可能达到。不要说这是系统分析的责任，程序每一部分都有自己要解决的问题，怎么可能每一部分程序质量的保证都是系统分析的责任。

此外当你要把原来用软件实现的功能换做用硬件来实现的时候，这点就分外的明显－－软件其实就是一组逻辑关系。

但眼下主流意识形态似乎并不认同这点,各种招聘广告可为明证。

下面是一个招聘软件工程师的广告：

1. BS degree or above in computer science.
2. At least 2 years of driver development experience.
3. Experience in C, C++, windows SDK/DDK or Linux system development.
4. Familiar with computer networking or telecommunication 802.3, 802.11, TCP/IP protocol is a plus.
5. Familiar with embedded system design.
6. Familiar with Bluetooth is a plus.

如果把编程与磨刀砍柴做类比的化，那么

当某个人熟悉某种语言、某个框架、某个IDE、某个协议某个开发包的时候我们可以认为这个人拥有一把较锋利的柴刀。但这和这个人最终擅不擅长砍柴并没有必然的关系。夫欲善其事，必先利其器。但利其器了未必就会善其事。所以说上面的广告一定程度上相当于想找一个会砍柴的人，但看人的时候却更注重他有没有一把锋利的刀子。（更可悲的是挣扎在生存边缘的我们，纵然不愿却也不得不迎合这种要求）

未避免矫枉过正，这里要强调一点，不是说基本技能不重要，没有对语言、框架、IDE的一定认识，根本就产生不了有用的程序。但当我们执迷于对不同语言、框架、IDE的优缺点进行比较的时候，不要忘了他们并不对程序的健壮性、可重用性、易扩充性、容错性等最终衡量程序优劣的诸多方面起决定作用。起决定作用的是你对概念的定义方式和对各种复杂逻辑关系的描述方式。

语言是什么？语言是逻辑的载体和描述的工具。当你试图表述逻辑关系的时候大多语言应该是满足这一要求的，要不然他早被淘汰了。框架是什么？框架是对逻辑和概念的一种封装。框架把某一领域通用的概念和逻辑封装起来，进而使程序员不必做一些重复性的工作。而实际上对这个领域的这些通用概念并不只有这么一种表述方式，也就是说并不只有一种逻辑表述。你选择某个框架的同时也就意味这你从n种方式中选择了一种，舍弃了其他。没有那个框架是完美的，选择的同时自然也就继承了这种不完美。所以善用他们，他们很重要，但不会再重要了。

当我意识到这点时，我发现虽然编程许久，但在对逻辑表述方面的能力却没有寸进，因为把90％以上的时间都投在了技巧的提升上了。Jeffrey Richter和Matt Pietrek两位堪称Windows编程界中的技巧大师。可我现在敢说即使你把《Windows核心编程》、《Programming Server-Side Application for Micorsoft Windows 2000》还有MSDN杂志的Under the Hood专栏倒背如流，你可能还是写不出高质量的程序。这些东西是必须的，但远不是全部。

林锐写过一本《高质量C++/C编程指南》，此书在网上流传甚广，我想原因有二：一是此书对C/C++语言中的容易造成模糊的地方进行了详细说明（真的很有用）；二是林锐笔法不错。但也正因其流传甚广，我觉得在这里必须指出，此书严重的文不对题。按照书中所说那些就能设计出高质量的C/C++程序么？那些都是编程所需要的技巧，不过是告诉你怎么能磨出一把锋利的刀而已。如果读过此书的人都把这些技巧和高质量的程序相等价，那么学习时恐怕就难免会误入歧途了。

这个题目太大，我是姑妄言之。这里不过是刚刚开始一种探讨而远非结论。欢迎大家一起讨论，还望诸君有以教我！