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

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	学习有关软件开发的方法论，熟悉基本的软件开发流程，通过“做中学”提高软件开发的能力
这个作业在哪个具体方面帮助我实现目标	这次作业可以让我了解软件开发的基本理论知识，同时提问题的环节也能让我明确自身的知识漏洞和不足。

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

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

在我看来，private函数（或者方法）都是一些实现比较简单的功能、并且不希望被用户单独调用的函数。而私有函数最终都会被public函数调用，最终实现一个更为复杂的功能。对外部调用者而言，private函数都是不可见的，而public函数才是类功能的最小单位。在我看来，单元测试就是对最小的功能单元进行测试。而基于上面的理解，只需要测试public函数即可完成单元测试的目标。

书中的观点让我对自己一直以来的看法产生了怀疑，于是就在stack overflow上搜了搜，结果发现大家对这个问题是众说纷纭、争论不休。不过大多数人还是倾向于“不对私有方法进行测试”——

I do not unit test private methods. A private method is an implementation detail that should be hidden to the users of the class. Testing private methods breaks encapsulation. —— Luke

Unit tests I believe are for testing public methods. Your public methods use your private methods, so indirectly they are also getting tested. —— scubabbl

In general, you don’t want to break any encapsulation for the sake of testing (or as Mom used to say, “don’t expose your privates!”). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there’s another class in there struggling to get out. —— Dave

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#程序设计”这一技能吗？相反，故事中的程序员解决问题的过程是手忙脚乱的，没有任何方法可言，自然谈不上技能。因此我认为，“技能的反面”应该更精确的描述为——“不能条理清晰、方法得当的解决问题”

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

函数最好有单一的出口， 为了达到这一目的， 可以使用 goto。 只要有助于程序逻辑的清晰体现，什么方法都可以使用， 包括goto。 (From Page 75)

从大一上C语言开始，老师们就一直跟我们讲——“尽量要在程序中使用goto语句，这会让程序的控制流难以追踪”，还不时的搬出Dijkstra的《go to statement considered harmful》加以佐证。渐渐的，“goto有害”似乎已经成为程序设计的金科玉律了。不过，书中却说“可以使用goto”，似乎是对“常识”的一种挑战。 对于书中的说法，我其实是部分同意的——在日常编程的过程中，我们经常会遇到多层循环嵌套的情况，而goto是跳出深嵌套的一个有力工具，可以非常简洁的解决问题。不过不可否认，goto破坏了代码的结构，让高级语言程序写的像汇编，大大降低了代码的可读性。尤其是对于强调可读性、可维护性的软件工程来说，goto的使用明显是弊大于利。最后贴一个经典插图

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

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

荣老师在课上经常说——“不要奢求让用户说出自己的需求，因为大多数用户都不知道自己的需求是什么”。为了能够更好的了解用户需求，直接对用户使用软件的过程进行追踪无疑是最有效的。但是，这样直接在软件中加入收集信息的代码，难免会对用户的个人隐私造成威胁，而且对于“是否过度收集”也难以界定。

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

软件项目的团队各式各样， 假设一个团队做得还不错， 现在要变成敏捷流程， 那团队要做下面的改变：

1. 自主管理： 以前领导布置了任务， 我们实现就可以了， 现在要自己挑选任务； 每次Sprint 结束之后， 还要总结不足， 提出改进， 并且自己要实施这些改进。 “自主管理”不等于“没有管理”。

2. 自我组织： 以前做好自己的事情就好了， 安心下班。 现在每个人要联合起来对项目负责， 有人工作落后了还要帮助他改进， 项目缺少某类资源还要自己顶上去。

3. 多功能型： 以前规格说明书由 PM 来写， 测试由测试人员来做， 现在每个人都全面负责， 自己搞定规格说明书， 和别人沟通， 同时自己搞定测试。 (From Page 123 )

敏捷开发是以用户需求为核心，通过不断迭代、循序渐进的方法进行开发，强调的就是“敏捷”二字。要求敏捷团队“多功能性”，要求每个人都对Spec、开发、测试负责，的确会提高Sprint的效率。但是，这样是否会在一定程度上带来混乱？每个人的写作能力不同，Spec质量会参差不齐，难以起到”契约“的作用；每个人都对自己写的代码进行测试，容易受到"固定思维"的影响…最终会影响产品的质量。敏捷开发的原则有提到——”尽早并持续的交付有价值的软件以满足客户需求“，但这样通过牺牲质量来换取效率，真的可以交付有价值的软件吗？我认为，即使是敏捷开发，也应该是各司其职，把合适的人放在合适的位置上，不能一味追求”多功能性“。