| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春北航计算学院软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 合作开发出一个具有实用性的项目，并锻炼自己的工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾课程内容，总结具体收获与不足 |
| 提问博客 | 软工个人阅读作业 #2 |
一、阅读提问回答
问题1：代码规范和代码复审
于是我们最后做了这个选择，每个“{”和“}”都独占一行。就是格式D：
if ( condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}······
回答
根据我从网上阅读的材料，不同的语言种类有不同的风格，同时该风格会随着时间、地点的改变而改变。举例来说，C/C++的左花括号另起一行较多，而Java则在同一行末尾较多，这点从C/C++的标准库头文件，以及JDK源码就能看出。
参考链接：
(1)https://blog.csdn.net/iteye_18916/article/details/82515601
(2)https://blog.csdn.net/weixin_34354173/article/details/86346443
问题2：代码规范和代码复审
（3）运算符的实现必须非常有效率，如果有复杂的操作，应定义一个单独的函数。
（4）当你拿不定主意的时候，用成员函数，不要用运算符。
这是教材中对于C++操作符使用规范的说明。到目前为止，我使用重载操作符的操作次数并不多（主要都是上学期的编译实验课使用的）。我想知道对于相同的操作，C++中使用定义操作符以及定义函数在效率上是否有区别（尤其是在使用频繁的情况下）。依我本人的理解，定义函数有压栈、传参等操作，这些操作都需要时间，因此使用操作符会不会节省这些操作的时间？如果能的话，这两条规范是否过于绝对？
回答
该问题助教为我提供了一个能够较好解决该问题的阅读材料，我在阅读该材料后也有了较为明确的答案。对于C++来说，运算符本质上也是函数。只是运算符是编译器需要进行进一步解释。而函数是直接调用。我曾经在编译课上也写过类C文法的编译器，结合编译器的工作原理可以得知，二者实际上都是对过程调用的体现（运算符指重载运算符，基础运算符并无调用过程），二者的差别仅体现在编译阶段，运行时无本质差别。对于该规则的目的，依我的理解，函数更方便于复用和调试。
参考链接：
https://blog.csdn.net/farmwang/article/details/77989350
问题3：团队成员不同的投入和心态
在官僚层次驱动的项目中, 往往有一些鹦鹉会控制流程的关卡, 鹦鹉虽然对项目具体情况不了解, 也很忙, 但是项目的一些决定非得由她们来做, 她们做完决定之后, 拍拍翅膀飞走了... 这的确是比较让人郁闷的事。
我从身边从事计算机相关工作了解得知，这种毫不知情的”项目经理“正在减少（即项目经理的门槛正在变高），那么即使作为一直”鹦鹉“，不参与项目创作的过程，是否也需要对项目有一定了解？我认为在对项目不甚了解的情况下很难做出正确的关键决策。（而且原文中这个”她“字是否用得不妥，容易引起某些对于性别问题比较敏感的人群的误会）
回答
经过多方面的了解，这种情况的确时有发生，并且不仅限于IT行业。在一个公司，“设计师”职位的存在往往是必要的，我们不能要求团队中的每个人员都了解项目的具体过程，因此及时的沟通显得尤为重要。当然，如果“鹦鹉”固执己见导致项目出现问题，那么她们必须要为此承担责任。
问题4：测试的计划和执行
效能测试：在100个用户的情况下，产品搜索必须在3秒钟内返回结果。
负载测试：在2 000个用户的情况下，产品搜索必须在5秒钟内返回结果。
压力测试：在高峰压力（4 000个用户）持续48小时的情况下，产品搜索的返回时间必须保持稳定。系统不至于崩溃。
从数学的角度，我的第一反应并不能理解这些数字（几组时间的数字和用户的数量显然不成正比）。我想了解这几个测试的具体偏重解决的问题是什么，当工程能满足后面的测试时，前面的测试是否有必要？
根据助教的解答以及我个人搜集的资料，我的理解：
效能测试通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标，或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失。 主要的测试对象是达到的最佳性能。
负载测试不限制软件的运行资源，测试软件的数据吞吐量上限，以发现设计上的错误或验证系统的负载能力。该测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。与负载测试相比，压力测试的负载来源于外部环境。
问题5：绩效管理
在理想条件下, 把任务做得很好, 当然贡献会在最上面的 20%; 做的最差的, 贡献应该是最低的 10%. 但是在实践中要复杂得多, 有些人因为任务相对简单, 完成的很好, 但是对整个集体的贡献一般, 这种人可以得到 [好, 70%] 的位置。 有些人敢于做很难的事情, 结果未必令人满意, 但是对团队很重要, [中, 20%] 应该是一个合适的评价。
······
回答
我认为我在软件开发项目团队的经历就很好地解决了这一问题。我们团队制定了科学的绩效管理制度，尤其在β阶段。参见博客：beta阶段贡献计算
二、原有问题疑难及新问题
对于原有问题，我仍然存疑的主要是问题四，以上回答是我个人的总结，对于三种测试具体的联系与区别我认为仍需要研究。
经过了一学期的课程，结合自身的经历，我想提出以下两个新问题：
Q1：代码规范与代码复审：
另外，注释（包括所有源代码）应只用ASCII字符，不要用中文或其他特殊字符，它们会极大地影响程序的可移植性。
在软件开发项目中，我的职责是前端开发，用到的开发平台是微信开发者工具。该工具用于开发微信小程序，显然使用该工具的绝大多数程序员均为中国人。在这种情况下，中文注释就显得较为方便，从官方文档的一些注释中也可以发现大量中文。考虑到教材编写的时间，该条规则是否应该针对开发的地点及环境方面做出调整？
Q2：结对编程
不适合结对编程的情况——
并不是所有的项目都适合结对编程，下面是一些不适合使用的例子。
1）处于探索阶段的项目，需要深入地研究，在这种情况下，一个人长时间的独立钻研是有必要的。
······
在第二次结对项目中，我们当时在项目的架构设计方面做了不少探讨，最终的架构结合了两人的构思。同时，我们当时采用了逐步分析的方式，对每个部分提出自己的构思。我的想法是，由于思维定势，探索时每个人都会遵循一定的思路，短时间内难以改变。如果在结对时互相交流想法，大概率可以开拓思路，找到更好的解决方法。因此，在探索阶段是不是也应该共同钻研？
三、做中学
需求
《构建之法》中提到，需求分析的一些常见问题包括“这是刚性需求，或辅助性需求？需求的量有多大？ 需求会一直存在么？”，而最后一点正是最容易被忽视的，我所在的项目小组当时就没有充分考虑这点。我们当时分析的最典型用户需求为“基础物理实验”，然而当我们的β版本发布时，大部分学院的基础物理实验考试都已结束，我们团队成员与剩下的学院同学的交流又甚少，因此损失了很多用户。这告诉我们需求分析一定要注意时间线的影响，要做长远考虑。
设计
一个刚成立的团队，他们对自己的实际能力往往不太了解。 例如有学生说 - 我懂 Java，其实他只是上过一个讲Java 的课，开卷考试通过而已，和在实际中能用 Java 语言和相关的框架按时按量地完成任务还差得很远。
在初始阶段，我们对于软件功能的设计实际上我认为做得相当充分。但是，后续我们的实现离既定目标还有显著的差距。我认为，很大一部分原因是我们对于自身的实际能力不够了解。就拿我自己来说，之前我利用过腾讯云平台的一些API接口，于是我认为小程序的很多功能都可以简单地调用官方接口来实现，但实际上小程序实现起来和PC应用程序差别巨大。这也和我们调研时没有充分尝试样例有关。因此，我认为设计过程中不断地认清自身对于项目的实际能力尤为重要。
实现
实现阶段我最大的收获是相关技术栈的学习。结合网上的教程以及现有同学的代码，我能够达成速成的效果。我认为分析代码实例对于代码能力的提升是非常巨大的，很容易突破独自学习遇到的瓶颈。
在实现阶段我认为我们团队最需要改进的地方是源代码的管理。我曾经不只一次错误地合并冲突导致额外地花了一些不必要的时间来修复错误合并导致的问题。同时，我们团队对于分支管理并没有达成共识，既没有独立的分支，也没有采用统一的分支，在分支合并时也没有互相通知。因此，如果以后我继续参加项目开发，会尽可能做好代码及分支的管理。
测试
在《构建之法》中，特别提到了错误报告（Bug Report）的重要性，这是在我之前测试的过程中从未进行过的环节，而该环节最大的作用是对bug进行复现。在我们的开发过程中，我们遵循了该环节的步骤，减少了很多不必要的尝试复现bug的时间。同时，该环节还提醒我们，在测试过程中，应当对自己的每个操作步骤进行记录，便于对bug的出现进行分析和记录。
发布
发布过程中，我使用了“易企秀”宣传内容制作平台，学习了一些操作技巧，并制作了我自己比较满意的海报。同时，宣传最好主要面向需求的用户，这样能够达到短时间快速积累用户的效果。
维护
在项目α阶段开发结束和β阶段开始之间差不多有两周时间，在这段时间内我们的团队并没有对原有项目进行充分的维护。这导致部分用户对于我们的项目失去兴趣，因此维护也是用户量的一种保证。
四、项目经历心得
个人项目
本课程的个人项目主要是博客作业。第一次博客作业主题是刚进入课程时对于自我的思考，通过给出的几个方面来加深对于自我的认知，明确自身的定位。两次阅读作业，第一次是对教材《构建之法》的通读，第二次是对市面上用户较多的软件的调研。
三次博客作业中，我通过现有案例认识到软件项目开发不同于一般的科学研究，实际上并没有100%的对与错，也不可能做到完美，即使是现有比较成熟的项目，依然值得我们去探索并大胆质疑，我们在之后的项目开发中也不会一帆风顺，但我们应当遵循一定的规则，在现有条件下尽可能做到最好。
结对编程
我的结对编程队友是yyh，可以说是非常大佬的一个人物。无论是CI的配置还是单元测试的编写，他都让我非常迅速地完成了从无到有的蜕变，在他的帮助下，我在很短的时间内掌握了这些技能。
结对编程，给我的最大感受是两个人都能够发挥自己的长处。由于我本学期重修了一门与java有关的课程，我在相关API的调用方面更加熟悉，而其他方面都是我队友要更优秀一些。两个人共同交流思路，问题能够得到及时讨论，基本没有一个小时内不能解决的问题，体验非常好。对于代码中的细节，互相也能够清楚的了解，从而避免了个人的思维定势，减少了bug的产生。
除此之外，他的debug能力也帮助我们减少了很多的错误。Debug一直是我的弱项，通过学习他的找bug思路，我也收获了很多，同时在其他的项目中也得以应用。
团队项目
我所在的团队是万里阳光号。这个团队虽然只有5个人，但是目标统一，除了我之外都是大佬。经过2个阶段的努力，我们最终开发出了功能完备的手机绘图小程序Sunny图表。
在项目的开始，我遇到了很大的困难，因为不管是前端还是后端，用到的技术栈我都不会。但是团队并没有因此责怪我，更没有抛弃我，他们尽可能地让我在短时间内掌握了必要的技能，参与到项目的工作中。我在几周的短时间内入门Javascript、wxss、wxml并渐入佳境，同时，该技能也能和Web开发有着很大的联系，对我以后帮助极大。
在开发的过程中，大家的学业都较为繁重，但没有人因此放弃，都在尽可能抽出时间进行线下的讨论和开发。我在开发过程中写出了很多bug，团队给予充分的指导修复这些bug，最终我们共同完成了这一项目。可以说，课程的大部分收获都在这团队开发项目过程中。团队充分遵循《构建之法》上的原则，将书本上的内容应用于实际，也加深了我对书本内容的理解。
非常感谢万里阳光号的所有队友，5个人最终以高质量完成Sunny图表这个项目，取得了令人满意的成果。也感谢课程组在各个阶段的指导和付出，相信课程一定会越来越好！