方法论、方法论——程序员的阿喀琉斯之踵

方法论、方法论——程序员的阿喀琉斯之踵

By 刘未鹏(pongba)

C++的罗浮宫(http://blog.csdn.net/pongba)

TopLanguage(https://groups.google.com/group/pongba)

以前，我认为一个事物对我没有直接用途的时候就不会去理会它，心理学上说我们都戴着自己的认知偏见的有色眼镜去有选择性地看待这个世界，纷繁的信息经过我们的认知图式过滤之后便成为少量有序的事件，所以我们都在有强烈选择性地关注一些事物和忽视另一些事物，然而，这样可能会导致丧失一些很有价值的信息，而总是将知识面停留在自己的小世界中——当然这倒也不是说看到什么都要凑上去学一学。如何在这两者中间取得折中，我觉得一个好的办法是先简略地想一下这是个什么东东，他的本质是什么，出现是为了满足什么需求，等等比较“高层”的问题（即“What”和“Why”而不是“How”），这些问题应该是可以通过简单的调研和思考得出结论的，至于背后的技术细节，如果你打算入行，就可以去学，如果不打算的话则可以免了，至少前面的思考和简单的调研能够一定程度上保证当有价值的信息或机会摆在你面前的时候你不会把眼睛蒙上走开，并且多做做这类思考对于思维的广度也很有价值。最近我开始认为，最佳的学习方法就是先广度优先遍历（先弄清What和Why），然后择最合适的分支深入（How）（算法牛人DD同学在TopLang上的一个帖子里面也提到类似的想法，刚进大学就能够如此清晰地看清前方道路的走法，我对DD很佩服）。

方法论看似是个很抽象的东西，并且的确有一些方法论是抽象到 over-generalized （泛化过度）的地步，然而说实话在实践当中我总是发现（正确的）方法论是再现实不过的东西，比如一个大家都明白的道理是：如果方向走错了，那么做的功就基本全白费了（还有比如“如果方法对头，就能事半功倍，反之可能多走很多弯路”）——然而现实中有多少人能够真正实践这个方法呢？绝大多数人都是只顾解决眼前问题，抓了这头丢了那头，更多人是不知道问题是什么，只管把头脑中能联想到的一个以前类似情况下的类似方案套用上来。以前我总是觉得一个公司里面，CEO/CTO 这样的角色是基本摆设，但我现在不这样想了。在 How 层面把事情做好，做成一个精钻的程序员，那顶多就是能把钳子使好，这样的事情很多人都能做到，熟能生巧嘛。换句话说程序员基本上是去解决一个定义好的问题，去实施一个定义好的方案。然而决策问题就不一样了，决策问题是需要去定义问题是什么，以及权衡最佳方案是什么，不管是决策技术架构还是决策商业策略，都是非常复杂的思维过程，需要综合和权衡大量的信息，这种能力就不是简单楞着头搞下去能练出来的了，很多时候需要抬起头来看，免得只见树木不见森林。（以上也是为什么我在讨论组里面一篇帖子（什么是算法？为什么学习算法？以及学到什么程度？）中提到我觉得学数学学到精通未必就会思考日常决策问题的原因——数学几乎总是去解决一个定义好的问题，用的也都是定义好的严密的逻辑推导。然而现实中的问题是一个复杂系统，诸多变量互相影响，如何权衡最佳方案实际上是一个复杂的统筹规划。更重要的是，你往往甚至都不知道问题是什么，能够从纷繁的信息中抽象出问题，是一种极大的能力。这里推荐《你的灯亮着吗？》和《失败的逻辑》）

当然，我自己还没能到这个层面，尚需要不断实践和总结，所以只能稍微的谈一点感受，再往下扯只怕就会流于空泛了。这一点上我还是举一个程序员们喜闻乐见的例子吧，在程序员眼睛里面，做一个项目，也许首先想到的是用什么语言，什么框架，什么库，在这个方向上那就是什么看上去牛B用什么，恨不能都用 haskell、lisp 来写才爽，用 Java？那多没意思啊，Java 那坨弱智语法我小学的弟弟都能掌握，也没啥牛B的语言特性，忒没成就感（只可惜真正判别弱智与否的并非用什么语言技术，而是做出什么产品满足什么需求）。这就是属于只考虑单个孤立因素的简单（或者说 Naive 的）决策，这个因素就是——只要让我自己感觉爽——只可惜并不是让自己感觉爽的做法就是真正解决问题的做法，始终要弄清问题是什么，在后者意义上，一些对于技术型程序员往往没有吸引力的话题其实有着极其重大的价值——比如什么时候设计，什么时候重构，什么时候集成，再往上一层其实这些又都是次级问题，首要的问题还是这个产品满足什么需求，有什么市场（即这件事情值不值得做），有一句话想必很多人常听说，如果不知道要做什么，套上十二层架构也无济于事，方法永远不是因，而是果（我在以前的另一篇文章“Failing to see the Big Picture – Mistakes we make when learning programming”中也阐述了类似的观点）。

再举个例子，如果我想给我的网站做一个 feature ，我认为这个 feature 技术上很牛很强大，而且刚好有机会使用一下我最近修炼的某某 framework 和某某语言，而且这玩意很有挑战性，还不是一般人能够做得了的，综合以上三点，我立时觉得心痒难耐摩拳擦掌。然而实际上这个问题应该怎样分析呢？首先，考虑到以上三点，这将会是一个投入相当大的项目，那么其收益就必须要对得起这个投入，技术上很牛不代表商业上就牛，再牛再难做的 feature 如果不能带来商业价值那就是负收益。总而言之，

1. 一件事情仅仅让你感觉挺牛不代表这件事情就是值得做的；
2. 一件事情仅仅让你感到很有兴趣并不代表这件事情就是值得做的。

这两句话和我们日常的认识并不冲突，其实我们几乎总可以找到既有价值、又有趣、又有足够挑战性的工作。举个例子，本科数学学得精纯无比的同学有没有偶尔也会觉得盲目呢？做这些题目到底有什么实际用途呢？这就像是你总是在磨一把刀，磨得闪闪发光锋利无比，你可以向别人炫耀自己的刀很牛B，但是刀是为了冲锋陷阵血溅五步的，你也不想让它折戟沉沙吧，不管是将数学用在数学物理上还是用在人工智能、机器学习、密码学、通信上，都是既让人有成就感，同时又有意义和价值的事情。对我们程序员来说，你把一门语言玩得很精通，不仅知晓它所有的语法细节，陷阱和缺陷，还了解它的底层实现模型是如何。你觉得很牛很有成就感——的确，我们都会为一件自己做到了别人做不到的事情而感到自豪，然而反问一句，除了情绪价值之外，这样的事情在本身的价值上有没有你感觉到的那么牛呢？如果你只是在削铅笔，那么何必磨一把倚天屠龙剑来？反之，如果你做的是一个本身功能很牛很创新很有价值的软件，那么语言技术其实完全是次要的，并不是看上去越眩越好，关键是选择各个方面综合考虑起来最合适的工具即可，瑞士军刀也许很丑，但对于丛林冒险很实用就行。拿着一把屠龙宝刀去野外生存，同样也不靠谱。

编程语言是为了实现软件的，软件是为了服务于人的。诚然，了解一门语言的方方面面能够使你更有效地使用它，然而另一方面，如果结果发现这门语言并不何时来解决你手头的问题呢？受到投入的沉没成本的影响你一定觉得很不甘心吧？同理，由于你对一门工具投入了很多的精力，这门工具已经和你的情感挂上了钩，于是如果让你来决策用什么工具来完成一个任务的时候，你几乎会毫无疑问地想到使用你最熟悉而喜爱的那个，这就是“当你手头拿的是一个锤子，任何东西看上去都像钉子”这句话的一个解释。原先的问题是使用一门技术使得能够性价比最高地实现要完成地产品，然而到你那里问题就悄悄地变成了“使用一门技术让我感觉最爽”，问题的所有其他需要综合考虑的因素都被选择性忽略掉了，所以如果你是一个语言技术 fans ，那么几乎毫无疑问你会成为一个糟糕的决策者。最近，在学习和研究的方法论上我已经听到不止一个人（参见《失败的逻辑》和这里——一位诺贝尔奖得主的忠告（引言如下））忠告我们，不要为了工具而工具，忘记了工具的目的是什么。

…我们前面提过的显微摄影专家，擅长于拍矽藻的照片，动物学家着迷于昆虫贝壳跟有美丽羽毛的鸟类。我们的爱书狂最高兴的事情，就是读最新书和专论，他认为这些东西很重要，而且很能够刺激头脑，可是别人没办法，找到另外一本同样的书。我们博学的模范，经过这种策略，让他的朋友惊奇，让他的朋友佩服…

…没有效率的科学家中，有一小类就是所谓的崇拜研究仪器的狂人，他们对金属的闪烁非常着迷，就像是夜鹰对它在镜里的反影着迷一样。他们非常仔细照顾所崇拜的东西，把仪器拭擦得雪亮，可以当镜子使用，而且把它摆饰在最崇高的地方，就好像在教堂里面的圣坛…

CodingHorror 的作者最近在博客里面跟着 Steve Yegge 同学宣称，如果有一件事情是他想教给程序员同学们的，那就是 Marketing 。无独有偶，有一次吃饭的时候鲍志云同学也提到： Marketing Sense 是很重要的。其实也就是不要总想着写牛代码，用牛语言技术，不要落入为技术而技术的怪圈，而是首先想明白做的事情有什么价值，先弄清做什么，为什么做，再去想怎么做，这样后面的功夫才花的有价值。

You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business.

当然，最后必须声明的是，不要矫枉过正，误会以上的观点，以上观点并不是说学生时代做的基本功是不需要的，一些非常基本的功夫（如计算机体系结构、数据结构和算法、两个主要流派（命令式和声明式）的编程语言都使用了哪些主要的编程范式、对主流语言的优缺点和适用场合的了解等等）是有必要掌握牢靠的，因为一方面我们并不是都能去做判断与决策，码农总是一个可靠的职业。另一方面对技术大方向的把握也是决策的基础知识，只是不要掉进无尽的技术漩涡，成为技术追星族。此外也许还有一个小小的好处就是如果被老板逼着用一门不熟悉的语言时不会很不痛快，因为真正重要的事情是你完成的产品，而不是用的语言。

一个有趣的附录

我们的思维有很多很多的弱点，前文讲的其实就是这样的弱点，更多更系统一点总结可以看下这里，和这里。我一向认为，正确的思维方式，是一切高效学习的基础。比如参见如下2个例子，错误的思维方式得到的结论有大得多的可能性是谬误。

[1] 人总喜欢沿袭以往习得的经验，并通过类比来进行外推。我第一次在一个地铁终点站坐地铁的时候，看着从远方开来的地铁，我心生疑惑——“这车每节车厢都这么长，待会怎么调头呢（我心说没看到铁轨终点有一个大大的供调头的U形弯啊）？”，当车开始开的时候我终于意识到原来车是可以往两头方向开的。

[2] 人喜欢从关联当中寻找因果，有一次我我老婆去银行取款，到了 ATM 室的自动门口，我开玩笑地拿着手头的饭卡去刷了一下，然后——门居然开了。我顿时来了劲，立即得出一个结论：这个刷卡装置不安全，至少不是能够专门识别银联的卡的。我甚至飞快地泛化出了一个更具一般性的理论来解释这个现象：即可能所有带有磁性的卡都可以用来开门。老婆看我得意洋洋，就泼过来一盘冷水：不一定是你的卡刷开的啊，你不刷卡试试看。我不信，说怎么可能呢，心想我刷卡，门就开了，还有比这更明显的因果关系嘛。但出乎我意料的是，我走出门，这次没刷卡，门也开了——原来是感应门——原先这个 ATM 室的确是刷卡门，但后来改成了感应门，刷卡的那个装置只不过没拆掉残留在那里而已。

[3] 《失败的逻辑》里面从认知心理学的角度系统介绍了我们在复杂情况下的判断与决策是如何出错的，非常值得一读。