北航软件工程 2022 提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022年北航敏捷软件工程社区-CSDN社区云 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结-CSDN社区 |
| 回顾的提问在哪里 | 见此 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾和总结课程的收获与体会 |
一、问题与解答
北航软件工程 2022 阅读与调研作业 - 人生就像一盘棋 - 博客园 (cnblogs.com)
1. 单元测试必须由最熟悉代码的人（程序的作者）撰写么？
我认为作者说得太绝对了。程序的作者可能有很多情况都没有考虑到，如果他写单元测试的时候仍然没有考虑到，那就测不出这方面的问题。
现在我仍然坚持我的看法，单元测试可以由测试人员撰写。毕竟我在团队项目中就担任测试工作，因为有完善的的文档，没有遇到什么阻碍。
2. 不包含调试信息的“Release”版本程序是如何分析效能的？
作者在第 31 页附近以使用即时编译的 C# 为例介绍了基于“抽样”的效能分析方法。但对于直接编译为机器码并经过优化的 C/C++ “Release” 版本程序，有些函数被内联，效能分析程序如何能跟踪栈帧并采样得到函数的调用情况？
可以通过调试或采样等方式，获得大致分布。
3. 如何体现出解决“小问题”的工作量？
实际情况中，如果只是解决一个“小问题”，老师可能会质疑你的工作量。比如一个三分钟的答辩，评委自然是不会太关心项目的实现细节的，比如你的手册有多详细，代码有多规范，错误处理有多稳健等等。但如果从宏观上看只是解决了个“小问题”，怎么能出类拔萃？
主要看应用场景和价值。如果解决的问题虽然小，但让人觉得应用场景广泛、很有价值，别人也许就会工作量的大小了。
4. 书中介绍的微软的那一套代码规范是否值得推荐？
作者是微软人，当然免不了“夹带私货”。但我感觉 Win32 的代码由于函数的“抽象泄露”和变量的匈牙利命名法是格外的难懂（也有人这么认为但我忘了出处）。ANSI C 风格的代码感觉更为普遍，我也更喜欢。而苹果更是设计了现代的 Swift 语言，让代码就像文档一样易懂。我觉得“代码即文档”能够真正提高效率。
现在我仍然坚持我的看法。不过想补充一下，有规范总比没有好。本次团队项目就因为没有一开始制定规范（含文件组织、代码编码与风格、UI 字体图标对齐等）而在后期产生了很多麻烦，影响了效率。
5. 结对编程是否会对效率产生负面影响？
根据个人经历，如果实际写代码的人（“驾驶员”）已经有了清晰的设计，而由于结对过程中，“领航员”要经常提问，在这种情境下“驾驶员”有时也会自言自语，这些对效率可能会产生负面影响，并且未必会随着时间的流逝而消除。
现在我仍然坚持我的看法。不过想补充一下，我认为结对编程比较适合有挑战性的项目，即单独一个人并不能拿定主意，需要在两人讨论中逐渐理清思路，并且互相监督确保代码的正确性和完成进度。在这种情况下，结对编程应该是能提高效率的。
二、知识点回顾
需求：NABCD 模型
“NABCD”是由 Need、Approach、Benefit、Competitors、Delivery 五个单词的首字母组成，分别指需求、做法、好处、竞争、推广五部分。我们在需求分析阶段用此方法论问了五个问题：我们的创意解决了用户的什么需求？我们有什么方法来解决用户的问题？我们的产品或服务会给用户带来什么好处？我们的产品有没有类似的竞争者，他们的产品怎么样？我们如何推销你的产品？详见 【Beta阶段】计划阶段要求 - NABCD需求分析 - 灵境 | week12 - 头发茂盛队 - 博客园 (cnblogs.com)。
设计：用户体验
用户体验（User Experience，UX）是用户在使用产品过程中建立起来的一种纯主观感受。对于一个产品而言，我们不能仅满足功能完善——能用，而是在设计功能是就要考虑到用户的使用感受——好用。UI/UX 一些表面上的细节看似不重要，实际上是用户接触产品首先感受到的，通常直接与用户对产品的评价挂钩，若出现严重问题甚至可能影响功能。详见 Beta阶段开发 - 迭代事务 - UMeta - UMeta (coding.net)。
实现：项目进度管理
在规定的时间内，拟定出合理的进度计划，在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。我们借助 Coding 平台提需求或缺陷，采用 scrum meeting 的方式讨论问题、监督进度，这套机制非常值得应用到今后任何需要合作的项目中。详见 【会议目录】Beta阶段会议记录目录 - 头发茂盛队 - 头发茂盛队 - 博客园 (cnblogs.com)。
测试：自动化测试
自动化测试是提高测试效率和保证软件质量的有效手段。我后端学习使用了 SpringBoot 下使用 JUnit 和相关组件的测试方法，前端学习了 AirTest 测试工具，体会到敏捷开发的小项目根据列出的测试清单手测效率更高，但大项目固化样例后用自动化工具确保回归测试则非常必要。详见 【技术博客】Unity 测试调研 | week16 - 头发茂盛队 - 博客园 (cnblogs.com)。
发布：逐步冻结
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。临近发布时，对于一些非常细节的 UI 问题，PM 要求“冻结”这些 UI，不再随意修改了，因为很可能引入新 Bug。后续一些功能也被“冻结”，这些功能都经过全面测试，所有的 Bug 都解决了，功能进入稳定状态，在下一个版本前不再碰与此功能相关的代码。最终保证了稳定发布，详见 【Beta阶段】软件发布声明 - 灵境 | week16 - 头发茂盛队 - 博客园 (cnblogs.com)。
维护：结构化维护
用软件工程思想开发的软件具有各个阶段的文档，这对于理解和掌握软件功能、性能、软件结构、数据结构、系统接口和设计约束有很大作用。维护时需从评价需求说明开始，搞清楚软件功能和性能上的改变；评价设计说明文档，复查、修改设计说明文档；根据设计的变动修改程序；根据测试文档中的测试用例进行回归测试；最后，把修改后的软件再次交付使用。在发布结束后，我们继续提了一些缺陷和需求，并且根据用户使用情况，发现一些功能缺乏引导，用户不知道去主动使用。预计在修复和完成这些维护任务后，尝试发布 AppStore。详见 beta总结与完善 - 迭代事务 - UMeta - UMeta (coding.net)。
三、收获与体会
通过最早的个人博客作业，我阅读了《构建之法》，对软件工程有了较为宏观的认识，同时了解了持续集成/部署（CI/CD）工具。对 CI/CD 真是觉得相见恨晚，上学期数据库大作业的前端是不断通过手动编译上传服务器的方式部署的，效率极其低下。我还调研和分析一些身边常见的音乐软件，应用并熟悉了软件工程的一些原理。
通过结对编程作业，我提高了与他人密切协作的能力。我认为结对编程比较适合有挑战性的项目，即单独一个人并不能拿定主意，需要在两人讨论中逐渐理清思路，并且互相监督确保代码的正确性和完成进度。
而这次团队作业是我认为体验最好的合作经历之一。组里有带队经验丰富的 PM fzc，思维活跃、乐于投入的 PM yrb，技术过硬、让人安心的 Unity 大神 lyyf，还有审美在线的 gcy，封装优雅的 lhy，码力神速的 xwq，大家齐心协力，共同为项目的成功做出了卓越的贡献。我主要负责测试和 iOS 平台的打包发布，对于我提出的连环炮般的、强迫症似的细节缺陷和适配需求，大家也都能积极地修复和完成，非常省心！项目进度和质量管理上，我们借助 Coding 平台提需求或缺陷，利用 scrum meeting 的方式讨论问题、监督进度，这套机制非常值得应用到今后任何需要合作的项目中。测试方面，我后端学习使用了 SpringBoot 下使用 JUnit 和相关组件的测试方法，前端学习了 AirTest 测试工具，体会到敏捷开发的小项目根据列出的测试清单手测效率更高，但大项目固化样例后用自动化工具确保回归测试则非常必要。
总体来看，软件工程这门课给我们创造了一个不错的“做中学”的机会，除了前期工作量太大以外，整体还是不错的体验！
