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

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

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

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

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