敏捷开发

这次作业属于哪个课程 | 软件工程 这次作业的要求在哪 | 第一次阅读作业 [toc] ###读后的感想 <span style="color:blue">1.第四章两人合作部分</span> 代码的风格是简明，易读，无二义性。 --引用自 《构建之法》 我是非常赞同这个说法的。我认为我在以后的开发过程中，不会搞艺术，使用一些花里胡哨的或者说贪图简单的命名，应该代码风格规范，使用一些约定的规则。首先代码风格规范可以促进团队合作，其次可以为处理bug降低难度，还可以降低软件后期的维护成本，最后，我觉得规范化也是对自己的一个成长。 <span style="color:blue">1.第四章两人合作部分</span> 在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。 --引用自 《构建之法》 文中所描述的这种结对方式，给我一种就是先结婚后培养感情的感觉，两个人在各种因缘际会下，组成了一对。诚然，感情不是朝夕可得，有效的结对编程也不是一天就能做到的。《构建之法》一文中给我们介绍了很多关于结对的好处与适用性，可就目前来说，我觉得从两个人分开写模块变成一个写，一个审查，交替进行的模式，我觉得很新颖

项目 内容 本作业属于北航软件工程课程 博客园班级链接 作业要求请点击链接查看 作业要求 我在这门课程的目标是 成为一个具有一定经验的软件开发人员 这个作业在哪个具体方面帮助我实现目标 让我对自己目前的状况有一个更加清醒的认识 1. 快速阅读完教材仍然不懂的问题 1. 第4章 两人合作 4.3.4 如何处理C++中的类 类型继承 1）仅在必要时，才使用类型继承 2）用const标注只读的参数 3）用const标注不改变数据的参数 我的疑惑点主要是在第1条原则。在上上学期的面向对象课程中，我们学到了类的继承是一个很实用的方法，它可以帮助我们减少代码之间的重复，并且体现出设计的层次感。但《构建之法》的意思似乎是在说，要尽量避免使用类型继承。在实际的工程中，类型继承是被提倡使用的吗？ 2. 第4章 两人合作 4.5.3 不间断地复审 结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作导致观察力和判断力下降。 前文中作者提到，结对编程可以类比于现实中的一些搭档关系：越野赛车（驾驶、领航员）、驾驶飞机（驾驶、副驾驶）。但是在这些领域中，搭档的职务往往是固定的，这是因为两个人往往在不同的岗位上有不同的经验，让在某一个岗位具有更丰富经验的人去担任这一职务，比两个人交换岗位、在自己不熟悉的领域工作，要合适的多。因此，结对编程中驾驶员和领航员经常角色互换，是否是一个合理的选择？ 3.

软件工程 - 第一次阅读作业 项目 内容 这个作业属于哪个课程？ 北航软工2019班级博客 这个作业的要求在哪里？ 第一次阅读作业 我在这个课程的目标是？ 按时完成老师给的任务 这个作业在哪个具体方面帮助我实现目标 ？ 让我了解该课程的基本内容 1. 看完《构建之法》后的思考 快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。 作为一个平时看书不经过脑子思考的人，突然让我提出5~10个问题，真的挺让我头疼的。那我就先把这个空着吧。 1.1 有关结对编程 说起结对编程，我就想到了我和姐暑假一起玩《饥荒》的日子了。由于只有一台电脑，我们只能轮换着操作电脑玩。在一个人操作鼠标的时候，另一个人在旁边适时给予指导。我们也会互相问问题，询问建议。由于饥荒独特的游戏系统，当一个人操作电脑的时，有时需要另一个人在网上搜索各种食物配方等内容。饥荒这游戏最大的特点就是孤独，但两个人一起玩，我们不会感到孤独。我们很开心的一起玩了很久，度过了一整个夏天。 <figure align="center"> <img src="http://ww1.sinaimg.cn/large/0070O95Yly1g0vwhxds3hj30k00f0gxt.jpg" width="400"> <figcaption>饥荒</figcaption> </figure> 但是对于结对编程，我感觉有点难。

<table border='2px'> <tr><th>项目</th><th>内容</th></tr> <tr><td>这个作业属于哪个课程</td><td><a href='https://edu.cnblogs.com/campus/xbsf/nwnu2019SE'>2016计算机科学与工程学院软件工程(西北师范大学)</a></td></tr> <tr><td>这个作业的要求在哪里</td><td><a href='https://www.cnblogs.com/nwnu-daizh/p/11012922.html'>实验十二 团队作业8—软件测试与ALPHA冲刺</a></td></tr> <tr><td>团队名称</td><td>快活帮</td></tr> <tr><td>作业学习目标</td><td> （1）掌握软件测试基础技术。 （2）学习迭代式增量软件开发过程（Scrum）。 </td></tr> </table> <h2><span style='color:blue'>1.团队项目github仓库地址链接：</span><a href=''https://github.com/ss140522/bookStore">第三波二手书店</a></h2> <h2><span style='color:blue'>2.Scrum meeting 导航：</span><

转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 随着敏捷软件研发过程的引入，敏捷测试也开始成为研发团队的重点关注对象。在行业内，有些企业正在做敏捷测试的尝试，有些也取得了不错的效果。 随着普元研发管理体系（iPALM）的不断演进，敏捷的开发过程加速了产品的市场响应。 在普元DevOps平台的助力下，开始把质量构建进产品而不是在生产出来之后再进行测试。 在软件产品部整体团队的群策群力下，敏捷的软件测试模式在研发过程中运行非常成功，测试团队也积累了一些宝贵的经验，很高兴有机会拿出来与大家一起分享。 目录： 1.对敏捷软件测试的理解 2.敏捷软件测试的核心价值 3.敏捷软件测试的经验分享 4.总结 1.对敏捷软件测试的理解 敏捷测试的定义 Wikipedia对敏捷测试的定义： Agile testing is a software testing practice that follows the principles of agile software development. 1 译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。 这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。 敏捷测试与传统测试的区别 传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段

图：stoica-ionela-530970-unsplash AI 趋势已是必然。如果想与世界同步，跟进 AI 或许是明智之举。这不是说一定要从事 AI 直接相关的工作，但是起码得具备这方面的思维和知识，因为 AI 很快或已经渗透到各行各业。一些用传统方法解决的问题，用机器学习算法会不会解决地更好呢？这或许是我们在以后的工作或学习中首先要问自己的。 这是好事，毕竟解决问题的方法更多了。如何才能找到步入这扇门的钥匙呢？我想很多人都有自己心中的答案，或者也有一些现在找不到答案。最近，和几个朋友交流过这个问题，与大家一起分享下。 大致来说，要想步入这一行，假定未接触过任何算法，需要先了解一些基础算法，最最基础的。通过这一环节，你便能知道算法到底是怎么一回事。很多从事软件开发的，习惯了调用API，用 intuition 去实现业务逻辑，毕竟都究竟敏捷开发吗，但长此以往，形成了一种靠直觉写代码的习惯，如果再不爱总结，最终你会发现自己完全变成了一个 tool，而没有自己的 idea. 最后，你发现，没有 special 、没有别人无法复制你的东西。这也就是，很多做纯开发多年的人，想转行做产品经理偏管理，或者算法工程师偏算法的原因。如果你想转到算法这块，并且之前对算法没有专门的研究，你需要首先开始去学习基础算法比如从做基础的算法题开始。这样做，不是题海战术，而是培养真正的算法思维

本文由 网易云 发布。 作者：刘超，网易云解决方案架构师 一、持续集成对于微服务的意义：拆之前要先解决合的问题 在很多微服务化的文章中，很少会把持续集成放在第一篇，因为大多数的文章都会将如何拆的问题，例如拆的粒度，拆的时机，拆的方式。 为什么需要拆呢？因为这是人类处理问题的本质方式：将一个大的复杂问题，变成很多个小问题解决。 所以当一个系统复杂到一定程度，当维护一个系统的人数多到一定程度，解决问题的难度和沟通成本大大提高，因而需要拆成很多个工程，拆成很多个团队，分而治之。 然而当每个子团队将子问题解决了，整个系统的问题就解决了么？你可以想象你将一辆整车拆成零件，然后再组装起来的过程，你就可以想象拆虽然不容易，合则更难，需要各种标准，各种流水线，才能将零件组装称为车。 我们先来回顾一下拆的过程。 最初的应用大多数是一个单体应用： 单体应用 一个Java后端，后面跟一个数据库，基本上就搞定了。 随着系统复杂度的增加，首先Java程序需要做的是纵向的拆分。 纵向拆分 首先最外面是一个负载均衡，接着是接入的Nginx，做不同服务的路由。 不同的服务拆成独立的进程，独立部署，每个服务使用自己的数据库和缓存，解决数据库和缓存的单点瓶颈。 数据库使用一主多从的模式，进行读写分离，主要针对读多写少的场景。 为了承载更多的请求，设置缓存层，将数据缓存到Memcached或者Redis中，增加命中率。

不知道你有没有遇到这样的场景，刚上线的一个功能，就出现了一个严重Bug，团队周末集体加班吭哧吭哧的紧急处理，你们彼此抱怨不断；你和老板在给客户演示产品新功能的的时候，突然系统崩溃了，在场的人一阵尴尬，急忙解释一阵说这一块还没处理好。 遇到这种问题怎么办？是每个人只负责其中一个模块么，遇到问题出现问题的人处理吗？不行，这样忙的同学会忙死，闲的同学没事儿做；那招一个测试同学呢？也不行，我们并没有招聘的预算； 其实解决这个问题就是做好代码质量管理，而代码质量管理最重要的方法就是「Code Review」也就是代码审查 ，为了简单，下文我用CR简写。 代码审查在维基百科解释： 指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。 简单来说CR就是通过审查代码来提升软件质量和开发者技巧的方式。 为什么要做 Code Review 那么为什么说CR能够提升软件质量和开发者技巧呢？以及为什么我们要做CR？ 首先对于初学者，CR是一种很好的学习方式，因为负责主要审查的人往往具有更丰富的经验，知道哪些位置有坑，哪些写法会造成问题，这样可以最大限度的从代码过程中提升个人技能。 尤其是那些资深的同事给新人进行指导讲解的时候，效果可能不仅仅是知识代码层面的，更是对以后工作态度，学习求真的深远影响

题外话 在此之前，笔者主要从事传统IT企业的研发技术管理工作，对项目管理虽然有一定的经验，但纯粹摸石子过河，没有系统的学习过项目管理理论，也很容易犯下技术人员对项目管理的一系列毛病。 之前带的项目一般都是非产品型项目，功能一般以实现为主，对细节没有太多要求。项目一般采用瀑布模型，项目之初一般会制定一个非常详细的研发计划，涵盖需求分析、设计、研发、测试、验收的全过程。由于用户验收测试往往需要花大量时间，因此会输出一份沉甸甸的需求说明书，然后让客户签字，并在验收阶段，在现场维持长时间的驻场开发，以便实时跟进需求的变化。曾经创造了带领10人研发团队、连续3个月，每天维持12个小时以上工时的工作记录。（堪称土劳模） 这是第一次参与互联网项目的开发，有明确的迭代周期和需求计划，但是由于各种原因，却逐渐走向失控，过程中究竟发生了什么原因？ 失控全过程 话不多说，直接进入正题。 我将尽量以第三人称视角记录一个失控的项目，但事实上我实际是项目负责人，所以难免有失偏颇。 这是B公司一个面向特定行业的虚拟建站平台产品，虽然市面上建站产品非常多，但由于B公司在该行业颇有地位，能够获得一些比较实用的数据，这些数据是目标用户群体非常渴求的宝贵资源，因此如果将这些数据做成可视化组件然后打造这样的精准型建站产品，显然具有独特性的优势，能够为目标用户带来便利。 产品于2月底开始启动会，由研发部门内部碰头后

全文链接： https://www.cnblogs.com/nullering/p/9684820.html 一：软件生命周期 软件生存周期，分为8个阶段： 1、可行性研究与计划 2、需求分析 3、概要设计 4、详细设计 5、实现 6、集成测试 7、确认测试 8、使用和维护 二：软件开发模型 1：瀑布模型 瀑布模型也称为生命周期法，是结构化方法中最常用的开发模型。开发如同瀑布，从一个阶段流向下一个阶段。其思想认为软件开发是一个阶段化的精确过程，每一个步骤都划分得很明确，阶段之间有明显的界线。 当软件需求明确、稳定时，可以采用瀑布模型，一旦需求变动剧烈，往往到测试阶段才暴露，造成修改代价太大，风险难以控制。 2：演化模型 若干次瀑布模型的迭代。原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。 根据迭代内容，演化模型可以演变为螺旋模型、增量模型和原型法开发。 3：增量模型 增量发布将系统划分为若干版本，每一个版本都是完整的。版本的划分要均匀。 4：螺旋模型 特点是强调风险，每次瀑布模型迭代前，引入风险控制。将软件项目分解成一个个小项目，每个都标识风险，直到所有风险都被确定。 演化模型适合高风险项目。 5：原型 部分衍生关系： 6：快速应用开发（RAD） 　　是一个增量型的软件开发过程模型