此次學習主要記錄概念型知識點，摘抄如下：
第三章 軟體工程師的成長
軟體系統的絕大部分模組都是由個人開發或維護的。在軟體工程的術語中，我們把這些單個的成員叫做individ-ual contributor（ic）。ic在團隊中的流程是怎麼樣的呢？以開發人員為例，流程如下。
1. 積累軟體開發相關的知識，提公升技術技能（如對具體技術的掌握，動手能力）
2. 積累問題領域的知識和經驗（例如：對醫療或金融行業的了解）
3. 對通用的軟體設計思想和軟體工程思想的理解
4. 提公升職業技能（區別於技術技能）
職業技能包括：自我管理的能力，表達和交流的能力，與人合作的能力，按質按量完成任務的執行力，這些能力在it行業和其他行業都很重要。
5. 實際成果
是否按時交付？
在團隊工作中，穩定、一致的交付時間是衡量乙個員工能力的重要方面
第四章 兩人合作
每個人對於什麼是「好」的**規範未必認同，這時我們很有必要給出乙個基準線—什麼是好的**規範和設計規範
計算機只關心編譯生成的機器碼，你的程式採用哪種縮排風格，變數名有無統一的規範等，與機器碼的執行無關。但是，做乙個有商業價值的專案，或者在團隊裡工作，**規範相當重要。「**規範」可以分成兩個部分：
1. **風格規範——主要是文字上的規定，看似表面文章，實際上非常重要
2. **設計規範——牽涉到程式設計、模組之間的關係、設計模式等方方面面的通用原則
**風格的原則是：簡明，易讀，無二義性
提示：這裡談的風格是一家之言，如遇爭執，關鍵是要本著「保持簡明，讓**更容易讀」的原則，看看爭執中的**規範能否讓程式設計師們更好地理解和維護程式
2.1 縮排
是用tab鍵好，還是2、4、8個空格？
結論：4個空格，在visual studio和其他的一些編輯工具中都可以定義tab鍵擴充套件成為幾個空格鍵。不用tab鍵的理由是，tab鍵在不同的情況下會顯示不同的長度，嚴重干擾閱讀體驗。4個空格的距離從可讀性來說，正好
2.2 行寬
行寬必須限制，但是以前有些文件規定的80字元行寬太小了（以前的計算機/打字機顯示行寬為80字元），現在時代不同了，可以限定為100字元
2.3 括號
在複雜的條件表示式中，用括號清楚地表示邏輯優先順序
2.4 斷行與空白的行
1. 最精簡的格式a：
if (condition) dosomething();
else dosomethingelse();
優點：因為可以節省幾行
缺點：不同的語句（statement）放在一行中，程式除錯（debug）起來非常不方便，如果要一步一步觀察condition中各個變數（condition可能是包含函式呼叫的複雜表示式）的變化情況，單步執行就很難了
2. 有斷行的格式b：
if (condition)
dosomething();
else
dosomethingelse();
缺點：由於沒有明確的「」來判斷程式的結構，在有多層控制巢狀時，這樣的格式就不容易看清結構和對應關係
3. 改進的格式c
if (condition) else缺點：不夠清晰
4. 每個「」都獨佔一行，即格式d
if (condition)else
2.5 分行
不要把多條語句放在一行上
a =1; b =2; // bogus
if (ffoo) bar(); // bogus
更嚴格地說，不要把多個變數定義在一行上
foo foo1, foo2; // bogus2.6 命名
用單個字母給有複雜語義的實體命名並不可取，也是經過了實踐檢驗的方法叫「匈牙利命名法」。例如：
ffileexist // 表明是乙個bool值，表示檔案是否存在；
szpath // 表明是乙個以0結束的字串，表示乙個路徑
2.7 下劃線2.8 大小寫
由多個單詞組成的變數名，如果全部都是小寫，很不易讀，乙個簡單的解決方案就是用大小寫區分它們。
乙個通用的做法是：
2.9 注釋
需要注釋什麼？不要注釋程式是怎麼工作的（how），程式本身就應該能說明這一問題
for (i =0; i < len; i++)//this loop starts the i from0 to len, in each step, it// does something
for (i =0; i < len; i++)
以上的注釋是多餘的。注釋是為了解釋程式做什麼（what），為什麼這樣做（why），以及要特別注意的地方，如下
複雜的注釋應該放在函式頭，很多函式頭的注釋都用來解釋引數的型別等，如果程式正文已經能夠說明引數的型別in/out，就不要重複！
注釋也要隨著程式的修改而不斷更新，乙個誤導的（misleading）注釋往往比沒有注釋更糟糕
另外，注釋（包括所有源**）應該只用ascii字元，不要用中文或其他特殊字元，否則會極大地影響程式的可移植性。
在現代程式設計環境中，程式編輯器可以設定各種美觀得體的字型，我們可以使用不同的顯示風格來表示程式的不同部分。
注意：有些程式語言的教科書對於基本的語法有詳細的注釋，那是為了教學的目的，不宜在正式專案中也這麼做
正確定義：看**是否在「**規範」的框架內正確地解決了問題
軟體工程中最基本的複審手段，就是同伴複審
1. **複審的目的在於：
發現邏輯錯誤，程式可以編譯通過，但是**的邏輯是錯的
發現演算法錯誤，比如使用的演算法不夠優化，邊界條件沒有處理好等
發現潛在的錯誤和回歸性錯誤—當前的修改導致以前修復的缺陷又重新出現
發現可能需要改進的地方
結對程式設計的優勢
在開發層次，結對程式設計能提供更好的設計質量和**質量，兩人合作解決問題的能力更強
對開發人員自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感
在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動
總之，如果運用得當，結對程式設計可以取得更高的投入產出比（return of investment）
構建之法讀書筆記2
開始讀這本書，最大的感受的感受就是軟體工程原來是可以這麼學的，以前學習軟體工程的課程的時候，總是感覺這門課程及其枯燥無味，總是在說太多的理論，很少 會涉及到實踐，甚至根本就是沒有實踐這個環節，所以學習很無聊，但是研究生階段讀到這本書，真的是全新的感受，首先，不僅僅只是在說理論了，加入了很多實 踐的東...
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...
《構建之法》讀書筆記
乙個軟體除了穩定 功能強大，使用者體驗也很重要。程式開發人員和測試人員在強調其功能和效能的同時，還有一點很注重的就是使用者體驗。在我們學習的最初階段老師們就強調對於軟體開發來說使用者體驗的重要性，無論軟體還是硬體，都有很多功能部件，各個部件還要郵寄的結合起來，才能滿足使用者的需求。其中有一點特別，就...