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