[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	课程社区
这个作业的要求在哪里	作业要求
我在这个课程的目标是	通过一定的软件开发流程，在预计时间内发布"足够好"的符合用户需求的软件，并证明其是可维护和持续发展的。
这个作业在哪个具体方面帮助我实现目标	通过在一个学期的学习与实践后总结理解和心得，提升自身的软件工程能力，为后续的工作打下相应的基础。

[I.3] 个人作业：结课总结

对曾经提出的问题的解答与阐明

学期初的I.1 阅读与提问作业中，我提出了5个问题，经过一个学期的学习与实践后，我将这些问题大致都弄清楚了。

问题一：goto函数的是否使用问题？

我的回答：原问题是我认为原文中的如下表述：

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

是作者在鼓吹认为goto可以有助于程序逻辑的体现而可以使用的观点。但其实重新阅读原文，或许作者此处的表意应该是只要有助于程序逻辑的清晰体现，什么方法都可以使用，其中包括了goto，因此不是鼓吹使用goto，而是说要是使用了可以使程序逻辑清晰体现，那随便你怎么用，因此，此处是我对于作者的表意产生了误解。

问题二：AI流行的大背景下软件团队模式是否可能会出现超级个体的模式？

我的回答：经过一个学期的学习与实践，我认为会出现超级个体的模式，但是前提是这个个体有着扎实的理论基础，或者说是软件工程审美，知道什么是好的什么是不好的，因此这也回答了我的最后一个问题，软件工程依旧重要。因为ai再厉害，最终拍板的还是人，最后出事担责的也只能是人，因此这种理论层面，也就是培养判断项目大致处于什么阶段，还需要进行什么测试或者需要实现什么功能的能力相较于具体的编码实现更加重要。

问题三：“探索式”的测试太多真的意味着团队管理不佳嘛？

我的回答：经过一个学期的学习与实践，我更加坚定了我的想法，在实际的测试过程中，完全按照测试文档来进行测试并不能够很好的排查出尽可能多的bug，因此此时这种随机突然出现的“探索式”的测试，确实可以很好的补充原有测试文档的不足，同时我们团队的管理并不没有出现不佳的情况。

问题四：关于伙伴测试的一点疑惑？

我的回答：在经过一个学期的学习与实践后，我对于此处的伙伴测试有了更加深刻的认识，虽然我们团队并没有采用伙伴测试的方式进行测试，但是我在参与结伴编程的过程中感受到了一些共同处和差异，我认为这种团队内的伙伴测试的伙伴间的关系与结伴编程中的两人间的关系更加纯粹一些，前者只是一方开发一方测试，但后者则没有固定的身份，可以说是共同开发，相互测试。不过，这两者都是运用到了多一双眼睛来测试的方式来提高代码的可靠性，本质上还是相同的。

这种绑定并不会导致团队的冗余，因为项目的推进其实就是围绕开发人员展开的，因此如果能够做到每个开发人员一位测试人员，那便极好，保证开发高质量。若不行，由于测试工作相对简单，让一位测试人员按照人员分配绑定多位开发人员也是可行。

问题五：只能做猪、鸡或者鹦鹉嘛？

我的回答：经过一个学期的学习与实践，我更加坚定了我的看法，团队内成员的身份会不断，根据不同阶段的需求，投入程度可能也会发生改变。随着项目的逐步推进，有的人从“猪”变成了“鸡”，有的人也会反过来，因此使用实时的趋势来判断以及评判不同成员会更加合理。

在这个问题中产生的最后一个问题:

此外，我还好奇在AI横行的当下，鹦鹉是否也能拥有发言权？

我还是没有相应的回答，原鹦鹉可能指的是项目中的边缘人物，只是参与小部分的工作，并没有太多的话语权来决定项目的发展，因此我好奇ai加持之下是否人人都可以说上两句，都可以快速的掌握一个项目的脉络，并给出重要的决断，一方面现在大模型确实具有这个实力，但是另一方面太多人掌舵或许对于项目的正常推进与发展并不是一件好事。因此，我并没有对于这个问题的回答，但是基于上述分析，我大致认为基于后者原因，可以拥有发言权，但是还无法成为决断者。

产生的新问题

虽然我的主要职责是运维，但是由于整个团队的组成是由我拉拢起来的，因此，很多时候我担任了“传话筒”的工作，而这也导致了很多时候沟通效率较为低下，而成员之间又碍于不熟的关系，导致并不能及时指出一些问题，导致过程略有折磨。因此，我产生的新问题就是对于一只新组建的团队，如何才能尽快的让大家熟络起来并且高效的投入到项目开发工作中呢？

在项目的需求/设计/实现/测试/发布/维护阶段中学到的知识点

需求

我在需求分析阶段学习到了NABCD分析法，通过这种方法将产品在开发方向、竞争优势和发布流程等方面进行了全方位的分析，可以契合实际的用户需求，避免盲目开发的情况出现。

设计

通过对于功能和技术规格的设计，我们分别从开发范围及交付成果与技术选型等方面对产品进行了限制，避免开发陷入某些不必要的小细节或者技术框架严重不合适的情况发生，我学到了这样的提前设计，是为后续更好的开发与推进锚定了方向，选好了帆船，而这对于一个长久开发的项目来说极为重要。

实现

在实现过程中，我学习到了MVP原则，不用一下子开发完所有功能，而可以先实现一个最小功能集的产品，交给用户免费测试，并且逐步完善功能，修改bug，这样一来实现会更加顺畅，且一下子出大bug的概率大大降低。

测试

在测试阶段学到了单元测试、压力测试和黑白箱测试等，同时还认识到了测试不仅仅只是测试人员的事情，而应该尽可能地将测试下沉到开发的每一刻每一秒，因此开发人员也应该承担部分自身代码的测试工作，这在ai日益兴盛的大背景下更为重要了。

发布

在发布的阶段，我学习到了同开发阶段一样的知识点，也就是MVP原则，发布同样不需要等到所有功能都完成后才能进行发布，相反当某一个功能最小集都已经完成了，即可进行发布，也就是最小可交付版本，这也是敏捷开发的一个体现。

维护

在维护阶段，我学习到了一定要做好版本管理的工作，并且注意不同开发者本地版本与最终发布环境中版本的差异，同时由于我们购买的服务器内存较少因此，总是出现奔溃的情况。因此，对于这种情况，更需要间隔一定时间对项目的运行情况进行检查，以避免影响用户体验。

经历个人项目/结对编程/团队项目后的理解或心得

个人项目

在实验课上完成了lab1-lab4的四次上机作业，大小可以称之为个人项目吧，四次实验分别从需求、设计和测试分析、模型的作用、Spec-Driven开发范式和软件规约以及项目实现等多个维度进行了考察，虽然量不是很大，但是让我们大致了解了软件工程开发的一些必要流程，同时也让我认识到了一些文档类型工作的重要性。

结对编程

结对编程任务中，我和我的同伴(lhy)一同完成了对于桌游《花间小路》的实现，我们学习了AssemblyScript——这一类似TypeScript的编程语言，通过分阶段的12个小时的结对编程，我们完成了一个较为完善的项目，也算是体会过了“领航员-划桨员”模式优缺点。

在我看来，这不只是两个人简单地盯着一块屏幕敲代码，而是把原本只存在于个人脑子里的判断过程，一边讨论一边摊开来检查。尤其在这种规则多、边界多、时间又紧的任务之中，它最大的作用并不只是多一个人看代码，而是多一个大脑思考，这样很多容易被忽略的理解偏差，也会在这个过程中提前暴露出来。

实际做下来，结对的好处主要体现在两个地方。一个是规则理解更稳，像输入视角、标记编码等这类容易漏掉的细节，往往能更早被发现；另一个是实现过程更克制，不会一上来就把代码铺得很大，而是先把状态和辅助逻辑理顺，再往下推，所以整体会更清楚，也更不容易写偏。测试这块也一样，因为两个人会不断互相补充，很容易把那些只靠正常流程看不出来的边界情况补上。

不过它也不是没有代价。最明显的是，效率不一定会线性增加，前期沟通本身就要花时间，如果节奏没控制好，很容易两个人一起卡在同一个点上。另外，结对效果很依赖双方是否真的参与思考，如果一方只是旁观，那它就会退化成普通的单人开发。那反而不得当了。

因此，有利有弊关键在于如何使用与实践。

团队项目

我在团队中大致担任运维、协调前后端以及与不太熟的组员之间进行沟通媒介的工作。

总体来说还是收获更多，当然也遇到了很多麻烦，比如由于网易邮箱的抽风导致现场演示邮箱功能的时候没有办法正常运行起来。

其中学习到了更多的运维以及发布的技巧——比如MVP原则等，同时在与组员的交流与沟通中也提升了与人进行交流沟通的能力。

当然，由于我们是临时组建的团队，而且作为组建人的我还不是PM，导致有的时候真正的PM不好直接发号施令，导致一些情况下沟通不畅，不时拖慢项目进度，面对这种情况我也总结了经验教训，也就是一定要积极交流沟通，及时对齐，不要拖到最后一刻才想起来，同时对于并不相熟的人，我觉得还是需要先让大家熟络起来才好干活，这也是此后需要注意的。

总而言之，这是一段艰难但是利好成长的旅途，受益匪浅!