《構建之法》第十&十一章主要講述了在軟體設計前期的需求分析問題上的方法和實踐經驗，分為「典型使用者和場景」以及「軟體設計與實現」。其中第十章大部分內容和教授上課所講的一樣比如說，使用者的分類（典型使用者可以包括以下內容：
1. 名字（越自然越好）
2. 年齡（不同年齡和收入的使用者有不同的需求）
3. 收入
4. 代表的使用者在市場上的比例和重要性（比例大不等同於
重要性高，如付費的使用者比例較少，但是影響大，所以更重
要5. 使用這個軟體的典型場景
6. 使用本軟體/服務的環境（在辦公室/家裡/沙發/床上/公
共汽車/地鐵……）
7. 生活/工作情況
8. 知識層次和能力（教育程度，對電腦、網際網路的熟悉程
度）9. 使用者的動機、目的和困難（困難 = 需要解決的問題）
10. 使用者的偏好）
這十點已經將使用者的種類劃分得很詳細了，我們也可以有針對性的去編寫軟體以滿足對不同使用者的需求問題。
然後就是使用者場景分析，在沒有聽課或者看這本書之前呢這些我是完全想不到的，那時候腦子裡只有乙個簡單的想法——把功能實現了不就得了，哪有那摸多的麻煩事啊！真的是和書上說的一樣的那種人，但是看完書後發現是真不行，因為我們的軟體是要賣給別人的，不是單單的實現某些所謂的功能的。所以使用者場景分析就十分有必要了，這樣一來一是可以檢測到使用者在使用過程中會遇到哪些問題以便我們解決，以及在任何環境下或者使用者（外行人）的任何操作都必須讓軟體看起來是正常的，也就是傳說中的換位思考，把自己當場乙個不太了解電腦的使用者來做軟體。
接下來的事情就是寫文件了，「什麼？！程式設計師還需要寫文件？你不是在逗我吧！沒錯，不僅僅要寫而且還要寫的十分的詳細，就像，就像電視劇集本那樣詳細，但是用不著寫得那樣生動」反而呢要做的越簡單越容易理解越好，但是不能太枯燥乏味了，這樣沒人願意讀得好嗎！看到這裡呢，我又一次感到了巨大的壓力感和榮耀感，媽呀原來程式設計師還是數理文學通吃啊，全能人才啊！！
第十一章主要講到而「軟體設計與實現」，大體分為兩個部分第一」設計的方法「，第二"如何實現"
關於設計方法，我會學過一種「圖形建模」也就是畫用例圖等等，還有「表達資料流動」等方法，還是需要我們用時間和精力去學習的。至於如何實現，無非是按照步驟：估計開發時間
快速編寫偽**以快速理解整個程式，撰寫文件，與同事交流文件，編寫**，直到專案完成。
文章注重強調了「構建」的重要性，把抽象的構建比作為蓋樓是的手腳架 ，貌似不是砌牆或蓋樓的一部分但是沒有它卻是不行的，沒有它樓就很難蓋起來很難蓋得標準和堅固。
書中還提到了關於做基本事情的心態的問題，我覺得經理回答得很好「我還沒有見過從天而降的白領或金領。所謂的大拿們都是從藍領摸爬滾打出來的。換句話說，我眼裡沒有白領或藍領，只有「汗領」——就是大家都得出汗幹活。」大家都得幹活，踏踏實實的幹每個人的成長都是乙個過程，急於求成是不現實的。
這本書不僅僅帶給我的是關於現在該如何學習或者以後進入工作該如何做，更多的我覺得是做人方面的心態和素質的教育。
第十 十一章 賞金計畫及成本
第十章 bounty program 風險的預先管理 以前在還沒開交易所之前，我總會好奇，業界的 bounty program 會是給誰玩的。真的會有人玩嗎？後來在我開交易所之後，簽約的第乙個資安顧問，就建議我要設立 bounty program。知名的 bounty program 有 hacke...
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
《構建之法》閱讀筆記
第五章的內容是團隊的話題。團隊一直是乙個不可或缺的話題，球場上，網遊中都有著若干個團隊。個人離開團隊無法健康成長，團隊離開個人無法存在。團隊在我們軟體工程中是乙個非常重要的內容。團隊的特點 團隊有一致的集體目標，團隊要一起完成這個目標。乙個團隊的成員不一定要同時工作。團隊成員有各自的分工，互相依賴合...