软工2023个人作业三——提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	学习并掌握现代软件开发和项目管理技术，体验敏捷开发工作流程
这个作业在哪个具体方面帮助我实现目标	对本学期课堂上所学与实践中所获得的体会进行总结反思

提问回顾

学期初提问博客

提问 1

文章背景

文章第 4.3.2 节中写到：

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

问题提出

我看了这段文字后有疑问。我们在学习 C 语言时都曾听说过 Dijkstra 提出的 “goto 有害论”。本人在编译原理课程上阅读类 pascal 代码时，确实感受到 goto 语句使程序难以理解。并且本人在阅读实际投入使用的高级语言代码时（github 上开源项目或者实习经历）也从未见到过 goto 语句。因此我仍持有疑惑，作者认为 goto 可能使程序逻辑清晰体现这种观点是否不符合主流？

问题回答

我认为可能对于资深程序员，结合自身的开发经历和对编程语言以及程序设计的理解，可能对这样的问题会有一些个人化的看法；但我们作为学生、初学者，一开始还是学习一些已在实践中被证明有效且广泛认可的程序设计模式，打好基础，等到对编程语言或程序设计形成自己理解时，再说对一些有争议问题的个人看法。具体到本问题，我认为现阶段我们还是少使用goto为好，毕竟我们能够看到能够学习的实现较好的C/C++开源项目程序，似乎很少有经常使用goto语句的。

提问 2

文章背景

文章第 4.5.3 节中写到，结对编程是“不间断地复审”：

结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。

问题提出

我看了这段文字后有疑问。根据我在以往课程中的实践与观察，但有些人的编程习惯可能是有了大致设计后先搭起初步框架，之后具体实现每一部分时再调整，这个过程中可能发现之前的设计有考虑不周的地方进而做修改。这个过程是很自然的，效率可能比“试图想清所有问题再动手”的悲观方式更高。
但如果处于“不间断地复审”，同伴可能对最初起草的框架有诸多疑问、或者在实现上有不同想法，进而引入很多问答环节。那么我存疑，这样会不会导致了两人在实际动手前花过多时间讨论实现方案的各种细节？

问题回答

在实际体验中，合作较好的同伴两人往往可以找到一种平衡，对于架构讨论到一定程度就开始动手，在实现过程中再不断做细化和调整，不过这个度需要二人协调、共同把握。

提问 3

文章背景

在文章第 4.6 节中写到：

为什么这一节要讲这么多两人合作的反馈问题？因为，如果软件工程师连一对一的合作都做不好，不能有效地去影响同伴，让合作双方都能从合作中受益，提高水平，那大家就别扯什么团队合作这些事了。

问题提出

本人对这种说法持质疑态度。从文章描述的结对编程和敏捷团队合作流程可以看出，二者的合作模式是不同的：结对编程时两人轮流编程，另一人始终在旁复审，随时沟通，两个人几乎处于平等的角色；而团队合作时大家各司其职，有 PM、DEV、测试之分，DEV 可能还分前端和后端。我设想，在结对编程中，如果一个人的能力明显高于另一人，比如拥有 20 年 C++ 开发经验的程序员和 ta 新带的实习生，可能实习生并不能给 mentor 的代码提太多意见，反而还会因为各种问题不懂，需要讲解，而拖慢开发进度。但实习生未必不能参与团队合作，ta 可能可以很好地完成一些相对简单机械、 mentor 没时间亲自完成的部分；或者做一部分测试工作，在此过程中通过阅读代码提升自己。所以我对结对编程到团队合作的必要性存疑。

问题回答

正如我在下下小节“心得与体会”中探讨了我认为的结对编程所适合的场景，我认为适合于这种编程模式的开发场景是比较特定的，在特定场景中应该还是能起到比较有效的效果。（更详细的讨论请见“心得与体会”）

问题提出

提问 4

文章背景

文章第 9.1 节这样描述 PM：

你是否觉得你的长处不在于写代码和debug，而是协调、沟通，让一个团队或组织有效运转起来？你是否喜欢表达，善于和各种专业背景的人沟通？你是否经常思考如何该井生活中点点滴滴的小问题？你是否会思考这样的问题么：新浪微博、豆瓣、qq、微信都可以社交，它们的定位、产品特性、用户群、解决的需求，有什么不同？你是否对以下领域感兴趣，甚至自己找过相关的书来看：心理学、社会学、组织行为学、统计学、商业模式？

问题提出

读了这段文字，我对 PM 这一岗位的选择标准有所疑问。想起来实习时组里的 PM 姐姐（CS 专业毕业）曾回忆往昔：“感觉我毕业时那阵 PM 这个岗位特别火，每个人都拿着一本《人人都是产品经理》，但产品经理哪是那么好做的啊！”根据文章所写，产品经理无疑是要懂得技术的，ta 需要“做开发和测试之外的所有事情”，但 ta 还需要协调沟通。那么成为产品经理最重要的特质是什么呢？或者说如何选择产品经理呢？是选择技术了解全面，还是善于统筹规划，或者是团队沟通、领导能力强的人呢？

问题回答

可以选择既对技术了解全面（也许只是泛泛了解，并不是说样样专精），又相对善于统筹规划的人。在实践中我认为可能还是后者更重要一些，毕竟CS学生做到对项目使用技术均泛泛了解并不是难事，但要做到对项目整体进度进行把控、和甲方沟通需求协调交付、主持宣发工作、跟进团队成员开发进度，还是需要拥有一定统筹规划、团队沟通领导能力的人。在此称赞一下我们团队的pm！

提问 5

文章背景

文章第 14.6.1 节写到：

要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。

但敏捷开发鼓励每日例会，在文章第 6.1 节中有写到：

每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。

问题提出

读了这两段文字，我认为这两种观点看似有矛盾之处。本人理解为，作者反对频繁的程式化的大规模集体会议，但小型的敏捷团队需要随时和组员同步自己的动态。但我依然质疑在实际操作中这两者是否如此泾渭分明。在“会前苦心准备材料，会上汇报自己工作进度给老板听，其它同事汇报时就摸鱼”的累赘和“我昨天写代码-我今天继续写代码-我没碰到什么问题-散会”的草率之间的平衡点如何把控？

问题回答

这个问题在我提交了提问博客作业以后熊助教进行过回复，他的回复启发了我的思考——我这个问题描述的两种情景中，其实前一种中“团队成员的参与和互动被弱化了”，后一种中“会议的目标模糊化了”，所以“本质上是如何追求会议的【效率】和【效能】齐备的问题”

而这个问题的回答，我在我们的项目实践中就得到了。在每日例会前，一般来说pm会大致整理今日所有议题列在notion中，并建一个每人“我前两天做什么-我后两天做什么-我遇到什么困难”的表格；大家会前会填写表格，如果有遇到比较重要问题也会添加在议题之后，并投票表决是否需要线下会议。这样每次会前，每个人都可以看到今日是否是一切平稳运行、5min速通的简短例会，还是有重要或众多事项需要讨论的较大会议，如果是后一种也可以针对议题提前准备一些材料或做调研。如此，我认为我们团队的会议就“【效率】和【效能】齐备”这一点，效果是比较理想的。

新问题

以上，我针对学期初提的所有问题都进行的自己的解答，同时也没有产生什么新的问题。

知识点总结

项目开发分为需求/设计/实现/测试/发布/维护六个阶段，我在每个阶段分别学到了以下知识点：

需求阶段

我学习到可以通过观察、访谈、问卷调查、文献调研等多种方法，与客户方了解其对于项目的需求，并且为保证项目后续发展符合用户预期，防止用户可能对需求描述不清或开发团队出现理解偏差，我们还应当在收集需求后与客户确认需求。

设计阶段

我学习到在架构设计阶段，可以灵活使用设计模式来提高之后的代码质量。典型的设计模式有单例模式、工厂模式、观察者模式等。使用设计模式进行架构设计，不仅可以建立可维护性高的架构，还可减少出错概率，从而降低之后开发、测试、bug修复的工作量。

实现阶段

我积累了使用 Vue2 框架进行前端开发的经验，并且了解了一些常见的网站安全漏洞种类与相对应的解决办法，还有如何运用 git 进行代码管理、规范合作开发流程。

测试阶段

我认识到了单元测试的意义，在实践中我们通过编写单元测试，测试代码中每个最小可测试单元，此外我们也尝试了其它测试，如集成测试。

发布阶段

我对敏捷开发所要求的持续集成与持续部署有了更深入的理解。我们的团队搭建了较好的自动化构建、测试和部署的流程以实现这一目标，而实现CI/CD则保证了软件时刻处于一种可交付状态，且能够将任何时刻的修改快速部署到生产环境，降低软件发布环节出现意外的风险。

维护阶段

我们的团队使用Docker容器进行部署，并且设置了后端评测记录日志，以便监控事故发生现场和及时进行修复或回退，并且团队采用了开发/生产环境隔离的形式，在开发环境中配置更详细的log信息，而在开发测试和修复过程中不会影响生产环境，造成软件对用户不可用。

心得和体会

课程之前

在本学期的软件工程课程之前，我的开发经历主要也局限于校内课设，大多是个人项目，即计组、面向对象、编译等专业课的实验作业；或者小规模的团队合作开发，如数据库或基物实验的大作业。在这样的开发过程中，工作流程通常是比较随意的，并且没有明确的、需要交付产品“客户”，有的只是验收作业的老师和助教。

结对编程

在软工课上我第一次体验了结对编程。我能体会到结对编程是适用于时间紧迫、任务体量不大的需求的一种开发模式，在这种情境下，两个搭档始终共同完成开发，轮流进行编程和不间断复审的工作，可降低出错概率，减少代码复审和bug修复的时间，并且保证两人对程序均有完整细致的了解同时精简项目参与人数，降低沟通和讨论的成本。

结对开发对我来说是一种有趣的体验，不过经过了体验和思考，我觉得这种开发模式还是对场景有较高需求的。首先我认为它比较适合于从零开始的体量不大的项目，而不是在已有很大规模代码的项目上做增量开发，我感觉后一种情况一般企业里应该都有对该项目相对了解的senior做主要负责人，其他人对该项目做修改则需要ta（们）复审。其次我认为适合结对编程——省去代码复审和修改流程，两人轮流编程和审核——的项目应该时间比较紧迫，它基本要求两个人放下手头其他工作和自己的节奏，去集中精力完成这一个任务，这听上去像初创公司开发和交付产品的情景（比如我现在实习公司）。还有，我认为结对编程的两人最好能力水平相近，或者说在该项目所用到的技能上的了解熟悉程度相近，并且两个人的水平都应较高为好，否则会造成“能力强者可以不停给能力弱者提意见，效率还不如ta自己写，但能力弱者看不出能力强者的问题”或者“两人能力都一般，理解对方代码和继续对方思路写都需要花费较长时间”的尴尬局面。这听上去大概更适合“几个强者创业”的初创公司的情景了。不过根据实际经验，在我们那个初创小公司，虽然最初也是有几个核心的强者，不过大家技能点并不相同，比如有C++大师负责基本所有的软件基础架构，图形算法大师基本负责所有的节点功能实现，CUDA大师负责基本所有的并行优化，后来招来的人也各负责不同模块和子模块，很难找到两个能做“结对编程”的人。

团队开发

在软工课程上我们还学习并体验了敏捷开发流程，体会了持续开发、持续部署、不断交付可用产品的工作模式，完整走过了需求分析、原型设计、代码规范制定、两阶段开发-测试-发布-反馈收集-完善、事后分析的全过程。我切实感受到，想要做出中等或稍大规模的实际可用的产品，有一个明晰的工作流还是很重要的，以此可以保证工作效率。

并且软工中的团队合作也给我很多体会。原先我只有实习的经历，主要是由senior给我分配任务，我在开发中遇到任何问题，通常只要询问他们，都能顺利得到解决。但在软工课程中，我们没有senior和junior的差异，没有万能的“靠山”，大家要一起从头开发我们的项目。首先团队内不同职责的分工给了我很好的体验，这里不仅指角色上存在pm前端后端运维的分别，更是指大家各有所长，遇到问题时，总会有比较了解这方面的组员去做调研和实现，快速解决问题，唯一的遗憾大概是我们组没有很擅长美工的同学（）其次我在团队开发中学到了任务分配的重要性，在初期往往很难进行细粒度的任务划分，因为此时我们仅拥有一个大致的原型，在实际实现中可能还会不断细化和调整，但太粗粒度的任务划分又会造成每个人完成各自工作时的困难，可能会出现多个人的实现冲突或者互相等待的“死锁”，但我们的团队并没有走到这种局面，虽然在最初遇到了任务划分太模糊的问题，不过我们不断沟通和调整工作安排，及时改善了情况。最后是团队开发锻炼了我与人合作的能力，我大概不是一个很有耐心的人，很容易感到烦躁和跟人起争执，在本学期专业课压力+个人实习与准备出国的压力下，我也多次陷入焦躁不安的状态，但看到同样忙碌的队友们每一次scrum meeting都保持着认真与平和，我便调整自己的心态，继续踏实做事。