提问回顾与个人总结
| 问题 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 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图表能够从设想到实现。
