编程调试改错优化

1、软件实现 编程、调试改错、优化 上 海 漫 索 计 算 机 科 技 有 限 公 司目录1. 软件实现的流程2. 准备工作 3. 对编程的建议4. 内部测试与代码审查5. 调试改错的方法6. 完善性工作 1. 软件实现的流程1.1 概念 软件实现（Software Implementation）不等同于纯粹的编程，它是“编程、内部测试、代码审查、调试改错、优化”的综合表述。软件实现是人员最多、时间最长、工作量最大的开发阶段。 对于现代软件开发而言，超级程序员不再是法宝了。正是因为软件实现阶段“人多、活儿多、问题更多”，天生就有混乱倾向，因此必须制定软件实现的规范，让所有人员都按照规范执行，才可能

2、顺利地完成任务。 1.2 流程图2. 软件实现的准备工作 2.1 准备什么开发小组制定计划（包括编程计划、代码审查计划、测试计划等），项目经理审批该计划。 开发小组确定编程、代码审查、内部测试等规范。如果机构已经存在相应的规范，则采用之。如果机构不存在相应的规范，则由开发小组制定。 开发小组构建编程与测试环境，例如安装软件开发工具（包括可复用库）、配置管理工具、软件测试工具和缺陷跟踪工具等等。如果是异地开发和测试，那么要构建Internet环境。如果开发组长认为开发小组需要接受编程、测试、代码审查等方面的培训，那么由开发组长安排相应的培训。 2.2 制定计划软件实现阶段的一些计划中，编程计划最

3、重要，是主线，代码审查计划和测试计划可以根据编程计划推演出来。这些计划可以合并成一个软件实现计划，当然也可以分开写。 编程计划应当根据产品的功能特征和开发人员的技能来制定。假设一个系统由N个模块组成，每个模块又分前台和后台两部分。有些人可能擅长开发前台程序，有些人可能擅长开发后台程序，还有些人对前台和后台程序的熟练程度差不多。开发组长要充分了解组员的技能优缺点，让他们扬长避短，而不是平均分配任务。 2. 软件实现的准备工作 2.3 制定编程规范如果没有统一的编程规范，放任程序员按照自己的风格编程的话，那么代码风格将五花八门，可能潜伏许多Bug，即使没有Bug也让别人难以理解。 编程规范的主要用

4、途是统一编程风格、提高代码质量，是给已经懂得编程的人用的，所以不要把编程规范写成入门教科书。Internet上有许多公开的C+、Java编程规范，人们根据企业的需求适当裁剪就可以了，不必彻头彻尾地自己撰写。 一般地，编程规范应当覆盖以下主题：文件版式、命名规则、基本语句、函数设计、内存管理、错误处理 等等 通常每个主题都有若干的规则、建议和示例，其中“规则”是必须要遵守的，“建议”不是强制的但是推荐采用的，“示例”用来解释“规则”和“建议”。 公司制定编程规范后，应当马上组织程序员们学习，促使大家按照该规范编写应用程序，逐步形成统一的风格。千万不可让编程规范成为一种摆设。 2. 软件实现的准备

5、工作 2.4 技术预研在软件开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。 一般说来，在遭遇到了技术障碍之后才匆忙地去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统的话，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。 技术预研是指对项目将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。技术预研不同于真正地开发产品，投入人员与时

6、间相对比较少，主要步骤如下： 项目经理或技术负责人识别项目中的技术难题，指定技术人员攻克该问题。 技术攻关人员制定简要的计划，设定技术预研的内容和目标，预计应递交的工作成果，制定进度表。 按照计划进行技术攻关。在任务结束时，技术攻关人员撰写技术攻关报告，并向相关人员介绍工作成果。 3. 对编程的建议3.1 尽可能采用成熟可靠的技术 人们开发软件是为了满足客户的需求，而不是自己闹着玩或者追求技术挑战。为了提高质量、提高开发效率并且降低成本，我们应当尽可能采用成熟可靠的技术来开发软件。软件复用体现了这种思想，正被越来越多的企业倡导。据统计，世上已有一千多亿行程序，无数功能被重写了成千上万次，真是浪

7、费啊！面向对象学者呼吁“请不要再发明相同的车轮子了”。 不要急于从零开始编程，应当先调查是否有现成的程序库可以使用（可能要花钱去买也可能是免费的）？除非是没有现成的程序或者现成的程序不符合应用要求，我们再自己编写程序，这样省时省力，何乐而不为呢？ 在编程的时候尽量少用技巧。技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中使用太多的技巧，可能会留下错误隐患，别人也难以理解。一个局部的优点对整个系统而言是微小的，而一个错误则可能对整个系统是致命的。因此建议用自然的方式编程，不要滥用技巧。 3. 对编程的建议3.2 对所有代码进行单步跟踪调试大多数程序员有这样的习惯，如果程

8、序通过了编译和连接，他就认为程序基本上没有问题了，就交给别人测试，等到别人发现Bug后自己才去调试改错。 Steve Maguire在其著作Writing Clean Code中极力提倡程序员应当养成“对代码进行单步跟踪调试”的习惯。即当程序员编写完成一个和几个相关程序之后，不必等别人测试，自己马上对代码进行单步跟踪调试。 单步跟踪调试能够发现数据溢出、内存泄漏、野指针等仅靠黑盒测试难以察觉的Bug，无疑大大地提高了程序的质量和开发、测试效率。 但遗憾的是，大多数程序员觉得“单步跟踪调试”太花费时间，不值得这样做。理由是：程序中正确的代码远比错误的代码多，单步跟踪调试简直就是大海捞针，还不如等

9、别人发现Bug后再改错来得方便。 假设我们设计和编写200行C+代码要花费一天时间（8小时），那么对这200行代码进行单步跟踪调试大约会花费10分钟。这10分钟的单步跟踪调试不会让我们很劳累，它带来的好处是：（1）减少了后继的测试和改错代价（远远不止10分钟的工作量）；（2）让你对自己的程序更有信心，不再为未知的Bug提心吊胆，日子过得更加快乐。所以程序员朋友们，不要拒绝单步跟踪调试了。 3. 对编程的建议3.3 及时写编程日记随时随地记录你在工作中遇到的问题，以及你产生的灵感。不要等到将来再靠回忆来写总结，那时候你可能想不起来了，岂非浪费了一笔“财富”？ 程序员每天应该写一份简短的工作日记，

10、花几分钟就行了。很多程序员觉得他们的光荣任务就是开发软件，写工作日记很费时间很烦人。整个团队都写工作日记不仅对个人有好处，而且有利于项目的管理。如果这些工作日记保存在数据库里，那么管理者会对各人的工作进展一目了然。如果大家还没有写工作日记的习惯，项目经理就强迫大家写，用不了几天就习惯了。 3.4 对代码进行配置管理曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及，工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：我要你。如果非得加一个期限的话，我希望是一辈子。 配置管理忏悔录人们每天将产生许多代码，而且会不断地修改代码。如果不使用配置管理工具

11、对源代码进行版本管理的话，人们在同一个文件上修改程序，保存之后，那么新的程序覆盖了老的程序。如果发现新程序是错误的，而老程序却是对的，可是老程序被新程序覆盖了，再也无法恢复。怎么办呢？只好重新写老程序再覆盖新程序，这种做法是很落后的。程序员不对源代码进行版本管理那是自寻烦恼。 3. 对编程的建议3.5 正常作息编程和调试有这样的特点，干活要一鼓作气完成，不要中途停下来做其它事情之后再接着编程调试，否则思路丢失，重新捡起来很费劲。所以程序员经常在夜里干活，这样效率比较高。 据说真正的程序员不会在上午9:00到下午5:00之间工作，如果你看到他在上午9:00工作，这表明他从昨晚一直干到现在。 我在

12、读大学的10年里有8年是当程序员，通宵编程是家常便饭（有时化20个小时追踪算法错误 ） ，曾经引以为豪。现在反思，觉得很不值得，因为夜里干活白天睡觉的生活很不正常，天长日久绝对伤害身体健康。 我曾经给一个软件公司讲课，建议程序员要学一点养生之道，席间有个程序员大发感叹：我的大学专业不是计算机，很少编程，毕业后到公司当程序员，很兴奋，工作两年来经常熬夜干活。你看我现在脸色发青，毛孔粗大，背有点弯了，时不时腰椎发痛。我以后再也不熬夜干活了。 只要你是程序员，总是有写不完的程序，抓不尽的Bug，就让我们以平常心对待程序和Bug，过正常人的生活吧。 4. 内部测试与代码审查4.1 内部测试一般地，软件

13、实现阶段的单元测试和集成测试都在开发小组内部开展，因为这样效率最高并且节约人力资源。（软件测试将在其它专题论述，这里省略） 对于严格系统，开发人员编写完成某个程序之后，先进行单步跟踪调试，然后请同伴进行代码审查和内部测试。 对于非严格系统，那么代码审查和内部测试的力度可以适当减弱一些。 如果发现缺陷，则记录在缺陷跟踪工具中，开发者应当及时修正程序，消除缺陷。 4.2 代码审查代码审查通常在开发人员之间开展，用眼睛检查代码是否符合编程规范。为什么有了软件测试，还要代码审查呢？因为代码审查有一些独到的优点，可以弥补软件测试的不足：（1）软件测试不能发现代码风格不统一的问题，而代码审查则很容易做到；

14、（2）有经验的人可以一目十行地审查代码，很快就能抓住一些Bug（主要是常见的Bug）。开发小组在执行代码审查之前要制定“代码审查表”，从编程规范中提取最重要的规则。 为了提高代码审查效率，检查者不必给每一个检查项填写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。 5. 调试改错的方法5.1 主动改错是个大悲大喜的过程，一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏。软件中的错误通常只有开发者自己才能找出并改掉。如果因畏惧而拖延，会让你终日心情不定，食无味，睡不香。所以长痛不如短痛，要集中精力对付错误 5.2 对症下药 改错的第一步是找出错误的根源，如同医生治病，必须先找出病因才能“对症下

15、药”。改错过程很像侦破案件，我们必须从结果出发，逆向思考。一旦找到了根源，我们就知道如何改正了。 根据软件错误的症状推断出根源并不是件容易的事，因为：症状和根源可能相隔很远 症状可能在另一个错误被纠正后暂时性消失 症状可能并不是由某个程序错误直接引发的，如误差累积。 症状可能时隐时现，如内存泄漏。 很难重新产生完全一样的输入条件，难以恢复“错误的现场”。 症状可能分布在许多不同的任务中，难以跟踪。 人们把寻找错误根源的过程称为调试（debugging）。 5.调试改错的方法5.3 “神奇”的硬件调试改错方法据说硬件调试改错继承了中医的“望闻听切”诊断方法： （1）望，即用眼睛查看哪些地方是否有

16、破损。（2）闻，即用鼻子闻哪些地方是否有烧焦的味道。（3）听，即用耳朵听哪些地方是否有异常的噪声。（4）切，即用手触摸哪些地方是否异常发烫。 据有经验的电器修理工说，“望闻听切”这4招能解决大部分问题。 5.4 软件调试软件调试的基本方法是“粗分细找”。对于隐藏得很深的Bug，我们应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。如果没有调试工具，那么只好用“土办法”：在程序中插入打印语句如printf()，观看屏幕的输出。有些时候，世界上最好的调试工具恐怕是那些有经验的人。我们经常会长时间地追踪某个Bug，苦恼万分。恰好有高手路

17、过，被他一语“道破天机”，顿时沮丧的阴云就被驱散。（故事） 通常软件改错要比硬件改错的代价低得多，因为后者经常抛弃原来的东西。（故事） 5.调试改错的方法5.5 修改代码错误的注意事项找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？如果没有问题，可以放心修改。如果有问题，那么可能要改动程序结构，而不止一行代码。 有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。好不容易逮住一个，应当乘胜追击，全部歼灭。 在改错之后一定要马上进行回归测试，以免引入新的错误。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原先程序是否绝对正确，

18、只要对此程序作过改动（哪怕是微不足道的），都要进行回归测试。 上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。 6. 完善性工作 6.1 优化软件的优化是指优化软件的各个质量属性，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好等等。想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。当优化工作成为一种责任时，开发人员才会不断改进软件中的数据结构、算法和程序，从而提高软件质量。优化工作的复杂之处是很多目标之间存在千丝万缕的关系，可谓数不清理还乱。当不能够使所有的目标都得到优化时，就需要“折衷”。 “折衷”是指协调各个质量属性，实现整体质量的最优。软件折衷的重要原则是不能使某一方损失关键的功能，更不可以像“舍鱼而取熊掌”那样抛弃一方。人都有惰性，如果允许滥用折衷的话，那么一旦碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。折衷原则：在保证其他质量属性不差的前提下，使某些重要质量属性变得更好。 6. 完善性