>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

　　看過我之前文章的人，可能會感覺到我對不加思考的所謂分享是持鄙視態度的，不管這種分享被冠以干貨，經驗或者隨便什么名字。不是說這類分享沒價值，而是說越是這類分享越適合具體問題，而不適合影響因素過多的事物，比如管理，比如文化，比如方法論，比如對軟件本質問題的認知。

　　我們當然可以到 StackOverflow 上分享某個問題的具體解決方法，因為具體技術類問題只依賴于簡單的上下文；但我們真的可以用一種簡單問答的形式去解決管理、文化、方法論上的問題么，顯然是不行的，這需要一種更系統的思考，也就是我之前經常提到的特殊到一般，一般再到特殊的過程。但在具體思考解決問題前，其實還有個事情要做，你要對問題的載體有所認識，對 IT 人，問題的載體幾乎一定是軟件，那么也就等價于需要對軟件的本質有所認識。

　　這就是上面的題目的來源，在忙于解決具體問題的同時：誰還愿意談談軟件開發的本質？

　　本質問題的思考往往不作用于當下，而只對未來產生潛移默化的影響，當然也可能沒等產生影響，當事人就失去了所有機會。它的關鍵價值在于可以幫助一個人形成屬于自己的方法論。軟件是個很奇妙的東西，更像每個人都在橫看成嶺側成峰狀態的東西，所以很容易大家都自我感覺良好，看別人大大的不對，這時候要想不只局限在怎么解決一個 Bug，就要思考一點本質的問題。

　　軟件的本質是什么

　　為了嚴密一點，我一般這么描述軟件的本質：

　　軟件是一種固化的思維，這一點決定了許多的事情。從特質上來看，既然軟件是固化的思維，那就必然同時具備思維以及思維所承載之物之特質。

• 思維的特質是指：思維的澄清通常是漸進的，思維自身是不可度量的，思維的主體一定是人，思維通常由概念和邏輯組成，思維的無邊界化（靈活易變）這樣的特質。這部分特質是共通部分，同時屬于所有軟件。
• 思維承載之物之特質是指：當思維的對象是數學的時候，思維本身也就具備了數學的特質；當思維的對象是商業邏輯的時候，思維自身也就具備了商業邏輯的特質。

　　既然思維自身的特質是復合的，那么作為固化思維的軟件，其特質必然也是復合的：

既有屬于所有軟件的共同特質，也有特屬于某類軟件，甚至同其他類軟件完全相反的獨有特質。

——《完美軟件開發:方法與邏輯》

　　這也就意味著在軟件這一大的范疇里，兩種矛盾的說法同時成立，并不是什么值得驚訝的事情。只要思維承載的東西蘊含著彼此對立的東西，那么兩種對立的觀點同屬于軟件這一范疇，并且同時爭取，一點也不稀奇。這很可能是大家吵來吵去的一個根本原因，因為我們總是喜歡用自己的經歷來定義軟件是什么以及判斷標準，但如果這種經歷來自完全不同的兩個領域，并且互相矛盾，那就只能吵架。實際上只有基于軟件是一種思維這樣特質推導出來的東西才更有普適性。

　　在什么時候對本質的思考會有用

　　簡單來講越處理全局性長期性問題的時候，對本質的認知越能起點作用；而越是眼下就用類型的工作對本質問題的思考越沒什么幫助。

　　比如：有個 Bug 讓程序崩潰了，而程序明天就用，最好的方法可能還是趕緊調試，而不是思考什么本質。

　　但當我們要思考怎么讓一個方法論落地更適合自己的時候，對本質的思考就能起點作用。比如始終會有公司會嘗試按 Bug 數和代碼行來度量一個人的績效。如果結合對本質問題的思考，一般來講就不會做這類決定。

　　對人進行量化管理的基石是：量化后的數字主要受個人表現這一個因素的影響，否則將產生巨大的不公正，并對個人工作意愿產生不良影響，是真正的事與愿違。

　　好比說，不同的工人在同等條件下生產杯子，一個人一小時生產 5 個，一個人 1 小時生產 6 個，那顯然后者要好于前者。這時，5 和 6 可以用來比較的前提是兩個人的生產條件相同，比如生產工藝等。在這種情況下，量化后的數字為個人表現的函數，因此量化管理基本上是公正的。

　　這時可以進一步來考慮下面的情形：兩個人同時生產杯子，廠方安排一個人用工藝a，另一個人用工藝b，這個時候前者一小時生產 5 個，后者 1 小時生產 6 個。這個時候單純比較 5 和 6 事實上是不公平的，因為這 1 個杯子的差距可能是工藝造成的。

　　大多時候，軟件的情況比后一個情形還要糟糕一些。在軟件開發中，往往既沒有辦法清楚的界定一個人的輸入，也沒辦法清楚的界定一個人的輸出。

　　軟件開發的輸入是需求，對需求自身的復雜程度眼下來看還只能依賴判斷，而不能精確度量，現實中并沒有一種有效方法用以度量需求。

　　軟件開發的輸出是代碼，而代碼自身屬于固化后的思維。在度量思維時，多少、大小、長短、厚薄這類慣常的度量方向，并不具有多大意義。就好比說，不能講一個人代碼寫的越多貢獻就越大一樣。

　　誠然思維的表現形式是可以度量的，我們可以通過頁數來度量一本書的厚薄，通過分鐘來度量一部電影的長短，通過代碼行來度量軟件，但這種度量所反映的內涵是有限度的，精度也是有限度的。最終結果很可能是人員之間的差距是由誤差或其他非主觀因素造成的，而不是由個人工作好壞所造成的。

　　總結來看，在軟件開發中，數字含義的模糊性會導致使用數字進行評價包含非常多的不公正，這種不公正會對工作意愿構成致命傷害，所以個人層面的量化管理在軟件開發面前，幾乎必然崩潰。

　　如果有這類思考和認知，想必做某些決定的時候正確性會稍微提高一點吧。

　　本質決定成敗還是細節決定成敗

　　這世上同時存在著兩種對立的聲音：本質決定成敗和細節決定成敗。偏好本質的人喜歡說本質論。偏好細節的人則喜歡說精細化管理。但如果在較長的時間軸上考量這兩種觀點，就會發現他們之間并不真的對立。

　　本質決定大尺度時間上的走勢和必然性，而細節則決定差異（包括短期成敗）。比如說：人的本質特征是能思考，有一個頭，會衰老，壽命有限等，但區別不同人卻不是這些，而是性格，膚色，發色等細節。

　　具體來看：軟件本質上是只有人才能處理的東西，因此公司中程序員群體的衰落一定會導致軟件自身的衰落，只有優秀的程序員群體，才能保證軟件的持久成功，這是必然性。但優秀的程序員卻不一定確保當前項目成功，任何人在細節上的小疏忽，都可能導致軟件在市場上崩潰，死鎖，進而導致災難性后果，這就是細節決定成敗。

　　成敗自身雖然萬眾矚目，對個體而言卻只是一種偶然和機巧。當事人可以很努力的平衡本質上的追求（長期視點）和細節上的追求（短期視點），但變更的始終是一種成敗可能性。

CSDN 2014-07-15 11:29:40