知识的偏见 - 读《暗时间》的思考

最近刚刚读了《暗时间》，这篇来自本书引发的思考：『知识的偏见』

在思考这个问题的时候，先用 10 秒钟思考一下这个问题：

『如何建一个网站卖化妆品？』

对于这个问题没有答案，如果你思考，把解决方案保留在你的脑海里。看完本片我们再回来思考这个问题。

『如果你手里有把锤子，所有东西看上去都想钉子』

hack_joking.png

在真实世界里每人都会自己独特的经历，不同的经历会造成对一个问题产生不同的直觉，比如 Developer 和 Sales 基本不可能站在同一个视角思考问题。这种由经历不同产生偏见我们很好理解：成长经历不同，对事物的看法会不同。

还有一种 偏见 可以归为 知识偏见。这类偏见由我们掌握的知识决定的。不同的知识给我们带来不同的解决问题的工具（锤子），不同工具（锤子）有不同的思路。这种偏见在程序员的世界非常常见。

编程语言

language_preduice.png

每种语言的开发者，对其所掌握的语言都会有一种无法抑制的执着。

比如说这个强大的 《程序员鄙视链》。

记得 6 年前刚参加工作的时候，公司基于 GWT 使用 Java 写 SPA。 GWT 是 Google 推出的神奇的工具，它可以使用 Java 代替 Javascript，不但如此，在 GWT 中不用再担心浏览器兼容问题。Google 红极一时的 Google Wave 便是用 GWT 编写的。

『使用 Java 代替 Javascript！』

一切听起来都很美，当我真正的用它的时候，各种限制接踵而至。GWT 中只能使用部分 Java 的功能，比如 java.util.Date 就无法使用。这种限制使得大部分 Java 库都无法在 GWT 环境下运行。除了 Java 标准库的限制，Javascript 世界中的库也无法直接在 GWT 下使用，比如 jQuery 就需要使用 JSNI 引入到 GWT 中。
如果你同时掌握 Java 和 Javascript，如果强迫你用 Java 去写 Javascript 估计你会有什么感想？我是被 GWT 虐了两年，现在再也不想回到用 Java 写前端的世界。

『用合适的语言做合适的事情』

TDD

tdd.png

在写本文时，笔者还在实践 TDD。现在已经到了不先写测试，不会写代码的程度。但是对一种编程模式过于执着总是会让我陷入一种恐慌，闲暇听听其他不同的声音，希望自己不会陷入对 TDD 宗教般的崇拜：

• TDD is dead. Long live test
• TDD 并不是看上去的那么美
• Bob 大叔和 Jim Coplien 对 TDD 的论战

『软件开发没有银弹，方法论同样也适用』

OOP

OOP.png

听听不同的声音：

• 如此理解面向对象编程
• 面向对象编程的弊端是什么？
• 《函数式编程思想》

如果你对面向对象还保持着封装，继承，多态，教条的遵循 SOLID 原则，可能仅对 OOP，可能还需要更多的思考。

『OOP 不是万能的』

Design Pattern

design pattern.png

四人帮的 Design Pattern 犹如圣经般存在于 OOP 的世界。估计每个采用 OOP 的都被它虐过。尤其是对 Java 程序员，没用几种设计模式，可能连找工作都会有点困难。

那 23 个 Design Pattern 背后隐含的思想，其他语言会很好的解决方案。

比如我们可在 Ruby 中使用 Duck Typing 解决 AbstractFactory 问题。同样属于编译型语言的 Objective C 也支持这个特性。
（Objective C 中将方法调用抽象成向对象发消息，只要该对象能够处理这个消息即可）

比如 Ruby，Javascript，Java 8 中支持的 each 方法，可以非常简单的解决了 Iterator Pattern 要解决的问题。

当然这种类比还有很多。有一个很搞笑的编程模式：《设计模式驱动开发》

『Design Pattern 是我们重构代码时的参考，不是我们写代码的准则』

讲个故事

fan.png

联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的情况,而 在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自 动化、机械、机电一体化等专业博士组成的Solution小组来解决这个问题,没 多久他们在装配线的头上开发了全自动X光透射检查线,透射检查所有的装配 线尽头等待装箱单香皂盒,如果有空的就用机械臂取走。

无独有偶,在中国一乡镇企业生产香皂也遇到了类似问题,老板吩咐线上小公务必想出对策解决之,小工拿了一个电风扇放在装配线的头上,对着最后的成 品吹,空盒子被吹走了,问题也解决了。

『如果你想钉一颗钉子，所有东西看上去都像是锤子。』

如果我们专注与问题，按照 How，Why，Who did it？ 反复思考待解决的问题。可能会更容易的得到合适的解决方案。

使用合适的语言解决合适的事情。

language_thinking.png

使用 DSL 处理特定的领域

dsl.png

写在最后

我始终觉得视野很重要，每种语言，工具都能带来不同的思考方式。对同一个问题，不同语言有不同的的思路，了解这些不同的思路可以扩展自己的视野，让自己不会拘泥于某一中语言所带来的生态圈中。

2009 我作为 Java 程序员从一个非计算机的专业转到了计算机领域。在 2012 年，我做了一个很有意思的回顾，自己平均每年都会学习一门新的语言或者新的技术领域：

• 2009 精通CSS
• 2010 Groovy
• 2011 Ruby, node.js
• 2012 Objective C

由于每个技术领域都能带来新的思维方法，这也让我不由自主的保持了一年一门语言或者框架的习惯：

• 2013 Shell， improve ruby
• 2014 Lisp ( SICP, Scheme )
• 2015 Swift，Clojure，Rails

系统的学习CSS，让我懂得如何布局，如何使用 CSS 灵活的创建 UI。做页面的时候也偏向于先用 HTML + CSS 构建原型，再完成实现。

接触 Groovy 是由于 Grails 这个类 Rails 的框架。Groovy 让我见识到了脚本语言的强大，之后使用 Groovy 作为胶水语言为项目设计了基于 Groovy 描述的工作流引擎。

学习 Ruby 是因为 Rails。非常喜欢 Ruby 社区的气氛，非常活跃，时刻都能拥抱最新的技术。由于对 Ruby 的热情，让我买了第一台 Macbook， 同时也让我有幸参加了 ShanghaiOnRails 和 2012 RubyConfChina 聚会。也是由于 Ruby，让我有机会加入 Thoughtworks，有机会跟 Ruby 社区活跃的开源贡献者 FredWu 有共事的机会。

学习 iOS 开发，让产品有机会跟上海的 SMG 广电集团有了一次合作，也让我步入了 iOS Developer 的行列。

了解 Lisp 是从读 《黑客与画家》开始，2014 在 Thoughtworks 和同事共同搞 SICP Bookclub，这个活动让我刷新了对编程的认识，也让我了解到函数式思维的强大。

2015 年初接触 Clojure，其中有一个 Memorization 的思想对函数运算进行缓存，这个思想激发了灵感。按照 Momorization 思想对项目中的校验引擎做了优化，性能提升了近 100 倍。

知识犹如我们手中工具，我们可以通过不断学习来丰富我们的『工具箱』。每当碰见问题的时候，怀着开放的心，从自己的『工具箱』中选出做顺手的工具来达成自己的目标，这样可以避免知识的偏见带来的副作用。

再回来思考一下本文开头的问题：『如何建一个网站卖化妆品？』

此时你会有什么想法？