软工课程总结
软件工程博客作业
Software Engineering
至此，软工课即将结束，团队项目也已经完成了M2阶段，下面回顾这个学期软工课的实践经历，对一些问题再次进行思考：
软件工程M1/M2总结:
XubaOnline:bugphobia团队
- M1阶段
这个时期，对于我们团队来说可以用两个词来描述：Passion 和 Confusion。 Passion是因为我们有着对团队和项目的高度自信，有着对项目的美好憧憬，对新技术学习的好奇和激动…… Confusion是因为这个时期的我们对不仅仅在每个模块的技术细节上都存在着很多无知，需要耗费大量的学习成本，更是因为在组内各个模块的对接、与其他小组的数据对接都存在着很多问题。这些问题导致项目出现了较长时间的阻塞，令我们很是困扰，但庆幸的是我们是一个有责任感有激情的团队，在后期我们及时采用组内结对编程的模式来协调模块间的拼接，同时实现快速敏捷开发。
在M1阶段我主要负责的是后端，当时感觉比较深的是和前端的耦合程度太高。因为django采用的模板渲染机制，所以有时我需要先获得前端开发人员完成的页面来进行调整，如果前端此时还未开发完成，那么我需要自己写一些页面。这就造成了模块之间的界限不是很清晰，不仅带来了重复的工作，也带来了由于模块间依赖而引起的等待阻塞。
同时在这个阶段前期我们太过自由了，当时没有PM来进行全局的协调和管理，导致任务有些拖沓，不过也有一部分原因是因为技术学习成本，导致整个过程不够“敏捷”。后来自从结对编程后，我作为后端功能组与前端开发人员以及数据组进行结对编程，整体的效率提高了很多，于是明白了来自团队的激励和约束在一个团队项目开发过程中来说是非常关键的。
- M2阶段
这个时期，在开发中有很多的无奈，但是让我们很有成就感。无奈是因为其他课程的压力特别重，导致在项目上能够投入的时间远不能达到预期的标准，很多功能被迫转变；但是成就感来自我们针对M1阶段中存在的问题通过架构修改和团队管理制定专门的方案进行解决，同时更是通过设计了一套完整的架构让Xuba项目的四个小组整合了起来，而我们组作为其中的核心起着至关重要的作用。
这个阶段我是后端的总负责人，不仅仅将原来的后端代码通过交互方式的修改转变成能够适应前后端接口，同时与另一个小组进行组间的结对合作，将问答平台移植到了django的后端之中。同时为了满足开发的接口能够让前端开发者正常顺畅的调用，我们在开发后端的时候还专门进行了单元测试，其中单元测试分了两层，首先第一层也就是最基础的一层，我对数据库的所有操作进行了测试；第二层，针对的是我们web的特点，对于所有http交互接口进行了测试。上面的两层单元测试保证了能让前端开发者安心的调用接口获取数据，从而提升效率。
从中可以很好的感受到，我们的团队合作和管理有了很大的提升，尤其是各个模块之间的解耦让我们开发人员可以专心按照需求完成自己的工作，模块之间的依赖直接就下降了。
同时我们的任务审核机制能够及时对任务完成情况进行监控，同时对目标进行调整，这也是为什么我们M2阶段中后期及时将目标转为面向后期的开发人员，为此我们在后面的开发之中非常注重代码的质量以及注释的完整情况，同时也准备了大量的学习总结文档，让下一届的团队能够很轻松得入手我们的项目。
- 总结
在M1/M2结束之后来看我们的经历，确实有种别样的感觉，有种“阳光总在风雨后”的舒畅，心里确实挺开心的，虽然我们的项目beta阶段没能给用户一个完整的版本，但是我们组无疑是有最多体会的，无论在技术层面，还是组内组间协调合作方面，中间都碰到了很多其他组没遇到的问题，正因为如此我们有更丰富的软件工程开发体验。最后，再次感谢老师们推行这样的课程模式。
课程总结
早期博客链接
阅读《构建之法》后的思考和疑问
对以前问题的理解
- 关于单元测试的自动化。
大家都喜欢在写代码时能够确定自己原来写的东西没有错误，所以单元测试确实在开发中起到很是吸引人，但是单元测试又确实很是繁琐。那么这里所谓的单元测试“自动化”，其自动化是针对哪些方面？
对于这个问题：当初助教给的解释是可以从“单元测试框架”，以及通过定期运行单元测试来确定bug的出处这两个方面来进行理解。后来发现还真是这样。
我们使用的后端是Django，我专门负责的后端，在M2阶段我通过给所有数据库操作以及http请求进行单元测试保证这两个层次上的正确性。其中后端运用的就是Django提供的UnitTest 框架，这给错误定位带来了很大的帮助。在单元测试时，它自动对数据库进行备份，然后在每个Testcase中可以随意得进行操作，但是在整个测试结束之后会恢复数据库，对原有的数据库一点都不会产生影响；而且每次只需要简单的一行指令就行运行所有的测试，迅速就能进行单元测试和回归测试，让代码可靠性有很大的提升。
总的来说，通过实践的开发过程，我清楚得认识了单元测试的重要意义。
- 关于项目设计与开发速度上的问题。
设计到怎样的程度有利于能够提高开发的速度，是否存在某些设计需要在实践中考察后才能判断优劣的情况？
对于这个问题：这个问题显然是需要在项目开发的过程中去体验从最初设计到最后的这样一个过程，才能有所思虑和认识。
这个问题我最初想问的是设计方面需要细化到什么样的程度，在开发过程中我认识到，设计方面需要充分考虑到很多细节的问题上面去，这样才能让项目能有很好的扩展和发展，同时这也是为了能够让开发过程中各个模块之间能够更好得协调开发，从而让项目能够更好得依照预期的进度去推进。比如我们beta阶段的重构就是因为在alpha阶段初期设计时没能够预料到模块之间的耦合度会这么高，并且最初没有去想如何将Xuba四个组联合起来。如果当初的设计就能够预料到这些问题，那么会减少很多不必要的时间消耗，但是问题往往在于我们软件工程经验性比例比较大，所以我们只有见识过足够多的架构之后才能在自己设计时有个宏观的把控。另一方面，具体细化的程度至少要完成各个模块之间的接口设计，然后的设计就可以留个各个模块的开发人员去保留创造力了。
- 关于软件工程师成长方面的问题。
书中有提到很多关于软件工程师资格认证的内容，那么一个优秀的软件工程师应该有怎样的习惯和精神素养呢？
对于这个问题：通过开发体验我有了这样几点想说：
- 提高学习能力
- 在使用新技术的时候，需要我们快速去上手
- 解决问题的能力
- 开发实际上是去解决从需求问题出发的一条条问题链，你为了解决一个问题往往会引发一系列的其他问题，这些触发的问题与原问题的关系可以是子集关系或者是承接的关系，不管怎么说都是在推动进程。所以如果不能去解决设计、开发中遇到的问题很难前进。
- 沟通能力
- 软件工程不是一个人在开发，我们需要及时与他人沟通，将自己的进度汇报给他人，同时及时去获取他们的进展，只有在这样的互相协调中，才能够推动合作。
- 责任感
- 需要对自己的代码负责，不将自己范畴内的问题留个别人，同时要将自己做的一些调整给别人说清楚，不能做了不说。因为计算机思维讲究的就是一种不断的抽象的思维过程，在开发中每个模块就相当于一个大的抽象，需要有模块负责人将模块内的东西保障好。
- 精神层面
- 进取心
- 坚韧的意志
- 职业道德
- 关于敏捷流程。
现实的开发过程中往往会比理论中多出很多问题，比如需要如何能够将需求细化到任务，然后在细化到设计，最终使得能够在规定的时间内有条不紊的完成目标？
对于这个问题：我觉得可以有一下几点的看法。
- 用熟悉的工具会更敏捷
- 毕竟可以减少学习成本嘛，不过目前的我们总是希望能接触新的东西，这也是没办法的，不过这样感觉也是挺充实的。。。
- 好的团队机制能够使得更敏捷
- 减少模块间的依赖
- 增强交流与合作
- 增加激励机制
- 任务划分尽可能细化，并制定好优先级
- 如此能够让开发部至于迷茫。
- 关于优化。
如果最后做性能分析的时候发现的性能问题造成的原因是前期一个隐藏在很深地方的不妥当架构造成的，这个时候该如何取舍？
对于这个问题：我目前的感觉还不是特别深，但是有一点可以确定，在优化之前先得将项目的功能给完成了，所以不需要过分去担心这种由于架构带来的问题，只要在设计过程中尽量多考虑一些问题就行。曾经在《数学之美》一书中看到这么一个说法，往往人们最初为了解决某个核心的问题而设计出来的framework会具备很好的实践运用效果，后期即使再怎么优化都很难有什么较大的改善。
新的问题
- 软件工程中很多解决方法都是经验性的，我们在每次工程经历之中，应该着重哪些环节呢？除了技术层面，还有哪些领域的东西能够提高我们的见识从而能让我们在协调团队管理的过程中更加有针对性呢？
阅读体会
这些论文和博客都比较长，但是主题还都是比较清晰的。
软件工程的复杂性和可变性确实是太大了，其中存在着很多的变数，尤其在时间的安排和管理方面很难和预期的一致，这个时候对我们的要求就很高了。我们有很多经验性的方法可以尝试，但是具体的效果如何还是需要具体得去结合实际的项目需求以及开发情况。
所以在软件开发过程一定要有一个很好的团队管理机制，然后通过这个机制积极调动成员的参与和合作，同时还需要有沟通交流，及时反馈。时刻对照监督任务的完成情况，好让预期的目标得以实现。
知识点感悟
需求阶段
正如上面所提到的，它是整个问题链的开端。所有需求分析显得非常重要。首先需要对项目有个基本定位，然后对潜在的用户进行需求调研分析问卷，并且对问卷的结果进行分析来确定功能的选择及其开发的优先级。
NABC分析，SWOT分析也都是为了通过需求来明确我们项目的核心目标和出发点的，对于后面的进一步开发起着非常重要的作用。
设计阶段
在设计阶段首先有一个总体的架构设计，这个架构设计需要明确前端和后端使用的框架，以及之间如何进行连接的接口设计。然后需要对具体的前端设计两个层次，第一个层次是设计页面的布局，然后根据页面布局和跳转得到功能上的需求设计，然后在根据这些功能上的设计需求来得到关于后端的具体设计规范。
实现阶段
这里讲究的是任务的分派问题，在团队管理方面会有很多激励和监督机制，从而来保证任务的正常完成，项目进度的正常推进。同时也会需要制定一些代码规范来保证代码质量。具体实现阶段的合作方式可以有结对编程。
测试阶段
包括：
- 开发阶段的单元测试
- 测试环境配置说明
- 功能测试说明
- 手工测试
- 性能测试
- 由于在服务器运行过程中进行性能测试可能影响用户使用
- 包括：间隔请求，同时请求，带宽瓶颈，CDN负载等等
- 兼容性测试
- 测试各种环境下的情况（手工测试）
- 场景测试
- 模拟用户使用环境的测试
发布阶段
需要对功能进行全面的介绍，同时需要对针对各种环境进行说明，对发行版本存在的问题进行记录。
维护阶段
需要开放专门的反馈平台来接受用户的反馈，同时要秉着负责人的态度，积极和用户反馈并对反馈的问题进行补丁。