个人回顾总结
一、开课提出问题
第一次博客地址：https://www.cnblogs.com/Slow-Walker/p/11513179.html
二、问题回答
2.1问题1：针对单元测试
怎么保持单元测试的孤立性呢，假如测试方法中的参数过多就会造成在被测试方法业务逻辑复杂，而且会频繁调用其它接口，他的优缺点具体有哪些呢？
课程学习回答：通过本次的课程的学习以及后面的单元测试项目实践、以及最后的团队项目实践都用到了单元测试，也较为深刻的掌握了单元测试的方法以及他的测试，也深刻的体会到了他的优点缺点；首先是采用自顶向下的单元测试策略，解决单元测试孤立性问题，实践的步骤如下：
（1）以单元组件的层次及调用关系为依据，从最顶层开始，把被顶层调用的单元做成桩模块。
（2）对第二层单元组件进行测试，如果第二层单元组件又被其上层调用，以上层已测试的单元代码为依据开发驱动模块来测试第二层单元组件。同时，如果有第二层单元组件调用的下一层单元组件，则还需要依据其下一层单元组件开发桩，桩的数量可以有多个。
（3）依此类推，直到全部单元组件测试结束。
项目中体会到它真正具备的优点个人总结如下：
因为单元测试是直接或间接地以单元组件的层次及调用关系为依据，所以可以在集成测试之前为系统提供早期的集成途径。由于详细设计一般都是自顶向下进行设计的，这样自顶向下的单元测试策略在顺序上同详细设计一致，因此测试可以与详细设计和编码工作重叠或交叉进行。
相应的自己也能感受到他的缺点：
测试过程会复杂，因为要开发驱动模块和桩模块。由于需求变更或其他原因而必须更改任何一个单元组件时，就必须重新测试该单元下层调用的所有单元。
2.2问题2：敏捷开发
针对于复杂的开发确实很有用，回想之前自己开发的几个程序，只是简单的执行，使用敏捷开发并不适用，简单的东西也许敏捷反而不敏捷了？
针对这个问题，确实如此，通过本次的对敏捷开发的学习与具体的实践，真正明白了他的实用的地方，也真正领略了他的魅力。确实对于小项目不用敏捷开发，比如就我自己一个人写的或者就我和我的小伙伴两个人的项目确实不适合，首先是针对敏捷开发起码最少也是三个人，敏捷的含义就是最注重沟通解决问题，两个人之间也很方便，反而增加这样一个流程会显得很麻烦，这样的小规模软件开发可以用原型开发或者边设计边改的模式就可以。
然而对于一个具有工程性需求不明确随时在变动的项目来说，敏捷开发就能真正的恰到好处，因为他天生就是给需求变动的项目设计的一种软件过程，他的三个角色以及里面的三个工件甚至每一个活动，现在真的能够体会到他设置的相应的意义，缺一不可。
2.3问题3：代码重构
然而现在对重构还有似乎疑惑，针对何时重构，在刚刚开始开发的时候应该在那些方面应该考虑后面的重构？
针对这个问题自己也确实感觉当初想的还是很好这个问题，对于一个软件的开发之前就考虑重构的思想，这样虽然在开发时期会比较费时、但是对于后期二次开发该是多么大的一件幸福的事啊。针对我们团队的项目我就在开发之前综合考虑了我自己设计的每一个小功能模块，尽最大能力遵从运用设计模式的思想，综合考虑了单一原则、开闭原则、里氏替换、依赖倒转、接口隔离、迪米特法则、合成复用原则。
比如我在设计党员管理和党员的里面接口时候就充分用了依赖倒转、接口隔离的原则也基本实现了低耦合高内聚的效果，里面在积分管理以及添加的时候运用到了观察者模式，以及在书记信箱的里面也用到了单例模式。确实在设计的时候要综合考虑各个接口之间的关联关系，看看这个业务逻辑能不能用设计模式的具体案例来优化，我想这也是我在这一门课程中实践到的最终要的一个思想。
2.4问题4：用户的角度参与测试
可以加一种测试方法，就是将用户和测试人员相结合的方式一起进行测试，这样的话通过用户的角度就能够更多的去发现问题，同事在他们测试过程过程中，也能让他们发现问题，并及时解决问题，不至于到最后交付项目时候出现偏？
确实是如此也真的感觉当时考虑的很全面，我们在团队项目的过程中，每一次的自己任务开发完成就会进行自己的单元测试，其次我将大家的代码整合到一起后我也会进行集成测试，乃至到每个冲刺版本结束之后我们也会对我们这个阶段的完成的功能模块进行全部测试。确实我感觉这个只是我们开发人员你的自己测试还有一些不完美的地方是通过我们的角度是发现很困难的。
因此我们将我们的学院领导微信添加了开发者模式，让他们站在用户的角度来试用我们的最近开发的模块的功能，他确实就能在这个体验过程中给我们提很多问题（其实第一次邀请他来的时候他在夸赞了我们的实现效果了之后，给我们提了超多一件，说这里要改哪里要改，瞬间觉得他前面的话是故意说的），没办法他是领导确实我们做的不够完美，虽然我们程序员确实都不愿意看到自己的代码出现错误，但是却是人家给我提的问题确实是问题在哪里。好在我们还是按照用户（领导）的意见更改了，也基本达到了要求，到最后beta版本交付的时候确实他就再也没有提出什么问题了，因此交付的也非常成功，也确实源于前几次冲刺版本他的意见帮助。
2.5问题五：什么是软件工程创新
针对软件工程开发领域创新到底什么样的才叫创新？要达到什么要求水平才能称得上创新？新的开发技术的出现算是软件工程的创新吗？
个人觉得当时提的这问题还是有点点大哦。但是学完这门课程确实有了不一样的理解和体会。我感觉针对本次项目的实践的scrum流程，他当初由人家创造的手这也是创新，他产生的原因就是解决其他软件开发模型解决不了的问题-需求变动较大、需求不明确的问题。个人觉得如果要算创新，起码是其他没有这种思想而重新生成的产物才叫创新，我感觉如果能够结合各个软件过程模型的优点避开他们相应的缺点，从而定义出了一种新的软件过程模型能够对软件开发过程中解决实际的开发问题，这样才能算创新，比如设计一个瀑布+敏捷折中的软件设计模型，这也是一种创新。
我个人认为新的技术上的产生真的不是软件工程的创新。个人认为应该是致力于提升软件工程管理质量、明确计算机软件工程管理内容等方面的创新才是软件工程上的创新。原因是新技术是日新月异的，随时更替的，并不能对软件工程这样一个工程性的思想性概念产生太大的影响。
三、新提问
实践的具体过程中体验了敏捷开发具体体验到了那些他的优点，具体应用在哪？
针对本次的实践真正发自内心的感受到了敏捷开发的优点：
| 体会优点 |
具体感知 |
| 更大的灵活性和稳定性 |
我们后期需求针对不明确，在一直变化，这样一个开发过程满足了我们后期开发的变动 |
| 更高的质量，更快的交付 |
我们细化了每一个冲刺版本、具体到我们每一个冲刺订单到每一个人头上、使得大家更加的明晰了自己的任务、达到了最大的效率和质量 |
| 提高团队绩效 |
在每次立会的时候大家都会总结过去几天的不足，这样真得能够提高大家在下一个阶段的开发效绩 |
| 简历持续改善的文化 |
在这里我们团队也有相应的惩罚和奖励文化，形成了自己的一套团队文化，激励大家不断向前 |
| 更高的客户满意度 |
因为分了版本我们每期结束都跟学院领导进行了交互，这样用户就能时刻看到我们的进度提高了对我们的满意度 |
| 更高的队员满意度 |
大家每天虽然遇到很多困难和绝望但是在每次自己工作完成之后都能看到大家对这样一个开发流程还是很满意，因为大家都做出了自己的成绩 |
| 失败成本更低 |
相应的我们严格按照这样一个流程即便中间有些延误我们也进行了相应的调整、最终成功交付了项目 |
四、课程实践总结
终于这一次也是我这门课程最后一次写博客了，不禁感慨当初助教开始布置的那么多作业。回顾这门课程经过了个人实践团队实践，真的也明白了为什么陈老师要申请这门课程不考试的原因了，确实真的好有道理。感悟很深自己也对自己分三个方面总结一下自己：
（1）专业技能的提升：说实话微信开发第一次做这么大的作品，之前做过很多开发，包括c#桌面开发，java高并发开发、一致到这次tp5开发，后端从零到各个功能的填充完成实现，不禁感慨我的队友们当初的仅仅是为了钱来开发这个项目（学院资助），当初想想都不可能实现的任务，曾在这门课程开课选题时候都想着给大家选一个简单的，然而最终还是选择了这个。真好，这次自己也是做小程序后段的，我的开发过程也是在本地搭的微擎服务器，一步步用thinkphp5的框架进行，其实之前还不是很熟这个，但是慢慢的这门课程之后对PHP也就更加熟练了，一致与从微信开发到最终发布的这样一个流程自己心里都有一个较为明晰的过程，确实自己的动手能力也增加太多了。
（2）工程实践认知技能提升：说实话我之前听过瀑布敏捷原型螺旋这些软件模型、也去了解过他的公司的实际运用情况，但是真的没有这次亲身体验震撼scrum这样一个过程的深刻感受。其实陈老师在课堂上也转们花了一次课讲敏捷，那个时候我也就大概字面上知道他的优点或者内容，但是真正的花了三个月去搞它真的感受不一样。
估计自己这一辈子都记得到他的三个角色三个工件五个活动，原因就是真的亲身组织和经历了这样的一个过程、经历了无数次日日夜夜的实践，折服于这样一个软件开发思想，把各方面都想的很到位。在本次scrum的角色中自己主要是担任master的角色，自己也深刻的体会到了master的肩负的责任，首先是自己要严格要求自己，才能严格要求他人，我们队友们大家都要兼顾学习，然而我们还是严格三天开一次会议乃至到最后形成会议记录真的太不容易了。我也有幸自己能在这样一个团队里面担任领导者来亲自组织大家做这样一个事情，收获得太多太多。。。
（3）个人领导力团队管理提升：从大一以来到大二以至于到现在，自己也真的愿意和想去做这样一群支持自己的小伙伴的领头羊，带领团队总结经验永争第一，即便没有达到也不后悔。
前两天有两件事特别深深感触了我，第一个就是我身边的小伙伴他们自己报的一个科研项目，然而大家都是轮流来当组长，起初我还是以为他们想互相锻炼，结果他们是以抽签的形式相互推诿的形式，其次是另外一个小伙伴他们要做一个课程设计的汇报，小组内竟然没有一个人愿意去当这样一个组长去牵头做这样一件事，大家都等着。唉，回过头来不禁感慨，这样的话这个大团队还怎么发展怎么能够冲在最前面呢？
自己也思考自己一直做领队的经验有成功也有失败，成功是最大是源于队友的信任与支持，更包括自己全新全意的为整个团队付出不留所有。本次scrum课程实践也是一样的，虽然自己团队里面各方面技术的人都有比自己厉害的，但是自己依然愿意敢这样的一个勇气去担起这份责任，跟随大家一起进步我想有担当能接受失败、善于总结经验、将心比心团结队友这也许才是最重要的。