前沿讲座心得体会

北京邮电大学软件学院 前沿课题讲座心得体会 报告人： 学号： 导师： （日期：2015 年 1 月 20 日） 在北京邮电大学软件学院学习期间，我积极参加学校组织的前沿课题讲座 和各大企业举办的新技术讲座，下边分几个方面谈一谈对敏捷开发、自动化测 试、大数据讲座的体会： 一、敏捷开发 最近一段时间以来，很多人开始谈论敏捷开发、研究敏捷开发，那么究竟 什么才是敏捷开发呢? 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在 敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过 测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联 系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用 状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团 队具有快速工作、响应变化能力的价值观和原则，并于 2001 初成立了敏捷联盟。 他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 敏捷开发(agile development)概念从 2004 年初开始广为流行。Bailar 非常支 持这一理论，他采取了“敏捷方式 “组建团队：Capital One 的“ 敏捷团队“包括 3 名业务人员、两名操作人员和 57 名 IT 人员，其中包括 1 个业务信息指导(实 际上是业务部门和 IT 部门之间的 “翻译者“);另外，还有一个由项目经理和至少 80 名开发人员组成的团队。这些开发人员都曾被 Bailar 送去参加过“ 敏捷开发“ 的培训，具备相关的技能。 每个团队都有自己的敏捷指导(Bailar 聘用了 20 个敏捷指导 )，他的工作是 关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详 细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合 作，开发有规律地停顿-在 9 周开发过程中停顿 34 次，以评估过程及决定需 求变更是否必要。在 Capital One，大的 IT 项目会被拆分成多个子项目，安排给 各“ 敏捷团队“ ，这种方式在 “敏捷开发“中叫“ 蜂巢式 (swarming)“，所有过程由一 名项目经理控制。 为了检验这个系统的效果，Bailar 将项目拆分，从旧的“ 瀑布式“开发转变为 “并列式“ 开发，形成了 “敏捷开发“所倡导的精干而灵活的开发团队，并将开发 阶段分成 30 天一个周期，进行“冲刺“-每个冲刺始于一个启动会议，到下个冲 刺前结束。 在 Bailar 将其与传统的开发方式做了对比后，他感到非常兴奋-“敏捷开发“ 使开发时间减少了 30%40%，有时甚至接近 50%，提高了交付产品的质量。“ 不过，有些需求不能用敏捷开发来处理。“ Bailar 承认，“敏捷开发“也有局限性， 比如对那些不明确、优先权不清楚的需求或处于“ 较快、较便宜、较优“ 的三角 架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则 的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事， 但经过阵痛之后，需求处理流程会让 CIO 受益匪浅。 二、敏捷开发模式内容 Test-Driven Development，测试驱动开发，它是敏捷开发的最重要的部分。 在 ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分 析，分解为一个一个的 Story，记录在 Story Card 上。然后两个人同时坐在电脑 前面，一个人依照 Story，从业务需求的角度来编写测试代码，另一个人看着他 并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样 写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编 写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写 测试代码，能够让开发人员明确目标，就是让测试通过。 Continuous Integration，持续集成。在以往的软件开发过程中，集成是一件 很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题， 比如 build 未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成 十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一 次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情 呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元测 试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些 其它的任务，比如说代码分析、测试覆盖率分析等等。 在我们公司里，开发人 员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如 果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠 的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原 因从而让灯变绿。 有很多很多的书用来介绍重构，最著名的是 Martin 的重构 ，Joshua 的 从重构到模式等。重构是在不改变系统外部行为下，对内部结构进行整理 优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过 来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程 3 中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于 整个开发流程，每一次开发者 check in 代码之前，都要对所写代码进行重构， 让代码达到 clean code that works。值得注意的是，在重构时，每一次改变要尽 可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重 构，如果测试代码中有重复，也要对它进行重构。 Pair-Programming，结对编程。在敏捷开发中，做任何事情都是 Pair 的，包 括分析、写测试、写实现代码或者重构。Pair 做事有很多好处，两个人在一起 探讨很容易产生思想的火花，也不容易走上偏路。 Stand up，站立会议。每天早上，项目组的所有成员都会站立进行一次会议， 由于是站立的，所以时间不会很长，一般来说是 15-20 分钟。会议的内容并不 是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？ 2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此 相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后， 他就会和你进行讨论。 Frequent Releases，小版本发布。在敏捷开发中，不会出现这种情况，拿到 需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布， 一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用， 而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版 本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化 了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变 动，也能很快的适应。 Minimal Documentation，较少的文档。其实敏捷开发中并不是没有文档， 而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统 API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代 码，而比一边看着文档一边进行 debug 要高效。如果用书面文档或者注释，某 天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码 和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有 测试变化了，代码才会变化，测试是真实反应代码的。 这时有人会问：代码不 写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码 才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对 代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示 设计还不够简单，需要对它进行重构。 Collaborative Focus，以合作为中心，表现为代码共享。在敏捷开发中，代 码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统 任何一部分的代码然后修改它，每个人都能够对这部分代码重构而不需要征求 代码作者的同意。这样每个人都能熟悉系统的代码，即使团队的人员变动，也 没有风险。 Customer Engagement ，现场客户。敏捷开发中，客户是与开发团队一起 工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开 发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反 馈。 敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情 有活力的，能够适应更大的变化，做出更高质量的软件。 三、自动化测试 Automated Testing ，自动化测试。为了减小人力或者重复劳动，所有的测 试包括单元测试、功能测试或集成测试等都是自动化的，这对 QA 人员提出了 更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚 本或者用工具录制。 在自动化测试过程中，UI 的自动化测试实施难度比后台程序的自动化要大， 那么 UI 自动化测试是怎么做的呢？首先需要用一个持续集成的工具 hudson 作 为一个颗粒度比较粗的测试用例管理工具，hudson 作为自动化测试的主心骨， QA 们可以在 hudson 上触发自动化测试的运行，运行完了以后可以看到测试结 果，并且，利用了 hudson 的分布式结构，由多个测试机来执行测试，达到了很 好的资源调配。对浏览器的控制方面，用了 Selenium，会上没有问 UI 是否利用 了 Selenium 的多浏览器支持，从演示上来看应该只做的 Firefox 的。他们的分 工很明确，分了专门做功能测试的 QA 和专门做自动化测试工具开发的 SDET，SDET 主要是负责写 RUBY 代码，封装并且暴露了一些通用的方法给 QA 使用，并且同时使用了 Cucumber 作为一个 DSL，QA 是用 Cucumber 来做 自动化测试的一些描述，Cucumber 的作用就是对功能测试的 QA 屏蔽了底层 RUBY 脚本，对上就是“翻译”功能测试 QA 的意图， “翻译”成 RUBY。优点在 于：分开了自动化测试工具开发和自动化测试实施；使用了大量开源工具，提 高效率；在测试过程中我将这个方式加以运用，提高了测试技术。 自动化测试是软件测试发展的一个方向。很多人都认为做测试，懂得自动 化测试是很重要的。我之前用 QTP 的时候，给自己最大的感触就是录制脚本和 调试脚本的时间太长了。通过一些讲座和交流，我对自动化测试和脚本的录制 修改技巧慢慢熟知，大大提高了自动化测试设计的效率。测试是一个思考的过 程，自动化测试是测试发展的必然趋势，所以在自动化测试的运用之中我还是 有很多需要学习的内容。 5 四、大数据 现在，当数据的积累量足够大的时候，量变引起了质变， “大数据”通过对 海量数据有针对性的分析，赋予了互联网“智商” ，这使得互联网的作用，从简 单的数据交流和信息传递，上升到基于海量数据的分析，一句话“他开始思考 了” 。简言之，大数据就是将碎片化的海量数据在一定的时间内完成筛选、分析， 并整理成为有用的资讯，帮助用户完成决策。借助大数据企业的决策者可以迅 速感知市场需求变化，从而促使他们作出对企业更有利的决策，使得这些企业 拥有更强的创新力和竞争力。这是继云计算、物联网之后 I