|
關于我們
 書單推薦 新書推薦 |
軟件開發(fā)的201個原則（必讀經(jīng)典簡裝本） 
定 價：76 元
9 7 4 8 4 7 4 1 6 2 6 1 1 讀者對象:本書面向的讀者包括軟件工程師和管理者、軟件工程專業(yè)的學生、軟件工程領域的研發(fā)人員等。 
軟件工程是一門工程學科，是對經(jīng)過驗證的原則、技術、語言和工具的智慧的運用，用于有成本效益的創(chuàng)造和維護能夠滿足用戶需求的軟件。 本書匯總了軟件工程原則，對于軟件研發(fā)中的主要思想，以一系列分類原則的方式，給出了總結。原則是關于軟件工程的基本原理、規(guī)則或結論，不管所選的技術、工具或語言是什么，這些原則都有效。 全書共9章，第1章為引言，后面8章將201個軟件工程的原則劃分為8個大的類別：一般原則、需求工程原則、設計原則、編碼原則、測試原則、管理原則、產(chǎn)品保證原則和演變原則。
Alan M. Davis是一名計算機科學家（伊利諾伊大學厄巴納-香檳分校計算機科學博士），他的職業(yè)生涯大約有一半在工業(yè)界，一半在學術界。他在工業(yè)界的經(jīng)歷包括：1.Offtoa公司的聯(lián)合創(chuàng)始人兼首席執(zhí)行官，這是一家?guī)椭髽I(yè)家制定商業(yè)戰(zhàn)略的互聯(lián)網(wǎng)公司（2012年至今）。2. Omni-Vista公司的聯(lián)合創(chuàng)始人、董事長兼首席執(zhí)行官，這是一家位于科羅拉多斯普林斯的軟件公司（1998—2002）。3. Requisite公司的董事會創(chuàng)始成員，被Rational Software收購，后來被IBM收購（1995—1997）。4. BTG公司副總裁，該公司位于弗吉尼亞州，于1995年上市，被Titan收購，隨后被L-3 Communications收購（1984—1991）。5. 亞利桑那州鳳凰城GTE通信系統(tǒng)的研發(fā)總監(jiān)（1983—1984）。6. 馬薩諸塞州沃爾瑟姆GTE實驗室的軟件工程師、項目經(jīng)理、部門經(jīng)理和軟件技術總監(jiān)（1977—1983）。7. 位于科羅拉多斯普林斯的天使俱樂部High Altitude Investors（HAI）的選舉委員會成員（2008—2015）。8. 催化劑信息技術發(fā)展基金（Catalyst InfoTech Development Fund）的非管理普通合伙人和有限合伙人。催化劑信息技術發(fā)展基金是科羅拉多州的一個小型風險投資基金（1995—2002）。他在學術界的經(jīng)歷包括：9. 位于丹佛的科羅拉多大學行政MBA創(chuàng)業(yè)教授，前任學術主席（2006—2018）。10. 科羅拉多大學斯普林斯分校的商業(yè)策略與企業(yè)家精神專業(yè)的教授，前El Pomar軟件工程教授（1991—2015）。11. 曾在澳大利亞、印度尼西亞、尼日利亞、南非和西班牙等國家擔任教職。
本書譯者均為百度公司員工，同時也是參加百度培訓項目“代碼的藝術訓練營”的學員，他們是：葉王、馬學翔、吳斌、王冰清、楊光、曾浩浩、李殿斌、甘璐、李子昂、肖遠昊、賈儒、王瑩、張苗、李雙婕、榮文升。
第1章 引言 ................................................................................... 3
第2章 一般原則 ........................................................................... 7 原則1 質(zhì)量第一 ................................................................. 8 原則2 質(zhì)量在每個人眼中都不同 ....................................... 9 原則3 開發(fā)效率和質(zhì)量密不可分 .....................................10 原則4 高質(zhì)量軟件是可以實現(xiàn)的 .....................................11 原則5 不要試圖通過改進軟件實現(xiàn)高質(zhì)量 ......................12 原則6 低可靠性比低效率更糟糕 .....................................13 原則7 盡早把產(chǎn)品交給客戶.............................................14 原則8 與客戶/用戶溝通 ...................................................15 原則9 促使開發(fā)者與客戶的目標一致 .............................16 原則10 做好拋棄的準備 ..................................................17 原則11 開發(fā)正確的原型 ..................................................18 原則12 構建合適功能的原型 ..........................................19 原則13 要快速地開發(fā)一次性原型 ...................................20 原則14 漸進地擴展系統(tǒng) ..................................................21 原則15 看到越多，需要越多 ..........................................22 原則16 開發(fā)過程中的變化是不可避免的 ........................23 原則17 只要可能，購買而非開發(fā) ...................................24 原則18 讓軟件只需簡短的用戶手冊 ...............................25 原則19 每個復雜問題都有一個解決方案 ........................26 原則20 記錄你的假設 ......................................................27 原則21 不同的階段，使用不同的語言 ...........................28 原則22 技術優(yōu)先于工具 ..................................................29 原則23 使用工具，但要務實 ..........................................30 原則24 把工具交給優(yōu)秀的工程師 ...................................31 原則25 CASE工具是昂貴的 ...........................................32 原則26 “知道何時”和“知道如何”同樣重要 ............33 原則27 實現(xiàn)目標就停止 ..................................................34 原則28 了解形式化方法 ..................................................35 原則29 和組織榮辱與共 ..................................................36 原則30 跟風要小心 ..........................................................37 原則31 不要忽視技術 ......................................................38 原則32 使用文檔標準 ......................................................39 原則33 文檔要有術語表 ..................................................40 原則34 軟件文檔都要有索引 ..........................................41 原則35 對相同的概念用相同的名字 ...............................42 原則36 研究再轉(zhuǎn)化，不可行 ..........................................43 原則37 要承擔責任 ..........................................................44 第3章 需求工程原則 .................................................................. 47 原則38 低質(zhì)量的需求分析，導致低質(zhì)量的成本估算 .....48 原則39 先確定問題，再寫需求 .......................................49 原則40 立即確定需求 ......................................................50 原則41 立即修復需求規(guī)格說明中的錯誤 ........................51 原則42 原型可降低選擇用戶界面的風險 ........................52 原則43 記錄需求為什么被引入 .......................................53 原則44 確定子集 .............................................................54 原則45 評審需求 .............................................................55 原則46 避免在需求分析時進行系統(tǒng)設計 ........................56 原則47 使用正確的方法 ..................................................57 原則48 使用多角度的需求視圖 .......................................58 原則49 合理地組織需求 ..................................................59 原則50 給需求排列優(yōu)先級 ..............................................60 原則51 書寫要簡潔 ..........................................................61 原則52 給每個需求單獨編號 ..........................................62 原則53 減少需求中的歧義 ..............................................63 原則54 對自然語言輔助增強，而非替換 ........................64 原則55 在更形式化的模型前，先寫自然語言 ................65 原則56 保持需求規(guī)格說明的可讀性 ...............................66 原則57 明確規(guī)定可靠性 ..................................................67 原則58 應明確環(huán)境超出“可接受”時的系統(tǒng)行為 ........68 原則59 自毀的待定項 ......................................................69 原則60 將需求保存到數(shù)據(jù)庫 ..........................................70 第4章 設計原則 ......................................................................... 73 原則61 從需求到設計的轉(zhuǎn)換并不容易 ...........................74 原則62 將設計追溯至需求 ..............................................75 原則63 評估備選方案 ......................................................76 原則64 沒有文檔的設計不是設計 ...................................77 原則65 封裝 .....................................................................78 原則66 不要重復造輪子 ..................................................79 原則67 保持簡單 .............................................................80 原則68 避免大量的特殊案例 ..........................................81 原則69 縮小智力距離 ......................................................82 原則70 將設計置于知識控制之下 ...................................83 原則71 保持概念一致 ......................................................84 原則72 概念性錯誤比語法錯誤更嚴重 ...........................85 原則73 使用耦合和內(nèi)聚 ..................................................86 原則74 為變化而設計 ......................................................87 原則75 為維護而設計 ......................................................88 原則76 為防備出現(xiàn)錯誤而設計 .......................................89 原則77 在軟件中植入通用性 ..........................................90 原則78 在軟件中植入靈活性 ..........................................91 原則79 使用高效的算法 ..................................................92 原則80 模塊規(guī)格說明只提供用戶需要的所有信息 ........93 原則81 設計是多維的 ......................................................94 原則82 優(yōu)秀的設計出自優(yōu)秀的設計師 ...........................95 原則83 理解你的應用場景 ..............................................96 原則84 無須太多投資，即可實現(xiàn)復用 ...........................97 原則85 “錯進錯出”是不正確的 ...................................98 原則86 軟件可靠性可以通過冗余來實現(xiàn) ........................99 第5章 編碼原則 ....................................................................... 101 原則87 避免使用特殊技巧 ............................................102 原則88 避免使用全局變量 ............................................103 原則89 編寫可自上而下閱讀的程序 .............................104 原則90 避免副作用 ........................................................105 原則91 使用有意義的命名 ............................................106 原則92 程序首先是寫給人看的 .....................................107 原則93 使用最優(yōu)的數(shù)據(jù)結構 ........................................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 依據(jù)需求跟蹤測試 ..........................................124 原則108 在測試之前早做測試計劃 ...............................125 原則109 不要測試自己開發(fā)的軟件 ...............................126 原則110 不要為自己的軟件做測試計劃 .......................127 原則111 測試只能揭示缺陷的存在 ...............................128 原則112 雖然大量的錯誤可證明軟件毫無價值， 但是零錯誤并不能說明軟件的價值 ................129 原則113 成功的測試應發(fā)現(xiàn)錯誤 ...................................130 原則114 半數(shù)的錯誤出現(xiàn)在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 使用恰當?shù)姆椒?..............................................147 原則129 不要相信你讀到的一切 ...................................148 原則130 理解客戶的優(yōu)先級 ..........................................149 原則131 人是成功的關鍵 ..............................................150 原則132 幾個好手要強過很多生手 ...............................151 原則133 傾聽你的員工 ..................................................152 原則134 信任你的員工 ..................................................153 原則135 期望優(yōu)秀 .........................................................154 原則136 溝通技巧是必要的 ..........................................155 原則137 端茶送水 .........................................................156 原則138 人們的動機是不同的 ......................................157 原則139 讓辦公室保持安靜 ..........................................158 原則140 人和時間是不可互換的 ...................................159 原則141 軟件工程師之間存在巨大的差異 ....................160 原則142 你可以優(yōu)化任何你想要優(yōu)化的 .......................161 原則143 隱蔽地收集數(shù)據(jù) ..............................................162 原則144 每行代碼的成本是沒用的 ...............................163 原則145 衡量開發(fā)效率沒有完美的方法 .......................164 原則146 剪裁成本估算方法 ..........................................165 原則147 不要設定不切實際的截止時間 .......................166 原則148 避免不可能 ......................................................167 原則149 評估之前先要了解 ..........................................168 原則150 收集生產(chǎn)力數(shù)據(jù) ..............................................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 使用適當?shù)牧鞒棠Ｐ?......................................182 原則164 方法無法挽救你 ..............................................183 原則165 沒有奇跡般提升效率的秘密 ...........................184 原則166 了解進度的含義 ..............................................185 原則167 按差異管理 ......................................................186 原則168 不要過度使用你的硬件 ...................................187 原則169 對硬件的演化要樂觀 ......................................188 原則170 對軟件的進化要悲觀 ......................................189 原則171 認為災難是不可能的想法往往導致災難 ........190 原則172 做項目總結 ......................................................191 第8章 產(chǎn)品保證原則 ................................................................ 193 原則173 產(chǎn)品保證并不是奢侈品 ...................................194 原則174 盡早建立軟件配置管理過程 ...........................195 原則175 使軟件配置管理適應軟件過程 .......................196 原則176 組織SCM獨立于項目管理 .............................197 原則177 輪換人員到產(chǎn)品保證組織 ...............................198 原則178 給所有中間產(chǎn)品一個名稱和版本 ....................199 原則179 控制基準 .........................................................200 原則180 保存所有內(nèi)容 ..................................................201 原則181 跟蹤每一個變更 ..............................................202 原則182 不要繞過變更控制 ..........................................203 原則183 對變更請求進行分級和排期 ...........................204 原則184 在大型開發(fā)項目中使用確認和驗證（V＆V） ....205 第9章 演變原則 ....................................................................... 207 原則185 軟件會持續(xù)變化 ..............................................208 原則186 軟件的熵增加 ..................................................209 原則187 如果沒有壞，就不要修理它 ...........................210 原則188 解決問題，而不是癥狀 ...................................211 原則189 先變更需求 ......................................................212 原則190 發(fā)布之前的錯誤也會在發(fā)布之后出現(xiàn) ............213 原則191 一個程序越老，維護起來越困難 ....................214 原則192 語言影響可維護性 ..........................................215 原則193 有時重新開始會更好 ......................................216 原則194 首先翻新最差的 ..............................................217 原則195 維護階段比開發(fā)階段產(chǎn)生的錯誤更多 ............218 原則196 每次變更后都要進行回歸測試 .......................219 原則197 “變更很容易”的想法，會使變更更 容易出錯 .........................................................220 原則198 對非結構化代碼進行結構化改造，并不 一定會使它更好 ..............................................221 原則199 在優(yōu)化前先進行性能分析 ...............................222 原則200 保持熟悉 .........................................................223 原則201 系統(tǒng)的存在促進了演變 ...................................224 參考資料索引 ............................................................................... 225
你還可能感興趣
我要評論
|
