编程调试改错优化PPT课件下载推荐.ppt

编程调试改错优化PPT课件下载推荐.ppt

《编程调试改错优化PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《编程调试改错优化PPT课件下载推荐.ppt（16页珍藏版）》请在冰豆网上搜索。

u如果开发组长认为开发小组需要接受编程、测试、代码审查等方面的培训，那么由开发组长安排相应的培训。

2.2制定计划制定计划u软件实现阶段的一些计划中，编程计划最重要，是主线，代码审查计划和测试计划可以根据编程计划推演出来。

这些计划可以合并成一个软件实现计划，当然也可以分开写。

u编程计划应当根据产品的功能特征和开发人员的技能来制定。

假设一个系统由N个模块组成，每个模块又分前台和后台两部分。

有些人可能擅长开发前台程序，有些人可能擅长开发后台程序，还有些人对前台和后台程序的熟练程度差不多。

开发组长要充分了解组员的技能优缺点，让他们扬长避短，而不是平均分配任务。

Page52.软件实现的准备工作软件实现的准备工作2.3制定编程规范制定编程规范u如果没有统一的编程规范，放任程序员按照自己的风格编程的话，那么代码风格将五花八门，可能潜伏许多Bug，即使没有Bug也让别人难以理解。

u编程规范的主要用途是统一编程风格、提高代码质量，是给已经懂得编程的人用的，所以不要把编程规范写成入门教科书。

Internet上有许多公开的C+、Java编程规范，人们根据企业的需求适当裁剪就可以了，不必彻头彻尾地自己撰写。

u一般地，编程规范应当覆盖以下主题：

文件版式、命名规则、基本语句、函数设计、内存管理、错误处理等等u通常每个主题都有若干的规则、建议和示例，其中“规则”是必须要遵守的，“建议”不是强制的但是推荐采用的，“示例”用来解释“规则”和“建议”。

u公司制定编程规范后，应当马上组织程序员们学习，促使大家按照该规范编写应用程序，逐步形成统一的风格。

千万不可让编程规范成为一种摆设。

Page62.软件实现的准备工作软件实现的准备工作2.4技术预研技术预研u在软件开发过程中，技术问题可能会层出不穷。

如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。

u一般说来，在遭遇到了技术障碍之后才匆忙地去攻克问题，其代价通常比较高。

因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。

最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统的话，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。

u技术预研是指对项目将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。

u技术预研不同于真正地开发产品，投入人员与时间相对比较少，主要步骤如下：

项目经理或技术负责人识别项目中的技术难题，指定技术人员攻克该问题。

技术攻关人员制定简要的计划，设定技术预研的内容和目标，预计应递交的工作成果，制定进度表。

按照计划进行技术攻关。

在任务结束时，技术攻关人员撰写技术攻关报告，并向相关人员介绍工作成果。

Page73.对编程的建议对编程的建议3.1尽可能采用成熟可靠的技术尽可能采用成熟可靠的技术u人们开发软件是为了满足客户的需求，而不是自己闹着玩或者追求技术挑战。

为了提高质量、提高开发效率并且降低成本，我们应当尽可能采用成熟可靠的技术来开发软件。

u软件复用体现了这种思想，正被越来越多的企业倡导。

据统计，世上已有一千多亿行程序，无数功能被重写了成千上万次，真是浪费啊！

面向对象学者呼吁“请不要再发明相同的车轮子了”。

u不要急于从零开始编程，应当先调查是否有现成的程序库可以使用（可能要花钱去买也可能是免费的）？

除非是没有现成的程序或者现成的程序不符合应用要求，我们再自己编写程序，这样省时省力，何乐而不为呢？

u在编程的时候尽量少用技巧。

技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。

若在程序中使用太多的技巧，可能会留下错误隐患，别人也难以理解。

一个局部的优点对整个系统而言是微小的，而一个错误则可能对整个系统是致命的。

因此建议用自然的方式编程，不要滥用技巧。

Page83.对编程的建议对编程的建议3.2对所有代码进行单步跟踪调试对所有代码进行单步跟踪调试u大多数程序员有这样的习惯，如果程序通过了编译和连接，他就认为程序基本上没有问题了，就交给别人测试，等到别人发现Bug后自己才去调试改错。

uSteveMaguire在其著作WritingCleanCode中极力提倡程序员应当养成“对代码进行单步跟踪调试”的习惯。

即当程序员编写完成一个和几个相关程序之后，不必等别人测试，自己马上对代码进行单步跟踪调试。

单步跟踪调试能够发现数据溢出、内存泄漏、野指针等仅靠黑盒测试难以察觉的Bug，无疑大大地提高了程序的质量和开发、测试效率。

u但遗憾的是，大多数程序员觉得“单步跟踪调试”太花费时间，不值得这样做。

理由是：

程序中正确的代码远比错误的代码多，单步跟踪调试简直就是大海捞针，还不如等别人发现Bug后再改错来得方便。

u假设我们设计和编写200行C+代码要花费一天时间（8小时），那么对这200行代码进行单步跟踪调试大约会花费10分钟。

这10分钟的单步跟踪调试不会让我们很劳累，它带来的好处是：

（1）减少了后继的测试和改错代价（远远不止10分钟的工作量）；

（2）让你对自己的程序更有信心，不再为未知的Bug提心吊胆，日子过得更加快乐。

u所以程序员朋友们，不要拒绝单步跟踪调试了。

Page93.对编程的建议对编程的建议3.3及时写编程日记及时写编程日记u随时随地记录你在工作中遇到的问题，以及你产生的灵感。

不要等到将来再靠回忆来写总结，那时候你可能想不起来了，岂非浪费了一笔“财富”？

u程序员每天应该写一份简短的工作日记，花几分钟就行了。

很多程序员觉得他们的光荣任务就是开发软件，写工作日记很费时间很烦人。

整个团队都写工作日记不仅对个人有好处，而且有利于项目的管理。

如果这些工作日记保存在数据库里，那么管理者会对各人的工作进展一目了然。

如果大家还没有写工作日记的习惯，项目经理就强迫大家写，用不了几天就习惯了。

3.4对代码进行配置管理对代码进行配置管理u曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及，工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：

我要你。

如果非得加一个期限的话，我希望是一辈子。

配置管理忏悔录u人们每天将产生许多代码，而且会不断地修改代码。

如果不使用配置管理工具对源代码进行版本管理的话，人们在同一个文件上修改程序，保存之后，那么新的程序覆盖了老的程序。

如果发现新程序是错误的，而老程序却是对的，可是老程序被新程序覆盖了，再也无法恢复。

怎么办呢？

只好重新写老程序再覆盖新程序，这种做法是很落后的。

程序员不对源代码进行版本管理那是自寻烦恼。

Page103.对编程的建议对编程的建议3.5正常作息正常作息u编程和调试有这样的特点，干活要一鼓作气完成，不要中途停下来做其它事情之后再接着编程调试，否则思路丢失，重新捡起来很费劲。

所以程序员经常在夜里干活，这样效率比较高。

据说真正的程序员不会在上午9:

00到下午5:

00之间工作，如果你看到他在上午9:

00工作，这表明他从昨晚一直干到现在。

u我在读大学的10年里有8年是当程序员，通宵编程是家常便饭（有时化20个小时追踪算法错误），曾经引以为豪。

现在反思，觉得很不值得，因为夜里干活白天睡觉的生活很不正常，天长日久绝对伤害身体健康。

u我曾经给一个软件公司讲课，建议程序员要学一点养生之道，席间有个程序员大发感叹：

我的大学专业不是计算机，很少编程，毕业后到公司当程序员，很兴奋，工作两年来经常熬夜干活。

你看我现在脸色发青，毛孔粗大，背有点弯了，时不时腰椎发痛。

我以后再也不熬夜干活了。

u只要你是程序员，总是有写不完的程序，抓不尽的Bug，就让我们以平常心对待程序和Bug，过正常人的生活吧。

Page114.内部测试与代码审查内部测试与代码审查4.1内部测试内部测试u一般地，软件实现阶段的单元测试和集成测试都在开发小组内部开展，因为这样效率最高并且节约人力资源。

（软件测试将在其它专题论述，这里省略）对于严格系统，开发人员编写完成某个程序之后，先进行单步跟踪调试，然后请同伴进行代码审查和内部测试。

对于非严格系统，那么代码审查和内部测试的力度可以适当减弱一些。

如果发现缺陷，则记录在缺陷跟踪工具中，开发者应当及时修正程序，消除缺陷。

4.2代码审查代码审查u代码审查通常在开发人员之间开展，用眼睛检查代码是否符合编程规范。

为什么有了软件测试，还要代码审查呢？

u因为代码审查有一些独到的优点，可以弥补软件测试的不足：

（1）软件测试不能发现代码风格不统一的问题，而代码审查则很容易做到；

（2）有经验的人可以一目十行地审查代码，很快就能抓住一些Bug（主要是常见的Bug）。

u开发小组在执行代码审查之前要制定“代码审查表”，从编程规范中提取最重要的规则最重要的规则。

u为了提高代码审查效率，检查者不必给每一个检查项填写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。

Page125.调试改错的方法调试改错的方法5.1主动主动u改错是个大悲大喜的过程，一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏。

u软件中的错误通常只有开发者自己才能找出并改掉。

如果因畏惧而拖延，会让你终日心情不定，食无味，睡不香。

所以长痛不如短痛，要集中精力对付错误5.2对症下药对症下药u改错的第一步是找出错误的根源，如同医生治病，必须先找出病因才能“对症下药”。

改错过程很像侦破案件，我们必须从结果出发，逆向思考。

一旦找到了根源，我们就知道如何改正了。

u根据软件错误的症状推断出根源并不是件容易的事，因为：

症状和根源可能相隔很远症状可能在另一个错误被纠正后暂时性消失症状可能并不是由某个程序错误直接引发的，如误差累积。

症状可能时隐时现，如内存泄漏。

很难重新产生完全一样的输入条件，难以恢复“错误的现场”。

症状可能分布在许多不同的任务中，难以跟踪。

u人们把寻找错误根源的过程称为调试（debugging）。

Page135.调试改错的方法调试改错的方法5.3“神奇神奇”的硬件调试改错方法的硬件调试改错方法u据说硬件调试改错继承了中医的“望闻听切”诊断方法：

（1）望，即用眼睛查看哪些地方是否有破损。

（2）闻，即用鼻子闻哪些地方是否有烧焦的味道。

（3）听，即用耳朵听哪些地方是否有异常的噪声。

（4）切，即用手触摸哪些地方是否异常发烫。

u据有经验的电器修理工说，“望闻听切”这4招能解决大部分问题。

5.4软件调试软件调试u软件调试的基本方法是“粗分细找”。

对于隐藏得很深的Bug，我们应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围