摘要：我們總是喜歡用自己的經歷來定義軟體是什麼以及判斷標準，但如果這種經歷來自完全不同的兩個領域，並且互相矛盾，那麼就有可能讓大家吵來吵去……是的，各位在忙於解決具體問題時，誰還會想到談談軟體開發的本質？
看過我之前文章的人，可能會感覺到我對不加思考的所謂分享是持鄙視態度的，不管這種分享被冠以乾貨，經驗或者隨便什麼名字。不是說這類分享沒價值，而是說越是這類分享越適合具體問題，而不適合影響因素過多的事物，比如管理，比如文化，比如方**，比如對軟體本質問題的認知。
我們當然可以到stackoverflow上分享某個問題的具體解決方法，因為具體技術類問題只依賴於簡單的上下文；但我們真的可以用一種簡單問答的形式去解決管理、文化、方**上的問題麼，顯然是不行的，這需要一種更系統的思考，也就是我之前經常提到的特殊到一般，一般再到特殊的過程。但在具體思考解決問題前，其實還有個事情要做，你要對問題的載體有所認識，對it人，問題的載體幾乎一定是軟體，那麼也就等價於需要對軟體的本質有所認識。
這就是上面的題目的**，在忙於解決具體問題的同時：誰還願意談談軟體開發的本質？
本質問題的思考往往不作用於當下，而只對未來產生潛移默化的影響，當然也可能沒等產生影響，當事人就失去了所有機會。它的關鍵價值在於可以幫助乙個人形成屬於自己的方**。軟體是個很奇妙的東西，更像每個人都在橫看成嶺側成峰狀態的東西，所以很容易大家都自我感覺良好，看別人大大的不對，這時候要想不只侷限在怎麼解決乙個bug，就要思考一點本質的問題。
軟體的本質是什麼
為了嚴密一點，我一般這麼描述軟體的本質：
軟體是一種固化的思維，這一點決定了許多的事情。從特質上來看，既然軟體是固化的思維，那就必然同時具備思維以及思維所承載之物之特質。
既然思維自身的特質是復合的，那麼作為固化思維的軟體，其特質必然也是復合的：
既有屬於所有軟體的共同特質，也有特屬於某類軟體，甚至同其他類軟體完全相反的獨有特質。---《完美軟體開發:方法與邏輯》這也就意味著在軟體這一大的範疇裡，兩種矛盾的說法同時成立，並不是什麼值得驚訝的事情。只要思維承載的東西蘊含著彼此對立的東西，那麼兩種對立的觀點同屬於軟體這一範疇，並且同時爭取，一點也不稀奇。這很可能是大家吵來吵去的乙個根本原因，因為我們總是喜歡用自己的經歷來定義軟體是什麼以及判斷標準，但如果這種經歷來自完全不同的兩個領域，並且互相矛盾，那就只能吵架。實際上只有基於軟體是一種思維這樣特質推導出來的東西才更有普適性。
在什麼時候對本質的思考會有用
簡單來講越處理全域性性長期性問題的時候，對本質的認知越能起點作用；而越是眼下就用型別的工作對本質問題的思考越沒什麼幫助。
比如：有個bug讓程式崩潰了，而程式明天就用，最好的方法可能還是趕緊除錯，而不是思考什麼本質。
但當我們要思考怎麼讓乙個方**落地更適合自己的時候，對本質的思考就能起點作用。比如始終會有公司會嘗試按bug數和**行來度量乙個人的績效。如果結合對本質問題的思考，一般來講就不會做這類決定。
對人進行量化管理的基石是：量化後的數字主要受個人表現這乙個因素的影響，否則將產生巨大的不公正，並對個人工作意願產生不良影響，是真正的事與願違。
好比說，不同的工人在同等條件下生產杯子，乙個人一小時生產5個，乙個人1小時生產6個，那顯然後者要好於前者。這時，5和6可以用來比較的前提是兩個人的生產條件相同，比如生產工藝等。在這種情況下，量化後的數字為個人表現的函式，因此量化管理基本上是公正的。
這時可以進一步來考慮下面的情形：兩個人同時生產杯子，廠方安排乙個人用工藝a，另乙個人用工藝b，這個時候前者一小時生產5個，後者1小時生產6個。這個時候單純比較5和6事實上是不公平的，因為這1個杯子的差距可能是工藝造成的。
大多時候，軟體的情況比後乙個情形還要糟糕一些。在軟體開發中，往往既沒有辦法清楚的界定乙個人的輸入，也沒辦法清楚的界定乙個人的輸出。
軟體開發的輸入是需求，對需求自身的複雜程度眼下來看還只能依賴判斷，而不能精確度量，現實中並沒有一種有效方法用以度量需求。
軟體開發的輸出是**，而**自身屬於固化後的思維。在度量思維時，多少、大小、長短、厚薄這類慣常的度量方向，並不具有多大意義。就好比說，不能講乙個人**寫的越多貢獻就越大一樣。
誠然思維的表現形式是可以度量的，我們可以通過頁數來度量一本書的厚薄，通過分鐘來度量一部電影的長短，通過**行來度量軟體，但這種度量所反映的內涵是有限度的，精度也是有限度的。最終結果很可能是人員之間的差距是由誤差或其他非主觀因素造成的，而不是由個人工作好壞所造成的。
總結來看，在軟體開發中，數字含義的模糊性會導致使用數字進行評價包含非常多的不公正，這種不公正會對工作意願構成致命傷害，所以個人層面的量化管理在軟體開發面前，幾乎必然崩潰。
如果有這類思考和認知，想必做某些決定的時候正確性會稍微提高一點吧。
本質決定成敗還是細節決定成敗
這世上同時存在著兩種對立的聲音：本質決定成敗和細節決定成敗。偏好本質的人喜歡說本質論。偏好細節的人則喜歡說精細化管理。但如果在較長的時間軸上考量這兩種觀點，就會發現他們之間並不真的對立。
本質決定大尺度時間上的走勢和必然性，而細節則決定差異（包括短期成敗）。比如說：人的本質特徵是能思考，有乙個頭，會衰老，壽命有限等，但區別不同人卻不是這些，而是性格，膚色，髮色等細節。
具體來看：軟體本質上是只有人才能處理的東西，因此公司中程式設計師群體的衰落一定會導致軟體自身的衰落，只有優秀的程式設計師群體，才能保證軟體的持久成功，這是必然性。但優秀的程式設計師卻不一定確保當前專案成功，任何人在細節上的小疏忽，都可能導致軟體在市場上崩潰，死鎖，進而導致災難性後果，這就是細節決定成敗。
成敗自身雖然萬眾矚目，對個體而言卻只是一種偶然和機巧。當事人可以很努力的平衡本質上的追求（長期視點）和細節上的追求（短期視點），但變更的始終是一種成敗可能性。
軟體開發的本質
關於這個話題，我似乎說過好多次了。軟體系統其實就是現實系統的抽象，就是現實系統的模型。最近，看到乙個論點，是這樣說的 軟體建模 架構 的過程其實就是乙個定理證明的過程。我得說，在我看來，這有一定的真理性。但是事實有一定的差異。基本原因是 我們碰到問題的時候，並不總是對問題的解決方案一無所知的，或者更...
你真的了解Java嗎？
三目運算子規則 如果第二個和第三個運算元具有相同的型別，那麼它就是條件表示式的類 型。換句話說，你可以通過繞過混合型別的計算來避免 煩。如果乙個運算元的型別是 t，t 表示 byte short 或 char，而另乙個運算元是乙個 int 型別的常量表示式，它的值是可以用型別 t 表示的，那麼條件表...
你真的了解restful api嗎？
在以前，乙個 的完成總是 all in one 頁面，資料，渲染全部在服務端完成，這樣做的最大的弊端是後期維護，擴充套件極其痛苦，開發人員必須同時具備前後端知識。於是慢慢的後來興起了前後端分離的思想 後端負責資料編造,而前端則負責資料渲染，前端靜態頁面呼叫指定api獲取到有固定格式的資料，再將資料展...