写在前面
| 项目 | 内容 |
|---|---|
| 所属课程 | 2020春季计算机学院软件工程(罗杰 任健) (北航) |
| 作业要求 | 提问回顾与个人总结 |
| 课程目标 | 培养软件开发能力 |
| 个人博客 | 提问博客链接 |
1.回答以前的提问
(1) 单元测试相关问题
这一问题我依然保持原有的观点：单元测试可由最熟悉代码的程序作者来写，但也需要一定的他人辅助。在这次团队项目的开发中，这一点我深有体会。一个人自己写自己的单元测试，可能会思维受限，考虑不全。那么多少辅助测试比较合适？又要选择谁作为辅助测试的人员呢？首先，程序作者自身需要对自己的代码进行规范，要有注释和说明文档，尽可能降低他人理解的成本。其次，不可完全依赖辅助测试，需要让辅助人员清楚已经覆盖了哪些测试，避免重复工作，辅助测试则更偏向精准化的补充。再者，辅助测试的人员需是与程序作者工作相似或者对该部分功能比较了解的人员。
（2）软件团队的模式
对于不同模式的优劣性问题，我认为“不管白猫黑猫，抓到老鼠就是好猫“。但经过一学期的体验，我也有了新的认识。无论什么模式，团队能达成共识是很重要的，要有明确的共同目标。如果有的人止步于水完任务，有的人却力求把产品做到最好，那么设定的目标不同，合作过程中必然产生诸多分歧与矛盾。不同模式中，由于每个人的能力水平不同，达成共识的难易程度也是不同的。若大家都想把项目做好，那么根据各组的情况选择合适自身的模式，再加上合理的任务分配与有效的管理与领导，结果也并不会太差。
（3) 关于项目经理
通过这次的团队合作解决了我的这一问题。我们项目的PM是很有能力的，他在提出需求、协调工作等方面完成得很出色。加上自身冯如杯项目队长的体验以及与小伙伴们的沟通，我对PM这一职位有了更深的认识。PM不一定需要苛求技术开发的深度，但对项目广度上了解的要求很高。若想要将工作分配合理，PM必须要了解各个组员的能力和各个部分工作的大致情况。若想使项目具有竞争力，PM要提出导向性的合理方案，这就要求PM收集大量的用户需求，并且对相应的技术领域有一定的了解，以衡量开发的可行性。
（4） 质量保障的问题
项目可见性对于不同性质的项目，其具体情况不同。我们这次的团队项目并没有遇到这样的问题。由于采用前后端分离的方式，所以阶段性的工作都可以展示，可见性较强。
（5）关于创新的迷思
对于这个问题，我依然有之前的疑问。但我想，这样一个问题并不需要一个是与否的答案。
2. 新问题
-
前后端对接问题
Alpha阶段，我们组在前后端对接时耗费了大量时间。我们的前后端开发是分离的，原设想按照事先规定的json和api格式分别写好各自的部分，对接就可以顺利进行。但实际并非如此，由于原先规定的格式欠妥和前后端交流不及时，导致对接时大量之前的工作被推翻重做，甚至最后一方要根据另一方做大改动。
前后端对接的关键在于要规范接口。我们组确实是这么做的，但期间也出现了很多问题。规范接口应该什么时候完成？早了，对项目需求了解不深入，无法设计出合理全面的接口；晚了，又将延迟开发时间。若前端或后端某一方提出调整接口格式，那调整与否最后是由接口设计的合理性，还是由某一端实现的难度决定呢？
-
如何对待某些低概率的bug
在项目开发的过程中，我耗费了大量的时间在解决一个bug--联动问题。这个bug是组件自身固有的问题，只有在某种特定的操作顺序下才会出现。根据人的行为分析，这样操作的概率极低且并不影响正确性 。我的队友后来也在帮我de这个bug，我们耗费了相当多的时间和精力在此，可最后依然没有解决办法。
这样的bug可被定义为修复价值不高，修复成本却巨高的bug。那对于这样的bug，我们应该怎么处理呢？是死磕到底，为了那句“细节决定成败”？还是尝试无果后搁置，看重付出与回报的比率？
3.学到的知识点
（1）需求阶段
需求阶段是分析项目的NABCD，主要是学习了如何具体分析需求、做法、好处、竞争、推广。
首先，我觉得明确需求，并能对各种需求的重要性进行衡量是非常重要的。这一步的关键作用在于明确产品定位。“勿忘初心”这一点并没有想象中那么容易做到。在我们开发的过程中，由于实现难度等原因，我们确实有些时候偏离了“初心”，那么及时的回顾需求分析就很必要，这样才不会搞错核心功能。
其次，推广也是门学问。广撒网的推广方式并不是最佳的。我们要明确产品的目标用户，对于不同的细分市场进行针对性的推广。
（2） 设计阶段
设计阶段主要学习了如何设计技术规格说明书和功能规格说明书。
技术规格说明目的是让开发者明确需要实现哪些接口以及实现的整体逻辑。功能规格书目的是让用户了解产品的页面原型，对产品的核心功能有初印象。
（3）实现阶段
这个阶段让我明白了计划安排的重要性，其实这一点我们组做的并不是很好。每个人心里对时间的认知并不相同，有的人是“拖延症患者”，有的人是“积极分子”。并且每个人的作息以及工作习惯都是不同的。那么要想一个多人团队能够按期优秀地完成一个项目，那么预告性与计划性就很重要。整个团队需对进度安排有明确的计划，这需要全组队员辅助PM完成的。个人也需对自己的工作有计划安排，并且在能力许可的情况下预留缓冲区。
此外团队开发中要学会使用便捷的团队项目管理工具，善用GitHub或是Gitee上的issue和pull request。
（4）测试阶段
- 进行单元测试，尽可能覆盖。
- 每添加一个功能或是修复一个bug，需进行回归测试，以保证其他功能未受影响。
- 对访问量持续高的网站，需进行压力测试，确保高访问量时网站不会崩溃。
- 模拟实际用户的操作对产品进行测试。
（5）发布阶段
根据目标用户，针对性推广。发布时要重点宣传项目的核心功能和解决的痛点。为用户提供便捷的使用和反馈途经。
（6）维护阶段
及时收集用户的反馈，对提出的bug进行修复，对提出的新需求进行考量采纳。若产品有更新，需要告知用户更新内容。
4.理解与心得
（1） 个人项目
个人项目的难度不大，但是工作量也不小。这一次作业我花了较多时间在框架设计和正确性测试上，性能优化方面也做了一些工作。但从最终的性能得分来看，我做的还不够。这可能是由于我搜集资料不足、相关知识缺乏导致的。比如我后来才了解到VS中Debug模式和Release模式的区别。
（2）结对项目
这是我首次接触结对编程。虽然由于疫情原因，我们并不能面对面进行协作，但线上会议+代码共享的方式也让我们体会到了结对编程的诸多好处。在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。也正是由于这一优点，在团队项目的开发过程中，我们小组也融入了”结对编程“的方法，取得了不错的效果。结对编程也是有着极高的成本的，毕竟需要两个人的共同时间。那么，让过程变得高效就很关键。
（3）团队项目
首先，让我认识到了前期准备工作的重要性。朋友圈中有很多吐槽前端工作的，他们多表达的是对没有选择模板的后悔，从零开发遇到了很多难以解决的问题。完成一个完整的网站，前端的工作是庞大的，逻辑也很复杂，涉及的知识很多。对于前端小白来说，短时间里从零完成一个项目是困难的。我很庆幸自己的前期准备工作是充分的。我找了大量的模板和UI组件库，通过对比从中选择了最适合我们的。因为模板的教程非常详细，让我们迅速建立起了对于整个网站框架的理解，也让我们后来的前端开发变得事半功倍，没有走弯路。在这里，我不是提倡走捷径，学习核心知识也是我们需要的。只是考虑到我们自身的水平和项目的性质，这样做不失为一种较好的选择。这件事也让我深刻地体会到了“磨刀不误砍柴工”。
其次，软件工程是一门需要实践的学科。在开发工程中，我们组摸索出来了一套适合自己的合作方式--”多人结对编程“+"石墨文档"。”多人结对编程“让我们组内高效互相学习、分享经验；”石墨文档“让我们清楚各个需要填补的”坑“和需要去承担的”锅“，精准分配，无遗漏，使每个人对项目的总体进度都有了解。前人流传下来的经验，必然有其道理，但是否为最适合自己的方法却并不一定。通过实践与创新，我们可在规范的流程中进行个性化的补充，找到最适合自己的一套方法。
最后，我很高兴能和团队一起完成这个项目。队友都很优秀，我们在项目初期就达成了共识：做一个真正实用的、可流传的软件。正是因为这一共同目标，我们在开发过程中始终没有逃避困难，力求打磨每一个细节，给用户最好的体验。看到注册人数不断上涨，也收到了很多同学的感谢反馈，我们是很欣喜和自豪的。