提问回顾与个人总结
作业介绍
| 项目 | 内容 |
|---|---|
| 作业所处课程 | 软件工程班级博客 |
| 作业要求介绍 | 作业要求 |
| 我在这个课程的目标 | 学习系统化、规范化、量化的方法在软件开发、操作和维护中的应用 |
| 这个作业在哪个具体方面帮助我实现目标 | 本学期软件工程课的个人总结 |
作业正文
第一部分 提问博客链接
第二部分 问题解答
一）为确保函数有单一的出口，是否应该使用goto？
在结对作业中，我写的C++函数都比较简单，基本上都是单一出口，没有用到goto。在团队作业中，我主要负责后端代码，使用的后端框架是基于python的Django，由于python不自带goto函数，因此我也没有使用。Django框架中的函数主要是视图函数，由于Django视图函数总是返回一个HttpResponse对象，所以我们可以只在函数的末尾返回一个该对象，用它作为函数的出口，这样就保证了函数有单一的出口，因此不必使用goto。在之后的学习或者工作中，如果使用C++写工程的话可能会遇到需要使用goto的情况，到时候是否使用goto要根据具体情况决定。
二）结对编程是否需要两个人水平接近？
之前我认为参加结对编程的两个人的水平应该相差不多，这样能够避免编程过程完全由一个人主导的情况。在我提出看法后，@SoftwareTeacher在评论区留言：
如果一个软件团队的目的包括了培养员工， 那么结对编程就能顺便实现这个目标。
我想了想，觉得@ SoftwareTeacher说的很有道理。我之所以有结对编程需要两个人水平接近的判断，是因为我把目光局限在了软件工程这门课的结对编程任务上。对于课程作业来说，如果结对的两个人水平相差过大可能确实会导致这两个人的结对体验比较差，水平较高的感觉自己做了额外工作，水平较低的感觉自己参与度不够。但是在实际开发过程中，结对编程不是单独的一份作业，它必定是团队项目开发过程的一个环节，在这种情况下，即使结对中的一个人水平较低，他也会在结对的过程中不断接受另一个人授予的知识，而这些知识往往可以继续应用于后续的开发任务，因此不会对双方造成什么损失。除此之外，@SoftwareTeacher还说道：
结对编程能让同伴互相了解各自负责的模块。
在实际开发过程中 ，少不了人员变动，如果团队里的人都对其他人负责的模块有一定的了解 ，那么即使团队经历了人员变动，也总是有人可及时顶上，这样就可以减轻项目进度的延误。
在软工团队作业中，我也和其他同学结对编程过。当我从前端转战后端时，跟一个之前负责后端的同学结对编程了一段时间，这让我得以迅速上手Django，对后续开发有一定帮助。
三）是否应把思维导图视为其他图的前置形式？
我认为这样做很合理。我在学习搭建Django后端的时候，就是先画出思维导图，在从思维导图提炼出后端的结构图的。
四）测试人员是否应该从“用户的角度”来测试软件？
之前我认为只要产品100%符合Spec要求就是合格的，测试人员无需对用户体验负责，现在我觉得之前的想法是错误的。在写Spec的时候，我们其实不能完全预知产品做出来的实际效果，只能凭经验和感觉来设计产品，因此根据Spec做出来的产品可能并不能像预期的那样符合用户的使用要求。而测试人员是产品面世前的原始用户，他们就是产品功能和用户体验的保障。从这个意义上来讲，测试人员在测试产品的时候应该从用户的角度出发。在写团队项目的时候，我们就遇到了这种情况，负责测试的同学发现了我们的网站的一些影响用户体验的地方（比如搜索算法不够完善），然后负责后端的同学根据此反馈做了修改。
五）把“铱星计划”作为反例来说明技术的创新不一定是创新的关键是否合理？
我依然保留以前提问题的博客中提到的观点——不合理。我认为如果把“铱星计划”作为反例来说明“技术创新不一定保证创新的成功”就比较合理了。
第三部分 新的问题
一）如何应对核心人员突然流失？
这个问题比较棘手，然而我们组却偏偏遇上了。负责后端的两位同学在没有提前通知其他人的情况下突然脱队，这让大家都有些措手不及。因为除了离开的同学没有人掌握了之前的后端技术，所以我们只能临时换后端框架。遇到这种问题，我认为我们组所有人都有责任，之前负责其他部分的同学没有给负责后端的同学足够的支持，后来负责后端的同学也没有提前通知其他人他们将要离开。当然，这种情况的发生也和课程的安排有关，老师和助教没有考虑到一些同学为了取得高分而放弃之前的组直接转投其他人员配置比较豪华的组的可能性。关于如何应对核心人员突然流失，我现在也想不出什么好的应对方法，只能希望在以后的软工课上，那些已经确定要离队的同学能够把自己的想法提前告知其他人吧。
第四部分 学到的知识点
一）需求阶段
应该通过调查掌握用户真正的需求，而不是臆想一个用户的需求。我们当时就犯了这个错误，没有经过大量的调查就“确认”了需求，导致之后的用户使用情况和预期有一定偏差。
二）设计阶段
设计功能的时候不但要考虑用户需求，还要考虑所使用的开发工具的局限性。例如有些复杂的功能，在买有开源工具的情况下，手写起来非常困难，这时就要考虑这个功能是否真正值得实现，或者能否被其他相似的功能代替。
三）实现阶段
开发的过程应该“敏捷”起来，负责前端的同学不能只顾前端 ，负责后端的同学也不能只顾后端，每个人都应该至少了解一下负责其他模块的同学都在做什么，这样对团队的协作开发有很大的帮助。
四）测试阶段
测试应该从用户的角度出发，除了找功能和排版的bug之外，还应该考虑用户体验的问题 。测试人员应该把自己想象成普通的用户，把自己的使用体验泛化成普通用户的使用体验，从而对产品提出改进意见，这样的意见对产品的后续开发有着很大帮助。
五）发布阶段
应该找到合适的发布平台，这个平台应该是我们预期的用户群体可以很方便接触到的。
六）维护阶段
对于已经发布后的项目，如果遇到bug或者用户反馈应该立即做出相应修复，以把损失降到最小，这也是开发者对用户负责的一种体现。
第五部分 理解与心得
本学期的软工课让我理解了沟通的重要性。沟通可以让结对的两个人了解各自的任务，也可以让结构松散的开发团队重新凝聚在一起。凡是包含一个人以上的开发团队，如果人员之间沟通不畅，那么团队就不能发挥其最大的效率，1+1就会小于2。沟通还是一门艺术，它不是单方面的灌输也不是机械的提醒与告知，它的宗旨应该是增进沟通双方对对方的了解。
总而言之，“学会沟通”就是本学期软工课教给我最重要的知识。