「软工博客作业」：提问回顾和个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	学习有关软件开发的方法论，熟悉基本的软件开发流程，通过“做中学”提高软件开发的能力
这个作业在哪个具体方面帮助我实现目标	对整个学期的学习和开发进行总结

一、提问回顾

博客链接：「软工博客作业」：《构建之法》阅读与思考

Q1: 需要对私有的函数或方法进行单元测试么？

单元测试应覆盖所测单元的所有代码路径， 包括错误处理路径。 为了保证代码覆盖率， 单元测试必须测试公开的和私有的函数/方法。 ( From Page 27)

对于私有函数或方法，通常不需要进行单元测试。

单元测试主要是对公共接口进行测试，以确保其功能的正确性和稳定性。私有函数或方法是为了在类内部使用的，不直接对外提供接口，因此不需要单独测试其功能。但是，这并不意味着私有函数的功能正确性无法得到验证——私有函数最终通常都会被共有函数调用，因此它的正确性可以在公有函数的测试中得到验证。

Q2: 技能的反面为什么是解决问题？

巴克斯顿说技能的反面是 “Problem Solving” — “ 解决问题” ， 这个听起来有点绕， 我们看看 IT 人士熟悉的一个例子吧。 一个 IT 专业的大学生来面试， 简历上写“技能： 精通 Visual Studio C# 编程” ： 于是面试官请他用 Visual Studio IDE 写一段程序。 一个 “不精通” 的面试者的编程过程实际上就是一个 “解决问题” 的过程——

嗯， 怎么开始一个 C# 的命令行程序呢？
定义数组是怎么弄的？ 是 “int [] arr"还是"int arr[]“还是"ArrayList”, 还是"Array”。 哦， 我平时都是上网査的。哦，我不知道还有 MSDN 网站。
嗯， 为什么编译没过呢， 哦， 这里少一个分号。
嗯， 怎么设断点？ 怎么定义命令行参数？ 额， 我要査一査…… (From Page 61)

经过一学期的开发和学习，我更加坚定了之前的看法——“技能的反面”应该更精确的描述为“不能条理清晰、方法得当的解决问题”，只不是仅仅的简单描述为“解决问题”。

就像我在《阅读与思考》这篇博客中写的：“即使是一个可以熟练使用C#的程序员，C#的很多特性也无法完全掌握，因此他仍然需要不时的查看技术手册。但是他这种“有意识”解决问题的过程，是有方法、有条理的，我们不能说他没有掌握“C#程序设计”这一技能。相反，故事中的程序员解决问题的过程是手忙脚乱的，没有任何方法可言，自然谈不上技能”

在这学期的团队开发过程中，我们遇到了无数个前端技术上的问题。尽管这些问题都不是看一眼下意识就可以解决的，但是我们知道可以从哪里查到相关的资料、文档（MDN Web Docs、框架官网…），可以在哪些QA网站查到可能的答案（stackoverflow、csdn…），因此最终我们都能顺利的解决它们——这种解决问题的方式尽管不是“下意识”的，但是是有条例的、有方法论的，因此仍然可以说“我们掌握了技能”。

Q3: 程序中是否应该使用goto？

使用 goto 语句在程序中是一个有争议的话题。

虽然goto语句可以使程序的控制流更灵活，但滥用 goto 语句可能会导致代码变得难以理解和维护。当程序中存在大量的 goto 语句时，代码的逻辑流程会变得混乱，增加了代码的复杂性，使代码难以阅读和调试——这对于强调可维护性、可读性的软件工程来说， goto 带来的负面影响无疑是巨大的。

但是，我们也不能以偏概全。对于一个控制流本身非常复杂的程序（例如多层循环嵌套），适当的使用 goto 可能会让程序的可读性更高，同时也便于维护。因此，在这种情况下，我们可以在征得队友/同事的同意下使用 goto。

总的来说，我们对待 goto 的态度应该是——“小用怡情、大用伤身”

Q4: 是否应该为了“更好的了解用户行为和需求”对用户数据进行自动收集？

有些需求的目的是要 “更好地了解用户的行为和需求” ， 例如， 我们要在软件的各个功能点加上收集信息的代码， 并在后台实现数据收集 、 整理、 报告和数据挖掘（ Data Mining )工作。 此类技术在一些公司叫作 Telemetry。 (From Page 158)

为了更好地了解用户行为和需求，自动收集用户数据可能是有益的，但必须在合法、透明和安全的基础上进行。因此，我们应该遵守隐私法规，获得用户的明确同意，并提供透明的数据收集目的和数据处理方式。此外，用户应该有权访问、控制和删除他们的个人数据。

Q5: 要求敏捷团队“多功能型”是否会带来混乱？

多功能型主要针对敏捷开发的上下文来说。实际开发时，每个人的职责分为基本职责和附加职责，基本职责是分工明确的，比如某个人负责某个业务接口开发。附加职责比如某个人负责和外部团队对接，某个人需要帮助另一个人进行某些复杂代码开发等，目的是合理协调团队资源，加快开发进度，适应高频率的持续集成发布。

二、知识点总结

需求

我了解到了用于需求分析的NABCD模型——即需求、做法、好处、竞争、推广。

设计

我了解到了很多设计方法——思维导图、用例图、数据流程图、UML等等。

实现

在实现过程中，我们使用了git、github进行代码管理，同时使用notion对每个人的任务进行分配和安排，同时使用CI进行代码持续集成。

测试

我学习了如何进行软件测试，包括单元测试、集成测试、系统测试等，熟悉测试工具的使用，在保证软件质量的同时提高了软件的可用性和可靠性。

发布

我学习了如何进行软件部署，以及如何通过多种渠道、多元方式进行宣发。

维护

学习如何快速定位和解决软件故障，及时对用户反映的bug进行修复。

三、心得体会

在寒假的时候，我便和几个志同道合的同学组好了队，准备在新学期一起选择罗杰老师的软工。当时几乎是义无反顾——因为很早就听学长们说罗杰老师的软工“非常硬核”，“可以体验真实的开发场景”等等，所以对着门课充满了憧憬和期待。

说实话，在我刚刚进入这门课程的学习时，其实是有后悔的——开学还没上课就4个ddl加身，结对编程时和我不熟悉的C++、CMake、VS斗智斗勇，团队开发前调研“所见即所得编辑器”的实现方式时几近崩溃… 尤其是看到周围选其他老师软工课的同学都 闲云野鹤、优哉游哉的时候，我不禁更加怀疑自己当初的选择。

但是，当团队开发真正开始的时候，我开始渐入佳境，开始享受这个过程——享受alpha阶段冲刺前大家一起熬夜修bug的日子；享受每次组会上大家一边发着牢骚一边齐心开发的时光；享受看到自己写了几天的功能能够跑通；享受看到发布的宣传贴浏览量从几十涨到几百再到一千多…

可以说，团队开发是一个让我痛并快乐着的经历。尽管开发的时候偶尔会比较折磨，但是我知道我不是孤单一个人。在我的身边，有充满奇思妙想才华横溢的PM强哥、无所不知无所不能的哲哥、设计能力和代码能力都超强的楠哥、美工能力堪称顶尖的燕老师、担当团队核心的杰哥、稳健又可靠的后盾朱哥… 有了他们的陪伴，我心中充满了安全感，开发起来也充满了干劲和动力。能和他们一起并肩作战，是幸运，也是荣幸。

（最后再附上 gg=G 大家庭的合照