软工个人作业 1 - 阅读与提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	熟悉并在实践中体会软件开发流程，学习软件构建思维，提升编码能力
这个作业在哪个具体方面帮助我实现目标	通过阅读了解了软件开发与团队合作的基本流程、软件工程师需要具备的个人职业素养

文章目录

软工个人作业 1 - 阅读与提问
- Q1：Build to Win 是种种技术突破最好的试金石吗？
- Q2：单元测试“不自动”的限制在哪里？
- Q3：不在变量名中补充尽量多的信息是合适的吗？
- A1：Boss Driven Process 在这个时代未必仍是官僚的代表
- Q4：个人软件开发流程记录的意义
- Q5：挑选舞伴——什么是适合结对编程的双方

Q1：Build to Win 是种种技术突破最好的试金石吗？

Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现、技术突破最好的试金石。

—— Page 14

笔者困惑的本质或许应该换成：

“科学发现的价值是否需要靠商业应用来衡量？”
以赢得用户为出发点构建的产品及其衍生技术线是否真的能够触发有价值的研究，而不是对商业模式 / 时代风口做出的 tradeoff ？
- 正如俗语所说：“如果你手里有一把锤子，所有东西看上去都像钉子。”

根据阅读书籍后对软件工程概念的理解，这里我选择的措辞是商业应用而非工业应用。

上图摘自 2021 年数字货币与金融科技创新高峰论坛上李毅中的讲话。根据实践经验，我们知道一项有趣甚至具有特殊价值的技术突破并不一定能够转化为成熟的、系统的、可量化的软件产品（科技转化率最高也不到 30%！），而转化为软件产品之后，它也并不一定能够在市场上赢得足够多的用户，与竞品竞争的过程甚至可能折损产品的“技术含量”（比如在界面和互动上投入更多的时间与资金）——我们可以以此为硎石就基本否决了这项技术研究的启发式意义吗？笔者亲身参与的一些学界 - 工业界合作项目就因为需要在时间和成本等非技术因素上“赢得用户”，修剪了相当大一部分具有研究意义的技术路线。

Q2：单元测试“不自动”的限制在哪里？

阅读 Chapt2.1.单元测试 一章时，我了解到：

单元测试应该覆盖所有的代码路径（包括错误处理路径、所有公开 / 私有的函数和方法）；

单元测试应该集成到自动测试的框架中；

——Page 27

第二点让我感到尤为迷惑，因为在我的个人体验和阅读总结中，我感受到单元测试实际上是一个非常“不自动”的东西。所以我的困惑是：

是否存在有效的单元测试自动化手段？
- 如果没有，其技术壁垒是什么 / 对单元测试的自动化要求是否是不合理的？

此时与编译器 / 程序分析场景不同，对程序“正确性”的判定依赖于具体的语义信息。因此在实践中，大部分的单元测试代码依旧需要由开发人员手工书写（根据笔者查询到的资料，单元测试甚至在一些企业内单元测试推行得并不好）。此时智能化的单元测试用例自动生成工具似乎应当顺势而生，然而目前成熟的技术是单元测试框架和覆盖率检测工具，自动化的用例生成工具依旧存在许多缺陷，只能辅助测试，不能完全取代人工——以 EvoSuite 为例，其测试用例的正确性甚至都需要人工进行二次判断。

当然，笔者搜索资料时发现对于部分程序员来说，将撰写单元测试用例的时间转化为对自动样例 debug 的时间效率更高。比如：

懒人必备：一款自动生成单元测试的 IDEA 插件

排除自动化工具无法解决的语义正确性识别，根据程序分析的知识，我们知道针对单一模块（以 cpp 的单函数和 Java 的单一类为例）可以采用基于符号执行等技术的一些方法，进行风险代码的检测。至少现有的静态分析技术可以检测泄漏等内存相关问题（如 Valgrind 工具）、逻辑和运算错误问题、可疑检查（死循环、死锁、变量溢出等）等。遗憾的是，从现有工具的使用报告看来（以 EvoSuite 为例：工具尝鲜–单元测试自动生成工具 evosuite），它们并没有完成这些功能。

（图示为 Valgrind 工具检测 C 程序内存泄漏问题的效果）

自动化样例生成工具不集成此类功能的技术限制在哪里？如果不存在显著的技术壁垒，是否可以考虑结合代码分析技术，开发更高效、更智能的单元测试工具？还是说代码分析的步骤并不属于单元测试的范畴呢？

Q3：不在变量名中补充尽量多的信息是合适的吗？

在变量名中不要提到语法方面的描述；

如果信息可以从上下文中得到，那么此类信息就不必写在变量名中；

——Page 72

这类对代码风格规范的限制在实践中困扰过笔者理解项目代码的效率。笔者的困惑在于：

如何定义变量名中的信息冗余程度？

为了适应可能出现的不同类型的团队成员，“宁多勿少”似乎才是合理的。

针对前者，语法信息可能会在代码复审等环节帮助评估数据结构的效能等内容；针对后者，初步浏览大型项目代码时，笔者习惯使用搜索工具定位不熟悉的变量，有时信息量过少的变量名十分影响对程序语义的阅读。以及，如何定义上下文信息的范围（像窥孔优化那样定义一个窗口？这个窗口大小需要定义在规范文档里吗？），如何定义有效信息……这些都是精简代码的过程中可能出现的问题。

A1：Boss Driven Process 在这个时代未必仍是官僚的代表

作者在 Chapt5.团队和流程 中讨论 Boss Driven Process 时，似乎由于时代区域的限制，对这种模式提出了一些略显偏颇的评价。

领导对许多技术细节是外行。

领导最擅长的管理方式是行政命令，这未必能管好软件团队或任何需要创造力的团队。

—— Page 109

在这个优秀科技初创企业频出、技术大牛乐于创业的时代，Boss Driven 模式正越来越多地像是主治医生模式甚至明星模式的变式（如太极图形等大多数独角兽公司，而且事实上它们并不像传统意义上的明星团队，而是超级人才领导人才的高水平团队），技术出身并仍把控技术方向的老板并不在少数。技术型 Boss 在互联网事业上或许更能把控前期，提出的需求除了满足市场需求以外，在技术可实施性和方案创新性上也能获得很好的成就。

这里也引出我的一个与作者相左的看法： “明星”对成功的团队来说应当是不可或缺的 ，有的时候我们或许应该承认明星的陨落等于团队的衰微，除非新的明星冉冉升起。作者把那种没有明星、享有高自由度的团队模式称为“爵士乐模式”，这个比喻是不太合适的：优秀的爵士乐其实都有连贯的 Baseline，好的乐手（比如作者提到的 Miles Davis，从作者对爵士乐模式的描述看，我斗胆认为作者并不非常了解爵士乐）可以牢牢把握住现场的音乐语言不至于跑偏——这个中心乐手，其实就是明星模式中谈论到的明星呀。这种情况下，乐队的个性化表达 == 中心乐手的个性化表达，但笔者认为这并不是一个非常严重的问题，Creative 的工作往往从此萌发（当然，我们不能忽视这种中心明显的团队存在的成员团结性问题）。

就像齐奥朗在《自由的双重面孔》中谈到的那样：

意识受到这一启示强大的冲击，于是疑问起来，战栗不休。在一个自己什么都能把握的世界里，谁不曾感受过如此的晕眩？

Q4：个人软件开发流程记录的意义

PSP 的目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度。工程师有可能很高效地开发出一个顾客不喜欢的软件，那么这位工程师还是一个优秀的工程师么？

——Page 36

从我的阅读体验来看，PSP 更像是一个“工作用时分配记录表”，通过工程师主观填入在各个阶段花费的时间，最终生成一个类似饼状图的数据记录。因此我的困惑是：

这样的工作记录是否有意义？

首先，它无法反映工程师的工作质量（没有产品的满意度、同事或领导的反馈、Bug 记录、使用的技术栈或算法信息、代码的能效等）；

其次，笔者不太了解它在帮助工程师自我提升这一点上的有效程度（分配更多时间在测试和代码复审上比分配更多时间在编码上要更“有水平”吗？如果一个工程师花费了比别人更少的时间在文档设计上，ta 需要对此反省还是感到自豪？）；

同时，用时多寡与比例很难反映一个人的真实工作情况和能力水平，比如一个在番茄钟软件上记录日均学习时长 10h+ / 工作时长比例大于 70% 的人很有可能在考试或升职中失利，因为 ta 绝大多数的时间都用在了“自我感动”上。更何况，在没有电子计时等强制手段监督的情况下，工程师很有可能出于面子和绩效考核等因素谎报用时。

一个反映工作用时分配比重的信息表格可以在什么方面起到什么显著的作用呢？

Q5：挑选舞伴——什么是适合结对编程的双方

在本书 Chapt4. 两人合作 一章中，作者给出了一段关于结对编程方法的、令我感到稍显恐怖的叙述：

驾驶员：写设计文档，进行编码和单元测试等 XP 开发流程。

领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行……

驾驶员和领航员不断轮换角色……

——Page 87

阅读完全书后返回这里，我发现我对 XP 的期望更接近于敏捷开发中 Sprint 的场景。时刻处于复审状态，时刻有人准备着对正在编写的代码提出问题并期望得到合理的回应—— 如何选择驾驶员和领航员的双方，才能让这种工作模式真正有益于集中精力解决问题？ 或者说，这种工作模式是如何影响开发效率的？当然，这个困惑非常抽象，可能笔者只有通过在软工课程中亲身实践才能体会到。

笔者搜索资料后，发现已开展结对编程的开发团队也对其给出了以下反馈：

结对编程很累，要求结对的双方都要保证有充足的精力；
结对的双方如果技术观点相近，结对会很愉快……反之就有可能陷入很多的争吵，影响团队协作；
如果两个人的水平相似，结对编程有浪费时间的嫌疑和思维趋同的问题……

——App Annie 研发副总裁，Zhang Jason

反馈的后两点甚至是存在矛盾的：

如果两个人的技术思维相近，那么结对编程的出发点“时刻处于代码评审状态”就不再具有意义，况且在笔者的阅读理解里，结对编程的目标应当是让每个人都成为技术专家，水平相近的人似乎很难促进对方进步；
- 笔者在这里还有一个问题，就是采取了结对编程后还是否需要进行团队级别的代码评审环节？如果需要，请问又何必在一开始使用结对编程？（毕竟书中引出结对概念时使用的就是“时刻复审”这个需求）
如果两个人熟悉的领域不同，好的情况下可以利于知识的分享和传递，坏的情况下就有可能影响团队协作和工作效率，根据书中的问题层次理论，双方都处于学习区层级属于“好的情况”，而开发结对要怎样才能保证满足这个略显严苛的前置条件呢？这是否还需要对团队管理者的识人水平做出要求？

最后，我想谈一个本来列在问题清单上，最终被我删去了的开放性问题： 软件开发究竟是一门工程，一门艺术，还是一门手艺？ 回答了这个问题之后，诸如 Q1 这样的问题就都能够迎刃而解了。

然而在搜索资料的过程中，我看到了《程序员的四种类型》这样一篇年代久远的文章。读完之后，我感到软件开发也是这样：既有科学，也有搬砖；既有工程，也有艺术。在“程序 + 商业模式”的软件世界里，为性价比与理想性的冲突矛盾感到纠结与痛苦似乎是必然的，犹如在大海中航行，却总是控制不住谈迷雾另一边的陆地。

而每一种软件，每一种类型的开发者，都有属于自己的精彩。航行者们只是扩张和敞开自己，接受那些从海面吹往大陆抑或从大陆伸向海面的水汽。但需谨记：热忱抛却，颓唐必致灵魂。