编程调试改错优化PPT课件

软件实现 编程 调试改错 优化林锐博士linrui 上海漫索计算机科技有限公司 目录 1 软件实现的流程2 准备工作3 对编程的建议4 内部测试与代码审查5 调试改错的方法6 完善性工作 1 软件实现的流程 1 1概念软件实现 SoftwareImplementation 不等同于纯粹的编程 它是 编程 内部测试 代码审查 调试改错 优化 的综合表述 软件实现是人员最多 时间最长 工作量最大的开发阶段 对于现代软件开发而言 超级程序员不再是法宝了 正是因为软件实现阶段 人多 活儿多 问题更多 天生就有混乱倾向 因此必须制定软件实现的规范 让所有人员都按照规范执行 才可能顺利地完成任务 1 2流程图 2 软件实现的准备工作 2 1准备什么开发小组制定计划 包括编程计划 代码审查计划 测试计划等 项目经理审批该计划 开发小组确定编程 代码审查 内部测试等规范 如果机构已经存在相应的规范 则采用之 如果机构不存在相应的规范 则由开发小组制定 开发小组构建编程与测试环境 例如安装软件开发工具 包括可复用库 配置管理工具 软件测试工具和缺陷跟踪工具等等 如果是异地开发和测试 那么要构建Internet环境 如果开发组长认为开发小组需要接受编程 测试 代码审查等方面的培训 那么由开发组长安排相应的培训 2 2制定计划软件实现阶段的一些计划中 编程计划最重要 是主线 代码审查计划和测试计划可以根据编程计划推演出来 这些计划可以合并成一个 软件实现计划 当然也可以分开写 编程计划应当根据产品的功能特征和开发人员的技能来制定 假设一个系统由N个模块组成 每个模块又分前台和后台两部分 有些人可能擅长开发前台程序 有些人可能擅长开发后台程序 还有些人对前台和后台程序的熟练程度差不多 开发组长要充分了解组员的技能优缺点 让他们扬长避短 而不是平均分配任务 2 软件实现的准备工作 2 3制定编程规范如果没有统一的编程规范 放任程序员按照自己的风格编程的话 那么代码风格将五花八门 可能潜伏许多Bug 即使没有Bug也让别人难以理解 编程规范的主要用途是统一编程风格 提高代码质量 是给已经懂得编程的人用的 所以不要把编程规范写成入门教科书 Internet上有许多公开的C Java编程规范 人们根据企业的需求适当裁剪就可以了 不必彻头彻尾地自己撰写 一般地 编程规范应当覆盖以下主题 文件版式 命名规则 基本语句 函数设计 内存管理 错误处理等等通常每个主题都有若干的规则 建议和示例 其中 规则 是必须要遵守的 建议 不是强制的但是推荐采用的 示例 用来解释 规则 和 建议 公司制定编程规范后 应当马上组织程序员们学习 促使大家按照该规范编写应用程序 逐步形成统一的风格 千万不可让编程规范成为一种摆设 2 软件实现的准备工作 2 4技术预研在软件开发过程中 技术问题可能会层出不穷 如果一点技术障碍都没有遇到 要么是开发人员的技术水平实在太高了 要么是项目的技术含量实在太低了 这类情况比较少见 一般说来 在遭遇到了技术障碍之后才匆忙地去攻克问题 其代价通常比较高 因为其他人的工作可能会被阻塞 已经投入的不少资源将被闲置 最糟糕的是 如果此技术障碍无法攻克 不得已要改变技术方案 重新设计系统的话 那么不仅浪费了人力 财力 时间 处理不好还会使开发队伍陷入混乱状态 技术预研是指对项目将采用的关键技术提前学习和研究 以便尽可能早地发现并解决开发过程中将会遇到的技术障碍 技术预研不同于真正地开发产品 投入人员与时间相对比较少 主要步骤如下 项目经理或技术负责人识别项目中的技术难题 指定技术人员攻克该问题 技术攻关人员制定简要的计划 设定技术预研的内容和目标 预计应递交的工作成果 制定进度表 按照计划进行技术攻关 在任务结束时 技术攻关人员撰写 技术攻关报告 并向相关人员介绍工作成果 3 对编程的建议 3 1尽可能采用成熟可靠的技术人们开发软件是为了满足客户的需求 而不是自己闹着玩或者追求技术挑战 为了提高质量 提高开发效率并且降低成本 我们应当尽可能采用成熟可靠的技术来开发软件 软件复用体现了这种思想 正被越来越多的企业倡导 据统计 世上已有一千多亿行程序 无数功能被重写了成千上万次 真是浪费啊 面向对象学者呼吁 请不要再发明相同的车轮子了 不要急于从零开始编程 应当先调查是否有现成的程序库可以使用 可能要花钱去买也可能是免费的 除非是没有现成的程序或者现成的程序不符合应用要求 我们再自己编写程序 这样省时省力 何乐而不为呢 在编程的时候尽量少用技巧 技巧的优点在于能另辟蹊径地解决一些问题 缺点是技巧并不为人熟知 若在程序中使用太多的技巧 可能会留下错误隐患 别人也难以理解 一个局部的优点对整个系统而言是微小的 而一个错误则可能对整个系统是致命的 因此建议用自然的方式编程 不要滥用技巧 3 对编程的建议 3 2对所有代码进行单步跟踪调试大多数程序员有这样的习惯 如果程序通过了编译和连接 他就认为程序基本上没有问题了 就交给别人测试 等到别人发现Bug后自己才去调试改错 SteveMaguire在其著作 WritingCleanCode 中极力提倡程序员应当养成 对代码进行单步跟踪调试 的习惯 即当程序员编写完成一个和几个相关程序之后 不必等别人测试 自己马上对代码进行单步跟踪调试 单步跟踪调试能够发现数据溢出 内存泄漏 野指针等仅靠黑盒测试难以察觉的Bug 无疑大大地提高了程序的质量和开发 测试效率 但遗憾的是 大多数程序员觉得 单步跟踪调试 太花费时间 不值得这样做 理由是 程序中正确的代码远比错误的代码多 单步跟踪调试简直就是大海捞针 还不如等别人发现Bug后再改错来得方便 假设我们设计和编写200行C 代码要花费一天时间 8小时 那么对这200行代码进行单步跟踪调试大约会花费10分钟 这10分钟的单步跟踪调试不会让我们很劳累 它带来的好处是 1 减少了后继的测试和改错代价 远远不止10分钟的工作量 2 让你对自己的程序更有信心 不再为未知的Bug提心吊胆 日子过得更加快乐 所以程序员朋友们 不要拒绝单步跟踪调试了 3 对编程的建议 3 3及时写编程日记随时随地记录你在工作中遇到的问题 以及你产生的灵感 不要等到将来再靠回忆来写总结 那时候你可能想不起来了 岂非浪费了一笔 财富 程序员每天应该写一份简短的工作日记 花几分钟就行了 很多程序员觉得他们的光荣任务就是开发软件 写工作日记很费时间很烦人 整个团队都写工作日记不仅对个人有好处 而且有利于项目的管理 如果这些工作日记保存在数据库里 那么管理者会对各人的工作进展一目了然 如果大家还没有写工作日记的习惯 项目经理就强迫大家写 用不了几天就习惯了 3 4对代码进行配置管理曾经有一个很好的配置管理工具在我面前 我没有理睬 直到版本混乱的时候才后悔莫及 工作中最大的痛苦莫过于此 如果上天再给我一次机会的话 我向对它说三个字 我要你 如果非得加一个期限的话 我希望是一辈子 配置管理忏悔录人们每天将产生许多代码 而且会不断地修改代码 如果不使用配置管理工具对源代码进行版本管理的话 人们在同一个文件上修改程序 保存之后 那么新的程序覆盖了老的程序 如果发现新程序是错误的 而老程序却是对的 可是老程序被新程序覆盖了 再也无法恢复 怎么办呢 只好重新写老程序再覆盖新程序 这种做法是很落后的 程序员不对源代码进行版本管理那是自寻烦恼 3 对编程的建议 3 5正常作息编程和调试有这样的特点 干活要一鼓作气完成 不要中途停下来做其它事情之后再接着编程调试 否则思路丢失 重新捡起来很费劲 所以程序员经常在夜里干活 这样效率比较高 据说真正的程序员不会在上午9 00到下午5 00之间工作 如果你看到他在上午9 00工作 这表明他从昨晚一直干到现在 我在读大学的10年里有8年是当程序员 通宵编程是家常便饭 有时化20个小时追踪算法错误 曾经引以为豪 现在反思 觉得很不值得 因为夜里干活白天睡觉的生活很不正常 天长日久绝对伤害身体健康 我曾经给一个软件公司讲课 建议程序员要学一点养生之道 席间有个程序员大发感叹 我的大学专业不是计算机 很少编程 毕业后到公司当程序员 很兴奋 工作两年来经常熬夜干活 你看我现在脸色发青 毛孔粗大 背有点弯了 时不时腰椎发痛 我以后再也不熬夜干活了 只要你是程序员 总是有写不完的程序 抓不尽的Bug 就让我们以平常心对待程序和Bug 过正常人的生活吧 4 内部测试与代码审查 4 1内部测试一般地 软件实现阶段的单元测试和集成测试都在开发小组内部开展 因为这样效率最高并且节约人力资源 软件测试将在其它专题论述 这里省略 对于严格系统 开发人员编写完成某个程序之后 先进行单步跟踪调试 然后请同伴进行代码审查和内部测试 对于非严格系统 那么代码审查和内部测试的力度可以适当减弱一些 如果发现缺陷 则记录在缺陷跟踪工具中 开发者应当及时修正程序 消除缺陷 4 2代码审查代码审查通常在开发人员之间开展 用眼睛检查代码是否符合编程规范 为什么有了软件测试 还要代码审查呢 因为代码审查有一些独到的优点 可以弥补软件测试的不足 1 软件测试不能发现代码风格不统一的问题 而代码审查则很容易做到 2 有经验的人可以一目十行地审查代码 很快就能抓住一些Bug 主要是常见的Bug 开发小组在执行代码审查之前要制定 代码审查表 从编程规范中提取最重要的规则 为了提高代码审查效率 检查者不必给每一个检查项填写结论 凡是正确的就跳过去 仅仅记录缺陷就行了 5 调试改错的方法 5 1主动改错是个大悲大喜的过程 一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏 软件中的错误通常只有开发者自己才能找出并改掉 如果因畏惧而拖延 会让你终日心情不定 食无味 睡不香 所以长痛不如短痛 要集中精力对付错误5 2对症下药改错的第一步是找出错误的根源 如同医生治病 必须先找出病因才能 对症下药 改错过程很像侦破案件 我们必须从结果出发 逆向思考 一旦找到了根源 我们就知道如何改正了 根据软件错误的症状推断出根源并不是件容易的事 因为 症状和根源可能相隔很远症状可能在另一个错误被纠正后暂时性消失症状可能并不是由某个程序错误直接引发的 如误差累积 症状可能时隐时现 如内存泄漏 很难重新产生完全一样的输入条件 难以恢复 错误的现场 症状可能分布在许多不同的任务中 难以跟踪 人们把寻找错误根源的过程称为调试 debugging 5 调试改错的方法 5 3 神奇 的硬件调试改错方法据说硬件调试改错继承了中医的 望闻听切 诊断方法 1 望 即用眼睛查看哪些地方是否有破损 2 闻 即用鼻子闻哪些地方是否有烧焦的味道 3 听 即用耳朵听哪些地方是否有异常的噪声 4 切 即用手触摸哪些地方是否异常发烫 据有经验的电器修理工说 望闻听切 这4招能解决大部分问题 5 4软件调试软件调试的基本方法是 粗分细找 对于隐藏得很深的Bug 我们应该运用归纳 推理 二分 等方法先 快速 粗略 地确定错误根源的范围 然后再用调试工具仔细地跟踪此范围的源代码 如果没有调试工具 那么只好用 土办法 在程序中插入打印语句如printf 观看屏幕的输出 有些时候 世界上最好的调试工具恐怕是那些有经验的人 我们经常会长时间地追踪某个Bug 苦恼万分 恰好有高手路过 被他一语 道破天机 顿时沮丧的阴云就被驱散 故事 通常软件改错要比硬件改错的代价低得多 因为后者经常抛弃原来的东西 故事 5 调试改错的方法 5 5修改代码错误的注意事项找到错误的代码时 不要急于修改 先思考一下 修改此代码会不会引发其它问题 如果没有问题 可以放心修改 如果有问题 那么可能要改动程序结构 而不止一行代码 有些时候 软件中可能潜伏同一类型的许多错误 例如由不良的编程习惯引起的 好不容易逮住一个 应当乘胜追击 全部歼灭 在改错之后一定要马上进行回归测试 以免引入新的错误 改了一个程序错误固然是喜事 但要防止乐极生悲 更加严格的要求是 不论原先程序是否绝对正确 只要对此程序作过改动 哪怕是微不足道的 都要进行回归测试 上述事情做完后 应当好好反思 我为什么会犯这样的错误 怎么能够防止下次不犯相似的错误 最好能写下心得体会 与他人共享经验教训 6 完善性工作 6 1优化软件的优化是指优化软件的各个质量属性 如提高运行速度 提高对内存资源的利用率 使用户界面更加友好等等 想做好优化工作 首先要让开发人员都有正确的认识 优化工作不是可有可无的事情 而是必须要做的事情 当优化工作成为一种责任时 开发人员才会不断改进软件中的数据结构 算法和程序 从而提高软件质量 优化工作的复杂之处是很多目标之间存在千丝万缕的关系 可谓数不清理还乱 当不能够使所有的目标都得到优化时 就需要 折衷 折衷 是指协调各个质量属性 实现整体质量的最优 软件折衷的重要原则是不能使某一方损失关键的功能 更不可以像 舍鱼而取熊掌 那样抛弃一方 人都有惰性 如果允许滥用折衷的话 那么一旦碰到困难 人们就会用拆东墙补西墙的方式去折衷 不再下苦功去做有意义的优化 折衷原则 在保证其他质量属性不差的前提下 使某些重要质量属性变得更好 6 完善性工作