第十三章：軟體測試。一些基本名詞的解釋：bug：軟體的缺陷、test case：測試用例、test suite：測試用例集。而bug分為：症狀、程式錯誤和根本原因。測試方法有：單元測試（第二章提到過）、**覆蓋率測試、構造驗證測試、驗收測試、「探索性」的測試、回歸測試、場景整合系統測試、夥伴測試……並且測試還是需要寫文件。總的來說，測試這章有的部分我不太懂，沒有接觸和實踐過。但是沒有想到測試還要寫文件？？？
第十四章，又是乙個公式，軟體質量=程式質量+軟體工程質量。軟體要在功能、成本、實踐三個方面滿足利益相關者的需求。對於使用者來說，最簡單粗暴的要求就是，使用者可以保持自己的「懶惰」，因為軟體足夠使用方便。保證軟體的質量也是要付出一定成本的，包括預防、評審、內部故障、外部故障、流程分析改進、投資改進。我曾經就認為軟體測試是用來保證軟體質量的，但是書上告訴我這兩者區別很大。不能盲目信任專業人士扮演的角色，畫地為牢的分工和無明確責任的分工都是不可取的。
第十五章，穩定和發布階段。**開發過後並不是萬事大吉了，軟體發布同樣都是問題。軟體團隊居然也有血型……軟體團隊中有會診小組，對於每乙個bug，會診小組決定採取，修復，設計本來如此（即軟體在這方面沒有問題），不修復，推遲的處理。後面有一些招數，我發現在考試中我經常使用的就是「砍掉」，直接刪去那一部分**。
第十六章，創新。看完創新的迷思我整個人都迷思了。好多事情在現實生活裡是沒有定論的。但是還是要分析這個問題。產品追求質量公司追求價值是一定的，影響產品競爭力的因素有：產品行業、公司和市場、團隊執行、產品價值。接下來書上寫了「作坊」，我們開發簡單的專案時也要形狀好的小作坊，從小事做起，重質量。
第十七章，人、績效和職業道德。**都離不開和人打交道，即使是對著電腦程式設計。有人的地方就會有很多問題，為了避免一些扯皮的問題，就要談到績效管理。而績效管理的量化學問也很大。團隊合作分為：萌芽階段、磨合階段、規範階段、創造階段。軟體工程師的原則有：公眾、客戶與雇主、產品、判斷、管理、職業、同事、自身。
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...
構建之法閱讀筆記06
夢斷 06 程式設計師常依賴一種稱為 媽媽測試 的手段，以對計算機一無所知的父母為假象用例，有時甚至請這類使用者親自體驗。這是現在程式設計師的通病，做出來的軟體或許在計算機上是完美無誤的程式，甚至是最優化做快的演算法，但是使用者的體驗和反饋卻並不是很好，這就要考慮到軟體設計的問題了，良好的軟體設計像...
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...