| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) (北京航空航天大学 - 计算机学院) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 实现自己在软件工程方面的个人素质的飞跃 |
| 个人提问博客链接 | BUAA软工第二次作业 |
对曾经提出的问题进行解答
关于增量编程，如何解决增量到一定程度后系统过于臃肿的问题？（第6章）
随着软件的开发，软件的功能在通常情况下都是越来越丰富，但随之而来的就是软件的臃肿。由于在我所在的项目开发中，更多的是负责前端相关的工作，所以对我之前所问的，关于拥有复杂逻辑的后端开发基本没有涉及，不过从同伴的代码中还是可以窥知一二。在写好一个功能后，为了避免增量开发导致新增bug，要尽量避免修改这个功能的代码，虽然这并不能保证新功能的开发不会触发老功能代码中潜在的bug，但至少不会因为随意的改动而触发新的bug。如果老功能必须进行代码的改动才能跟上新版本呢？那就尽可能以新增代码的方式进行改动，而不去改动现有的代码。
关于开发与测试的对立（第7章）
实际开发的时候，感觉开发和测试并不是像某些课程一样，处于一个完全对立的状态。毕竟在软工课程上，开发人员和测试人员的利益都是一致的，最终目标都是交付一个能够正确运行的软件。但如果在实际开发团队中，将开发人员与测试人员放在一个对立的位置（比如测试人员测试出bug后惩罚写bug的开发人员或让他加班修bug），就有可能导致开发和测试的矛盾，影响软件工程的实施。
关于bug hell的设定（第11章）
这个问题倒是在开发中没有遇到，我们也没设置这样的bug hell。主要的原因是，我们的程序规模较小，不太可能出现人均写出大量bug的情况。并且在开发的时候，遇到的bug都是那种直接导致功能无法实现的bug，这种bug在发生时就会用最快的时间排除。
关于“小强大扫荡”，如何确定bug的数目（第13章）
这个事情仔细想来的话，标准可以有很多种。不仅是从发现的问题或者修复的问题来划分不同的bug，也可以根据bug的严重性进行划分。像GitHub的Issue一样，对每个bug划分不同的size，可能是一种好方法。
关于软件工程师的职业道德（第17章）
这件事情实施起来还真不好讲。在开发的过程中，我们也曾经有过利用破解版插件进行开发的计划（虽然最后没有实施）。今后做类似开发的时候，应当注意避免此类问题，不仅是道德层面，更要小心法律风险。
新的问题
- 关于开发过程中人员的分工，是按前后端划分（我们在\(\alpha\)阶段的做法），还是按功能划分（在\(\beta\)阶段的做法）效率更高？个人感觉按前后端划分更适合技术水平不太高的团队（或起步阶段），熟悉开发流程后就可以按功能进行人员划分。不过是否还有其他更好的解法？
- 当团队成员中沟通不是那么便利的情况，如何保证开发进度仍然处于计划之中？我们的做法是定期开会，汇报各自进度。有没有其他的方法呢？
学到的知识点
需求
对需求的分析是软件工程的开端。好的开始是成功的一半，在需求阶段，需要投入一些精力，通过各种调查手段，结合团队内部的分析，对用户的需求下一个明确的定义。在这一阶段，应该尽可能重视现实的调查结果，而不能陷于开发者自己的美好想象中，否则就会出现产品和用户需求不匹配的情况。
设计
在设计阶段，可以借助一些有效的设计工具，前端可以使用框架绘制工具，以现有网站为模板也是一种可行的方法；后端则可以利用UML，Modeling Language等工具定义代码结构和功能。
实现
开发的过程中可以使用Git Issue，Pull Request等管理代码，避免不同成员提交导致的代码冲突。
测试
前端测试比较复杂，了解的可用框架也不多，更多的是人工测试。在这种情况下，要注意对测试结果的描述，尽可能在不丢失细节的情况下描述得规范一些，并且要更多关注测试结果的变化。
发布
发布时，要注意重新检测bug，因为服务器配置可能不与本地相同，可能会出现相关问题。对这类问题进行排查时，则要结合本地运行结果进行对比，看看bug是不是因为在服务器上部署而产生的。
维护
发布后，要注意浏览访问量等后端相关数据，并查看用户反馈，为维护做准备。
课程心得
课程虽然占用时间很多，但总体上看，收获和投入的时间是成正比的。希望这门课程中所积累的宝贵开发经验，能够成为今后工作学习的筑路基石，