微软开发成功之路.pptVIP

微软开发者成功之路 (之一) 概 要 目标：编写高质量的代码 ----正确对待Bug ----游戏规则 ----编程技巧 ----资源和工具 听众对象 ----软件管理和开发人员 设计稳定可靠的产品级代码 正确对待Bug 什么是Bug？ Bug：影响客户正常使用产品的任何问题 ----钢中的杂质 注意：----客户是上帝----因您的产品让上帝心情不好，您就。。。----客户的功能规范会产生Bug----产品中没有明确功能规范的部分会产生bug 为什么关注Bug？ Bug的危害----降低产品质量----让您无法预计和控制产品发布日期----损害团队的积极性----损害未来的产品 开发的效率图 Bug的来源 项目期限的压力 产品的复杂度 沟通不良 开发人员的疲劳、压力或受到干扰 缺乏足够的知识、技能和经验 不了解客户的需求 缺乏动力 Bug是正常的—再好的钢也不是100%纯 怎样减少Bug？ 开发中为质量工作留足时间 越简单越好 改善沟通（团队内部、团队与客户） 重视和避免开发人员的疲劳、压力或受到干扰 增加知识、技能和经验 了解您的客户 把项目质量与个人利益挂钩 树立正确的bug观 设计稳定可靠的产品级代码 游戏规则 游戏规则—本章概要 在程序设计上倾注心血 照顾到代码的方方面面 在您的产品或功能“完成”之前发现和解决bug 设计稳定可靠的产品级代码：面临的挑战 确保钢炼完之前自己不要掉到高炉里 设计：需要完整的功能规范 功能规范----从客户的角度描述问题----不需要描述实现方法 审阅功能规范----以客户情景来理解用户的视角----发现并解决问题----越具体越好----写出初步的功能设计文档 功能设计文档 强迫你在动手编程之前找出并解决难题--避免编程中的不确定因素--避免编程中忘记重要的客户要求--避免做无用工--加快编程速度 帮助你制作进度表 帮助其他开发人员为你提供建议和参考 为你的代码提供注释 功能设计文档？ 描述数据结构和接口 发现并解决难题 了解所有不需要做的事 使用检查清单或者设计文档模板 简单的做法：列出你所知道的和不知道的 正式的做法：使用MSDN Universal版中的UML工具 设计：拿来主义 首先考虑借用现成代码--“拿来主义”是提高工作效率的最有效办法* 节省时间* 提高质量--拿来主义的方式* 可执行文件（DLLS，libraries）* 源程序代码* 算法* 架构* 用户界面 拿来主义（继续） 哪里有可以借用的代码？--你当前或以前开发的项目中--系统调用--标准的代码库（CRT，STL）--其他项目 可能带来的问题--需要时间来集成--拿来的代码质量低下--拿来的代码不完全符合需要--给开发带来不确定因素 设计：编写开发者测试计划 在编程开始之前编写测试计划--编程时会考虑到测试的要求--铁面无私：测试要求不随编程而改变--可以避免敷衍测试的行为 测试计划需要考虑：--用户情景--输入和输出--边界情况--可能出现的错误--功能之间的集成和连接 照顾到代码的方方面面 好的代码是简洁、可读和一丝不苟的 建议双程序员合作制度 编程中进行不断的测试 使用编程技巧 使用工具 好代码：简洁 设计清晰、无误解的接口和对象 使用简单的算法和流程--避免模糊、隐藏、难懂、好玩和偷懒--把过长和身兼多职的函数细分为多个 不要为改善性能而盲目地改动程序--先做性能测试（benchmark and profile）--对症下药；只修改会影响性能的部分 避免编写不必要的代码 好代码：可读 让注释有用并容易维持 使用统一的编程标准---有助于改善程序员之间的沟通---定义编程标准文档 * 包含命名、格式，以及需要遵守和避免的原则 * 采用标准比标准如何定义更重要 好代码：一丝不苟 处理所有出错状况 检查所有返回值 严整所有外部参数 吃透你要实现的函数调用--你的假设是什么？正确吗？--杜绝“走一步看一步”--尽可能多了解你的功能和项目 * 客户和功能规范 * 架构和代码设计 * 开发环境（团队，规范，软硬件） 好代码：双程序员合作制度 一个和尚挑水吃，两个和尚抬水吃--集中精力，提高质量--互相验证对方的假设--弥补对方考虑的盲点--提供Code Review（代码审阅）--对现有代码特别有效 好代码：编程过程中的测试 在测试环境下走过所有新代码--在每个代码块中设断点--到达断点并验证代码块后，清除改断点 立即对每个功能的可测试部分做测试 设计和实现中都要考虑可测试性