网易 
新闻 LOFTER 邮箱 相册 阅读 图书 有道 摄影 企业邮箱 优惠券 云笔记 闪电邮 邮箱大师 印像派 考拉海购
 
更多
博客 
手机博客 博客搬家 博客VIP服务 发现 小组 风格
 
群博客 博客油菜地 博客话题 博客热点 博客圈子 找朋友
 
登录  
 加关注
   显示下一条  |  关闭
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

导航

 
 
 
 
 

日志

 
 
关于我
秒大刀
文章分类
 
 

读《代码大全2》第5部分 代码改善  

2009-12-24 18:34:37|  分类： 读书 |  标签： |举报 |字号大中小 订阅

  下载LOFTER 我的照片书  |

全部书摘参见 读《代码大全2》

第5部分 代码改善
第20章 软件质量概述
  1. 要让所有的特性都表现的尽善尽美是绝无可能的，需要根据一组互相竞争的目标寻找出一套优化的解决方案，正是这种情况使软件开发成为一个真正的工程学科。
  2. 有效管理变更是实现高质量的一个关键
  3. 程序员有很高的成就激励：他们会向明确的目标进发，但必须有人告诉他们目标是什么
  4. 不同目标之间可能是有冲突的，并且软件通常不可能在所有方面都做的很好
  5. 缺陷检测率：
  6. 检错措施 最低检出率(%)              典型检出率(%)              最高检出率(%)             
    非正式设计复查 25 35 40
    正式设计检查 45 55 65
    非正式代码复查 20 25 35
    正式代码检查 45 60 70
    建立模型或原型 35 65 80
    个人桌面代码检查 20 40 60
    单元测试 15 30 50
    新功能(组件)测试 20 30 35
    集成测试 25 35 40
    回归测试 15 25 30
    系统测试 25 40 55
    小规模Beta测试(小于10人参与) 25 35 40
    大规模Beta测试(大于1000人参与)              60 75 85
  7. 以上表格数据说明：
    1. 单独使用任何一个方法，其典型检出率都没有超过75%，平均来说仅在40%左右。
    2. 最常见的缺陷检测方法——单元测试和集成测试，一般检测率仅仅在30%到35%之间
    3. 借助大规模测试来检测缺陷也仅仅能达到85%左右（业界的平均缺陷检出率）
    4. 采取使用范围更广泛的更多方法才能够火的95%以上的检出率
  8. 不同的人可能找出不同的缺陷，群体测试中只有20%的bug被不同的人重复检出
  9. 阅读代码每小时能够检测出的缺陷要比测试高出80%左右，使用测试来检测缺陷的成本是检查的6倍。
  10. IBM：检查发现一个错误需要3.5h，而测试则需要15~25h
  11. MS：采用代码检查发现bug并修正的一步到位方法，一个错误需要3h，而通过测试然后再修正的两布方法需要花费12h
  12. 一个由超过400名程序员创建的70w行代码的程序中，代码复查的投资回报比为1.38，而测试的投资回报比仅为0.17
  13. 推荐的质量控制阵容：
    1. 对所有的需求、架构及系统关键部分的设计进行正式检查
    2. 建模或者创建原型
    3. 代码阅读或者检查(review)
    4. 执行测试
  14. 效果最明显的缩短开发周期的办法就是改善产品的质量，由此减少花费在调试和软件返工上面的时间总量
  15. 更多的质量保证工作能降低错误率，但不会增加开发的总成本
  16. 既不是最快的，也不是最慢的开发方法开发出的软件缺陷最多。最慢的开发时间大约是最快开发时间的5倍，但缺陷率却不相上下。编写无缺陷的软件可能让我们花费更少的时间。
  17. Key Points
    1. 开发高质量代码最终并没有要求你付出更多，只是你需要对资源进行重新分配，以低廉的成本来防止缺陷出现，从而避免代价高昂的修正工作。
    2. 并非所有的质量保证目标都可以全部实现。明确哪些目标是你希望达到的，并就这些目标和团队成员进行沟通
    3. 没有任何一种错误检测方法能够解决全部的问题，测试本身不是排除错误的最有效方法。成功的质量保证计划应该使用多种不同的技术来检查各种不同类型的错误。
    4. 在构建期间应当使用一些有效的质量保证技术，但在这之前，一些具有同样强大功能的质量保证技术也是必不可少的。错误发现越早，它与其余代码的纠缠就越少，由此造成的损失也越小
    5. 软件领域的质量保证是面向过程的。软件开发与制造业一样，在这里并不存在会影响最终产品的重复的阶段，因此，最终产品的质量受到开发软件所用的过程的控制


第21章 协同构建
  1. 协同构建——包括结对编程、正式检查、非正式技术复查、文档阅读，以及其他让开发人员共同承担创建代码及其他工作产品责任的技术。
  2. 设计过程中开发人员平均每小时引入1~3个缺陷，编码阶段平均每小时引入5~8个缺陷
  3. 全程结对编程的成本会比单人开发高10%~25%，但开发周期大约会缩短45%
  4. 代码复查可以快速地将所有开发者的水平提升到最优秀的开发者的高度
  5. 成功运行结对编程的关键：
    1. 用编码规范来支持结对编程
    2. 不要让结对编程变成旁观
    3. 不要强迫在简单的问题上使用结对编程
    4. 有规律的对结对人员和分配的工作任务进行轮换
    5. 鼓励双方跟上对方的步伐
    6. 确认两个人都能够看到显示器
    7. 不要强迫程序员与自己关系紧张的人组队
    8. 避免新手组合
    9. 指定一个组长
  6. 任何新的方法论都需要事实来证明它存在的必要性
  7. 采用定量分析，确定新方案比现行的更有效后再去真正实施。
  8. 承认一个批评并不意味着认同批评的内容
  9. 源码阅读每小时可发现3.3个缺陷，测试每小时仅可发现1.8个错误
  10. Key Points：
    1. 协同开发实践往往能比测试发现更多的缺陷，并且更有效率
    2. 协同开发实践所发现错误的类型通常跟测试所发现的不同，这意味着你需要同时使用详查和测试来保证你软件的质量
    3. 正式检查通过运用核查表、准备工作、明确定义的角色以及对方法的持续改善，将缺陷侦测的效率提升至最高。它往往能比走查发现更多的缺陷。
    4. 通常，结对编程拥有和详查相同的成本，并能产生质量相当的代码。当需要缩短开发周期的时候，结对编程就非常有价值。相对于单独工作来说，有些开发人员更喜欢结对工作。
    5. 正式检查可以应用在除代码之外的很多工作成果上，例如需求、设计以及测试用例等。
    6. 走查和代码阅读是详查的替代方案。代码阅读更富有弹性，能有效的利用每个人的时间。


第22章 开发者测试
  1. 首先写测试用例可以将从引入缺陷到发现并排除缺陷之间的时间缩减至最短
    1. 在开始写代码之前先写测试用例，并不比之后再写要多花工夫，只是调整了下测试用例编写活动的工作顺序而已
    2. 加入你首先编写测试用例，那么你将可以更早的发现缺陷，同时也更容易修正它们
    3. 首先编写测试用例，将迫使你在开始写代码之前至少思考一下需求和设计，而这往往会催生更高质量的代码
    4. 在编写代码之前先编写测试用例，能更早的把需求上的问题暴露出来，因为对于一个糟糕的需求来说，要写出测试用例是一件困难的事情
    5. 如果你保存了最初编写的测试用例——这是你应该做的，那么闲进行测试并非唯一选择，你仍然可以最后再进行测试。
  2. 测试先行的编程是过去十年中所形成的最有用的软件开发实践之一，同时也是一个非常好的通用方法。
  3. 数据使用的出错率至少不亚于控制流
  4. 80%的错误存在于项目20%的类或者子程序当中
  5. 50%的错误被发现存在于项目5%的类当中
  6. 项目中20%的子程序占用了80%的开发成本，但这20%的代码并不一定就是bug最多的那部分代码
  7. 提高质量就能缩短开发周期，同时降低开发成本
  8. 开发高质量的软件比开发低质量软件然后修正成本要低廉
  9. 如果你无法重复，那么就不可能改善
  10. Key Points：
    1. 开发人员测试是完整测试策略的一个关键部分。独立测试也很重要。
    2. 同编码之后编写测试用例相比较，编码开始之前编写测试用例，工作量和花费的时间差不多，但是后者可以缩短缺陷-侦测-调试-修正这一周期。
    3. 即使考虑到了各种可用的测试手段，测试仍然只是良好软件质量计划的一部分。高质量的开发方法至少和测试一样重要，这包括尽可能减少需求和设计阶段的缺陷。在检测错误方面，协同开发的成效至少与测试相当。这些方法所检测错误的类型也各不相同。
    4. 你可以根据各种不同的思路来产生很多测试用例，这些思路包括基础测试、数据流分析、边界分析、错误数据类型以及正确数据类型等。你还可以通过猜测错误的方式得到更多的测试用例。
    5. 错误往往集中在少数几个容易出错的类和子程序上。找出这部分代码，重新设计和编写它们。
    6. 测试数据本身出错的密度往往比被测试代码还要高。查找这种错误完全是浪费时间，又不能对代码有所改善，因此测试数据里面的错误更加让人烦恼。要像写代码一样下小心的开发测试用例，也是进行回归测试的基础。
    7. 自动化测试总体来说是很有用的，也是进行回归测试的基础。
    8. 从长远来看，改善测试过程的最好办法就是将其规范化，并对其进行评估，然后用从评估中获得的经验教训来改善这个过程。

第23章 调试
  1. 如果一个错误无法重现，这通常会是一个初始化错误，或者是一个同时间有关的问题，或者是悬野指针问题。
  2. 如果你大全通过捷径摘取胜利果实，那么请为你尝试捷径的时间设置一个上限。
  3. 程序员在第一次对缺陷进行修正的时候，有超过50%的几率出错
  4. 匆忙动手解决问题是你所能做的最低效的事情之一了
  5. 休息足够长的时间能让你肯定自己的解决方案是对的。不要受到所谓捷径的诱惑。休息一下或许会让你花掉更多的时间，但在多数情况下，你为问题所付出的成本会更少。
  6. 人们看到的是他们所希望看到的东西
  7. 某种工具可能被错误的使用，但这并不表示这种工具应该被抛弃
  8. Key Points
    1. 调试同整个软件开发的成败息息相关。最好的解决之道是避免缺陷的产生。然而，花点时间来提高自己的调试技能还是很划算的，因为优秀和拙劣的调试表现之间的差距至是10:1
    2. 要想成功，系统化的查找和改正错误的方法至关重要。要专注于你的调试工作，让每一次调试都能让你朝着正确的方向前进一步。要使用科学的调试方法。
    3. 在动手解决问题之前，要理解问题的根本。胡乱猜测错误的来源和随机修改将会让你的程序陷入比刚开始调试时更为糟糕的境地。
    4. 将编译器警告级别设置为最严格，把警告信息所报告的错误都改正。如果你忽略了明显的错误，那么要改正那些微妙的错误就会非常麻烦。
    5. 调试工具对软件开发而言是强有力的支持手段。找出这些工具并加以应用，当然，请记得在调试的时候开动脑筋。

第24章 重构
  1. 软件演化就像生物进化一样，有些突变对物种是有益的，另外一些则是有害的。
  2. 重构——在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改。
  3. 宁可让代码因较强的封装而出错，也不要减弱封装
  4. 只要看到某个子程序名优问题，就应该立刻着手修改
  5. 不要为拙劣的代码编写文档——应该重写代码
  6. 早期修订阶段是提升代码质量的最佳时机
  7. 超前设计整体效应就是拖了项目的后腿
  8. 对未来需求有所准备的办法并不是去编写空中楼阁式的代码，而是尽可能将满足当前需求的代码清晰直白的表现出来，使未来的程序员理解这些代码完成了什么功能，没有完成什么功能，从而根据他们的需求进行修改。
  9. 对于有一定风险的重构，谨慎才能避免出错。务必一次只处理一项重构。除了完成通常要做的编译检查和单元测试之外，还应该让其他人来检查你的重构工作，或是针对重构采用结对编程。
  10. Key Points：
    1. 修改是程序一声都要面对的事情，不仅包括最初的开发阶段，还包括首次发布之后
    2. 在修改中软件的质量要么改进，要么恶化。软件演化的首要法则就是代码演化应当提升程序的内在质量
    3. 重构成功之关键在于程序员应当学会关注那些标志着代码需要重构的众多的警告或“代码臭味”
    4. 重构成功的另一要素是程序员应当掌握大量特定的重构方法
    5. 重构成功的最后要点在于要有安全重构的策略。一些重构方法会比其他重构方法要好
    6. 开发阶段的重构是提升程序质量的最佳时机，因为你可以立刻让刚刚产生的改变梦想变成现实。请珍惜这些开发阶段的天赐良机！

第25章 代码调整策略
  1. 对用户来说，程序员按时交付软件，提供一个清爽的用户界面，避免系统死机常常比程序的性能更为重要
  2. 性能不一定代表的是程序的运行速度，往往是吞吐量、响应或某种表现
  3. 在花费时间处理一个性能为题之前，请想清楚你的确是在解决一个确实需要解决的问题。
  4. 有时，最经济也是最有效的提升程序性能的方法就是购买新的硬件设备。
  5. 高效的代码不一定就是“更好”的代码
  6. The best is the enemy of the good. 完美是优良之大敌。
  7. 不成熟优化的主要缺陷在于它缺乏前瞻性。过早的优化会对软件的整体质量产生严重的威胁，甚至包括软件的性能。
  8. Key Points：
    1. 性能只是软件整体质量的一个方面，通常不是最重要的。精细的代码调整也只是实现整体性能的一种方法，通常也不是决定性的。相对于代码本身的效率而言，程序的架构、细节设计以及数据结构和算法选择对程序的运行速度和资源占用的影响通常会更大。
    2. 定量测量是实现性能最优化的关键。定量测量需要找出能真正决定程序性能的部分，在修改之后，应当通过重复测量来明确修改是提高还是降低了软件的性能。
    3. 绝大多数的程序都有那么一小部分代码耗费了绝大部分的运行时间。如果没有测量，你不会知道是那一部分代码。
    4. 代码调整需要反复尝试，这样才能获得理想的性能提高。
    5. 为性能优化工作做好准备的最佳方式就是在最初阶段编写清晰的代码，从而使代码在后续工作中易于理解和修改。

第26章 代码调整技术
  1. Key Points：
    1. 优化结果在不同的语言、编译器和环境下有很大差异。如果没有对每一次的优化进行测量，你将无法判断优化到底是帮助还是损害了这个程序。
    2. 第一次优化通常不是最好的。即使找到了效果很不错的，也不要停下来扩大战果的步伐。
    3. 代码调整这一话题有点类似于核能，赋予争议，甚至会让人冲动。一些人认为代码调整损害了代码可读性和可维护性，他们绝对会将其弃之不用。其他人则认为只要有适当的安全保障，代码调整对程序是有益的。如果你决定使用代码调整，请务必谨慎行事。
  评论这张
 
阅读(1295)| 评论(0)

历史上的今天

评论

<#--最新日志，群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇，下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

我的照片书 - 手机博客 - 下载LOFTER APP - 订阅此博客

网易公司版权所有 ©1997-2018