【老物】2021软工-提问回顾与个人总结

一、解答自己提出的问题

结对编程总能做到1 + 1 > 2 吗？教材中第四章出现了结对编程(Pair programming)，这是一种变态的代码复审，有别于传统的Code Review。书中强调"复审的目的在于纠错改进与教育更多的开发人员"，随后在4.5.3节说到Pair中两人对程序深入了解，复审效果好。但代码复审包括具体代码、效能、设计规范等多方面，Pair中有时间像Code Review一样周全的考虑吗？在传授经验这个方面，Pair中比较多的也是口头交流吧，那么有些经验不就只停留在两人之间了吗？当开发想到一个新idea，为什么不形成书面形式在Code Review中“让更多的成员熟悉项目各部分的代码”？为什么想着不间断地复审而不去花时间提高团队Code Review的效率？

结对编程的优点是可以进行实时的代码复审与交流，从而提高二人的工作效率,减少可能出现的bugs。在团队开发中，相同分工的人员也适合以结对编程的形式进行开发，修复难以发现的漏洞时结对编程也往往能快速定位问题。而团队内的代码复审可以让成员对一份签入代码从一致性、编码风格、安全与冗余等方面综合监督，同时及时发现所用技术方案/框架的不足，减小试错成本。相比于结对编程大量的面对面交流，代码复审还能自然地衍生出技术说明、API说明等文档，一份确定的代码规范不可或缺，一方面可以统一项目代码风格，另一方面也能提高团队代码复审的效率。总之，在实际开发中是否进行结对编程，都需要从时间、工作重合度、成员相性等方面考量，灵活选择开发的方式。

代码测试中覆盖率要达到100%吗？教材提到“100%的代码覆盖率并不等同于100%的正确性”。从投入产出比的角度考虑，覆盖率达到100%势必要更多地考虑琐碎的问题，覆盖率不错的情况下边际收益岂不是下降了？100%的代码覆盖率并不说明代码正确，我认为覆盖率是一个基本指标，而不是目标。全覆盖的测试不一定考虑全了外部的问题

代码覆盖率是一个基本指标，而不是目标，也不能保证代码完全没有问题。结对编程项目中虽然实现了较高的行覆盖率，但分支覆盖率与特殊输入数据方面没有做到尽可能完善，导致在评测中仍出现了一些问题。在实际团队开发中，生产环境中的各种细节需要考虑，代码的性能，可靠性与可拓展性也很重要，软件不是做到刚好可用的程度就行了，发布前需要通过压力测试、CI/CD自动化测试等手段保障质量。在生产环境中，可能遇到开发时难以察觉的问题，如数据的存储安全与鉴权问题、远程服务器带宽限制，因此无法全面考虑周全时，就需要开发组吃狗食或尽早发布征求用户反馈，及时处理新问题。其次一个例子是多设备适配的问题，无论WEB/移动端/小程序都可能遇到，团队项目仅发布于Android平台，而Android设备型号过多，在发布软件后，确实在部分机型上出现了分辨率自适应、硬件性能不足的问题，软件发布前可以增加测试用设备、使用WeTest等工具，以解决机型适配问题。

根据敏捷理论，对于执行原定计划更倾向于响应变化，并与客户合作。所以在冲刺中产生新的需求不应是常态嘛。真有重要变化时，为什么不在Scrum Meeting中一齐讨论此改动的重要性和急迫性再考虑进不进行工作上的调整？既然每次新的需求产生时都可能波及到系统中多个模块，或者是现在完全没有考虑的优化方向，那么有时重构不可避免，拖到Sprint结束会不会导致问题积压，错过重构的黄金时间，Sprint中的安排不可改变吗？敏捷还强调个人和交流，这在小团队很奏效，团队规模大了以后难以保证高效的交流。而且相比传统的软件开发模式不重视正式的文档，这在团队工作交接的时候会不会有困难，敏捷开发中怎么将一个项目做大做长远？

实际团队项目中，只有两次冲刺的工时，因此需要适当舍弃一些边缘功能，尽可能接近开发计划吧，比如考虑到开发时间与功能重要性，团队软件最终没有实现好友、聊天等功能，但将精力投入在联机游戏这个核心功能之上。同时在β阶段初期，为了实现联机功能，及时花时间修改了原有代码，抽象出“玩家”实体，以防止冲刺阶段中出现难以拓展代码的问题。敏捷开发中，很重要的一环就是在冲刺结束后根据用户反馈及时调整计划，修改需求，团队开发中在β阶段就根据反馈额外加入了教程等功能。

为了保证团队工作的交接，首先代码本身需要有良的架构，不能内部过度耦合；其次要保证有必要的规范化的文档，如客户端/服务端的接口说明文档，代码细节方面首先需要统一代码风格，否则接手者可能难以适应混乱的编码方式；同时需要pydoc/jsdoc等格式化的注释，方便快速上手代码。

写不出好代码的PM是好PM吗？既然PM要做其他的那么多事情，那么对TA的代码能力有要求吗，要求多好呢？我认为PM应该做到的是对开发使用的技术路线与架构有个基本的认识，才能更合理地评估某一功能开发的难度，这样可以避免异想天开的设计，也更方便与开发者交流。

PM也不一定需要对开发使用的技术路线与架构都很了解，有能力把握住团队项目的全栈开发的要求太高了，所以我认为合适的团队组织形式是根据开发方向固定经验最多的一辆位成员作为技术顾问，并负责团队的技术选型与代码架构设计。在课程团队开发中，PM更不可代替的作用应是团队开发计划的制定、PUSH成员落实开发进度、及时协调成员间的工作。

创新不必是领域内专家，关键不必是技术？如果很多企业都只安于跟上主流技术，一味追求这些模式创新，怎么解决相关市场的同质化问题？

软件不一定需要通过技术创新成功，在团队项目中，大家都是在做传统的互联网软件，而且都是C端的软件。因此软件背后使用什么技术，使用者很难关心，使用者的评价往往是依据实际使用中的直接反馈，因此团队开发的重点是进行“模式”上的创新，应用现有的技术/框架去满足用户最重要的需求。没有硬性指标，因此在开发中只需要实现安全、可靠的服务端，性能只需要满足个体使用的需求，如解决服务器带宽限制、应对大量并发访问等；开发中需要实现好用的客户端，因为客户端直接与客户打交道，UI界面设计、交互流程设计、网络性能优化都是值得投入大量开发精力的模块。

同时团队项目中开发的软件为移动端游戏，因此创新方面还涉及到游戏机制的创新，这方面开发组没有选择独立从头设计一套游戏机制，主要考虑到自定游戏机制可能对玩家入门产生一定门槛，因此和广大游戏一样，开发的游戏基于多种游戏玩法，对原有游戏机制进行了细节上的修改与创新。

二、实践中学到的知识点

首先需求分析阶段需要通过问卷等调研方案获得一定量的真实反馈，用户需求很难是自己心中想当然的样子，它需要数据来佐证。同时另一个重点是对现有竞品的调查，找出自软件拿得出手的差异化功能是必要的，表面的同质化会直接影响用户使用的欲望。

对于一个万行级的团队项目，开发前的设计相当关键，如上文言，经过专门的代码架构设计才能把软件功能模块化，拆分成可分配的任务。同时作为游戏开发组，团队项目中设计环节更加重要，游戏机制上的变更难以预测，有时需要根据反馈修改游戏底层逻辑，因此开发中的游戏状态机设计与游戏运行脚本需要解耦合，有良的可拓展性

开发中高效工作的关键是及时的沟通与合理利用Git等多人协作开发工具，我体会到了每日例会的重要性，小组成员可以在例会上找到开发的节奏，及时总结并找出现存问题。在测试方面，不但要做好客户端/服务端的单元测试，也要综合考虑软件的安全性，如数据传输与存储的加密。当然，团队开发中，游戏客户端的多设备适配与测试、服务端的压力测试都是不可或缺的一环。

软件发布后，如果很难通过过硬的核心功能吸引长期用户，则有必要通过各种宣发手段招徕用户，即使是短时性的用户，因此需要通过微信、产品主页等方式积极进行宣传。在维护方面，如果想把团队项目长远地做下去，那么详尽的文档是必要的，同时在迭代开发中，要充分考虑到软件更新对旧版本的影响，在WEB开发中，接口地址的更改并无太大影响，但在Android平台上已发布的APP会遇到接口不可用的问题（如替换HTTP为HTTPS），这时就需要在代理网关处进行重定向，在不强制更新的情况下把对用户使用的影响降至最低。

三、 项目经历之中的心得

个人阅读作业1中我归档计算机系中学习历程，思考自己的定位与未来；个人阅读作业2中我通过阅读教材提炼所思所惑，并初探Git, CI/CD相关工具链。在结对项目中，我最大的收获是提升了交流能力，并体会到了代码架构设计的重要性，同时我也为无法进行阶段三的迭代开发任务感到可惜。

在团队项目中，我们的团队进行的是一个安卓手游的开发，我作为一个没有接触过Unity 3D的开发人员，却在发开阶段得到了有相关经验的队友的大力帮助，从而顺利地完成了一部分场景、脚本搭建以及游戏内UI开发的工作。依靠团队的力量，我们才能从零开始实现一个五脏俱全的游戏软件，在此感谢PM/服务端开发lcy，网络编程/游戏脚本开发组qy，wcf，UI组yyh，zsk的共同努力与付出。