讀構建之法筆記

2022-05-04 07:57:11 字數 2666 閱讀 6631

目錄對於乙個專案的構建在這本書被分為了大概以下幾個步驟

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

抽象化互資訊遞迴模組化規範

這本書在講到程式設計師的成長會在幾個方面都需要持續公升級,包括 **的編寫 , 團隊溝通能力 , 工程構建 , 程式設計思想 。

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

等級要求

sde(初級軟體工程師)

入門會一些技能,尚未熟練

sde ii (中級軟體工程師)

獨立編寫 ,如未清楚知道如何查

senior sde

小組領導,影響3-12工程師

principal sde 首席

團隊領導,影響著10人上的大團隊

這是乙個由小到大的過程,就像國學中「修身,齊家,治國」的迭代過程 。

從最初級的能夠修改一點別人的bug,可以連專案的語言本身都不用學會,只需仿造即可;

到能夠編寫要求的小模組,需要知道語言本身的語法

到編寫更為龐大和重要的模組,需要的是對語言特性的熟悉;再上的發展需要的確實對專案的整體把握

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

就是如何去決定乙個專案的結構,和如何去構建乙個龐大的專案

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

設定目標(需求分析)

設定結構

試執行豐滿它

以上的說法和書中很相似,但我個人看來,就是,抽離本質,賦予其象,也就是前兩步,也是最重要的兩步。對於乙個專案存在必要性就是完成需求,但是往往需求和最後的結果會有所偏差,最重要也是最最開始的一步就是抽離出需求的本質,這在具體下,便是需要理解要求。了解需求背後的意義

這是專案的結構,如何去構建。

往往了解行業普遍做法是很重要的,可以作為重要的參考,不要「一來就想搞個大新聞",借鑑的必要性不言而喻,可以讓專案的起點和最後的結果在乙個可以評估可以接受的範圍,而創新的到底在什麼地方,應該在需要它的時候才應該需要。

模仿和模擬使用者使用的過程能夠讓我們把結構的溝和壑大致理順

往往大多數軟體相似的很多,但真正優秀,而讓人長久的讚揚的很少,這之間的差別在哪?在我看來也是的程度問題,賈伯斯的「人機互動"是乙個很好的例子,程式設計師沉於自己的領域,但是計算機行業所服務的確是所有行業和所有普通人。這是乙個互資訊的深度過程,你對你所服務的物件又能了解多少呢?你對整個專案的結果也就是完成的軟體的本質了解到何種程度呢?

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

(defmacro 象 

(抽 需求))

(eq 專案 象)

文中在第三章提到的另外乙個概念就是領導

當過新人的導師麼?知道如何讓他們準從你的教誨?

做過乙個專案的靈魂人物麼?讓團隊的成員聽從,願意遵循你的安排?

這個東西要求的往往不在侷限於計算機領域了,而是社會學的內容,而這讓很多的程式設計師,特別是理科生為難,但對於這點我和 格拉漢姆 在《黑客與畫家》中所述的是贊同的,乙個人是否真的精通某項能力,就在於能否給普通人溝通並讓他明白。往往程式設計師之所以很難和別人溝通是因為往往我們陷入自己的世界。和別人溝通的時候總是用自己領域的行話,讓一般的人根本無法理解,這發生在很多領域中。我們學會的知識總會最後抽象為各種簡潔而難以理解的概念和名詞。

會有很有趣的以下的對話

你試試把下面這句話告訴普通人:

「如果分派給孩子們的任務不再需要了,父母會把它們殺掉。」

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

回到主題,溝通的關鍵是什麼?

我認為是理解溝通資訊的理解偏差,兩方聊到同乙個概念,必然對其理解有落差,比如說thread ,普通人知道它有線的含義,但乙個程式設計師即會知道它有線的含義,也會知道它代表執行緒。這在溝通的時候我們需要確定的東西.

「概念在溝通時會有落差」正確的溝通方式是如同瀑布一樣向下流,應該在都能理解的領域交流。而不是逆流.

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

讀《構建之法》

這周精讀了幾遍 構建之法 的 一 二 十六章,本人更偏好於語言精練概況的書籍,由於語言習慣問題,這本書對我而言有些解讀困難。由此在下面對幾章內容精練出總結概況,並提出問題。第一章1.1軟體 程式 軟體工程 軟體 資料結構 演算法 文中的軟體被定義為程式與軟體工程的結合,意在強調靜態 往往不足以滿足客...

讀《構建之法》

按照精讀的讀法,細緻的讀完了 構建之法 的第 一 二 十六章。結合書本內容與自我理解,提出以下問題。1.1軟體 程式 軟體工程 書中有這樣乙個例子 如果一架民用飛機上有需求,使用者使用它的概率是百萬分之一,你還要做這個功能麼?你會選擇 1 根本不考慮 2 如果沒時間實現這個功能就算了 3 做了,但不...

讀《構建之法》有感

這本書一開始講述了軟體工程的發展史,從開始到應用,所經歷的過各種變化,讓我們對這專業有更好的了解。強調要懂得團體的力量,合作取得雙贏,這樣才能大幅度提高軟體開發的效率。此書還講述了,要成為更好的軟體開發人員,我們要不斷積累軟體開發相關知識,提公升自己的技能技術,積累問題領域的知識和經驗,對通用的軟體...