| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 锻炼软件开发能力，学习团队协作方法 |
| 这个作业在哪个具体方面帮助我实现目标 | 对软工课程做一个总结回顾 |
| 以前提问的博客 | 构建之美——个人阅读作业2 |
一、提问回顾
问题1
教材2.1.2中写到
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
作者提出单元测试必须由代码作者来编写，因为代码的作者是最了解代码的人。但人的思维都是有局限性的，如果代码的作者真能思考到代码的方方面面，那就不会有那么多bug了，而且很多bug也正是由于代码作者写代码时候的思维局限性所导致的。
所以笔者认为单元测试可以由代码作者来参与编写，因为代码作者确实更了解代码，知道怎样更快的写好单元测试。但与此同时，也应该有非代码作者的参与，非代码作者往往能提供不一样的思路，有角度不同的理解，更容易想到代码作者的思维盲区，这样写出来的单元测试才能更加全面。
经过这学期软工课程的学习，对于单元测试也有了更深入的理解。当然，单元测试由代码作者与代码作者之外的人共同参与效果会更好，但在团队项目的实践中，发现其实并没有那么多时间，那么多人手来做测试。这种情况下显然是由代码的作者来写单元测试更为合适，在时间并不充裕的情况下，相对于其他人而言，作者能更快地写出覆盖更全面的单元测试，这也是一种对资源的最大化利用。
问题2
教材3.1中写到
对于这些任务，一个成熟的软件工程师应该能够降低任务交付时间的标准方差。如果你能长时间稳定而按时地交付工作的结果，内部和外部的顾客就会对你的工作有信心，更喜欢与你合作。
作者认为一个任务交付时间稳定的软件工程师，大家会对他更有信心，更喜欢跟他合作。如果所有人都这么认为，会不会因此导致很多软件工程师可以更短时间内完成任务却特意花更长时间呢？因为他们不能保证每次都可以在短时间内完成，另外毕竟市场和公司都喜欢任务交付时间稳定的软件工程师，这样拉长时间还更加轻松，何乐而不为。
当然从整个行业生态来看，在这种交付时间稳定更好的标准下，偶有这种能力资源的“浪费”也是可以接受的。但是否有更好的衡量标准可以避免这种“浪费”呢？
通过团队项目的实践，发现诚如助教所言，在团队合格的管理制度下，以及配合燃尽图、代码提交、issue等方式，可以大致看出任务的完成度，PM也可以很好的规划团队每个成员的任务，很大程度上可以防止“摸鱼”现象的存在。在软件开发过程中，也发现了任务稳定按时交付的重要性。在每次分配的任务量差不多的情况下，如果团队中一个成员有时交付一个任务只需要一天，而有时却需要好几天，这会打乱团队的整体任务规划，会导致一些需要迭代的任务难以进行。
问题3
教材4.3.2中写到
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
作者认为只要有助于逻辑清晰表达，使可以使用goto的。犹记得大一时接触c语言时，老师特地说过不要使用goto，goto虽然好用，但会使程序结构混乱。
于是抱着疑惑查阅了相关资料，发现主要有两种观点。一种就是不提倡使用goto，因为容易把逻辑弄乱且难以理解；另一种提倡使用goto，因为在跳出多层循环和异常处理时比较方便且效率高，很多大型项目、开源项目，包括linux都会巨量的出现goto来处理错误。所以比较好的标准就是在错误处理的时候使用goto，其他地方都禁止使用goto吗？
在本学期的软工课程中并没有使用到goto，不过经过团队项目的实践，还是很认同助教的观点“在团队项目中尽量约束”。对于大佬而言，goto可以简化逻辑，但在团队合作中，如果需要阅读含有goto的代码，那会变得非常头痛。
问题4
教材8.5中写到
杀手功能（Core）/外围功能（Context）
除此之外，我们的竞争对手和用户已经决定了一些此类产品必须要满足的需求，不能满足这些需求，产品就入不了用户和评论员的法眼，当然，还有许多功能是辅助性的。这样，我们又得到另一种划分：
必要需求（MissionCritical）/辅助需求（Enabling）
这四种划分结合起来，就得到了功能分析的四个象限。我们以一个英汉词典软件为例子来说明。
在教材后面也提到了，比较核心的功能要尽量做的好，达到行业最佳，而那些辅助性的、外围一点的功能则可以以最低代价来维持，甚至不做。
但现实中很多情况下这样做不太合理，很多软件的核心功能由于行业技术水平的限制，做的再好也就那样，用户甚至感觉不出来有什么差别。但那些外围、辅助性的功能反而是用户最能感受到差别的，比如界面操作的舒适度，比如有多种皮肤，用户可以自由定制。很多原版的软件和游戏不火，反而那些抄袭的软件或游戏被更多人欢迎，这些抄袭软件甚至再在核心功能上对比原版软件还略有不如。但就是因为它能提供舒适的操作界面，个性化的定制，容易上手等非核心特性，反而与其他软件拉开了差距，取得了胜利。
经过团队项目的实践，对这个问题的思考有了一些变化，核心功能是开发者眼中最重要的，但在用户眼中，使用舒适度才是最直观的。但还有一个问题，核心功能是核心竞争力，如果核心竞争力没有胜过其他软件，那么已经使用习惯了其他软件的用户不会因为界面更加好看等原因来使用你的软件。所以最好还是能做到核心功能与外围功能兼顾，既要做到有核心竞争力，也要有让用户使用体验更好的细节。当然，如果实在是资源不足，那还是要优先完成核心功能。毕竟使用体验再好，核心功能不行，这软件也是没人会用的。
问题5
教材16.1.5中提到
统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。
第一眼看到这个70%，就觉得难以相信。但经过仔细思考，觉得可能是一种统计偏差。当叫你去思考拿手领域外的创新时，你可能随便就能说出很多，但因为并不了解哪些是可实现的，哪些是有实际意义的，所以可能你说的99%的创新都是无意义的。而如果让你去思考领域内的创新，你可能思考半天也说不来，原因之一是长期处于这个领域，思维会被束缚，另一个原因则是你相比于外行人，更清晰地知道哪种创新是真正可行的且有价值的，所以在思考中就把很多想法给毙了。
所以在拿手领域外创新其实并不比领域内容易，只是思考方式可能与那个领域的工作者不同，加上“不知者无畏”，可以提出很多有意义或无意义的想法。此外，创新者就算在拿手领域外有了一个好的创新想法，最终还是需要那个领域内的工作者来将这个想法改进、细化，使这个想法真正有实现的可能并具有实际的价值，其实这个过程也算是一种“创新”。可以说是创新者提供了一个思考方向，领域内的工作者依着这个思考方向进行创新。
对于这个问题的思考大抵还是与以前相同，或许会有少数人在拿手领域外进行了创新，但他们只是提供了一个思考方向，而领域内的工作者则依着这个思考方向进行创新。
二、在实践中学习
需求
在需求分析阶段不能自己主观认为有某些需求，而需要采用发问卷等方法调研是否真的存在某些需求。在定需求时要多与潜在用户沟通，积极征求建议。NABCD分析是一种很有效的方法，可以更明确的确定软件需要的功能。
设计
设计阶段需要充分调研某些技术，避免技术风险。在团队协作设计中，还需要使用原型设计，UML图，ER图等来进行交流。设计阶段还需要考虑充分，设计完善，避免在开发过程中发现需要增加新功能等情况，打乱开发计划。
实现
在团队合作中，例会非常重要。既能有效推进项目开发，也能防止某些成员“摸鱼”。PM通过例会也可以更好地把控团队开发进度，以及每个成员的开发情况。发现有些成员任务量过大时可以动态进行调整。实现过程中文档也很重要，如代码设计文档，接口文档等，一有改变都需要实时更新并通知团队所有人。
测试
测试应该最开始就有一个测试计划，单元测试还需要在开发阶段随着代码的编写同步进行。如果全部代码都等到最后阶段进行集中测试，那修bug可能修到让人绝望。在开发阶段结束后要进行的测试应该是压力测试，性能测试等。
发布
发布阶段需要团队积极宣传，宣传也是一门技术，所以最好还是有专门的宣传团队。但在本学期的软工项目中，还是要发动团队中每个人都为宣传贡献一份力量，如制作海报，写宣传语，制作宣传视频等。
维护
维护阶段需要积极收集反馈并进行更新，对软件进行日常维护等。对于用户反馈中bug相关的问题需要及时修复，对于一些功能的改进建议等需要收集整合，在下一阶段的迭代开发中可以参考。
三、个人总结
本学期的软工课程终于落下帷幕，从个人博客作业到结对编程，再到团队项目，花费了大量时间投入到了这门课程中，也从中收获了大量知识与经验。
个人博客作业帮助我对软件工程有了一些理论上的认知与思考，但仅仅只有理论没有实践，所以还存在着很多疑惑，之后的结对编程和团队项目则是真正的实践，许多疑惑在实践中一一印证，得到了解答。结对编程通过与伙伴进行合作编程，认识到了代码规范的重要性以及设计的重要性。在团队项目的例会中学习到了沟通交流的重要性，团队中各成员分工合作，完成各自的任务，最终做出一个团队项目，这个中体验还是比较有趣的。从这门课程中学会了很多，交流、合作、规范、设计......，学到了很多技术、能力，更大的收获是宝贵的经验。
经过这学期的软工课程，对于软件工程中的各种方法有了更深入的理解，也收获了宝贵的实践经验，相信在之后的项目开发中，这些宝贵的经验都会派上用场的。