軟件開發的 201個原則 201 Principles of Software Development

★作者介紹★
Alan M. Davis是一名計算機科學家，他的職業生涯大約有一半在工業界，一半在學術界。
他在工業界的經歷包括：
Offtoa公司的聯合創始人兼首席執行官，這是一家幫助企業家製定商業戰略的互聯網公司（2012年至今）。
Omni-Vista公司的聯合創始人、董事長兼首席執行官，這是一家位於科羅拉多斯普林斯的軟件公司（1998—2002）。
他在學術界的經歷包括：
位於丹佛的科羅拉多大學行政MBA創業教授，前任學術主席（2006—2018）。
科羅拉多大學斯普林斯分校的商業策略與企業家精神專業的教授，前El Pomar軟件工程教授（1991—2015）。
Davis博士在1994年至1998年擔任《IEEE 軟件》的主編；在全球28個國家或地區演講2000餘次，並撰寫了9本圖書；他自1994年起成為IEEE會士；曾多次訪問中國，其中包括領導EMBA學生小組三度赴上海、北京出訪。

★譯者介紹★
本書譯者均為百度內部培訓項目“代碼的藝術訓練營”的學員。
出於對本書的熱愛和推廣優秀軟件工程理念的使命，大家自發組織起來，利用業務時間完成了本書的翻譯。
翻譯小組的成員包括：葉王，馬學翔，吳斌，王冰清，楊光，曾浩浩，李殿斌，甘璐，李子昂，肖遠昊，賈儒，王瑩，張苗，李雙婕，榮文升。
大家很高興能夠在百度完成這件非常有意義的工作。

第1章 引言 ................................................................................... 3

第2章 一般原則 ........................................................................... 7
原則1 質量第#一 ................................................................. 8
原則2 質量在每個人眼中都不同 ....................................... 9
原則3 開發效率和質量密不可分 .....................................10
原則4 高質量軟件是可以實現的 .....................................11
原則5 不要試圖通過改進軟件實現高質量 ......................12
原則6 低可靠性比低效率更糟糕 .....................................13
原則7 儘早把產品交給客戶.............................................14
原則8 與客戶/用戶溝通 ...................................................15
原則9 促使開發#者與客戶的目標一致 .............................16
原則10 做好拋棄的準備 ..................................................17
原則11 開發正確的原型 ..................................................18
原則12 構建合適功能的原型 ..........................................19
原則13 要快速地開發一次性原型 ...................................20
原則14 漸進地擴展系統 ..................................................21
原則15 看到越多，需要越多 ..........................................22
原則16 開發過程中的變化是不可避免的 ........................23
原則17 只要可能，購買而非開發 ...................................24
原則18 讓軟件只需簡短的用戶手冊 ...............................25
原則19 每個複雜問題都有一個解決方案 ........................26
原則20 記錄你的假設 ......................................................27
原則21 不同的階段，使用不同的語言 ...........................28
原則22 技術優先於工具 ..................................................29
原則23 使用工具，但要務實 ..........................................30
原則24 把工具交給優秀的工程師 ...................................31
原則25 CASE工具是昂貴的 ...........................................32
原則26 “知道何時”和“知道如何”同樣重要 ............33
原則27 實現目標就停止 ..................................................34
原則28 了解形式化方法 ..................................................35
原則29 和組織榮辱與共 ..................................................36
原則30 跟風要小心 ..........................................................37
原則31 不要忽視技術 ......................................................38
原則32 使用文檔標準 ......................................................39
原則33 文檔要有術語表 ..................................................40
原則34 軟件文檔都要有索引 ..........................................41
原則35 對相同的概念用相同的名字 ...............................42
原則36 研究再轉化，不可行 ..........................................43
原則37 要承擔責任 ..........................................................44

第3章 需求工程原則 .................................................................. 47
原則38 低質量的需求分析，導致低質量的成本估算 .....48
原則39 先確定問題，再寫需求 .......................................49
原則40 立即確定需求 ......................................................50
原則41 立即修復需求規格說明中的錯誤 ........................51
原則42 原型可降低選擇用戶界面的風險 ........................52
原則43 記錄需求為什麼被引入 .......................................53
原則44 確定子集 .............................................................54
原則45 評審需求 .............................................................55
原則46 避免在需求分析時進行系統設計 ........................56
原則47 使用正確的方法 ..................................................57
原則48 使用多角度的需求視圖 .......................................58
原則49 合理地組織需求 ..................................................59
原則50 給需求排列優先級 ..............................................60
原則51 書寫要簡潔 ..........................................................61
原則52 給每個需求單獨編號 ..........................................62
原則53 減少需求中的歧義 ..............................................63
原則54 對自然語言輔助增強，而非替換 ........................64
原則55 在更形式化的模型前，先寫自然語言 ................65
原則56 保持需求規格說明的可讀性 ...............................66
原則57 明確規定可靠性 ..................................................67
原則58 應明確環境超出“可接受”時的系統行為 ........68
原則59 自毀的待定項 ......................................................69
原則60 將需求保存到數據庫 ..........................................70

第4章 設計原則 ......................................................................... 73
原則61 從需求到設計的轉換並不容易 ...........................74
原則62 將設計追溯至需求 ..............................................75
原則63 評估備選方案 ......................................................76
原則64 沒有文檔的設計不是設計 ...................................77
原則65 封裝 .....................................................................78
原則66 不要重複造輪子 ..................................................79
原則67 保持簡單 .............................................................80
原則68 避免大量的特殊案例 ..........................................81
原則69 縮小智力距離 ......................................................82
原則70 將設計置於知識控制之下 ...................................83
原則71 保持概念一致 ......................................................84
原則72 概念性錯誤比語法錯誤更嚴重 ...........................85
原則73 使用耦合和內聚 ..................................................86
原則74 為變化而設計 ......................................................87
原則75 為維護而設計 ......................................................88
原則76 為防備出現錯誤而設計 .......................................89
原則77 在軟件中

植入通用性 ..........................................90
原則78 在軟件中植入靈活性 ..........................................91
原則79 使用高效的算法 ..................................................92
原則80 模塊規格說明只提供用戶需要的所有信息 ........93
原則81 設計是多維的 ......................................................94
原則82 優秀的設計出自優秀的設計師 ...........................95
原則83 理解你的應用場景 ..............................................96
原則84 無須太多投資，即可實現復用 ...........................97
原則85 “錯進錯出”是不正確的 ...................................98
原則86 軟件可靠性可以通過冗餘來實現 ........................99

第5章 編碼原則 ....................................................................... 101
原則87 避免使用特殊技巧 ............................................102
原則88 避免使用全局變量 ............................................103
原則89 編寫可自上而下閱讀的程序 .............................104
原則90 避免副作用 ........................................................105
原則91 使用有意義的命名 ............................................106
原則92 程序首先是寫給人看的 .....................................107
原則93 使用#優的數據結構 ........................................108
原則94 先確保正確，再提升性能 .................................109
原則95 在寫完代碼之前寫註釋 .....................................110
原則96 先寫文檔後寫代碼 ............................................111
原則97 手動運行每個組件 ............................................112
原則98 代碼審查 ...........................................................113
原則99 你可以使用非結構化的語言 .............................114
原則100 結構化的代碼未必是好的代碼 .......................115
原則101 不要嵌套太深 ..................................................116
原則102 使用合適的語言 ..............................................117
原則103 編程語言不是藉口 ..........................................118
原則104 編程語言的知識沒那麼重要 ...........................119
原則105 格式化你的代碼 ..............................................120
原則106 不要太早編碼 ..................................................121

第6章 測試原則 ....................................................................... 123
原則107 依據需求跟踪測試 ..........................................124
原則108 在測試之前早做測試計劃 ...............................125
原則109 不要測試自己開發的軟件 ...............................126
原則110 不要為自己的軟件做測試計劃 .......................127
原則111 測試只能揭示缺陷的存在 ...............................128
原則112 雖然大量的錯誤可證明軟件毫無價值，但是零錯誤並不能說明軟件的價值 ................129
原則113 成功的測試應發現錯誤 ...................................130
原則114 半數的錯誤出現在15%的模塊中 ...................131
原則115 使用黑盒測試和白盒測試 ...............................132
原則116 測試用例應包含期望的結果 ...........................133
原則117 測試不正確的輸入 ..........................................134
原則118 壓力測試必不可少 ..........................................135
原則119 大爆#炸理論不適用 ..........................................136
原則120 使用 McCabe 複雜度指標 ............................137
原則121 使用有效的測試完成度標準 ...........................138
原則122 達成有效的測試覆蓋 ......................................139
原則123 不要在單元測試之前集成 ...............................140
原則124 測量你的軟件 ..................................................141
原則125 分析錯誤的原因 ..............................................142
原則126 對“錯”不對人 ..............................................143

第7章 管理原則 ....................................................................... 145
原則127 好的管理比好的技術更重要 ...........................146
原則128 使用恰當的方法 ..............................................147
原則129 不要相信你讀到的一切 ...................................148
原則130 理解客戶的優先級 ..........................................149
原則131 人是成功的關鍵 ..............................................150
原則132 幾個好手要強過很多生手 ...............................151
原則133 傾聽你的員工 ..................................................152
原則134 信任你的員工 ..................................................153
原則135 期望優秀 .........................................................154
原則136 溝通技巧是必要的 ..........................................155
原則137 端茶送水 .........................................................156
原則138 人們的動機是不同的 ......................................157
原則139 讓辦公室保持安靜 ..........................................158
原則140 人和時間是不可互換的 ...................................159
原則141 軟件工程師之間存在巨大的差異 ....................160
原則142 你可以優化任何你想要優化的 .......................161
原則143 隱蔽地收集數據 ..............................................162
原則144 每行代碼的成本是沒用的 ...............................163
原則145 衡量開發效率沒有完#美的方法 .......................164
原則146 剪裁成本估算方法 ..........................................165
原則147 不要設定不切實際的截止時間 .......................166
原則148 避免不可能 ......................................................167
原則149 估之前先要了解 ..........................................168
原則150 收集生產力數據 ..............................................169
原則151 不要忘記團隊效率 ..........................................170
原則152 LOC/PM與語言無關 .......................................171
原則153 相信排期 .........................................................172
原則154 精確的成本估算並不是萬無一失的 ................173
原則155 定期重新評估排期 ..........................................174
原則156 輕微的低估不總是壞事 ...................................175
原則157 分配合適的資源 .

.............................................176
原則158 制訂詳細的項目計劃 ......................................177
原則159 及時更新你的計劃 ..........................................178
原則160 避免駐波 .........................................................179
原則161 知曉十大風險 ..................................................180
原則162 預先了解風險 ..................................................181
原則163 使用適當的流程模型 ......................................182
原則164 方法無法挽救你 ..............................................183
原則165 沒有奇蹟般提升效率的秘密 ...........................184
原則166 了解進度的含義 ..............................................185
原則167 按差異管理 ......................................................186
原則168 不要過度使用你的硬件 ...................................187
原則169 對硬件的演化要樂觀 ......................................188
原則170 對軟件的進化要悲觀 ......................................189
原則171 認為災難是不可能的想法往往導致災難 ........190
原則172 做項目總結 ......................................................191
第8章 產品保證原則 ................................................................ 193
原則173 產品保證並不是奢#侈品 ...................................194
原則174 儘早建立軟件配置管理過程 ...........................195
原則175 使軟件配置管理適應軟件過程 .......................196
原則176 組織SCM獨立於項目管理 .............................197
原則177 輪換人員到產品保證組織 ...............................198
原則178 給所有中間產品一個名稱和版本 ....................199
原則179 控制基準 .........................................................200
原則180 保存所有內容 ..................................................201
原則181 跟踪每一個變更 ..............................................202
原則182 不要繞過變更控制 ..........................................203
原則183 對變更請求進行分級和排期 ...........................204
原則184 在大型開發項目中使用確認和驗證（V&V） ....205

第9章 演變原則 ....................................................................... 207
原則185 軟件會持續變化 ..............................................208
原則186 軟件的熵增加 ..................................................209
原則187 如果沒有壞，就不要修理它 ...........................210
原則188 解決問題，而不是症狀 ...................................211
原則189 先變更需求 ......................................................212
原則190 發布之前的錯誤也會在發布之後出現 ............213
原則191 一個程序越老，維護起來越困難 ....................214
原則192 語言影響可維護性 ..........................................215
原則193 有時重新開始會更好 ......................................216
原則194 首先翻新#差的 ..............................................217
原則195 維護階段比開發階段產生的錯誤更多 ............218
原則196 每次變更後都要進行回歸測試 .......................219
原則197 “變更很容易”的想法，會使變更更容易出錯 .........................................................220
原則198 對非結構化代碼進行結構化改造，並不一定會使它更好 ..............................................221
原則199 在優化前先進行性能分析 ...............................222
原則200 保持熟悉 .........................................................223
原則201 系統的存在促進了演變 ...................................224

參考資料索引 ............................................................................... 225
術語索引....................................................................................... 235