零、基本常識(shí) & 縮寫
- 軟件生命鏈：requirement -> design -> coding -> testing -> evolution
- 測(cè)試種類：?jiǎn)卧獪y(cè)試盛杰，集成測(cè)試挽荡，系統(tǒng)測(cè)試
- CASE：computer-aided software engineering
- SRS：software requirement specification
- TBD：to be determined
- SCM：Software Configuration Management
- V&V：Velidation and Verification
一、General
- quality對(duì)不同的人意味著不同的事情即供，并且可能互相矛盾定拟。
- productivity和quality負(fù)相關(guān)
- cost和quality正相關(guān)
- 需求是變化的，并且在任何階段都幾乎不可避免逗嫡，用戶看到的越多就想要的越多青自。
- 了解需求是重要的，沒(méi)有真正的用戶就去模擬一些
- 明確需求的優(yōu)先級(jí)
- 原型（prototype）分為一次性/進(jìn)化型兩種祸穷，選擇哪種的關(guān)鍵在于核心需求是否明確性穿，不明確->一次性。一次性原型：快點(diǎn)做雷滚，只做不確定的功能需曾，進(jìn)化型原型：只做確定的功能。
- 每次更新一點(diǎn)點(diǎn)
- 對(duì)于復(fù)雜問(wèn)題的簡(jiǎn)單解決方案要警惕
- 使用某種技術(shù)之前要了解它的原理，否則沒(méi)法好好使用
- 目標(biāo)在任何時(shí)候都是重要的
- 開(kāi)發(fā)之前就要寫文檔呆万，而非開(kāi)發(fā)完成后商源。
- 不要害怕犯錯(cuò)
- 不要盲從，無(wú)論是新技術(shù)谋减，還是大多數(shù)人的觀點(diǎn)
- 活到老學(xué)到老：conferences, magazines
- 技術(shù)文檔：盡量在選詞和句子結(jié)構(gòu)上保持一致屿岂。不是為了美，是為了效率
- 要負(fù)責(zé)江掩！
二馅袁、Requirement
- 目的是明確問(wèn)題和需求，并且明確系統(tǒng)的外部行為（滿足需求的方式）而非細(xì)節(jié)
- 明確需求：不能錯(cuò)严就，不能少总寻。明確對(duì)于不同的用戶，每個(gè)需求到底意味著什么梢为。
- 及時(shí)和用戶交流：少變渐行。必要時(shí)和用戶一起工作
- 收集數(shù)據(jù)、充分分析
- 多用原型
- 盡早發(fā)現(xiàn)問(wèn)題铸董，盡早解決
- 需求和設(shè)計(jì)分開(kāi)
- 記錄每個(gè)需求的背景祟印、變更歷史，需要包括時(shí)間粟害、場(chǎng)合蕴忆、相關(guān)人員（便于追溯）
- SRS需要各方審核
- SRS需要適當(dāng)?shù)姆诸惙绞脚c展示結(jié)構(gòu)
- SRS需要簡(jiǎn)潔
- SRS需要盡量減少歧義性
- 修改記錄需要保留，方便了解背景和歷史我磁。
- 文檔需要分為自然語(yǔ)言和代碼語(yǔ)言兩種孽文。先寫前者，后寫后者夺艰。
- 可靠性（Reliability）很難簡(jiǎn)單量化芋哭，需要靠其他具體指標(biāo)來(lái)量化，例如錯(cuò)誤率等
- 文檔中需要寫到環(huán)境和預(yù)期不符的情況下郁副，系統(tǒng)如何處理减牺。例如QPS超了
- 文檔中可以由不確定項(xiàng)，但是必須表明存谎，何時(shí)由誰(shuí)負(fù)責(zé)確定這一項(xiàng)
- 需求最好用數(shù)據(jù)庫(kù)存儲(chǔ)拔疚。表的內(nèi)容包括：id、內(nèi)容既荚、與其他需求的關(guān)系（父子關(guān)系等）稚失、重要性、預(yù)期沖突恰聘、來(lái)源句各、產(chǎn)品版本號(hào)等
三吸占、Design
- 設(shè)計(jì)系統(tǒng)框架，明確每個(gè)部分的功能
- 用requirement-design表格來(lái)維護(hù)需求和設(shè)計(jì)的關(guān)系凿宾。行是每個(gè)design components矾屯，列是需求
- 方案n選1，多角度衡量初厚，選最好
- 需求文檔是設(shè)計(jì)的先決條件件蚕，必須貼近需求來(lái)設(shè)計(jì)
- 注意封裝
- 能復(fù)用就復(fù)用，不要重復(fù)造輪子
- special cases不利于管理产禾，如果special cases過(guò)多就重構(gòu)
- 開(kāi)發(fā)者和維護(hù)者都需要【完全理解】（劃重點(diǎn)）設(shè)計(jì)文檔
- 設(shè)計(jì)文檔需要注意層次排作，便于reader自頂向下的理解
- 系統(tǒng)需要維持一致性（例如各個(gè)模塊的錯(cuò)誤信息、調(diào)用方式等）
- 注意模塊化
- 設(shè)計(jì)時(shí)下愈，需要注意：錯(cuò)誤情況纽绍、是否好維護(hù)、通用性势似、算法復(fù)雜度
- 一個(gè)模塊的設(shè)計(jì)文檔應(yīng)該包含且僅包含它的下游模塊需要知道的信息，例如接口僧著、變量履因、依賴、基本功能等
- clean盹愚，simple栅迄，elgant，fast皆怕，maintainable毅舆，easy to implement
- 設(shè)計(jì)時(shí)需要考慮到外部條件，包括硬件條件愈腾、輸入情況憋活、qps等
- 需要處理無(wú)效輸入，返回錯(cuò)誤虱黄，而非當(dāng)作正常輸入一樣處理
四悦即、Coding
- 避免開(kāi)發(fā)過(guò)快，開(kāi)發(fā)前一定要提前考慮好requirement和design
- 自頂向下的coding
- 先寫注釋橱乱，后寫代碼
- 一定記住代碼先是給人看的辜梳，其次才是給機(jī)器看的
- 每個(gè)部分單獨(dú)單測(cè)，不要一起測(cè)試太多
- 做好CR（CR時(shí)間=開(kāi)發(fā)時(shí)間）
- 語(yǔ)言知識(shí)是次要的泳叠，quality programming的常識(shí)才是最重要的
- 代碼風(fēng)格很重要作瞄！
- 避免tricks
- 數(shù)據(jù)模塊單獨(dú)封裝
- 盡量少用全局變量，不好控制危纫，盡量封裝
- 避免嵌套過(guò)多
五宗挥、Testing
- 用requirement-test表格來(lái)維護(hù)需求和test的關(guān)系乌庶，方便確定test優(yōu)先級(jí)，好維護(hù)
- 測(cè)試的目的就是找到錯(cuò)誤属韧，暴露錯(cuò)誤安拟，不要怕犯錯(cuò)
- test planning應(yīng)該和開(kāi)發(fā)并行，設(shè)計(jì)者應(yīng)該閱讀SRS
- 需要獨(dú)立的test planner和執(zhí)行者宵喂，rd只應(yīng)該負(fù)責(zé)debug和單元測(cè)試糠赦，qa應(yīng)該負(fù)責(zé)check單元測(cè)試和實(shí)施集成測(cè)試、系統(tǒng)測(cè)試
- error具有模塊集中性锅棕，50%的錯(cuò)誤出現(xiàn)在20%的模塊中
- 白盒+黑盒
- 測(cè)試用例中應(yīng)該包括預(yù)期結(jié)果
- 測(cè)試用例應(yīng)該包含各種無(wú)效輸入
- McCabe標(biāo)準(zhǔn)：測(cè)試程序復(fù)雜度
- 測(cè)試需要有標(biāo)準(zhǔn)：結(jié)束標(biāo)準(zhǔn)（新發(fā)現(xiàn)的錯(cuò)誤率拙泽，釣魚(yú)的錯(cuò)誤有沒(méi)有發(fā)現(xiàn)），覆蓋率（覆蓋多少語(yǔ)句裸燎，覆蓋多少分支顾瞻，覆蓋多少路徑）
- 測(cè)試出錯(cuò)誤后，需要分析錯(cuò)誤原因（方法論德绿，而非具體執(zhí)行）
六荷荤、Management
- 管理包括：planning，controlling移稳，monitoring蕴纳，reporting
- 理解用戶需求是最重要的
- 員工質(zhì)量>員工數(shù)量
- listen to 員工 ＆ 以身作則
- 辦公區(qū)要保持安靜，和其他區(qū)域隔離開(kāi)
- 必須要有優(yōu)先級(jí)
- productivity衡量方法：source lines of code（SLOC）每人月和function points（FP） 每人月个粱。但是兩種方法都不完美
- productivity與語(yǔ)言有關(guān)
- team productivity是重要的古毛，不一定是個(gè)人*n，與配合有關(guān)
- 不要設(shè)定不現(xiàn)實(shí)的ddl
- 及時(shí)調(diào)整排期
- 計(jì)劃要細(xì)致：PERT圖記錄不同任務(wù)之間的依賴都许；甘特圖記錄時(shí)間稻薇；milstones設(shè)定；文檔和代碼規(guī)范胶征；人員分配
- 及時(shí)更新計(jì)劃：需求變了塞椎，時(shí)間安排延誤了，發(fā)生了嚴(yán)重的錯(cuò)誤弧烤，原始條件變了忱屑，等等
- 延遲的計(jì)劃只會(huì)越來(lái)越延遲
- 十個(gè)最重要的風(fēng)險(xiǎn)點(diǎn)：人員問(wèn)題，不現(xiàn)實(shí)的時(shí)間安排暇昂，不理解用戶需求莺戒，用戶界面不好，浮夸的修飾急波，需求變更沒(méi)有控制好从铲，復(fù)用，外部表現(xiàn)功能澄暮，響應(yīng)時(shí)間名段，超出當(dāng)前技術(shù)范圍
- 選擇適當(dāng)?shù)膒rocess model：waterfall阱扬，一次性原型，增量開(kāi)發(fā)伸辟，螺旋模型等等
- 匯報(bào)的重點(diǎn)在于現(xiàn)實(shí)和計(jì)劃的差別
- 硬件的更新?lián)Q代要持樂(lè)觀態(tài)度麻惶，軟件的更新?lián)Q代要持悲觀態(tài)度
- 正視錯(cuò)誤和失敗，越逃避越嚴(yán)重
七信夫、Product Assurance
- Product Assurance 包括Software configuration management, Software quality assurance, Software verification and validation, Testing
- SCM：如何反應(yīng)軟件問(wèn)題窃蹋，需求變更如何反饋，有個(gè)board安排需要變更的需求静稻，等等
- SCM最好和開(kāi)發(fā)團(tuán)隊(duì)互相獨(dú)立
- SCM不能只安排新人和渣渣警没，牛人也應(yīng)該輪換去做
- 中間版本的產(chǎn)出要有名字和編號(hào)
- 注意備份，備份變更之前的版本
- change發(fā)生的時(shí)候振湾，首要解決變更需求杀迹，如果中間發(fā)現(xiàn)了其他問(wèn)題，次要解決
- 每次change要詳細(xì)記錄：需求押搪，背景树酪，發(fā)生的時(shí)間、地點(diǎn)大州、原因和人物嗅回，影響的產(chǎn)品功能
- V&V：第三方驗(yàn)收，包括Validation（順序驗(yàn)收摧茴，檢查每個(gè)功能是否滿足前一步的需求）和Verification（每個(gè)功能是否滿足用戶需求）
八、Evolution
- Evolution包括：新需求埂陆，優(yōu)化代碼性能苛白，修復(fù)bug
- change是不可避免的，即使真的需求能保持不變焚虱，環(huán)境也在變化
- 熵增原理：系統(tǒng)的復(fù)雜度會(huì)上升购裙，組織程度會(huì)下降
- 馬太效應(yīng)：錯(cuò)的越多的越可能錯(cuò)
- 系統(tǒng)越老，維護(hù)的成本越大
- 語(yǔ)言影響維護(hù)難度
- 維護(hù)階段比開(kāi)發(fā)階段產(chǎn)生的錯(cuò)誤更多
- fix problem之前必須完全的理解它鹃栽，否則會(huì)引入新的問(wèn)題
- fix problem之前先修改SRS躏率，讓所有角色都知曉
- fix problem之后必須做回歸測(cè)試
- 提升性能之前，先檢查哪里占用資源最多（profiler）
- 一次比平均規(guī)模更大的更新民鼓，很可能質(zhì)量比較差
