提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个项目属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提升个人的软件工程能力和团队意识 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾课程刚开始的提问 |
| 过去博客的链接 | 软工个人阅读作业#2 |
一、尝试对自己曾经提出的问题进行解答
Q1：关于商用软件和爱好者写的程序的区别
作者在文中提出：
说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：
如果一架民用飞机上有一个功能，用户使用它的概率是百万分之 一，你还要做这个功能么？
你会选择： 1. 根本不考虑
如果没时间实现这个功能就算了
做了，但是不用告诉用户
做了，而且不厌其烦地告诉用户如何使用 你会如何选择呢？
选择之后，这个功能究竟是什么呢？谜底是飞机的安全功能
作者想要强调商用软件和爱好者写的程序中最主要的一个区别就是商用软件会考虑一切用户可能用到的功能并加以实现，然后教用户如何使用。
但是拿飞机上的安全功能来举例似乎有些不妥，首先飞机的安全功能之所以重要是因为它会涉及到乘客的生命安全，即使飞机出事的概率很小，但是出事后的风险很大，这样一来飞机上的安全功能就显得极为重要。
我感觉真正对于一个商业软件来讲，需要实现的部分应该是该部分内容在软件中的重要性，而作者在原文中写的这一段话却似乎在强调使用概率这一点，让我有点困惑。
在原本的问题中，我提出判断商业软件中功能是否需要实现的是其重要性，与使用的概率无关，在本次软件工程课程结束后我依然保持这一观点。功能的重要性应该是排在最为优先的，即时一个功能使用的概率不大，但只要它对于需要使用的用户有着不可替代性，其就应该优先实现。而有些功能，即便是用户使用的频率可能比前述功能要高，但是其顶多算是锦上添花，那么其实现应该是在核心的重要功能之后。软件的杀手功能也在此列。我们应该更先考虑用户基础功能体验的完整性，然后在此基础上再发展自己的杀手功能，让软件在不失完备性的情况下拥有自己的特色。
Q2 关于单元测试
作者在文中提出：
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
作者是最熟悉代码的人，但是这可能也会导致作者会无法对自己的代码做出全面的审查。一直以来有句话叫“当局者迷，旁观者清”，作者可能会因为正是自己写的代码，导致无法看清自己代码的全貌，从而无法对一些复杂的模块写出完整的单元测试。
作者后续又写道：
单元测试不能解决所有问题，不必期望它会发现所有的缺陷。
单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。
单元测试只是一个覆盖测试，让旁观者来从旁观者的思路把代码重新梳理一遍后写出的单元测试可能会有不一样的效果吧。
在结对编程的时候，我和结对伙伴之间尝试了为对方写单元测试。回顾对方给自己写的单元测试的时候发现，对方给我写的单元测试内容并没有能完全覆盖我代码中所有可能的情况，可以明显的感觉到对方的思路和自己有所不同。现在我感觉单元测试确实应该由代码的开发者来写，单元测试作为一个覆盖测试，更需要的是其覆盖率，而对于一些细枝末节的bug则由他人来用另一种思路来梳理一遍可能会更好。
Q3 关于goto语句
作者在文中提出：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
goto语句一直是有争议的话题，在过去编程学习的时候就被老师和助教一直提醒要少用goto。在网上查阅后得到：
主张从高级程序语言中去掉GOTO语句的人认为，GOTO语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：GOTO语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。
但是同时也说到：
尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套
和文中一致。
于是最后有人采用了折中的说话，提出不加限制的goto语句会导致程序难以预测，但是有些时候却能让程序更加简明清晰、提高程序效率。我的问题是：对于我们这些编程的新手来说，又该如何判断什么时候该用goto语句呢？这些表面上看起来让程序更加清晰的goto语句是否会在程序中埋下一些隐藏的危险呢？
关于这点，助教的回复是：“不要用goto语句”。我现在的感觉是，goto语句会破坏代码的连贯性，导致很多地方的bug出现的莫名其妙。同时，如果一部分代码一定需要goto语句才能理清楚代码结构，那可能是这段代码本身就存在一些逻辑上的不清晰。这在我的开发过程中也出现过，当我发现我的方法有很多相同的return时，实际上就是我的代码逻辑上出了问题，把很多简单的问题复杂化了。所以实际上，goto语句还是不要用为好。
Q4 关于结对编程
作者在文中提到：
在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
同时，作者也提出了结对编程的疑问和好处。关于疑问中的“ 我习惯一个人写程序，不喜欢被人盯着工作，这样我不自在，无法工作”这一点我深表赞同。同时，我感觉每次我高效编程的时候会进入某种状态，能让我全身心的集中在眼前的屏幕上，周围人的打扰反而会让我脱离这种状态。
当然我目前还没有经历过结对编程，只是对于是否所有人都适合进行结对编程，结对编程对于效率真的能比其他的合作方式来的高吗表示疑问。
经历过结对编程的我得出的结论是，结对编程确实能让你在设计、开发、debug等各个阶段都有另一种视角，从而发现很多的漏洞和改进之处，但是实际上可能我的效率反而没有单独编程时高了。我个人目前还是倾向于团队项目时的多人合作模式。
Q5 关于创新
作者在文中提到：
最近几年，我们整个社会似乎对创新很感兴趣，媒体上充斥了创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会，等等名词。有些城市还把“创新”当作城市的精神之一，还有城市 要批量生产上千名顶级创新人才。
就如文中所说的，创新是我们这个时代和社会所需要的，虽然人人都能进行创新，但是能创造出有价值的“新”的真的不多。文中也提到了一大堆对于创新反对意见，其中夹杂着很多乱七八糟的个人情绪、政治因素在里面。同时，受限于当今社会膨胀的信息量和个体有限的阅历，创新的难度似乎也因此越来越大了。我之前看到一句话，类似是说：“每当你想到一个非常棒的能改变世界的idea，那只能说明你看的paper还不够多”。虽然是一句带点玩笑意味的话，但也说明了目前创新的一些尴尬局面。
近年来，创新的实例很多，但是真正在我们生活中留下痕迹的idea，和庞大数量的创新者相比，真的很少。对于我们这些普通人而言，在创新的要求越来越高的当下又该怎么做呢，一昧地鼓吹创新真的好吗。
在完成了一个项目之后，我感受到创新这件事其实真的挺难的。我们在软件的设计阶段提出了很多的idea，但是真正能称得上是创新的屈指可数，最后被我们用到软件中的可能也就只有一个比赛功能了。而这个功能其实也是参照了别的软件中的比赛功能。纯粹的创新在我看来真的是难上加难，而正因为如此，好的创新idea才难能可贵。
二、是否产生了新的问题？如果有，请提出
Q1：关于敏捷开发迭代
我们的产品最终怎样才算是合格呢？是达到当初设计的目标吗？还是用户基本都得到了正面的反馈呢？实际上，因为敏捷开发的特性，我们的产品是能够一直迭代下去的，每次都能做得比之前更好一点点。那么最终迭代的尽头在哪里呢？
Q2：关于用户的反馈
我们的产品才迭代了两个阶段，我们就出现了有用户对我们产品提出了完全相反的修改意见。就是alpha阶段有用户以“需要连续翻页”为理由建议我们把跳题按钮固定在底部，但是beta阶段又有用户根据点击的频率建议我们把按钮放到选项的下方。两方各自有自己的道理，这种情况下我们要如何决定呢？如果对于一个功能，组员和用户调研的意见都是55开的情况下，我们该如何决定迭代呢？
三、在实践中学习知识点
需求阶段
- NABCD分析
- NABCD包括需求、做法、优势、竞争、推广五个方面，如果把这五个方面都想清楚了，后续的实现也不会走的太歪。
- 用户调研能够从外部视角出发，来更进一步的确定需求的重要次序
- 这点实际上是从我们的竞品组的实现效果中得到的，他们通过问卷来对用户的需求进行调研，从而在实现阶段能够分出轻重，这点十分重要。
设计阶段
- 技术规格说明书和功能规格说明书相当重要
- 有好的技术规格说明书和功能规格说明书能够让全组都有明确的共同目标，能保证大家对于功能的理解和实现都保持一致
- 根据需求分析来确定功能重要性
- 根据实际的用户需求来为功能的重要性排序，可以将一些不必要的功能延后，甚至在开发余力不足时将需求砍去。
- “杀手功能”的重要性
- 如果产品要从同类中脱颖而出，“杀手功能”是必要的，即我们的产品有什么其他产品无法媲美的优势。关于这点我们在alpha阶段考虑不足，再加上我们该阶段只注重了基础功能的实现，直接导致了杀手功能不明确和竞争力不够。
实现阶段
- 文档伴随左右
- 每次开会讨论有新的产出时，应该即时更新文档。
- 文档应当要按照功能做分类，而不是大杂烩。
- 交流很重要
- 每个人在开发冲刺阶段应该要保持交流的通畅性，如果某人一天时间都联系不上的话可能会导致进度失去控制。同时要保证两天一次的会议对于进度的把控，即时有事无法参加会议的人也应该由相应的负责人去检查其进度。
- 分工要详细，验收要详尽
- 对于每一项任务需要做什么，什么时候验收都应该严格制定和执行。否则到最后就会导致拖沓。
- 注意单元测试和代码规范
- 开发过程中没有注意单元测试的话，会导致最后的测试阶段工作量较大。
- 通过codelint等工具可以方便地统一整个工程中的代码规范
测试阶段
- 每个人应该先对自己的页面负责
- 每个人在提交时应该先要保证自己的页面不会出现太过明显的问题，否则会增加测试人员的工作量
- 测试应该有详细的计划并且保证覆盖率
- 测试出的bug应当做相应的记录（如提出一个issue等）
发布阶段
- 提前为发布预留时间
- 由于微信小程序的审核原因，我们的发布拖到了计划当天的晚上，比预想的慢了将近一天。
- 宣传十分重要
- 我们在beta阶段进行了多次宣传，同时将软件转移到小程序平台，直接导致了我们beta阶段的用户大量增长。
维护阶段
- 收集用户的反馈很重要
- 通过直接和用户交流、分发调研问卷、在软件内设计反馈渠道等方式收集用户反馈，并及时对严重的bug做出修复，对于一些改进意见和小bug则纳入下一个迭代阶段。
四、自己的理解或心得
个人项目
本次课程的个人项目主要是几次的阅读作业和博客书写。前两次的博客作业主要是审视自身的各种优劣，同时对软件工程进行最开始的导入。通过前两次博客，我重新审视了过去的自己，同时也对软件工程有了初步的认识。在阅读了《构建之法》后，提出了自己的问题，并且带着问题投入到了后续结对编程和团队项目中。
之后，个人项目还有一个案例分析的作业。在本次作业通过对一个成熟软件的使用、分析和测评，首先对于何为软件、软件需要实现哪些功能和如何让软件能脱颖而出有了一个初步的认识。从一个用户的角度出发，和后续我们从一个开发者的角度出发是完全不同的。用户能够通过外部视角来更加清晰全面的审视一个软件，避免内部视角的狭隘性。在这次分析作业中得到的体会，也能运用到后续的团队项目中去。
结对编程
对于结对编程的总体评价在上面已经给出了，我和队友在设计阶段互相提出了改进的意见，以及在后续的开发和测试阶段通过不同的视角发现了很多的问题。但是对于我个人的感觉而言，开发阶段的效率确实没有自己一个人开发时高。不过我认为经过后续的锻炼，如果我能提高开发时的效率，结对编程确实能够弥补很多我个人编程时的缺点。
同时，在结对编程的过程中，我从队友的身上学到了很多东西。比如在设计阶段时比较各种容器之间的优劣，以及采用特定的模式进行开发等。此外，结对编程也迫使我养成一些多人合作写代码的习惯，比如命名的规范性、代码注释的书写等，同时也提高了我阅读他人代码的能力。归根到底，在结对编程的时候，我们不应该只注意自己代码写的爽，也要停下来想想别人看到自己的代码是否能理解思路，自己如何去理解别人的代码思路。
团队项目
在团队项目中，由于只有我先前有过一点前端开发的相关经验，我便自然而然地成为了项目的前端负责人。在整个项目的开发过程中，我要完成自己的任务，同时在开发的同时要学习新的技术，并且引导其他前端的成员来学习前端的内容并分配任务。这也是我第一次担任管理他人的职务。在整个团队项目的过程中，我认识了前端的uni-app框架，学到了一些安卓小程序开发和微信小程序开发的知识，同时从零开始用uni-app完成了对一个项目的构建，学习并实践了如何综合各种考虑因素进行任务的划分，并将任务分配给他人。
综合整个团队项目来看，我感受最深的还是对于项目管理和进度的把控，以及成员之间沟通的重要性。站在管理者的角度来将，对于每一项任务的说明都要尽可能的详细，同时要保证每一名成员能够正确理解功能的设计。同时，敏捷开发的特性决定了会有很多时候对需求做出调整和修改，这就更需要考验管理人员的应变能力，也需要保证各成员之间的交流通畅。经过这一次站在管理者立场上的开发之后，我更能清楚的明白，开发人员应该做到哪些事情才能够让管理人员的负担减轻，让全组的进度能够在可控的范围内。其中最重要的一点就是对自己的工作完全负责，同时也需要保持良好的沟通与反馈。
关于我们的项目，最终能够收获还算不错的用户量，远超了我们的原先的预期。我们能够在全组只有我有微不足道的前端经验，大部分人没有springBoot经验，以及大家都没有设计方面的才能的情况下完成小程序，离不开每个人的付出和能力。在这里感谢全组的每一位同学。
