(前沿讲座心得体会.docVIP

北京邮电大学软件学院 前沿课题讲座心得体会 报告人： 学号： 导师： （日期：2015 年 1月20日） 在北京邮电大学软件学院学习期间，我积极参加学校组织的前沿课题讲座和各大企业举办的新技术讲座，下边分几个方面谈一谈对敏捷开发、自动化测试、大数据讲座的体会： 一、敏捷开发 最近一段时间以来，很多人开始谈论敏捷开发、研究敏捷开发，那么究竟什么才是敏捷开发呢? 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 (agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了敏捷方式组建团队：Capital One的敏捷团队包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的翻译者);另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过敏捷开发的培训，具备相关的技能。(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次，以评估过程及决定需求变更是否必要。在Capital One，大的IT项目会被拆分成多个子项目，安排给各敏捷团队，这种方式在敏捷开发中叫蜂巢式(swarming)，所有过程由一名项目经理控制。 Bailar将项目拆分，从旧的瀑布式开发转变为并列式开发，形成了敏捷开发所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行冲刺--每个冲刺始于一个启动会议，到下个冲刺前结束。 Bailar将其与传统的开发方式做了对比后，他感到非常兴奋--敏捷开发使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的质量。不过，有些需求不能用敏捷开发来处理。 Bailar承认，敏捷开发也有局限性，比如对那些不明确、优先权不清楚的需求或处于较快、较便宜、较优的三角架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。Test-Driven Development，测试驱动开发，它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。 Continuous Integrationbuild未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。 在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。 有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码