軟件發展的201個原則（精裝珍藏版）


	本書匯總了軟體工程原則。原則是關於軟體工程的基本原理、規則或假設，不管所選的技術、工具或語言是什麼，這些原則都有效。全書共9章，第1章為引言，後面8章將201個軟體工程的原則劃分為8個大的類別：一般原則、需求工程原則、設計原則、編碼原則、測試原則、管理原則、產品保證原則和演變原則。本書面向的讀者包括軟體工程師和管理者、軟體工程專業的學生、軟體工程領域的研究人員等。本書由百度公司支持出版。百度以技術創新為信仰，在創新投入、研發佈局、人才引進方面均走在國際前列。百度一直秉承著“科技為更好”的社會責任理念，堅持運用創新技術，聚焦於解決社會問題，履行企業公民的社會責任，為幫助全球用戶創造更加美好的生活而不斷努力。



	購買中國簡體書籍請注意： 1. 因裝幀品質及貨運條件未臻完善，中國簡體書可能有出現磨痕、凹痕、折痕等問題，故簡體字館除封面破損、內頁脫落、缺頁等較嚴重的狀態外，其餘所有商品將正常出貨。


	目錄第1章　引言第2章　一般原則原則1　品質第一原則2　品質在每個人眼中都不同原則3　開發效率和品質密不可分原則4　高品質軟體是可以實現的原則5　不要試圖通過改進軟體實現高品質原則6　低可靠性比低效率更糟糕原則7　儘早把產品交給客戶原則8　與客戶/使用者溝通原則9　促使開發者與客戶的目標一致原則10　做好拋棄的準備原則11　開發正確的原型原則12　構建合適功能的原型原則13　要快速地開發一次性原型原則14　漸進地擴展系統原則15　看到越多，需要越多原則16　開發過程中的變化是不可避免的原則17　只要可能，購買而非開發原則18　讓軟體只需簡短的使用者手冊原則19　每個複雜問題都有一個解決方案原則20　記錄你的假設原則21　不同的階段，使用不同的語言原則22　技術優先於工具原則23　使用工具，但要務實原則24　把工具交給優秀的工程師原則25　CASE工具是昂貴的原則26　“知道何時”和“知道如何”同樣重要原則27　實現目標就停止原則28　瞭解形式化方法原則29　和組織榮辱與共原則30　跟風要小心原則31　不要忽視技術原則32　使用文檔標準原則33　文檔要有術語表原則34　軟體文檔都要有索引原則35　對相同的概念用相同的名字原則36　研究再轉化，不可行原則37　要承擔責任第3章　需求工程原則原則38　低品質的需求分析，導致低品質的成本估算原則39　先確定問題，再寫需求原則40　立即確定需求原則41　立即修復需求規格說明中的錯誤原則42　原型可降低選擇使用者介面的風險原則43　記錄需求為什麼被引入原則44　確定子集原則45　評審需求原則46　避免在需求分析時進行系統設計原則47　使用正確的方法原則48　使用多角度的需求視圖原則49　合理地組織需求原則50　給需求排列優先順序原則51　書寫要簡潔原則52　給每個需求單獨編號原則53　減少需求中的歧義原則54　對自然語言輔助增強，而非替換原則55　在更形式化的模型前，先寫自然語言原則56　保持需求規格說明的可讀性原則57　明確規定可靠性原則58　應明確環境超出預期時的系統行為原則59　自毀的待定項原則60　將需求保存到資料庫第4章　設計原則原則61　從需求到設計的轉換並不容易原則62　將設計追溯至需求原則63　評估備選方案原則64　沒有文檔的設計不是設計原則65　封裝原則66　不要重複造輪子原則67　保持簡單原則68　避免大量的特殊案例原則69　縮小智力距離原則70　將設計置於知識控制之下原則71　保持概念一致原則72　概念性錯誤比語法錯誤更嚴重原則73　使用耦合和內聚原則74　為變化而設計原則75　為維護而設計原則76　為防備出現錯誤而設計原則77　在軟體中植入通用性原則78　在軟體中植入靈活性原則79　使用高效的演算法原則80　模組規格說明只提供使用者需要的所有資訊原則81　設計是多維的原則82　優秀的設計出自優秀的設計師原則83　理解你的應用場景原則84　無須太多投資，即可實現複用原則85　“錯進錯出”是不正確的原則86　軟體可靠性可以通過冗餘來實現第5章　編碼原則原則87　避免使用特殊技巧原則88　避免使用全域變數原則89　編寫可自上而下閱讀的程式原則90　避免副作用原則91　使用有意義的命名原則92　程式首先是寫給人看的原則93　使用最優的資料結構原則94　先確保正確，再提升性能原則95　在寫完代碼之前寫注釋原則96　先寫文檔後寫代碼原則97　手動運行每個元件原則98　代碼審查原則99　你可以使用非結構化的語言原則100　結構化的代碼未必是好的代碼原則101　不要嵌套太深原則102　使用合適的語言原則103　程式設計語言不是藉口原則104　程式設計語言的知識沒那麼重要原則105　格式化你的代碼原則106　不要太早編碼第6章　測試原則原則107　依據需求跟蹤測試原則108　在測試之前早做測試計畫原則109　不要測試自己開發的軟體原則110　不要為自己的軟體做測試計畫原則111　測試只能揭示缺陷的存在原則112　雖然大量的錯誤可證明軟體毫無價值，但是零錯誤並不能說明軟體的價值原則113　成功的測試應發現錯誤原則114　半數的錯誤出現在15%的模組中原則115　使用黑盒測試和白盒測試原則116　測試用例應包含期望的結果原則117　測試不正確的輸入原則118　壓力測試必不可少原則119　大爆炸理論不適用原則120　使用 McCabe 複雜度指標原則121　使用有效的測試完成度標準原則122　達成有效的測試覆蓋原則123　不要在單元測試之前集成原則124　測量你的軟體原則125　分析錯誤的原因原則126　對“錯”不對人第7章　管理原則原則127　好的管理比好的技術更重要原則128　使用恰當的方法原則129　不要相信你讀到的一切原則130　理解客戶的優先順序原則131　人是成功的關鍵原則132　幾個好手要強過很多生手原則133　傾聽你的員工原則134　信任你的員工原則135　期望優秀原則136　溝通技巧是必要的原則137　端茶送水原則138　人們的動機是不同的原則139　讓辦公室保持安靜原則140　人和時間是不可互換的原則141　軟體工程師之間存在巨大的差異原則142　你可以優化任何你想要優化的原則143　隱蔽地收集資料原則144　每行代碼的成本是沒用的原則145　衡量開發效率沒有完美的方法原則146　剪裁成本估算方法原則147　不要設定不切實際的截止時間原則148　避免不可能原則149　評估之前先要瞭解原則150　收集生產力資料原則151　不要忘記團隊效率原則152　LOC/PM與語言無關原則153　相信排期原則154　精確的成本估算並不是萬無一失的原則155　定期重新評估排期原則156　輕微的低估不總是壞事原則157　分配合適的資源原則158　制訂詳細的專案計畫原則159　及時更新你的計畫原則160　避免駐波原則161　知曉十大風險原則162　預先瞭解風險原則163　使用適當的流程模型原則164　方法無法挽救你原則165　沒有奇跡般提升效率的秘密原則166　瞭解進度的含義原則167　按差異管理原則168　不要過度使用你的硬體原則169　對硬體的演化要樂觀原則170　對軟體的進化要悲觀原則171　認為災難是不可能的想法往往導致災難原則172　做專案總結第8章　產品保證原則原則173　產品保證並不是奢侈品原則174　儘早建立軟體配置管理過程原則175　使軟體配置管理適應軟體過程原則176　組織SCM獨立於專案管理原則177　輪換人員到產品保證組織原則178　給所有中間產品一個名稱和版本原則179　控制基準原則180　保存所有內容原則181　跟蹤每一個變更原則182　不要繞過變更控制原則183　對變更請求進行分級和排期原則184　在大型開發專案中使用確認和驗證（V&V）第9章　演變原則原則185　軟體會持續變化原則186　軟體的熵增加原則187　如果沒有壞，就不要修理它原則188　解決問題，而不是症狀原則189　先變更需求原則190　發佈之前的錯誤也會在發佈之後出現原則191　一個程式越老，維護起來越困難原則192　語言影響可維護性原則193　有時重新開始會更好原則194　首先翻新最差的原則195　維護階段比開發階段產生的錯誤更多原則196　每次變更後都要進行回歸測試原則197　“變更很容易”的想法，會使變更更容易出錯原則198　對非結構化代碼進行結構化改造，並不一定會使它更好原則199　在優化前先進行性能分析原則200　保持熟悉原則201　系統的存在促進了演變參考資料索引術語索引