BUAA_2023软工第一次作业——阅读和提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	个人作业-阅读和提问-CSDN社区
我在这个课程的目标是	了解软件工程方法论，提高工程能力以及团队协作开发能力，总结软件开发经验
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》整体了解软件开发流程，初步了解团队协作、工程化开发的基本要求

阅读提问

• Q1：如何定义成熟的团队成员？

  【3.1】个人能力的衡量与发展 P51

  理性地工作：软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家 Chuck Close 说：我总觉得灵感是属于业余爱好者的，我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作. 最终你会有所成就。

  本节中作者提到了TSP对团队成员的要求，其中包括需要其理性地工作，对此我表示赞同，然而对作者后续的描述不敢苟同。

  作者应用Chuck Close的话：灵感是属于业余爱好者的。但是真正的职业人士难道就不需要灵感和激情了吗？诚然，在充分学习前人总结的架构、设计后，我相信能在日复一日的工作对其愈发熟悉，开发出不错的产品。但是再棒的架构和设计总有黯然失色的一天，总有会被淘汰的时候，这时候往往需要从业者的灵感来提出新的idea。产生这样的灵感我相信是需要对所做工作持有一定的激情的，否则大脑会本能地拒绝思考，没有思考又谈何灵感呢，没有灵感又谈何创新呢？

  因此我认为成熟的团队人员确实是需要理性的，但是在关键时候，激情和灵感带来的灵光一现，往往才会体现其专业性的可贵。

• Q2：变量命名是否应该有描述？

  【4.2.6】命名 P72

  避免过多的描述。例如一个变量是游戏中最后出现的“大 boss” ，不用写 theFinalBattleMostDangerousBossMonster, 可以直接写 boss。

  在本章节中，作者介绍了编写代码的部分相关规范。作者指出变量命名不应该有过多描述，对这个观点我持怀疑态度。

  查阅资料发现，作为经典命名法的匈牙利命名法，其基本原则是：变量名=属性+类型+对象描述。可见软件开发中描述变量是极为重要的，书中所说的可以直接写boss以个人理解是存在一些问题的。

  对于工程开发而言，绝多数代码量都会在几千行甚至上万行，这个量级的代码往往包含大量的内容，而且通常不会由一两个人开发。而一个游戏中难道只会有一个boss吗？答案显然是否定的，如果以书中命名方式，每个boss不加以描述，那么同样的代码在不同开发人员眼中就会产生严重的歧义，这带来的影响是不言而喻的。

  再以笔者本人开发经验为例，在上学期《编译技术》课程课设的开发中，我在开发前期和后期将两个不同变量都命名为token，所幸全部代码均由自己编写，对代码比较熟悉，才没有造成难以发现的bug。然而试想一下如果同样量级的代码由多个人进行合作开发，对变量命名再不加以描述，这显然会阻碍开发进度。

• Q3：结对编程中角色的定位？

  【4.5.4】如何结对编程 P87

  结对编程中有两个角色：

  1. 驾驶员（Driver）：控制键盘输入。
  2. 领航员（Navigator）：起到领航、提醒的作用。

  如何结对编程：

  1. 驾驶员：写设计文档，进行编码和单元测试等 XP 开发流程。
  2. 领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。领航员也可以设计TDD 中的测试用例。
  3. 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。

  阅读之前笔者以为结对编程就是一个小型的团队开发，即两人经商量讨论确定各自负责开发的模块，规定好输入输出格式后将各自负责的模块合并起来，完成项目开发。

  然而书中的对结对编程的定义简单概括为"一人负责指导开发，一人负责实际开发"，笔者不禁会想这样的任务分配是否存在一些问题：

  • 这样的分工在学生队伍中是否会存在"摸鱼"现象？

    从书中指导如何结对编程的描述来看，领航员的部分任务其实是比较"虚"的，比如审阅文档、思考重构、监督开发等。以笔者几年的大学学习经验，这样的工作如果交给责任感较低的人员，相当于是提供了"摸鱼"机会，影响开发进度。

  • 轮换角色是否会影响开发效率？

    书中提到两个角色应该适时进行互换，但是每次互换都意味着要在对方的工作基础上进行开发，而理解对方的工作往往是会消耗一定时间的，更致命的是，如果理解不到位甚至会导致大量的工作功亏一篑，需要重新来过。

    但如果自己只负责自己的工作，对对方的工作只进行审阅和监督，那么就不会产生上述问题，自己需要负责的内容也不会显得那么多，不管从心理还是效率上来说，都显得比书中介绍的来得要好。

• Q4：如何类似A\B测试进行多变量测试？

  【8.3.9】A\B测试 P166

  在多年的软件（应用、游戏、网页等）使用体验中，笔者发现了一个奇怪的现象，很多软件在对用户UI界面进行修改或重塑后，往往会引起大量用户不满。

  2020年3月31日，英雄联盟官方发布了客户端优化用户使用界面的消息，不过迎来的却是网友的破口大骂。

  2021年，bilibili弹幕视频网发布网页端新版UI，被大量用户吐槽，至今该网站仍保留"返回旧版界面"按钮。

  笔者此前就在疑惑这些UI界面更新前难道没有进行调查吗，如果用户反对声过大，投入至UI界面更新的人力物力是否就此浪费了。本书提到的A\B测试很好的解决了我的这个疑惑。

  然而新的疑惑随之而来，在笔者调查发现，A\B测试第一步即为明确要测试的变量，界定可衡量指标，并控制其作为唯一影响变量。然而不难想象实际开发中很可能会出现将UI界面整体废弃重写的情况（并不是没有发生过），那么面对这种情况再使用A\B测试挨个控制变量进行测试显然从逻辑和时间的角度都是行不通的。

  带着这个疑惑笔者查阅资料发现这种情况可以使用如多变量(Multivariate)测试等测试方法，但笔者并未查阅到具体测试步骤，反而是找到该方法的诸如"测试时间过长"、"需要大量流量保证统计意义"等缺点。

  因此笔者比较好奇项目组在尝试全新UI界面时，是通过怎样的调查和测试，来避免大量人力物力的浪费。

• Q5：学生项目中PM角色的定位？

  【9.3】PM 做开发和测试之外的所有事情 P198

  在一个项目中，PM 的具体任务是什么呢？他们的任务是：

  1. 带领团队形成团队的目标/ 远景，把抽象的目标转化为可执行的、具体的、优美的设计；
  2. 管理软件的具体功能的生命周期（需求/ 设想/ 设计 / 实现 / 测试 / 修改 / 发布 /升级/ 迁移 /淘汰 ）;
  3. 创建并维护软件的规格说明书，让它成为开发 /测试人员及时准确的指导，而不是障碍；
  4. 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
  5. 分析并带领其他成员对缺陷 /变更需求形成一致意见，并确保实施；
  6. 带领其他成员确保项目保持功能 / 时间 /资源的合理平衡. 跟踪项目进展，确保团队发布令客户满意的软件；
  7. 收集团队项目管理和软件工程的各种数据,客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

  在本节中作者指出PM的具体任务，阅读不难总结PM的职能为规划和管理软件开发。然而这个任务和我在Q2中提到的问题相似，直观感受上来说会觉得任务比较"虚"，非常考验其软实力。

  在实际工程开发中，PM角色往往是有很多项目经验，在能力方面经得起考量，有一定威信和声望，才能担任好团队PM。这样的PM往往具有较强的软实力，能够以独到的见解和长远的眼光对项目整体进度、人员分配、杂务处理进行较好的把握。同时PM角色往往在职位上也会高于实际开发人员。基于这些因素，实际开发中PM才能发挥真正的作用，开发人员相对来说也比较心服口服。

  然而在学生团队中，各个成员对自己的能力和擅长往往还处于开发阶段，在这样的条件下选出的PM是否能真正规划好项目进度，分配好任务，我对此持怀疑态度。另一方面正如前文提到的，PM的任务给人直观感受比较"虚"，如果项目任务量较大，开发进度受阻时，难免会有组员闹情绪——“凭什么我干这么多活，ta就只用看着呢”。当一个团队出现这样不和谐的声音时，矛盾就会悄然发生。

  因此，我对学生团队中PM角色的定位表示好奇，这种条件下PM的工作和任务是否还应和书中所说一致？