提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	在结对项目和多人团队项目中，更加系统地学习软件开发，培养工程化的思维
这个作业在哪个具体方面帮助我实现目标	回顾本学期课程经历以及自己对课程的感悟
个人博客	提问博客链接

一、问题解答与分析

单元测试应该产生可重复、一致的结果......单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据，以保持单元测试的独立性。

Q1：书中的说法是否过于绝对？当针对多线程尤其是死锁等偶发性的问题进行测试时如何保证单元测试可重复性？另外，进行压力测试时，单元测试的运行会依赖别的测试，显然不满足书中所说条件，那我们难道就不测了吗？

我认为，单元测试主要是对代码逻辑进行的测试，并不能代替压力测试、黑盒测试等其他测试方式，因此也不必检测应当由其他测试方式检测出来的可能的问题。换句话说，多线程、死锁等问题的测试应当出现在压力测试或者是公测阶段，而不是由单元测试来解决，单元测试只应当针对某一段逻辑复杂的代码，并且单元测试的结果应当是可重复的，这样能够验证代码逻辑的正确性。

在单元测试通过以后，应当继续进行压力测试。在压力测试遇到问题时，测试人员应当及时调取相关的日志文件并保存下现场（例如记录发生死锁的线程编号或者引起系统崩溃时的资源占用率），并且撰写出bug文档返回给开发人员进行修改，这样能够最大限度地弥补单元测试无法针对这类不可复现问题的缺陷，从而提升测试的效果。二者应当相辅相成，互为补充。

这个问题的答案是我们小组进行测试时我思考得到的，一开始我总是试图用单元测试来代替其他各种各样的测试方式，后来发现单元测试并不能覆盖所有可能的异常情况，因而重新将单元测试的重心放在代码的逻辑上。

项目/任务有多大？说到项目的大小，一般用代码行数来表示......也可以用小时、天、月、年来表示......也可以用re-work（返工）的次数来表示

Q2:项目/任务的大小应当由什么指标来决定？我认为书中的答案只在特定前提下才能够很好的衡量工作量。

我认为，书上给出的用代码行数来衡量的方法是不准确的。以上学期的编译课设为例，有的同学编译器代码只有3000+行，而有的同学代码量则达到了7000+行，能说后者的工作量是前者的两倍吗？显然不行。由于每个人采用的算法不同、架构不同，会导致代码行数有所差异，用代码量衡量会有失偏颇。我认为，应当用代码行数的数量级衡量项目的大小。我们的大作业代码行数的量级是千，一般的iphone应用代码函数的量级是万，鸿蒙操作系统、谷歌浏览器代码行数的量级是百万，通过这些数据能够大致比较项目的大小，对于量级相同的工程我们可以认为其大小大致相当（除非使用的语言有较大的差异，例如一个项目使用底层汇编语言，另一个项目使用python等较为高级的语言）。

在小组合作的过程中，我发现在大家都对unity 3D不太了解的情况下，因为组内的各个成员能力水平相差不大，可以使用投入时间来衡量任务的大小。有时候，为了调用合适的接口函数，可能需要阅读各种各样的接口说明书，理解清楚了以后才能进行调用，这样看起来代码不长，但是背后所花费的时间是巨大的，因此此时使用代码量来衡量工作量就有失偏颇，而使用花费的时间来衡量就更能反映任务的实际难度。

在企业里，要衡量一个任务的大小，可以用普通员工完成该任务上花费的时间来确定。何为普通员工？在这里，我说的普通员工并不是某一个具体的人，而是一名能够代表社会平均劳动生产率的员工，即业界平均水平的程序员完成该任务所需要花费的时间。

软件团队和客户代表要在需求阶段把这些问题（指对产品功能性的需求、对产品开发过程的需求、非功能性的需求、综合需求）给搞清楚。

Q3:能在需求阶段就把这些问题都搞清楚当然最好，但是实际情况往往是用户并不了解自己的需求，或者软件团队无法准确获取用户在表述中隐含的需求，此时应当怎么办？

首先，在任务开始前应当尽可能详细地调查用户的需求。经验表明，用户的对于产品的最基础需求往往是能够通过调查得到的，这些需求大多是功能性需求，然后根据用户的需求开发出满足用户最基础要求的最小化版本。其次，对于用户的兴奋需求，我们认为是可以被诱导出来的。换句话说，应当通过团队的自主设计来引导用户的需求（例如，在网站上制作出一些精美的动画，让用户使用时感到惊叹不已；或者是我们在开发游戏的过程中尽可能的压缩游戏的大小，为用户节约流量等等）。这些功能我们设计出来了以后，即使用户在使用之前没有设想到会有这些需求，在使用过程中也会因为提升了体验感而起到加分的作用。通过团队合作开发项目的过程，我明白了自行设计并进行优化的重要性，优化过的产品往往能够满足用户隐含的需求。

我平时接触的同学都说计算机专业的，我平时上的网站都geek味或者hacker味十足......原来我并不了解海量中国用户，原来真实的用户并不是我想象的那样。我不理解为什么360的装机量那么大，但实际上有海量的用户不懂得如何管理电脑软件；我不理解为什么hao123能有那么大影响，但实际上有海量的用户并不会直接输入常用网站的网址；我不理解为什么那么多人愿意在QQ上为虚拟形象付费，但实际上有许多年轻女孩愿意花钱来为自己在社交平台上的形象打扮。

Q4：这个人不了解大多数用户的需求是因为他本人是计算机专业的，他周围接触的人大多都是计算机领域的，因此他认为的用户和实际情况相去甚远。而企业做调研报告的时候，回收的样本往往也会由于回收样本的群体不同而使得结果产生偏差。怎样尽量减少偏差？

在团队项目的过程中，我们在开发之前先通过调研等方式得到了典型用户，我们的产品是针对典型用户开发的。因此，我们的调查结果只要针对这一类典型用户群体的准确的，就能够让我们开发出来的软件有较高的用户满意度。换句话说，只要回收样本的群体是我们游戏的主要受众，那么收到的结果就是可信的。

PM(Program Manager)和大家平等工作，推动团队完成软件的功能......一个团队可以有很多PM......PM管事不管人。

Q5:PM没有领导权，会不会导致团队里的开发者偷懒？PM的工作分配很难做到平均，由于不存在领导关系，所以难以有效管理？创新不仅需要个人魄力，还需要有权力才能推动？

通过这次团队合作的经历，我们的PM李辰洋完美地用行动回答了以上问题。在一开始，我们就制定了奖励措施和惩罚措施，对于拖ddl、耽误小组进度的同学会有严厉的惩罚；同时，由于我们有着严格的出口条件和验收标准，使得组内的开发者难以浑水摸鱼，这样就杜绝了偷懒的现象。关于分配工作的问题，PM会私下调查同学们掌握的技术栈并在每项工作分配之前统计意向，优先给各个同学分配自己擅长、感兴趣的工作，这样能够有效调动成员积极性；如果实在需要有人委屈、牺牲去做一些没人愿意做的工作，在事后PM会征得大家的同意后给予一些补偿（例如分配更多的贡献分等等），尽可能地平衡大家的付出与收益，从而有效地完成分配任务和管理的工作。每一次在游戏内的创新都是PM领导大家做调研、开组会探讨得到的，在组会上我们会积极探究一个方案的可行性以及技术难点，在取得大家的认可了以后才会进行，因此对于我们而言创新是一个组的事情而非PM一个人的事，不需要PM去强迫大家来做，也不需要PM通过权力去push大家。这种自发性让我们在提出新的idea后能够更好地落实和实施。

二、学到的"知识点"

需求

需求分析阶段最重要的知识点是NABCD，即需求、做法、好处、竞争、推广五个方面进行分析。

对于用户的需求，我们小组采用的方法是面向典型群体进行调查和采访。我们通过微信问卷、朋友圈提问等方式收集了不同年龄段用户对于轻量级手游的需求，掌握了用户的整体需求量。此后，我们针对部分典型用户（例如高中生、在校大学生）进行了一对一的采访，倾听用户真实的声音。应该说，需求分析对于我们的产品定位具有重要意义，也对我们日后的开发产生了指导意义。通过调查需求量的大小，我们得以选择合适的服务器；调查用户的使用习惯我们实现和优化了许多游戏内部的细节。从用户中来，到用户中去一直是我们开发产品的初衷，通过需求分析，我们明确了许多在开发阶段应当注意的事项。在具体做法上，我们尽可能发挥了组内成员的优势，让善于写前端的同学去完成UI部分，让有丰富游戏经验同学去开发游戏逻辑部分，这样他们能够在开发之前有较为长远的规划，对于项目周期的估计更加准确，遇到问题时更好地拿出解决方案。好处是产品主打的优势，是项目能够让用户产生良好印象的关键。我们团队通过自主设计一些能提升用户满意度、满足用户兴奋需求的细节来提升产品的竞争力。在同类游戏产品中，我们的游戏占用内存小，游戏大小较小，运行流畅，能够在低级别的操作系统上兼容。而这些优势，也提升了我们的竞争力。在推广上，我们也深深明白推广一款新游戏的不易，但我们还是尽可能地在更多途径进行宣传，例如制作网页、在朋友圈转发、制作推送等等。同时，我们还注意到，由于在周末用户的需求量会有所提升，因此推广的时机也应当尽量选择在周末，这样用户更有可能有时间去尝试。

总体而言，在项目中我更加生动地感受到了NABCD的全过程，对于具体的实现细节有了进一步的体验。

设计

设计主要用到了技术规格说明书和功能规格说明书。我们在说明书中大量使用了表达控制流(Flow Chart)来进行设计，这种图利用类似状态转移的方式帮助我们理清复杂的逻辑，非常直观易懂。同时，我们的功能规格说明书将验收标准也包含进去了，这对于后面的测试和交叉互测非常有帮助。有了验收标准和指定负责人，实现了责任关系的明确化，一旦出了Bug能够很好的溯源和追责，也体现了设计阶段对于项目全过程的统领作用。

实现

本人在团队项目参与了游戏界面的部署以及网络部分的同步，学到的知识点是避免重复造轮子，以及如何选择合适的轮子。

在部署许多模块和组件的时候，应当最大限度的利用官方已经提供的接口，Unity3D是一个强大的组件，有许多的内置功能，而有时我因为懒得去翻阅官方的文档而走了很多的弯路，许多组件的配置都从头开始一点点用代码实现，而实际上这些配置只需要通过图形化界面下一键点击即可完成绑定。同时，官方提供了非常强大和全面的接口，在阅读完传入参数和后置条件以后即可使用，而不是自己尝试用原始的方法来完成任务。同时，选择合适的轮子非常重要。在部署服务器时，有三四个开源的接口可以选择，如果没有慎重选择的话，可能会因为服务器的限制（例如最大支持的连接数量的限制或者是不支持全双工通信等问题）而遇到麻烦，如果在项目的后期才遇到这种难以避免的问题可能会导致进退两难的情形。因此，在前期调研技术栈时应当尽可能详细，要对接下来的工作有了大致印象以后再选择合适的轮子，确保能够实现基本要求以后再选择合适的轮子。

测试

在团队项目中，因为前端单元测试难度较大，所以没有进行规范的单元测试。我们采用的是人工测试，让多个用户去体验产品，我们意识到有时人工测试是必不可少的，因为机器测试对于出来明显的卡顿和延迟，而人工测试能够及时发现前端方面的此类问题，我明白了不能过度依赖机器测试，毕竟我们的产品是面向用户的。

同时，我还明白了交叉互换、由他人进行测试的重要性。在结对编程阶段，由于我对于指导书产生了误解，按照自己错误理解书写了代码，并且自己根据错误的理解书写了测试程序，因此并没有能检测出Bug。而交叉检查能够很好地避免这个问题。我学习到了在可能的前提下应当尽量由另一个人来进行单元测试。

发布

发布主要学到的知识点就是：学会合适的时机、合适的平台进行推广。

我们发现，在周末进行推广的效果明显优于在周中进行推广的结果，说明用户在周末会更加有时间浏览并下载游戏，选择好了时机就能够事倍功半。同时，我们发现在QQ群推广的效果明显不如微信群，猜想这可能和用户的使用群体和使用量有关，QQ的使用量较少或者QQ的使用群体不如微信的使用群体对游戏热衷，因此在后期我们主要通过微信推广。我学习到了合适的推广渠道能够提升推广的效率。

维护

维护阶段主要学会的是把握好版本更新的时机。

如果版本更新过于频繁，可能会使用户不厌其烦，同时也会消耗用户过多的流量，对于没有wifi的用户不友好；版本更新太慢，则一些bug不能及时得到修复，一些严重的Bug可能会严重影响用户体验。

三、理解和心得

个人项目

本学期的个人项目，主要就是阅读给定材料和博客的撰写。

通过个人阅读作业#1,我尝试着整理和思考了自己已经走过的路，对于未来的职业有了初步的规划，明确了自己的软件工程这门课中应当学习到什么、应当有什么样的收获。

通过个人阅读作业#2，我阅读了《构建之法》，对于软件工程这门课的整体框架有了了解，还学习到了提问的艺术。另外，我还学习到了一整套关于软件工程的体系，了解了如何完成工程化、高质量的软件工程。同时，对于CI/CD工具的调研让我掌握了使用该工具进行自动化测试的基本流程，为团队合作项目中自动化测试提供了帮助。

而后的案例分析作业中,通过对市面上已有软件的使用和BUG亲自尝试，让我大致了解了目前已经走向市场、开始盈利的项目所应当具有的水准，也让我明白如何系统性的分析和对比市场上不同软件，了解软件评测基本方法。

结对编程

结对编程其实某种意义上是一次两个人共同完成的OO作业。相比于以往的OO作业，结对编程的好处在于有小伙伴来互帮互助，可以帮助自己理解还可以帮助自己测试，最大的难点在于如何做到1+1>2。我认为，要想做到1+1>2，首先要有良好的工程规范，变量的命名应当尽可能的通俗易懂，但凡有使用小技巧的地方一定要加注释，能够进行代码复用的部分尽量进行代码复用。如果能够做到以上几点，在队友进行代码复审时，就能够让对方快速读懂自己的代码，免去双方因为误会而耽误时间，起到高效沟通的作用，同时也为后续的迭代开发打下良好的基础。然后，双方共同写代码的过程中应当尽可能地做到高效沟通，尽量在一开始就把可能的问题给阐述清楚，避免越说越糊涂。此外，把控好自己的情绪非常重要，我的队友陈伟明在遇到困难时及时安慰我，调节双方的情绪，还非常体贴地在我筋疲力尽时送上小零食小甜品，让整个团队的氛围更好，让我们结对编程的效果更佳。在结对编程的过程中，我看到了陈伟明身上的种种闪光点以及他的人格魅力，我们收获的友谊无疑是结对编程给予我的重要经历。

团队项目

首先，很高效自己能够和一群优秀的队友共同开发出弈魂游戏。在软件工程课程之前，我也曾参加过包括冯如杯、实验室在内的项目开发，但是软工的项目是周期最长、过程最完整的项目。本项目设有alpha和beta两个阶段，每个阶段都有需求，设计，实现，测试，发布和维护的完整流程，而之前的项目往往都集中在开发阶段，不需要进行需求分析，也几乎不需要长期维护，偶尔需要自己设计一些细节，但是整体的架构都已经有成熟的框架了。通过这一次完整的项目经历，我明白了需求、设计对于后期开发工作的指导作用，也深刻认识到了详细的功能规格说明书、技术规格说明书对于日后的开发有多么重要。同时，在合作交流中，我明白了如何与他人协商，如何在组内协调好与组员之间的关系，达到平衡和协调，让每个人都能在自己擅长的领域发挥出最大的价值。最后，我们共同完成的一个功能完备、界面美观的游戏，我的内心有巨大的成就感，这也是团队项目带给我的最大收获。

最后，感谢发际线和我作队全体成员的辛苦付出!