最近剛剛讀了《暗時間》，這篇來自本書引發的思考：『知識的偏見』

在思考這個問題的時候，先用 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 倍。

知識猶如我們手中工具，我們可以通過不斷學習來豐富我們的『工具箱』。每當碰見問題的時候，懷著開放的心，從自己的『工具箱』中選出做順手的工具來達成自己的目標，這樣可以避免知識的偏見帶來的副作用。

再回來思考一下本文開頭的問題：『如何建一個網站賣化妝品？』

此時你會有什么想法？