顺序、分支和循环

“虽我之死，有子存焉” ，这里描述了可能存在的分支结构，即“IF”条件判断。

“子又生孙， 孙又生子； ⋯⋯子子孙孙， 无穷匮也” ，这里描述了完成这个工程所必须的循环结构。作为优秀的程序分析师，愚公论述了这个循环的可行性：由于“山不加增” ，所以条件“山平”必将成立(“何苦而不平”)，所以这不会是一个死循环。

在愚公的论述中，我们看到了编程的根本：顺序、分支和循环。庞大若“愚公移山”这样的工程，都是可以通过这样简单的编程来实现的。这，就是编程的精义了。

程序 = 算法 + 结构

编程作为一种行为，只需要知道其逻辑方法就可以了。所谓编程实际上是把一件事情交给计算机去做，你认为这件事该如何做，就用“程序语言”的形式描述给计算机。如果你原本就不明白如何去做，那么你也不要期望计算机去理解你想要做什么。

所以编程的第一要务是先把事情分析清楚， 事件先后的逻辑关系和依赖关系搞清楚，然后再去代码实现。一接到任务就开始 Coding 的程序员，通常就是加班最多的程序员。

“程序 = 算法 + 结构” 。这个公式的精彩之处，在于它没有任何的地方提及到 Code。甚至可以说，在这个公式里，代码是不存在的。存在的只是思想。

当你熟悉了一门语言之后，你会发现，编程语言只有喜欢与不喜欢的问题，没有会不会的问题。任何的一门语言，你都可以在两周内掌握并开始熟练编程。因为任何的一门语言，他们的底层函数库都是那么的相似，而他们API 都是那样的依赖于操作系统。A 语言里有的，B 语言里也基本都有。

通常而言，语言的差别主要表现在适用范围上。一些语言适合做数值处理，小数点后可以精确到原子级，而小数点前则可以表达到宇宙之无穷； 另一些语言则适合做图形处理， 它的底层函数库比其它语言可以快上十倍或数十倍；还有一些语言则适合于做网页，要用它来做一个通讯薄软件都将是史无前人的挑战。

成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。不但是悲其一叶障目，更要悲叹于那种大愚若智的自得心态。

懒人找方法

正是一个懒人造就了“烧石头”这个“碎石”的方法。愚公太勤快了，勤快得今天可以比昨天多凿一倍的石头。或者在愚公的项目计划案的首页里就写着朱笔大字： “吾今胜昨倍许，明胜今倍许，而山不加增，何苦而不快。 ”但是越发的勤快，愚公将越发没有机会找到更快的方法，人的精力终归是有极限的。提出新的“方法” ，解决的将是影响做事成效的根本问题。而愚公可以多吃点饭，多加点班，但突破不了人的精力的极限。

面向对象

面向过程是对“流程”、“结构”和“编程方法”的高度概括。而面向对象本身只解决了“结构”和“编程方法”的问题，而并没有对“流程”加以改造。

所以所谓的面向对象的事件还是“顺序”的。所以我们经常要考虑一个事件发生后对其他过程的影响， 所以面向对象现在而言是牵强的。

事件的连续性并不是某种编程方法或者程序逻辑结构所决定的。 正如你前面所说的，那是CPU决定的事。

你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？

实现，才是目的

很多人把问题的本质给忘掉了。从最开始，从我们编程开始，我们的目的就是实现一个东西。无论这个东西是

小到一个称手的工具，还是一个大到千万的工程，我们的目标，都是要“实现”它。工程只是一种实现的途径。最初做开发的前辈们，不用什么工程或者过程，也一样编出了程序，也一样解决了问题，也一样实现了目的。而现如今，我们讲工程了，讲过程了，讲方法了，却什么都再也做不出来了。不奇怪么？

工程被当成了借口， 掩盖了我们做事的真正目的： “实现” 。因此，我们在一个项目中常常听到说“工程要这样

做” ，或者“工程要那样做” ，而绝少听到“项目要求这样做”或者“客户的本意是那样的” 。这样的结果是：我们做完了工程(的每一个过程)，却没有完成项目(的每一个“实现目标”)。

为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD

之间的区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的， 再也没有挣扎一下

的力气。

总结造就GoF

推动这种逻辑向前发展的，是“方法”和“方法论”的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种(软件开发)方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。

这是实践的成果。 方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出某个方法，IBM 也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。

方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF 归纳、抽取、提升了这些行为的内在规律。

你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的

编程经验才能理解。同理，理解过程也需要编程经验，理解对象也需要编程经验，理解 MDA 与 SOA 还是需要编程经验。——这可能就发生在你去回顾你上一行代码编写的经过，或者上一个项目失败的经历的那一瞬息。经验来源

于回顾、理解与分析，而不是你将要写的下一行代码。

有人在寺院扫了一辈子的落叶而得道， 也有人因为一句话而得道。

GoF 因为无数次的代码回顾而得道。