程序員的創新修煉
以系統的方法來理解創新思維的基本方面有助于了解持續創新的內在規律。本文作者根據多年的工作體驗和思考，展現出了一個循序漸進的創新思考模型，并結合實例進行了深入的闡釋和分析。
關于創新
對程序員來說，“創新”是一個永恒的話題。它給世人的感覺是既簡單又玄妙。說它簡單是因為創新似乎不需要嚴格的外在條件，說它玄妙是因為我們很難說清楚創新產生的過程，所有的創新幾乎都是不可復制的。
【實例分析】前幾天聽到同事在抱怨沒有足夠的硬件資源做伸縮性測試，經過進一步詢問，我了解到：產品中有一個部分需要多任務（進程）執行；任務 進程原本是由 C++ 實現的，為了調用第三方 Java SDK 遠程訪問 WebService，每個進程都加載了一個 Java 虛擬機。經過測試發現使用了此 SDK 的 JVM 占用了大量的系統資源，最終大大降低了系統的可伸縮性。面對同樣的場景，人們的反應會有很大的差異：有些人會抱怨幾聲了事；有些人會設法尋找更為強大的機 器；還有人會嘗試從軟件架構的角度改變現狀。例如，把通過 Java SDK 遠程訪問 WebService 的邏輯封裝為本地代理服務，它可以將相關業務邏輯的重用從組件級提升為應用級（如圖 1 所示）。沒錯！這就是創新。本文將放棄任何對結果的討論，因為創新不應以成敗論英雄。
如果說這些微創新不但是每個程序員都可以做、而且必須要做的工作，那么我們是否已經準備好了呢？這方面的系統論述向來是比較少的，水平思維理論 的締造者和倡導者德·波諾教授在《比知識還多》一書中提出了一系列可用于提升思維創造力的工具（例如，通過隨機輸入突破現有思維模式、挑戰概念、跳出主要 觀點、定義問題和剔除錯誤等）是這當中杰出的代表。在我看來這些工具并不是獨立的，它們相互影響、共同發揮作用。接下來就走近它們，以探其真面目。
批判性思維
批判性思維是創新過程最顯著的特征（也就是剔除錯誤），就讓我們先從它開始吧。
在程序員江湖闖蕩久了，就會深知創新的艱辛。不求一鳴驚人、但求獨善其身是程序員隊伍中一種比較具有代表性的思潮。我們真正能做到獨善其身嗎？試想如果現有代碼的可維護性很差，任何人都很難在有限的時間內寫出高質量代碼，最終很可能落得個同流合污。
有時我們也會一不小心走到另一個極端：如果留意，我們總能在公司的茶水間里聽到員工關于公司缺乏產品創新的惡評。批評是有益的，但我們更需要批 評過后的冷靜思考和實際行動。創新無疑需要批判性思維，但前提是我們能將“批判”與“批判性思維”區別開：批判的目的只是為了達到對某個事物的否定；而批 判性思維則是通過否定來尋找更好的做事方法。單純的批判是消極的；而批判性思維則要積極得多。
問題的定義
批判性思維是建立在問題定義基礎上的，因為“沒有問題就無所謂批判”。
什么是問題
什么是問題？期望與現實的落差就是問題。現實是容易覺察的，但界定外界期望就難得多了。人們傾向于把外界的輸入作為建立合理預期的唯一標準，而 不是獨立形成自身對預期的認識。例如，開發人員總樂于將測試人員在缺陷描述中記錄的期望行為和結果作為實際的用戶需求，并據此來修改代碼。
【實例分析】某產品中定義了“策略”的概念，并提供了相應的編輯界面。在策略編輯界面（如圖 2 所示）中，允許用戶對原有策略進行保存或另存為一個新策略。測試人員曾經報過一個用戶體驗方面的缺陷：用戶在選擇“另存為”功能時，很可能會遇到系統提示 的失敗報告，原因只是忘記了修改策略名稱。
我們可以順著測試人員的思路將問題定義為“如何讓用戶避免令人沮喪的失敗報告”。進一步思考，不難發現策略編輯界面還有其他問題， 比如，用戶 原本希望創建一個新策略，卻錯誤地點擊了“保存”按鈕。因此，也可以將問題定義為“如何通過合理的功能布局，避免不能預期的用戶行為”。最后，我們決定提 供一個“策略拷貝”的新功能，并將“另存為”按鈕從策略編輯界面中移除。
在定義問題時，我們需要注意以下幾點。
- 一個現象可能隱藏著多個問題。
- 區分核心問題與非核心問題；可以存在多個核心問題。
- 問題可以在不同抽象層次上定義（從用戶體驗的角度來看，可分為表現層、框架層、結構層、范圍層和戰略層）。
隨著被灌輸信息的增多，人們所受到的來自外界的影響和約束不斷增強。一個人對現實的接受程度越高，問題形成的難度就越大。
外界是不完美的
對于軟件研發團隊，定義問題的能力直接影響其需求分析的質量，進而最終決定了產品的質量。一般認為軟件工程師參與到需求分析與產品設計的機會并 不是很多，他們接收來自用戶或者產品經理的需求規格，并且努力把功能列表轉變為可以運行的程序。不幸的是，現實中軟件生產過程要復雜得多：在開始階段，寫 下來的需求只是冰山一角；未寫下來的需求才是沉浸在水下的巨大冰塊；即使寫下來的、被用戶所確認的需求規格也不能確保最終一定能夠讓用戶滿意。
《用戶故事與敏捷方法》在論述用戶故事與需求規格、用例等傳統需求分析工具的區別時，特別強調用戶故事的目的不是記錄客戶與開發團隊之間的協議或契約，而是充當著用戶具體需求對話的占位符。
因此，我們不能把產品經理的輸入等同于用戶需求。在現實中，開發團隊總是容易認為項目早期形成的用戶故事就是對用戶需求的描述，因此大部分人都 放棄了對問題進行深入且持續的思考。敏捷實際上是想告訴我們：外界是不完美的，所有相關人員（產品經理、開發者、測試者、用戶、文檔編寫者等）只有通過不 斷的溝通才能加深對用戶需求以及產品策略的理解，并在討論的過程中達成一致。如果我們不能在這個方面放棄傳統的慣性思維，我甚至懷疑所謂的敏捷是否還具有 生命力。
外界的不完美導致我們必須關注自身定義問題能力的培養。首先，通過獨立的思考形成自己對一個事物的預期，而不是唯命是從；其次，通過各種可能的 手段來確認這個預期是否合理，并進行必要的修正；最后，對比現實與預期形成對問題的認識。當這種思維模式成為你的一個思考習慣時，問題就會不斷地從腦海中 涌現出來。
概念的建立
建立概念模型的意義
合理預期是建立在合理的概念模型基礎上的。只有明確了概念，才知道未來的路該往哪里走，才知道什么時候需要堅持原則、什么時候需要像現實妥協。只有建立起概念模型，你才有可能進一步思考現實與存在于你腦海中的概念是否一致。
每一個軟件設計問題的背后都隱藏著一個或簡單或復雜的概念系統。很多時候，軟件工程師并沒有意識與能力去主動地發掘這些概念，這是導致軟件設計不確定性的重要原因之一。因此，對概念的駕馭能力就成為軟件架構師最為倚重的基本能力之一。
忽視概念的歷史根源
對概念的忽視有其深刻的歷史原因，如下所述。
炒作概念。不知從什么時候開始，“概念”常常與一個動詞相關聯，它就是“炒作”。一個新產品往往借助炒作熱 門概念來提升自身的價值，“概念”漸漸變成了假、大、空的代名詞。這與概念本身的功能完全背道而馳——概念原本是為了讓一個或一類事物能夠更準確地被大眾 以一致的方式所理解。說句公道話：“之所以盛行炒作概念之風，不是因為今天概念太多了，恰恰是因為現如今人們缺乏對概念的理解。”這一切大概發生在過去的 十年里（十年前的我大約剛剛完成學業、步入社會）。
只摸石頭不過河。我們不妨把時間推得再久遠一些：在我念書的年代里，對概念的深入研究變成了教條與迂腐的代 名詞，因為對很多人來說概念意味著陳舊，意味著一成不變。概念確實表現出一定程度的穩定性，這種穩定性源于其抽象的本質。但我們切不能將這種穩定性絕對 化。概念同樣也會像這個世界上的絕大多數物質一樣，隨著時間的流逝發生變化。這種可變性源于其主觀的本質。沒錯！概念并不是像人們想象的那樣客觀。人們只 是試圖通過自身的努力將自己對概念的理解無限趨近于客觀。
“實踐是檢驗真理的唯一標準”—這是幾乎每一個中國人都熟知的一句話。我從不懷疑其合理性，但放在上述社會環境中，難免容易讓人迷失：既然是 “檢驗”，我們就應該首先澄清待檢驗對象。換句話說，我們應先形成對真理的假說，然后不斷地用實踐結果增加其可信程度，亦或反之。現實中，人們漸漸喪失了 事先形成對真理認知的耐心，這種不耐煩也許是源于人們對于可能出現的自我否定的恐懼，這直接導致實踐最終僅僅成為一些人收集數據的工具。
我曾與一些軟件研發人員討論有關軟件性能測試的問題。我發現他們并不能清楚地說出某個測試的目的。當我進一步詢問測試結果能否幫助我們得出一些 結論時，他們就變得含糊其辭。在我看來：單純為收集數據而進行的測試是毫無意義的，這就好比只惦記摸石頭而忘了過河才應是原本的目的。
缺少點科學精神。曾經的諾貝爾獎得主楊振寧在對比中華文化與近代科學時，有如下精彩總結：中國傳 統 文化所追求的“理”與近代科學所追求的“自然規律”方向上一致。但它們在求“理”的方法上是不同的。傳統中國文化主要依賴歸納法求理，這里面沒 有邏輯與推演；而近代科學除了使用歸納法以外，更依賴演繹法。
顯然，對于建立復雜的科學體系而言，演繹法更高效。這就不難解釋：為什么自然科學在近現代中國更多是以舶來品的形象出現？演繹法需要邏輯，而邏輯建立在概念的基礎之上。如果缺少這方面的先天基因，那么就更需要后天努力了。
樂觀精神
沒有精神層面的支持，創新是無從談起的，因為創新實在是一項艱巨的工作：概念的建立不是一蹴而就的，需要反復的推敲、對比、自我否定；問題的定 義更是自我意識游走在理想與現實之間，嘗試各種問題邊界的可能，不斷地進行權衡；人生貴在堅持批判性思維，而不淪落于簡單的批評與抱怨。所有這些行動都是 很困難的，因為它們會產生巨大的認知摩擦。由此可見，對于一個致力于創新的程序員，能夠建立并保持一個積極的人生態度才是最值得慶幸的事情。
當我請求同事們進行自我評價時，大多數人都會為自己打上樂觀的標簽，因為他們把樂觀與快樂、自我滿足等概念混為一談。一般人通過努力可以讓自己 維持一個相對快樂的心境，但要做到樂觀就很難了。快樂是一中狀態，而樂觀是一種態度；快樂是相對短暫的，而樂觀是相對持久的；快樂既可以源自內心，也可能 是源自環境，而樂觀是一定是由內而外的。
創新思考模型
我們可以將創新模型簡單地歸納為以下四個核心要素。
- 創新需要挑戰現狀，即批判性思維（要素）。
- 批判性思維需要準確的問題定義（要素）。
- 問題的定義有賴于概念系統的建立（要素）。
在初始階段，概念模型的正確與否是次要的，更為重要的是要有一個概念模型，然后這個概念模型可以隨著認識的深入而不斷演化。誰在幕后推動認識的 發展？答案還是批判性思維。批判性思維有助于我們修正原有概念的不足或創建全新的概念，在思維的各個階段都需要樂觀的人生態度的支持（要素）。
回到開篇的實例中，讓我們看看這些要素是如何發揮作用的：我們不能接受過高的資源占用這個事實，即使是在硬件變得越來越廉價的今天，濫用系統資 源永遠是值得我們去批判的。問題的關鍵在于我們如何將依賴于第三方 SDK 的業務邏輯（Java）從任務中物理地剝離出來。我們曾經探討徹底消除對第三方 SDK 依賴的可能性，后來發現其成本太高。組件級重用與應用級重用是在建立對問題定義的過程中很重要的兩個概念，典型的應用范例是微軟將二進制組建模型從 COM 升級為 COM+。SOA 是另一個發揮重要影響的概念,我們將業務邏輯封裝為本地服務代理，并以標準的方式暴露其接口（WebService）。
結束語
以系統的方法來理解創新思維的基本方面有助于我們了解持續創新的內在規律。上述分析結合了我近幾年的工作體驗與思考，并試圖展現出一個循序漸進的創新思考模型。創新思維之復雜原本不是我所能涉及一二的，但最終還是決定把目前的認識提出來，作為大家進一步討論的起點。
關于本文的論戰
周愛民：
作者意在討論方法論本身，而非某一具體的方法。從這一點來看，作者的邏輯是：創新需要批判，批判需要問題，問題需要概念模型；概念是從對認識的 持續批判中得出、修正與進化的。那么在這一邏輯中，所謂“創新”不過是一個具體方法的結果，甚至是對具體結果的修飾而己。作者對方法論的討論未能最終落足 于“如何‘認識’一個系統”，而是趨向于迎合讀者口味地去強調“創新”，這是本文的一大弊處。但文章總體的可讀性、系統性仍是可供讀者品評的。
許正華：
對于周愛民老師給出的點評意見我基本上同意，除了關于迎合讀者口味地去強調“創新”的評價，至少它不是我的本意。我想討論的是創新思考的方法本 身，而不是創新的結果。現實中人們更關注于結果，而忽視了創新性思考其實只是若干可以被訓練的思維方法中的一種。創新本身并不神奇—就像人們在談論所有天 才那樣，如果我們也能夠看到他們艱辛的成長道路與所使用的先進訓練方法，就不難理解“其實天才也是可以培養的”。