思勤无邪

网上看了篇文章，觉得很不错，抄在下面。因原文没注明作者，在这也不知道作者是谁了。

编程概述

编程术可以看作实用魔法的一个分支。编程魔法师用时间和精力做祭品，与生活在计算机中的精灵订立契约，以换取驾驭代码的能力。
---fmddlmyy

要提高编程水平，唯有多看多写。这篇文章看似经验之谈，实质还是灌水。本次灌水，拟定了以下几个主题：

§       编程概述

§       软件开发中的方法论

§       编程实践

§       嵌入式编程的特点

编程概述

本文将从不同角度讨论 “ 什么是编程 ” ，或者 “ 什么是编程的本质问题 ” 。这些讨论并不是要得出什么定义，我们实际上是在表述各种编程思想，以期加深对编程的理解。

1 编程不是艺术

我们的世界是模糊的、连续的、不精确的，但软件是精确、离散的、形式化的，这就注定了软件不能完全描述现实世界。因此我们需要知道描述哪些部分，忽略哪些部分，这就是软件的本质问题。
--- Tom Demarco

编程不是艺术。编程不追求完美，它的目的是解决问题。

和艺术上的 “ 只能意会，不可言传 ” 相反，编程甚至不能忍受自然语言的模糊性，它要求问题被表述成可编译、可运行的代码，文字和图表只是辅助交流的工具。

每个程序员有两个面具：职业的和专业的。戴上职业面具后，程序员会用能找到的最好用的工具，以尽可能简单的方式，在合理的成本内解决问题中必须解决的部分。

而戴上专业面具的程序员，会不厌其烦地学习各种编程知识（很多都不是职业需要的），积累经验值，吸收可复用的模式和思想。他们会用大量时间去理解程序的表象和 CPU 的汇编代码之间究竟发生了什么。他们有着探索未知领域和练功升级的强烈欲望。

他们在不断接近技艺的完美，而这个技艺本身是以不谈完美、但求有效的方式解决问题。他们付出了大量的努力，而这些努力的驱动力是好奇心和进取心。如同《魔法学徒》中描述的魔法师，一个魔法师所追求的东西只有志趣相投的魔法师才能理解，而不管他们出于哪个阵营。了解事物真相本身带来的满足就可以作为一切努力的回报，

2 控制复杂性

任何一个正在构建大型系统的人，天天面对的中心议题就是：如何剔除不必要的、人为的、自找的复杂部分，并控制好剩下的，无可逃避的复杂性。
--- Betrand Meyer

编程可以被看成一种管理工作，管理的对象是代码，控制的对象是代码的复杂性。

中国的传统思维比较喜欢谈本质，追求一种称作 “ 道 ” 的东西。而在编程上，表象和本质同样重要。所有程序说到底不过是一些汇编语句的组合，但了解这个本质在大多数场合都不能有助于解决实际问题。

写代码是为了解决实际问题。当代码的数量增加到一定程度，对代码自身的控制也会成为一个重要的问题。数量改变了本质。

管理的要诀是削弱、孤立被管理的对象， “ 使民无知 ” ， “ 使民 ”“ 鸡犬之声相闻 ” 却 “ 至老死 ” 而 “ 不相往来 ” 。每个被管理的对象在完成自身工作的前提下，对其它对象的了解应当尽可能少。通过尽量降低对象间的耦合程度来控制复杂性。

只有有效地控制复杂性，我们才能使用越来越大的信息块，驾驭越来越多的代码，用这些 0 和 1 的操作去实现前人没有，甚至无法完成的工作。

3 复用

编程技艺的核心是代码的复用。复用已有的知识是积累、提高的前提，否则就会像谁谁谁那样每天推石头上山，而不能累进。在上帝看来，重复是一种惩罚的手段。

编程这个职业知识更新比较快，可以学习的东西也很多。有些人觉得累，但有些人却觉得其乐无穷，觉得从事这个职业是很幸运的事情。

编程的实质是建筑，根据应用的需求，不断建筑更大的信息块。我们所写的所有程序，都可以被看作对语言的扩充。事实上，我们在不停地开发新的语言，我们所写的每个函数、每个类都是在为现有语言增加新的功能。我们按照适合特定应用的模式，组合各种信息块，完成实际的应用。这些信息块有的是我们自己做的，有的是拿来的。

信息块可以被组合的关键就是简单、明确的接口。所以，我们应当针对接口编程，而不是针对应用编程。应用意味着变化和不可复用。将应用合理分解为模块，定义好模块间的接口，然后按照接口构建模块。模块分解的原则是：

§       模块的耦合程度尽可能得低（有人称此为最少知识原则）；

§       接口尽可能简单（有人称此为接口隔离原则）；

§       如果将变化的因素封装到模块中，每个模块应该只封装一个因素（有人称此为单一责任原则）；

§       使特定于应用的代码尽可能得少 。

针对接口编程的好处有两个方面：

§       信息块可以被复用；

§       复杂性可以被更好地控制。

人们用各种方式复用知识，其实 C 语言本身又何尝不是知识的复用呢？其它复用方式包括：库函数、新的语言和编译器、新的脚本、类库、程序框架、设计模式、面向对象、面向组件、面向服务、面向方面、面向领域、各种开源代码、开发环境提供的各种 Wizard 和糖衣、各种代码生成工具等等。充分了解编程环境，善于复用各种资源，是程序员的基本功。

 

软件开发中的方法论

 

1 项目管理的方法论

1.1 方法论

方法论的英文为 Methodology ，编程的方法论应该是指软件开发的一整套方法、过程、规则、实践、技术。不过我们一般提到的方法论都偏重于项目、过程和人员的管理。

《 Agile Software Development 》的作者 Alistair Cockburn 提出方法论具有以下要素：角色、个性、技能、团队、技术、活动、过程、产品、里程碑、标准、质量、工具、团队价值，它们的关系可以用一幅图来表示：

 

虽然将这幅图贴在这里，事实上我不了解这些要素及其关系的确切定义，对于这些不能精确描述的东西，我接受起来比较困难。

其实，项目管理的核心是沟通和反馈。只要能够保证良好的沟通和即时的反馈，开发团队即使并没有采用先进的方法论，一样可以成功。从另一个角度说，过程和工件能辅助，但不能保证开发人员、项目经理和客户的良好交流。

1.2 重型方法

有的方法论规定了大量的中间文档和复杂的过程管理。那些中间文档被称为 artifact ，或工件。需要大量 artifact 和软件开发方法被称作重型（ Heavy Weight ）方法。

这些复杂的方法来源于恐惧。

在中大型的项目中，项目经理往往远离代码，他们无法有效的了解目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感，项目经理制定了大量的中间管理方法，希望能够控制整个项目，最典型的莫过于要求开发人员频繁地递交各种报告。重型方法中的基本假设是过程（及各种 artifact ）比个人可靠。

虽然很多轻型方法都将重型方法作为反面例子，但对于大多数大型项目，重型方法是管理所必需的。

1.3 轻型方法

为了解决重型方法存在的问题，业界出现了很多轻型（ Light Weight ）方法论。提出这些方法论的部分作者结成了一个联盟：敏捷软件开发。他们还有一个宣言：

§       Individuals and interactions over processes and tools.

§       Working software over comprehensive documentation.

§       Customer collaboration over contract negotiation.

§       Responding to change over following a plan.

在这些宣言后面还有很多原则。概括起来主要是：尊重个人，强调沟通和反馈，与客户紧密合作，保持设计的简单性等等。敏捷方法在重型方法论和无管理状态之间寻求一个平衡点，希望用低成本的管理活动带来最大的产出。

2 编程的方法论

作为程序员，我更感兴趣的是可以指导编程的方法论。

2.1 测试驱动开发

2.1.1 未谋进，先谋退

在开始一件事情之前，必须先明确什么时候可以停止。什么 “ 止于至善 ” ，在编程工作中可以一脚踢开。我们必须明确要做什么，做到什么样子就算完成了。

怎样才算明确呢？最理想的方法是先写一个测试程序，然后再编写代码，让测试通过。测试程序规定了停止的必要条件。

测试程序是针对接口编写的。要写出测试程序，必须先定义好接口，然后针对接口编程。测试程序同时示范了接口的使用。

如果有一个运行很方便的测试程序，我们在维护代码时，就放心得多。可以经常跑一跑，测试一下，以保证测试要求的功能还没有被破坏。相反，如果没有测试程序，我在修改代码的 bug 时，心里就很不踏实，因为我不清楚我的修改是否会引入新的 bug 。

2.1.2 保持可运行，可调试的状态

“ 先写测试程序 ” 适合没有 UI ，功能相对简单的模块。对于功能复杂的软件系统，需要测试的方面很多，测试时间很长，在开发前就建立一个比较全面的测试，并且随时使用，有时是不可能的。

但我们至少应该保证：写任何程序，都要尽量保持在可运行、可调试的状态。即使要为此写一些额外的程序，都是值得的。在不能运行的情况下，编写大量代码是不可思议的事情。

2.1.3 可测试性

IC 设计上有一个 “Design For Test” 的说法，即 IC 的设计中必须要考虑到如何测试，留好测试的接口。软件开发也是一样的，我们写每段代码，都要考虑一下这段代码是否可以测试，为了保证可测试性，必要的时候可以修改设计。

2.2 重构

《重构》这本书内容朴实、但对我个人影响很大。在了解 “ 两顶帽子 ” 和 “ 小步前进 ” 的方法后，我敢于修改任何代码，甚至是我不熟悉底层逻辑的代码。

2.2.1 两顶帽子

我们有两顶帽子：一顶是不改变功能的前提下，改善现有现有程序的设计；另一顶是增加新的功能，以适应需求变化。我们在任意阶段，应该只戴一顶帽子，绝对不能同时戴两顶帽子。

在增加新功能的时候，往往需要先改进现有的代码结构，使之能更好地适应变化。如果功能有较大变动，我们应该将这变动分解成尽可能小的步骤，并让改进代码和新增功能的小步骤交替进行。将原有代码平滑地演变到新代码，既增加了功能，又改善原有代码的设计。

重构的正式定义应该是 “ 在代码写好之后改进它的设计 ” 。但对我而言，重构的思想已经融入了我的开发过程。在开发中，我同样按照 “ 两顶帽子 ” 和 “ 小步前进 ” 的方针平滑地演变代码，从无到有，逐步完善。

2.2.2 代码的坏味道

重构的对象是消除 “ 代码的坏味道 ” ，保持新鲜、健康的代码。《重构》中列举了一些典型的坏味道，例如重复代码、太长的函数、太长的参数列等等。

2.2.3 设计和重构

存在这么一种说法： “ 设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来 ” 的。

事实上，在没有任何软件工程理论的时代，编程基本上是写到哪儿算哪儿。历史是螺旋上升的，在投影上很接近的两个点在铅垂线方向上是处于不同高度的。

重构是要纠正过度设计的倾向，告诉程序员：即使开始的设计有缺陷，也没关系，更不要僵化地保持，我们可以重构代码，平滑地修改原有设计。这并不是说前期设计不重要。

“ 设计是在整个开发过程中逐渐浮现出来 ” ，这是在说随着开发的深入，我们会对很多问题考虑地更加清楚。在必要的时候，我们应该用重构的方法灵活地改变设计，适应变化。

 

 

编程实践

鸠集遗失，鉴玩整理，昼夜精勤，每获一卷，遇一画，毕孜孜葺缀，竟日宝玩，可致者必货敝衣 , 减粮食。妻子童仆切切嗤笑，或曰：终日为无益之事何补哉。既而叹曰：若复不为无益之事，则安能悦有涯之生。
--- 唐 张彦远 《历代名画记》

1 编程的要素

编程有 3 个要素：语言、环境和思想。

1.1 语言

有人喜欢争论语言的优劣。其实，除了汇编语言，各种语言、脚本、标准库、类库、框架都蕴含着大量成熟的编程经验和思想。程序员应该多熟悉一些语言，特别是有代表性的语言。

个人觉得，一个程序员应该掌握一两种汇编语言（ CISC 的 X86 、 RISC 的 ARM ）、一种面向过程语言（ C ）、两、三种面向对象语言（ C++ 、 Java 、 Delphi ）、一两种脚本语言（ perl 、 python 、 ruby ）。如果有时间，可以再学习一些学术性较强的语言，例如 Scheme 。

学习新的语言，不仅可以吸收语言中蕴含的设计理念，还可以打开连接新空间的大门，使我们可以学习、复用使用该语言的各种资源，例如源代码、文章、书籍。

1.2 环境

1.2.1 开发时和运行时

环境可以被理解为程序所有外界环境的总和，包括开发时环境、运行时环境。我们在写一段程序时，应该对该程序的相关环境有清楚的了解。

开发时环境包括我们使用的编译（链接）环境、复用的代码（框架、类库、控件等），系统的逻辑结构、代码的文件组织、需要的工具软件、调试环境等等。

运行时环境包括程序运行时环境中所包含、发生的一切，特别是与我们的程序相关的部分。从小处看，我们应该知道如何确定每段代码运行的 context （线程和堆栈），每个变量所使用的空间的信息。从大处看，我们应该了解系统运行的来龙去脉，各个模块（逻辑概念）如何相互配合，各个线程（调度单位）如何相互通信，什么时候可能发生调度，系统中有哪些不确定的因素等等。

1.2.2 软件类型

比较 “ 典型 ” 的软件类型包括：

1.   Windows 操作系统；

2.   Linux 操作系统；

3.   编译器；

4.   虚拟机；

5.   调试器；

6.   Windows 的单机应用程序；

7.   Windows 的驱动程序；

8.   Linux 的应用程序和驱动程序；

9.   基于 socket 的客户端 - 服务器程序；

10.   数据库应用程序；

11.   使用数据库的 Web 应用程序；

12.   使用 RTOS 的嵌入式软件；

13.   不使用 RTOS 的单片机程序；

14.   DSP 程序；

15.   嵌入式环境的第三方程序（ J2ME 应用、 BREW 应用、 symbian 的应用程序等等）；

16.   各种中大型程序的脚本环境，插件的开发、运行环境；

17.   Office 应用程序开发；

18.   flash 编程；

软件的种类实在太多，所谓 “ 典型 ” 只是我个人的理解，肯定还有很多软件类型没有被列出来。程序员应该了解开发和运行这些软件时，究竟发生了什么。

对于 Windows 、 Linux 操作系统，我们应该有个概要的了解：从 BIOS 程序读 Master Boot Record ，到系统的装载运行；应用程序或动态连接库（ Linux 的 SO ）的装载；操作系统的基本模块（包括内核）的功能； Windows 如何通过 COM 机制将各个功能模块组合起来等等。这些内容是 PC 程序的基本运行环境。

嵌入式环境相对 PC 环境要简单一些，特别是用 NOR flash ，代码直接从 ROM 运行的系统。一方面，程序员通常可以看到系统运行的所有代码；另一方面，嵌入式环境有时不提供第三方程序运行机制，有时提供比较简单的机制，有时用 java 虚拟机当作第三方程序运行机制。不过，智能手机的应用处理器一般使用 NAND flash ，从 BIOS 运行一小段启动代码，将系统装载到 RAM 运行，同时支持应用程序装载运行，已经很接近 PC 环境。

编写单机应用程序，除了语言外，主要要熟悉各种库、框架、组件。一些通用库提供了常用函数、各种容器和算法、 GUI 、典型的程序框架，系统 API 的封装等等，例如：

§       移植性比较好的 C 标准库、 STL 、 boost 、 TK 等；

§       Windows 上的 MFC 、 VCL （ Delphi/C++ Builder ）；

§       Linux 上的 ncurses 、 X Windows 、 GTK 、 Qt 等；

§       访问数据库： VC++ 的 ODBC 、 DAO 、 ADO ， Borland 的 BDE 等；

§       Borland 做了一些在源代码级跨平台的库： Delphi/Kylix 的 CLX 、 dbExpress ；

§       CPAN 上的大量 perl 模块、 java 的类库等等；

上面列出的是一些比较通用的库。还有用于各种语言的大量专用库，各种提供二进制接口的组件、控件。

编译器、虚拟机也是单机应用程序（在嵌入式环境，虚拟机可能是系统软件的一个模块）。不过它们的地位比较特殊。作为程序员，我们应该了解编译器、集成开发环境、软件框架、虚拟机、操作系统分别为我们做了什么。

作为程序员，我们同样应该理解调试器也是一个应用程序，调试器的基本原理，它能做什么，有什么限制。如果调试器与目标程序运行在不同的 CPU 上，调试是如何实现的，有哪些不同的实现方式？例如 JTAG 调试利用了目标 CPU 的调试接口直接调试目标程序；串口调试要求将一段调试代码和目标程序链接在一起下到目标 CPU 中，由嵌入的调试代码与 PC 机的调试器通信实现调试。不同的实现手段决定了调试器的能力和限制。

目前最热门的软件类型就是使用数据库的 Web 应用了，例如各种网站、网络游戏、各种企业、行业、政府机构的管理系统，在这个领域集中了处于食物链不同环节的大量厂商，各种 Web 服务器、基础平台、应用开发框架。随便列一下，也能列出一堆名词：

§       HTML/CSS 和 CGI ；

§       java applet 、 java script 、 ActiveX 控件；

§       php 、 asp 、 jsp 、 servlet ；

§       .net 家族： asp.net 、 ado.net 等；

§       J2EE with/without EJB 、 Spring 、 Struts 、 Hibernate ；

§       Ruby on Rails 、 Plone 等；

在一种软件类型上，集中了这么多开发技术、框架、模式，也可以称得上蔚为壮观了。不过，这个领域里确实是各种最新的编程思想、方法、设计模式的演武厅，如同当年的编译器，值得所有程序员研究、学习。

1.3 思想

COM 可以被看作 OLE 发展的衍生品。但它的重要性远远超过了 OLE 。它首被独立出来，成为 OLE 、 ActiveX 的基础，然后逐步成为在 Windows 进行二进制集成的基础。 COM 和 RPC 的结合产生了 DCOM 。 DCOM 和 MTS 的结合产生了 COM+ 。虽然这些技术都是用于 Windows 平台的，但组件技术的基本思想是独立于具体环境的。也就是说，对程序员而言，存在着独立于语言和环境之外的领域，这就是编程的思想。

例如看看 Qualcomm 的 BREW ，就会发现它从 COM 中学习了多少东西。嵌入式平台的程序员使用 PC 平台的技术，这就是编程思想的价值。对于程序员来说，各种编程思想、设计模式，是最为宝贵的东西。这里所说的设计模式并不局限于 GOF 的《设计模式》，任何惯用的手法都可以被看作模式。

一些基本的编程思想起源于更普遍的智慧。例如：

心智的活动，除了尽力产生各种简单的认识之外，主要表现在以下三个方面： 1) 将若干简单认识组合成一个复合认识，由此产生出各种复杂的认识。 2) 将两个认识放在一起对照（在这样做时并不将它们合而为一），不管它们如何简单或者复杂，由此得到有关它们的相互关系的认识。 3) 将有关认识与那些在实际中和它们同在的所有其他认识隔离开，这就是抽象。所有具有普遍性的认识都是这样得到的。
--- John Locke, 有关人类理解的随笔

程序员从这段 1690 年的文字中能看到什么。组合、对照、抽象，这些基本的思维工具同样也是程序员最基本的工具。

2 编程规则

编程是一门技艺，如同我们必须跳到水里才能学会游泳，我们必须多看、多写程序，才能学会编程。

任何技艺的学习都包括知识和能力两个部分。知识是明确的，可以用时间换取。能力是说不清的，不易掌握的。一般而言，能力高的人能够更快地积累知识，善于从已有的实践中总结规律，善于复用已有的模式，他们能更快地对复杂的环境形成清晰的认识，用最简洁、优雅的方式解决问题。如何提高编程能力应该是因人而异，每个人应该找到自己的学习路径，有自己的规划。

编程的表象千变万化，但在表象背后，还是有一定规律的。在某些条件下，这样做会比那样做更好一些。我们可以将这些东西称作经验、原则、规则，或者其它任何名词。

下面松散地列举了一些规则。我们应该在实践中检验已知的规则，总结自己的规则。

规则一 这世界上唯一的真理就是不要盲目相信真理

从某种意义看，原则、规矩这类东西就是用来打破的。所谓原则，就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近，我们可以参考前人的经验。我们是主动地拿来，而不是被动的遵守。

规则二 未蕴而变，自欺也；知律而变，智者之道也

这句话谈的是学词，必须先了解格律，然后才谈得上变化，否则就是自欺欺人了。在编程上，也是一样。在有资格打破一条原则前，首先要了解这条原则。先了解事物的规律，然后才是变化和灵活的应用。不要打倒自己不了解的东西。

规则三 寻找结构和成本的平衡点。当结构不能容纳变化时，重构代码到新的平衡点

开闭原则要求：一个软件实体应该对扩展开放，对修改关闭。即软件的结构要达到：允许在不修改软件的前提下扩展软件功能。

但好结构是要花成本的。程序员总是在折衷，寻找结构和成本的平衡点。我们会放一些余量，让结构能承受一定的变化。

规则四 要针对接口编程，不要针对应用编程

前面谈过了。我们总希望通过工作得到一些收获，积累一些经验。只有将代码分解成尽可能独立的模块，然后针对接口编程，才能保护我们的成果，让我们有所积累。

规则五 最少知识原则：模块对外界的了解应当尽可能少

前面也谈过了。所谓 “ 圣人之治 ” ，经常是 “ 虚其心，实其腹；弱其志，强其骨，常使民无知无欲 ” 。让被管理的对象尽可能得弱，对象间的关系尽可能得简单，可以降低管理的成本。

在面向对象编程中 “ 组合优于继承 ” ，就是因为继承将基类的实现细节暴露给子类，两者的耦合性太强了。另外，继承的实现是静态的，而组合可以更灵活地实现。

规则六 尊重习惯

在任何领域编程，应该尽量了解这个领域的习惯，尽量符合这些习惯。这样，别人可以更容易地理解和使用我们的程序，更不容易出错。

规则七 程序中不要出现 magic number 或其它神奇的东西

magic number 就是诸如 17 、 42 这类数字。请用有描述性的常数名替代它们。常数名、变量名、函数名就是最好的注释。结构清晰的代码甚至可以不需要其它注释。

“ 需要很多注释的代码 ” 是代码坏味道的一种，常常意味着需要重构代码，使它更容易被理解。

规则八 “ 两顶帽子 ” 和 “ 小步前进 ”

“ 两顶帽子 ” 前面讲过了。面对复杂的问题，我们不仅要从结构上分解它，还要将实现步骤尽可能地分小，在一时一地以压倒性优势解决问题的一小部分。 n-1 个总比 n 个好对付，我们越来越强大，敌人越来越弱小，我们要做的只是将优势保持到最后。 “ 保持优势 ” 的关键是正确的理解、合理的划分。

规则九 适当地引入中间层，可以解决所有问题

这条规则是实质是 “ 抽象 ” 。在遇到问题时，多引入一层接口，将问题封装起来。

抽象本身并没有消除系统的复杂性，但它减少了在某个时刻需要处理的细节的数量。或者说，抽象将复杂性控制在接口和模型的后面，可以推迟我们处理这些复杂性的时刻。

这条规则的另一个说法是 “ 多做白日梦 ” 。假设我们已经得到了需要的东西，然后会怎么样？通过 “ 白日梦 ” 我们可以在更高的层次考察问题，可能找到解决问题的线索，也有可能发现这个问题毫无价值。即使毫无收获，我们也的损失也很小。

规则十 不要依赖调试，尽可能地依赖分析和推理

我经常会在头脑中预演调试的过程，计算我要做什么，我能得到什么。 “ 预演 ” 的结果经常是我没有必要这样调试，或者应该试一试另一个方法。

根据测不准原理，任何实际的测量、调试都会改变、影响被研究的对象。用调试辅助、验证我们的推测，但不要依赖调试。