个人作业——提问回顾与个人总结

[19374191-马天瑞]

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	学习工程化软件是如何构造的
这个作业在哪个具体方面帮助我实现目标	总结一学期的学习过程，吸取经验和教训

1. 原问题博客

阅读《构建之法：现代软件工程》的疑问

对原问题给出了一些自己的理解，暂时没有想到新的问题。

Q1 什么时候泛化、泛化到什么程度比较好

我认为这个完全是根据具体应用场景决定的，没有通式通法。

比如在大作业中，大量接口的功能都比较单一，没有复用的部分，这种情况就不用考虑泛化，而是把所有步骤写在一起，增加耦合。但是有少部分的工具性接口，如“上传”功能，上传文件、上传图片的逻辑都相似，这种功能就尽量泛化，让不同的业务都能使用，减少代码冗余。

Q2 函数建议使用 goto 吗

目前有许多框架，重视面向切面编程，在功能开头和结尾增加固定不变的代码，异常等也都统一处理。我认为在实际开发中，不应该手动使用 goto 控制，尽量让成熟的框架负责这部分，统一处理。

在写大作业时，大部分的函数耦合性都比较高，判断的异常情况也比较少。这样的代码特征甚至不需要统一的异常处理，在主函数中处理异常更加直观。统一处理部分只有运行时异常和事务异常，这部分也不便用 goto 语句处理。而且python语言也不支持 goto，因此我认为不建议使用 goto，这种容易出错的执行方式不应该由编程人员直接操作。

Q3 结对编程如何减少思维定势

一个好办法就是控制结对时间，留出自己思考的时间。

我们的结对编程不完全是同时的，只在某些时间段一起编程。在其他时间，我们可以自己思考，在结对编程时再交流想法。这样通过独立思考，我们更加容易提出不同的观点，而减少了思维定式。

Q4 如何平衡极限编程和程序质量

我认为在日常的编程中，相对于程序质量，需要更加偏重于编程速度。

在大作业工作中，我们前期花费了很多时间在讨论和商量中，在还没有开始编程时，就预想可能遇到的各种问题。结果我们在实际编程中，仍然会遇到其他的问题，迫使我们一边编程，一边修改设计。这样的结果就是我们白浪费了时间，没有解决问题，而是在空想。我认为只有实践才能知道问题在哪里，永远不会有完美的设计，计划赶不上变化。所以与其在开始之前做一份非常严格的计划，不如先指定一个宽松的设计，在实践中不断调整和完善。

Q5 如何合理地评估绩效

可以使用工作量评价，也可以通过投票方式进行评估。

我们在大作业中，遇到很严重的问题，即组长不负责，其他成员需要在开发中同时承担组织工作。根据最初的设想，使用工作量评价绩效可能对组织者不公平，因为组织工作和代码工作同样很重要。但是我们遇到的问题是组织者不负责，用工作量也无法量化评价。所以最后我们采用投票方式，每位成员给其他成员投票。最后的结果基本符合我们的预期，也符合各个成员的实际工作量，当然组长的分数是最低的，说明“公道自在人心”。

但是这种方法也许只能用于学生小组，学生小组的权责不对等，对不负责的组员也没有严厉的处理措施。我认为在工作中，应该有更加合理的绩效评价，因为公司和个人的权责相对对等，拥有权利的同时承担责任。无论是工作量还是投票等方式评价，更加容易趋近于一个平衡。

2. 实践中学习

需求

确定需求时，一定要找到明确负责的同学。

要充分和组员交流，尤其是需要线下交流。小组成员较多时，集体负责就是集体不负责。一定要找到直接负责的同学明确需求。

设计

设计时需要明确分割模块，而不需要事无巨细地设计周全。

我们组在设计中浪费了太多的时间，最后所有设计的细节和最终实现都不一样。如果早点抓大放小，在实践中调整，我们的时间会更加从容。

实现

需要明确分工，需要根据不同人的水平，分配适合的工作。

由于后端的模块划分合理，后端的分工比较自然。但是我听说前端的工作比较混杂，不方便分成多个模块。如何合理地设计分工是一个有技术的工作。

测试

测试应该是分步骤、分阶段的。

比如在编程中，遇到一个不确定的功能，需要测试。首先应该开一个小的工程，测试这种方法的合理性。确认方法可行后，在本地的测试环境编写代码，自己测试。测试无误后，部署到实际环境，进行实际的测试。最后，在多个功能实现之后，进行组合测试。如果盲目部署测试，可能会使代码更加混乱。

发布

发布应该分阶段，类似于内测与公测版本。

我们在 alpha 阶段发布时，时间晚了两周，导致我们无法宣发。在之后正式版发布以后，早就错过了最佳的时间，也收不到用户反馈。在有少量用户反馈之后，没有足够时间调整，又必须赶工。如果分阶段发布，每个阶段按时发布，一是可以在比较好的时间积累用户，二是对用户的的反馈能有时间优化。

维护

需要根据问题难度，决定修复的工作。

我们在开发中遇到了用户的反馈。其中一个是希望添加表情包，这个对于后端而言，只需要调整编码格式，比较容易，因此可以快速修复。另一个是传输的安全问题，这个就比较复杂，涉及到前后端的多种算法。在时间有限的情况下，我们只实现了安全传输的部分标准，就部署上线了。

3. 理解和心得

个人项目

从阅读《构建之法》到分析现有软件的优劣，我从原理上对软件工程有了一个大概的了解。我也认识到，即使是市面上的优秀软件，也不是十全十美的，用心寻找总能找到问题。但是瑕不掩瑜，这些问题不妨碍它们是优秀的软件。用户对软件的评价，一部分是软件是否满足用户的使用习惯，另一部分则是软件所呈现的内容。因此好的软件是好的工具，把核心内容更好地呈现给用户。

结对编程

在结对编程中，我和我的队友共同编写一份代码。但是在实际操作过程中，我们并不是所有的编程任务都需要结对完成。更多情况下，还是一起线上完成，通过会议和共享等方式开发。但是我们也有自己思考的时间，等到结对时再一起讨论。我认为这种模式比完全的结对更好，因为有独立思考的过程，可以减少盲从和人云亦云。

团队项目

我们的团队项目开发可以说不尽如人意，我们的小组在工作中遇到了各种困难。这些困难有些来自知识的欠缺——对开发软件的流程不熟悉，有些来自管理的问题——如何分工、如何处理不负责的组员、组长不负责时其他组员怎么办，有时内部无法解决，还需要求助助教和老师。到最后，我们的进度相比于其他小组也更加落后，这也导致我们的用户也比较少。

对于产品而言，我们的团队项目是失败的。对于学习而言，我们的开发过程是一个很好的学习过程。我们小组从无到有地开发了一款软件，在 alpha 阶段遇到了很大的问题。在遇到问题之后反思和调整，在 beta 阶段基本上解决了问题，同时完成甚至超额完成了最初对 beta 阶段的设计。我相信任何软件的开发都不会是一帆风顺的，一定会遇到各种棘手的问题，突发的情况。相信我能利用这次开发的经验教训，在面对更大的挑战时也能从容应对。

[SoftwareTeacher]

我们在大作业中，遇到很严重的问题，即组长不负责，其他成员需要在开发中同时承担组织工作。根据最初的设想，使用工作量评价绩效可能对组织者不公平，因为组织工作和代码工作同样很重要。但是我们遇到的问题是组织者不负责，用工作量也无法量化评价。所以最后我们采用投票方式，每位成员给其他成员投票。最后的结果基本符合我们的预期，也符合各个成员的实际工作量，当然组长的分数是最低的

---

那么，小组成员当初是如何选择组长的呢？