有的工程师不在乎效率，也不管架构或者代码漂不漂亮，上面要求他做什么，他就想办法东凑西凑，从

Google 找程

序剪贴，从

MSDN 抓范例来用，反正只要能随便测过一个 case 就能交差了。

…

他们常常只是因为火烧屁股了，就不管三七二十一先弄出可以动的程序再说，效率或架构等到下一阶段再来改就好

。问题是，下一阶段又有新的功能要做，这些人再度面临抉择时还是会决定先让程序「会动再说」。我看过很多各式

各样的程序员，只要碰到这种人，同样的过程是履试不爽不断出现。
所以要成为一个优秀的程序设计师的关键是什么？关键不在于

coding 速度有多快、懂多少算法，或是背了多少

patterns ，最重要的是「热情」！

伟大的程序设计师都非常喜欢写程序，写程序的过程是一种绝妙的享受，他们执着的地方或许不同，可能是程序的效

率，也可能是开发的效率，甚至是架构的弹性或是程序码的精简美观程度，但他们都非常想要并坚持自己应该写出

「好程序」。热情能驱动他们把软体的某一个面向雕琢到极致，这需要超乎常人的毅力和坚持，以及绝不向压力妥协

的精神。只要具备这种热情，不管你在乎的是什么，都可以成为一名伟大的程序设计大师。

写程序需要的思考能力第一是逻辑思考，主要其实就是用正确、清晰的逻辑表达想法而已，说来简单但要做好也是需

要一定时间的训练。第二是抽象化思考，这是许多人忽略掉的一点，也是我觉得区隔一个平凡与伟大程序设计师的重

要特质。
所有的程序都可以看成一个巨大的金字塔，顶端是这个程序的最终目标，一个模煳的概念；底部是细节的程序码。而

中间是一个经由不断切割与抽象化所构成的高塔，每一个程序都是切割为许多的元件、模组，再切为更细的

class 和

function ，再来是最底下的变数与逻辑判断式。
很有趣的是，不同的人看这个塔就会有不同的样子。初学者看到的塔只有两层，他们和人沟通的方法是鉅细靡遗的描

述程序码：「我在这里写个

for ，第一次把 i 设成 0 ，在循环内每次检查这个阵列的第 i

…

个元素 」，在他们眼中只有

程序的目标和程序码本身
有些经验后，会再多看到一层，利用

function 把一段程序码包装起来，赋予一个名字和独特的意义。学会这个后，就

可以利用抽象化后的

function 名称来沟通，例如：「我在这个循环里每次都用 isCaptial 来检查这个字串是不是都是

…

大写 」再接下去，可以再利用

class ，利用 design patterns ，利用更大的模组、子系统来沟通，认真说起来，这

其实是一个无止境的切割。
在开发这个领域，抽象化是个无穷无尽的必要行为。因为世间万物实在太多太复杂，我们只好不断把东西归类，并赋

予一个名称、一个意义，经由这样的过程我们才能用抽象的语言和符号来沟通，避免每次都要从最底层的琐碎细节开

始说起。而平凡和伟大的程序设计师，我觉得他们之间的差别就在于能看到多少这个高塔中间的分层。厉害的高手都

很善于切换自己思考的高度，一下能跟你讨论高阶的系统架构设计，一下又能深入到最底下的代码和

debug 。他们脑

中除了有这高塔每一层的详尽平面图，甚至也非常了解不同楼层之间的交互关系。而平凡的程序设计师大多只能专注

于自己所开发的范围，对于其上的架构或其下的细节都不一定能理清头绪，万一出现

bug 也会搞不清楚到底是哪一层

出了错，而被完全无关的细节绊住手脚。