讀建構之法筆記

建構之法感悟 更新中

目錄

• • to be continued

對于一個項目的建構在這本書被分為了大概以下幾個步驟

• 需求分析
• 設計文檔
• 編碼
• 單元測試
• 代碼複審

在我看來其實總的來說可以用以下幾個計算機行業的名詞來概括

抽象化

，

互資訊

遞歸

子產品化

規範

這本書在講到程式員的成長會在幾個方面都需要持續更新，包括 代碼的編寫 , 團隊溝通能力 , 工程建構 , 程式設計思想 。

并且在微軟的進階工程師和初級工程師的地方可以羅列為一張表

等級	要求
SDE（初級軟體工程師）	入門會一些技能，尚未熟練
SDE II （中級軟體工程師）	獨立編寫 ，如未清楚知道如何查
Senior SDE	小組上司，影響3-12工程師
Principal SDE 首席	團隊上司，影響着10人上的大團隊

這是一個由小到大的過程，就像國學中“修身，齊家，治國”的疊代過程 。

從最初級的能夠修改一點别人的bug，可以連項目的語言本身都不用學會，隻需仿造即可；

到能夠編寫要求的小子產品，需要知道語言本身的文法；

到編寫更為龐大和重要的子產品，需要的是對語言特性的熟悉；再上的發展需要的确實對項目的整體把握。

而在這個分水嶺的地方，有幾個很重要的東西：

就是如何去決定一個項目的結構，和如何去建構一個龐大的項目

這是抽象的最終的結果，而如何去完成這一過程，大概會從

設定目标（需求分析）

設定結構

試運作

豐滿它

以上的說法和書中很相似，但我個人看來，就是

抽

和

象

，抽離本質，賦予其象，也就是前兩步，也是最重要的兩步。對于一個項目存在必要性就是完成需求，但是往往需求和最後的結果會有所偏差，最重要也是最最開始的一步就是抽離出需求的本質，這在具體下，便是需要了解要求。了解需求背後的意義。

而

象

這是項目的結構，如何去建構。

1. 往往了解行業普遍做法是很重要的，可以作為重要的參考，不要“一來就想搞個大新聞"，借鑒的必要性不言而喻，可以讓項目的起點和最後的結果在一個可以評估和可以接受的範圍，而創新的到底在什麼地方，應該在需要它的時候才應該需要。
2. 模仿和模拟使用者使用的過程能夠讓我們把結構的溝和壑大緻理順
3. 往往大多數軟體相似的很多，但真正優秀，而讓人長久的贊揚的很少，這之間的差别在哪？在我看來也是象的程度問題，喬布斯的“人機互動"是一個很好的例子，程式員沉于自己的領域，但是計算機行業所服務的确是所有行業和所有普通人。這是一個互資訊的深度過程，你對你所服務的對象又能了解多少呢？你對整個項目的結果也就是完成的軟體的本質了解到何種程度呢？

這是一個疊代的過程，這整個過程和一門語言的程式設計過程很像，Lisp，其語言特性決定了它的抽象高度，如果要我對上面的我的感悟寫成某樣及其簡介的東西的話，我一定會寫

(defmacro 象 
		(抽  需求))

(eq 項目  象)
           

文中在第三章提到的另外一個概念就是上司

1. 當過新人的導師麼？知道如何讓他們準從你的教誨？
2. 做過一個項目的靈魂人物麼？讓團隊的成員聽從，願意遵循你的安排？

這個東西要求的往往不在局限于計算機領域了，而是社會學的内容，而這讓很多的程式員，特别是理科生 為難，但對于這點我和 格拉漢姆 在《黑客與畫家》中所述的是贊同的，一個人是否真的精通某項能力，就在于能否給普通人溝通并讓他明白。往往程式員之是以很難和别人溝通是因為往往我們陷入自己的世界。和别人溝通的時候總是用自己領域的

行話

，讓一般的人根本無法了解，這發生在很多領域中。我們學會的知識總會最後抽象為各種簡潔而難以了解的概念和名詞。

會有很有趣的以下的對話

你試試把下面這句話告訴普通人：
“如果分派給孩子們的任務不再需要了，父母會把它們殺掉。”
           

這讓普通人無法了解，但對計算機行業的人卻習以為常，這中間所唯一出的錯就是對于概念的了解的偏差，“sub thread ”和“children” 在通常意義上的偏差決定了溝通鴻溝有多深，如果你習慣于将行業術語作為日常概念，那麼溝通永遠無法正常進行。

回到主題，溝通的關鍵是什麼？

我認為是了解溝通資訊的了解偏差，兩方聊到同一個概念，必然對其了解有落差，比如說thread ，普通人知道它有線的含義，但一個程式員即會知道它有線的含義，也會知道它代表線程。這在溝通的時候我們需要确定的東西.

“概念在溝通時會有落差”正确的溝通方式是如同瀑布一樣向下流，應該在都能了解的領域交流。而不是逆流.

當然排除某種行業的刻意炫耀，在一個程式員與普通人，程式員與程式員之間溝通的時候，應該在有交集的領域溝通。。否則一個團隊的效率很難提高