| 问题 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 系统了解并参与软件开发过程，提升自身工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾以往提问，总结课程收获 |
提问回顾
以往提问
1.低层次的问题能依赖工具解决么？
书中认为一个精通xx的人应该能够解决高层次问题，而解决高层次问题要首先通过不断练习来解决掉低层次问题，才能有脑力解决高层次问题。
那在各种IDE越来越成熟的今天，像数组定义,函数名称这些IDE的自动补全都能做得非常好,另外一些像编译的依赖，断点设置，用现成的工具也能很好解决。
那能不能利用工具解决掉大部分份低层次的问题，直接去解决高层次问题呢？或者说什么时候该用工具解决什么时候该去练习呢呢?
我觉得在刚刚上手某一种语言的情况下，可以以来于工具解决低层次的问题，这也是一种很好地快速熟悉语言的过程。但是在一门长期使用的语言上，使用者应该会遇多次同样出现的问题，稍加留下记忆一下，这类问题就能少很多，所以在长期使用的语言上不应该出现过多低层次问题。
2.什么情况下该使用C++中的类?
我认为可能和语言特性有关，在C++中过度使用类可能会导致编译过慢或者性能下降?也许C++中有其他的编程范式。
3.团队该如何制定规范
对于一群没有实际经验的学生来说，有如此之多的设计流程和理论，那我们在开发的过程中是否应该制定例如每日例会的这样的规范，应该在开发流程的什么阶段设计规范，团队开发规范是否也能像软件功能需求一样进行更改?
我认为应该是有开发的规范的，比如复审、每日例会等机制。但是这个规范的制定应该是通过团队所有成员的讨论来确定下来，让大部分人都同意。同时相对于规范的制定，规范的推动可能是更加重要的一个部分，如果只有规范的制定没有推动的话，那很快规范就会变成空白。在团队开发过程中，如果规范不适用环境也应该及时更改，也需要团队所有成员一起来讨论。
4.创新不需要考虑实际问题吗?
书中16.1章创新迷思二中给出了一些反对创新人的观点这些问题固然可能是某些反对创新者的武器，但是在实际创新过程中，这些不都是非常实际的问题吗，难道创新的过程中不需要考虑这些问题吗?
- 这从来就行不通
- 没有人需要这些方案 在实际中根本行不通 大众不会理解这个创新
- 你的创新要解决的根本就不是一个问题
- 你的创新要解决的是一个问题，但是没人关心这个问题
- 这个问题早就被完全解决了
需要考虑，这些都是应该在风险规划中考虑到的问题。但是正确的态度可能是实际去调研，思考如何解决这些问题，如果可行迎难而上，如果不信就及时止损。
5.软件的缺陷是否应该在规格书中说明？
我觉得应该说明，不然用户因为这个缺陷造成损失，那这个软件的口碑和声誉就麻烦了。
实践总结
需求分析
- 通过NABCD来进行行性分析
- 通过四象限法来判断重点要做的功能
- 一定要和用户实地沟通，不要空想需求
- 我们开发阶段和用户沟通较少，很多功能都是觉得还行就开发了，导致最后使用体验一般。
设计
- 要做好风险估计，对可能出现的技术或其他风险留好备份方案
- 在团队项目中，拖拽功能功能就是明显就没有做好风险估计。拖拽由于小程序和echarts不支持，实现非常复杂，而且造成其他功能无法添加最终在beta阶段被砍掉。另外由于前期没有规划到，我们beta阶段发布时基物实验已经做完了。
实现
- 要先制定接口再开始开发，接口一定要用文档记好，及时更新
- 前后端开发同一功能模块要先后端再前端，这样前端在编写时能够调用后端的功能，一方面是编码速度更快，另外一个方面也是在帮后端进行测试。
- 不要把已知bug留到测试阶段，这样会造成破窗效应，其他人的代码质量也会受到影响，最好时及时构建和及时集成，避免潜在bug同时增加大家开发热情。
测试
- 要制定测试计划，开发过程中测试要安排相应的任务量，要边开发边测试，越早发现bug修复的代价可能就越小。
发布
- 发布要保证无bug，如果有某些非核心功能发布时候还存在bug，可以先注释掉，发布完后再修复。比较存在bug的影响远大于功能不过多。
维护阶段
- 维护阶段要和用户多沟通，听取他们的反馈，也是为之后版本开发做准备
软工心得
个人项目
在个人项目阶段，我完成了自我分析、调研CI/CD、阅读《构建之法》、案例分析几个作业，并完成了三篇博客。在这个过程中，自我分析案例中我不但分析我在计算机行业的发展，也通过阅读他人博客了解到大家对应计算和计算机学习的看法，M同学的二十万行算法题让我颇受震撼，Z同学做好每一件事的态度让我敬佩。调研
CI/CD
，让我对自动化开发和部署有了了解，也算搞懂上个学期ruby课的提交方式。构建之法和案例分析，在我脑海中种下了关于软件工程的种子，也许以后在某个不经意的时刻就会破土发芽，有恍然大悟的感觉。
结对项目
结对项目我和Mokoghost同学进行了结伴编程。我们采取的是每人负载一个模块的方式进行开发，我们采取的是先集中讨论确定架构，再各自开发不同模块的方式同步进行。通过结伴编程，一方面了解熟悉我对
CI/CD
，
code with me
linux
中文件系统，
gitlab
的
issue
评论规范有了了解，另一方面实际开发中让我对单元测试有了更加深刻的认识:充分的单元测试保证了你每次更新架构后能够进行一次回归测试，让开发者无后顾之忧。同时单元测试也能让你对于需求有更加深刻的认识。在和
Mokoghost
合作中，
Mokoghost
严谨的态度，清晰的思路也让我粗心、思路混乱的我学到了很多，特别是
Mokoghost
同学指出的非
FileSystem
级别的问题不应该放在
FileSystem
，让我恍然大悟，同时有了
Mokoghost
编写的上千行的单元测试，才能让我体会到存在单元测试情况下，变换某个模块而不用担心引入新的bug的快感。如果是我，我肯定就是随便写写了
团队项目
在团队项目中，我们选取了微信小程序平台进行Sunny图表的开发。在开发过程中我从无基础到熟悉了小程序开发 的全套流程，也学会了html一些布局构图的基本思想，基本的css调节方式，javascript的同步异步、原型链等知识。在开发的阶段中，经历了alpha阶段的发布前几天完成功能的慌乱后，更加深刻地认识到了工程化思想对于软件开发的重要性。在beta阶段，我开始担任PM，经历beta阶段开发和课上老师的沟通交流后，我对于风险管理，团队管理，测试计划这三个方面有了更加深刻的认识，特别是风险管理，我们遇到了发布后考完基物，表格技术上无法实现流畅输入，再回过头来看《构建之法》中风险管理一栏有了更加深刻的认识。在团队管理上，我作为PM有失职的地方，我没能成功调动起大家的积极性，当然也和我自己积极性不是特别高有关。另外，通过阅读其他团队对于软工的思考，也让我学习了很多，也让我在想摸鱼的时候，又能有重新开始工作的念头。最后感谢万里阳光号的所有队友，让Sunny图表能够从设想到实现。