2021年软工-提问回顾与个人总结

2021年软工-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	了解软件开发工程的具体流程，学习项目实践开发的方法与步骤。
这个作业在哪个具体方面帮助我实现目标	对整个学期的课程内容进行回顾，回答学期初阅读作业提出的问题，总结课程中开发经历的理解与心得。

提问回顾

提问作业链接：[2021年软工-第二次阅读作业](2021年软工-第二次阅读作业 - OmedetoHe - 博客园 (cnblogs.com))

问题1：对于编程水平相差较大或者说擅长领域完全没有重合的两人，驾驶员和领航员类型的结对编程方法是否仍能获得较优的合作投入产出比。

根据《构建之法》第4章4.5节单元测试部分的如下一段文字：

结对编程中有两个角色：

1.驾驶员（Driver）：控制键盘输入。

2.领航员（Navigator）：起到领航、提醒的作用。

这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编写程序等），另一个人负责导航、检查、掩护等。

在写当时这篇提问作业时，对于我个人来说还没有进行过正式的结对编程任务，因而对二人结对编程所能达到的最优合作投入产出比还抱有很大疑问，尤其是对于编程水平相差较大的团队。不过在经历本课程的结对编程任务、团队项目任务以及听取助教的部分建议后，我对这一问题也有了更深层次的理解。

在结对编程的过程中，我和我的搭档编程水平差不多是相当的，而通过严格执行驾驶员和领航员类型的结对编程方法，并定期更换两个人的角色，我们确实取得了较优的编程效率与准确率。而在团队项目中，我们团队的前端组中则出现了编程水平和开发经验参差不齐的情况。尽管这在某种程度上造成了我们团队 alpha 阶段的起步放缓，但经过一段时间的磨合后，我们团队的前端组还是迅速进入状态，水平稍差的同学也很快补齐差距，顺利完成了相应部分的开发任务。总之，对于编程水平相差较大的结对开发团队，需要保证团队成员之间相互帮助并相互信任，水平相对较高的同学应当认真负责的慢慢配合队友，水平稍差的同学也应当于开发中主动学习，主动补齐差距。而对于具有上述特征的c结对开发团队，最终依旧能够在经过磨合后获得较优的合作投入产出比。

问题2：敏捷开发是否会容易拉长项目最终完成的期限。

根据《构建之法》第6章6.4节敏捷总结部分的如下一段文字：

敏捷的方法能帮助你尽快让用户看到项目的部分价值。当你尽早交付部分价值时，也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其他需求。另一种可能是，用户看到了部分系统，他们有新的需求，这样你就可以实现新的需求，而不用再浪费时间实现过时的需求了。

对于这个问题，由于我也是在这个学期软件工程课程中第一次接触敏捷开发，敏捷开发的经历也并不丰富，因而我主要是通过阅读相关的技术博客，并与其他同学进行讨论来获得自己的见解。

在我看来，敏捷模式虽然能够较早交付部分价值，但是其主要目的并不是缩短项目最终完成的期限，而是提升开发流程的灵活性。对于那些需求相对稳定，目标明确且很少回头更改的项目来说，采用瀑布式的开发可能会更优。但对于需求不明确，需要大量尝试的项目来说，不确定性的变更确实会导致敏捷开发的时间与成本的提升，但其相对于其他开发模式来说依然具有更优的开发效率。因此，从上述相对性的比较来看，敏捷开发会容易拉长项目最终完成的期限这种说法并不正确。

问题3：计算机软件开发领域里的PM职业人才主要来源是哪里，主要会是来自于计算机相关专业的学生吗。

根据《构建之法》第9章9.6节PM人才主要特征的如下一段文字：

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

虽然上面的描述中并没有体现出PM人才与技术之间特别紧密的联系，但是通过调研我们可以知道，产品经理的日常工作是对产品的整个生命周期负责，从产品的需求，构思，设计，研发，测试，上线，运营以及后期的迭代等所有关乎产品的事情，理论上都是产品经理的分内之事。日常工作的形式多为需求收集，撰写产品文档，开产品会议，及时推动项目进度。协调项目资源，对用户和产品负责。这些工作同样是需要经过专业的教学与培训才能掌握，也因此可以知道计算机软件开发领域里的PM职业人才主要来源依然应该是软件专业科班出身的学生，当然也就包括系统学习过软件工程的计算机相关专业的学生。

问题4：Goto语句是否有利于清晰体现程序的逻辑。

根据《构建之法》第4章4.3节代码设计规范的如下一段文字：

只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

对于这个问题，我也询问了周围同学的看法，大家的观点大都也与我在提出疑问时的观点一致，goto语句可类比于汇编程序中的跳转指令，它容易造成包含分支和循环结构的程序逻辑混乱，往往会给阅读程序代码的工作人员带来更为复杂的任务难度，因而往往不建议在程序中使用goto语句。

问题5：软件开发过程中是否有必要保证代码具有100%的正确性，如果有必要又应该如何实现呢。

根据《构建之法》第2章中2.1节单元测试部分的如下一段文字：

要注意：100%的代码覆盖率并不等同于100%的正确性。

通过结对编程以及团队项目的开发过程，我对这个问题也有了一些自己的体会。通常来说，我们的单元测试应当保证较高的代码覆盖率，但是这个覆盖率是对代码的逻辑分支来说的，因而无法保证正确性的高低。此外，代码100%的正确性本身就难以保证，应该说我们通过测试后满足一定的规范要求就可以了。但是对于某些程序，可以从理论上来分析其正确性，并且约定相应的API规范，此时一定程度上是可以实现程序100%的正确性的。

新问题：在网页前端开发过程中，如何才能保证前端的内容展示不“简陋”。

通常来说，为应对课程网页前端开发，我们学生可能通常的操作是在网上找一份模板，针对自己的具体需求再改一改就可以算是开发完成了。但是，如果考虑自己开发前端内容，通常也只能使用前端组件库的现成组件，尽管美工风格采用较为简约的模式，开发出的网页前端还是往往会被认为十分“简陋”。针对这种问题，请问除去找模板这种方式外，是否还有更好的方法。

在实践中学习知识点

需求阶段

在这一阶段主要学习到的知识点就是NABCD的项目需求分析。需求分析的内容应当包括项目主要解决用户的什么需求，项目有什么做法用来解决用户目前的问题，项目会给用户带来什么好处，项目相似的竞争者的具体情况以及推广项目产品的具体方法。对于我们团队的项目而言，其主要解决了用户对疫情感染和疫苗接种相关信息的获取问题，而为了进一步获取更详细的用户需求，我们还应当对各个年龄阶段、不同工作背景的用户进行采访调查。总之，通过需求阶段的分析，应当确立最终的团队目标，并对以后努力开发的方向也有进一步的了解。

设计阶段

设计阶段应当从用户的需求出发，结合部分功能的实现难度，确定项目产品最终的功能设计。同时，具体功能作用的体现应当保证直观。在我们项目的alpha阶段，部分国家疫情数据折线图是通过点击或者下拉才能展示，但是对于用户来说，这样的设计并不是十分直观，很多用户都不清楚这里还有一个折线图可以显示出来。因此，我们在接下来的阶段增加了相关功能的简单使用指导，也将该功能的展示方式稍作修改，使其更加直观。

实现阶段

实现阶段应当注意团队接口文档的规范，确保编写的代码内容符合接口文档规定的内容。如果接口文档的设计者需要对部分内容进行更改，则需要及时通知团队中负责实现相关模块的成员，防止信息不一致导致功能无法正常实现。对于我们的团队项目来说，主要就是前后端数据传输的接口需要符合接口文档规定。而在beta阶段，由于需要对旧有功能进行拓展，接口文档也需要修改，此时就需要对负责实现相关模块的成员进行通知，保证实现的具体内容符合接口文档。

测试阶段

实际的项目产品不仅仅只有简单的功能测试和单元测试，还应当包含性能测试等非功能性测试。对于我们的团队项目来说，由于涉及大量疫情感染及疫苗接种数据的展示，在网页展示的过程中也涉及到大量前后端通信的流程。因此，在测试阶段进行性能测试并进行部分功能的性能优化是十分必要的。

发布阶段

发布应当从多渠道对项目产品进行宣传，保证能最大程度的收获用户量。通常来说，单一的宣传方式大都只能收获单一的用户群体，比如我们通过朋友圈的宣传大都只能获得周围同学这样的用户群体。但是，如果能够通过视频网站、媒体专栏等多种渠道对项目产品进行宣传，能够最终接收到我们发布信息的用户群体将大大增加，最终收获的用户量也将有所增长。

维护阶段

维护阶段应当注意对用户反馈的收集，并对内容进行分类考虑处理。对于影响最终功能的bug反馈，应当及时处理修复，并进行重新部署。对于部分外观设计，功能结构性的反馈，应当和小组成员共同讨论后，选出部分合理的内容进行更改。此外，由于我们的项目产品涉及到从其他网站爬取数据，还应当定期观察数据源网站的情况，确保数据来源始终无误。

总结与体会

经过这个学期软工课程个人阅读、结对编程以及团队项目的工作，我感到自己不仅在理论上对软件工程拥有了更深层次的理解，也在实践中获得了相应的开发经验，总之收获颇丰。

在前两次的个人博客作业中，通过阅读计算机行业大佬的经验分享以及《构建之法》中软件工程相关的理论内容，我不仅逐渐对自己未来的规划拥有了更加明确的目标，对目前国内计算机行业的具体情况有了进一步的了解，也对敏捷开发有了一定的初步了解。此外，通过调研 Gitlab CI 和 Github Action 这两个持续集成/部署工具，我也初步掌握了这些工具的使用方法。

在之后的结对编程项目中，通过和队友通力合作共同编写一个完整的文件管理系统，我对结对编程这一方式也有了亲身的实践体会。针对完成内容的不同，结对编程项目前后可大体分为两个阶段。在第一阶段，我的收获主要是探索两个人共同完成项目的方式，虽然我们最终确定的合作模式潜藏着一些问题，但总体上将我们最终实现的质量维持在了一个风险可控的范围内。而在第二阶段，我们基本上已经熟悉了自己的结对编程模式，因而主要的收获则在于针对不确定需求的实现思路上，虽然整个过程的修修改改难免会增加质量的不可控性，但最终也算是能够完成一个符合规范的版本。此外，在这个阶段，我们也进一步熟悉了持续集成/部署工具的使用，并掌握了代码单元测试工具的使用。

最后的团队项目中，在优秀的PM的指导下以及和负责的队友的共同努力下，我们团队最终克服重重困难，完成了这款基本达到疫情感染和疫苗接种可视化展示的网页应用的开发。在开发过程中，我主要负责前端内容的开发，虽然作为理工科的学生，对前端的美工设计并不熟悉，但我们还是通过广泛的调研与借鉴达成了大体上还说的过去的美工风格。此外，通过团队项目两个阶段的多次例会，我也逐渐体会到例会中成员沟通交流的重要性，团队项目中的需求分析、技术规格说明书、功能规格书明书、发布报告与测试报告的编写都是在我们团队进行长时间交流才最终确定的内容，而开发过程中定期的接口文档的更新也需要和队友进行及时的交流。总之，感谢助教团队PM和其他开发成员的辛勤付出。