首先說下什么叫“完美軟件開發”，想象一下，完美的圓在現實中是不存在的，現實中的圓只能是對完美的圓的回歸，但完美的圓描述了圓的構成規則，完美軟件開發意義與此相同，它試圖描述軟件開發的規則和鐵律。但既然現實中不存在，探討完美狀態又有神馬意思？好，那我們再來看一個完美狀態：
牛頓第一定律說：任何一個物體在不受任何外力或受到的力平衡時，總保持勻速直線運動或靜止狀態，直到有作用在它上面的外力迫使它改變這種狀態為止。
這顯然也是一個完美狀態或者說理想狀態，現實中也是不存在的，那這東西又有神馬意義？
個人感覺探討軟件開發的完美狀態，就和探討軟件中的牛頓定律一樣，雖然它現實中不存在，但對現實卻有着極大的指導意義。單純想做個高手，比如Android高手什么的是不太用的上這種探討、這種書的，但要想把握下全局，這種探討、這種書就有點意義了。
那怎么去探討這種完美狀態？
這類書，包括《人月神話》往往是用歸納法寫出來的。但這樣一來就會先天有種限制：一個人的眼界經歷是有限制的，而軟件世界其實無限寬廣，編譯器和信息管理系統的差別可能比人和豬的差別還大。所以一用歸納法，又說不清楚自己結論的邊界，書就很容易偏頗。所以這本書用演繹法來寫，用邏輯鏈來推導，看過三體的可能知道黑暗森林定律是咋整出來的，但把邏輯鏈用在這類書里，恐怕還很少人這么干。
看幾條邏輯鏈。這書預設了幾個前提，所有邏輯鏈都基於這幾個前提。
- 軟件是一種固化的思維
- 意識指導行動
- 項目所能耗費的資源是有限的
- 重復做同樣的工作會降低效率
下面列幾條書里的邏輯鏈。
關於量化管理的：
軟件是一種固化的思維 →思維的本質是概念和邏輯 → 概念和邏輯無法直接度量和精確度量 → 度量過程中需要很多的主觀判斷 → 以目標為導向的，以個人為中心的量化管理（相關的激勵和懲罰）將崩潰 → 參照無歧義數據（函數復雜度等）的判斷將成為程序員評價中的輔助手段
關於流程尺度：
軟件是一種固化的思維→思維固化本質上不可能是例行公事 → 現場的人需要較大的自主空間 →軟件的流程粒度需要比較大，而不能規定工作細節，手冊化。→ 可以把流程等價於一種打斷，從這個尺度上可以度量當前流程的程度是否過於繁重。
關於開發模型的選擇：
重復做同樣的工作會降低效率→預先沒有對既定問題的分析和准備，會導致同樣的工作做多遍→ 純粹的迭代會導致某些預先可以發現的問題得不到處理，進而導致不必要的重復，最終會降低組織總體生產效能
關於在何處終結需求開發：
項目所能耗費的資源是有限的 → 需求如果無限擴張，會造成以有限資源做無限工作的局面，最終導致忙中出錯 → 在廣度上，由於軟件的應用環境處在變動之中，導致需求天生有越來越多的趨勢。→ 在廣度上，對不做那些需求要有清楚定義。→在深度上，需求的明確是一漸進的過程。 指望在初期某一截止時間點，澄清所有需求是不現實的。但能夠澄清的，沒有澄清卻又導致效能降低。→ 在深度上，要使需求開發的細致程度有所定義
關於設計中的正交：
軟件是一種固化的思維 → 思維的固化體現為概念和邏輯的固化 → 為保證簡單性，邏輯要盡可能的少 →概念要盡可能正交
當然只有這些邏輯鏈是不夠的，還需要補充例子，對邏輯鏈的具體含義進行闡釋。
就拿最后一條邏輯鏈來說，你如果相信它是對的，再去看設計和代碼，就會看出許多新問題，比如：Robert C.Martin在《敏捷軟件開發：原則、方法與實踐》里給出過一個關於門的例子。
Robert C.Martin的例子說：在安全系統中，有一些門，這些門可以被加載和解鎖，並且知道自己是開着還是關着。
class Door
{
public:
virtual void Lock() =0;
virtual void Unlock() =0;
virtual bool IsDoorOpen() =0;
};
接下來，一種更高級的門出現了，這種門如果開着的時間過長，就會發警報，這種門被稱為TimedDoor。
因為要定時出發某些事件，所以TimedDoor要用到定時器，而定時器的基本創建機制是：
class TimerClient
{
public:
virtual void TimeOut()=0;
};
class Timer
{
public:
void Register(int timeout, TimerClient* client);
};
任何TimerClient都可以向Timer注冊自己，而Timer則會按照指定的時間間隔來調用TimerClient的TimeOut()。
到現在為止，Timer、TimeClient、Door在概念上是正交的，沒什么問題。
接下來，為了使TimedDoor具有定時發警報的功能，這三個概念要產生交互了。
處理方法可以有很多，第一種方法Door從TimeClient繼承，這種方法的正交程度最不好，接觸面過大，像Robert C.Martin在書里說的，很多Door根本和定時不定時沒有關系，但一旦讓Door從TimerClient繼承，那就不管什么門都有了定時的特征，這種關聯毫無道理。
第二種方法是讓TimedDoor分別繼承TimerClient和Door（多重繼承）。Robert C.Martin認為自己會優選這個方式。
從正交的角度看，在這種方式下，TimedDoor只和與自己有關的部分產生關聯，正交性已經非常好了。
如果仔細想想，就會發現Robert C.Martin的第二種方法其實還是有問題。
門是否計時報警是一個功能，是否能錄像也是一個功能，是否能自動發消息也是一個功能。
這些功能甚至可能是動態配置的，如果都用多重繼承來解決，那會衍生出各種各樣的對象，如：VideoDoor，TimeVideoDoor，MessageDoor，TimeVideoMessageDoor等等。這好像並不是什么好事。
這意味着正交的程度也許還是可以提升。
如果不讓自己的思維局限於所有東西必須都是對象，那么就可以找到其他解法。我們可以認為定時報警功能是門的可組合部分，是使用關系而不是繼承關系。也就是說，並不認為應該獨立存在着TimerClient這樣的類，而認為這是一種偶然的組合。否則的話，XXClient這樣的類會漫天飛。想象一下，門、馬桶等都可以是TimerClient，也可以是Motor的Client。
上面就是書中部分對正交的討論和分析，這類討論和分析會針對幾乎所有主要軟件開發的領域展開。好處是似乎可以多想到，多看到一些別人沒看到的東西，壞處是這樣一來很多地方會有點抽象。所以總的來看，這書適合願意琢磨事，願意思考本質問題的人，不適合喜歡做事，不喜歡思考的人。
除了用演繹法來重新解構軟件開發之外，這書還做了的一件事情是：探討軟件開發各個領域間的關系。做軟件的都知道，管理好≠項目結果好，流程好≠項目結果好，開發模型≠好項目結果好，設計編碼好≠項目結果好。但一實際操作起來，負責不同事情的人，總是會起沖突，做流程的和做現場編碼的總是捏不到一起去，因為不同部分間一方面是配合協作，一方面則是共同競爭有限資源。而為了配合好，顯然任何一部分都要停在某個程度上，這個也比較抽象，是這個書另一個探討的地方。
再寫下去就太長了，書的說明就此打住。
最后說兩句其他的。
看過我別的文章的人，應該大致知道，我比較喜歡寫本質的東西，喜歡用一種哲學思辨的方法來看待東西。從立刻有用的角度看，其實這類文章和書挺差的。但我有時候想《人月神話》也不是立刻有用，也還許多人看，所以可能這種對本質的思考還是有用的吧，所以就還是堅持把書寫出來了。
接下來會寫點怎么把書寫出來的東西，算是給想寫書的做點分享。
--------------------------------------------------------------
理想流 + 軟件 = 《完美軟件開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。