坚定的探索者

——AaronHuang，2022春·软件工程课程

一、一点回顾

在2022年春接触到这门课程时对软件工程充满了期待：

再次引用课程伊始的祝福迷路在现代软件工程中的羔羊——略读邹欣老师《构建之法》及讲义有感

很荣幸能够有机会在北航本科最后的时光中和罗杰老师、任健老师以及助教学长们结缘，感谢老师们正式带领我们这些迷路的羔羊看见“软件工程”这座宏伟的大厦。

我想每一位罗老师和任老师课程中的学生在一学期的收货之后都不再是那个迷失在路途中的羔羊了，看着OS助教团队的平台，张弛和濡冰团队的“灵境”，还有“求职岛”和TLE团队的事件管理app，当然还有我们团队的“时间轴”，充满了感慨。

二、问题解答

以下是我通过一学期的课程对原来部分问题的理解

问题一：关于“足够好”的软件，定义是否缺少维度？

参见《构建之法——现代软件工程》第1章第2节

在这里对于“足够好”的定义主要为Bug尽可能的少。邹老师对bug的定义很宽泛，并不是我们狭义上理解的“虫子”，是从用户使用、开发者角度来体现bug的内涵，这点很有趣。但是似乎只在研发阶段的投入成本、使用阶段的用户体验和使用流畅性进行判断。我认为这样来定义“足够好”只具备二重维度，那就是“之前”和“现在”，关于一个好的软件工程应该更需要第三维度——“未来”？这里的“未来”也是基于用户，但不是“现在的”或者“即将的”用户，而是未来长期间隔后的用户。那么“未来”的定义会偏向于：产品基于社会经济发展以及技术趋势而产生的潜在可能，换而言之就是潜在趋势（价值）。人类往往喜欢站在历史的角度看问题，产品的评价更大程度上取决于未来的人。当然我们没有“穿越机”去看看产品是否符合未来10~20年的发展趋势，但是预测和前瞻性就显得极为重要了。比如最初的QQ，用户的评分低到了极点，没有人认为其比得过当时的飞信，但是站在历史来看似乎并非如此。还有经济发展的的趋势，电商平台2000年出现的时候还不起眼，而到10年左右开始蓬勃生长，这应该归功于商品经济的转型；比如新型科技方向的影响，在人工智能刚出现时，引用新技术的产品可能会吃到后来的红利：还有可能收到人类可能的未来精神诉求、意识形态变化的影响，比如当前爆火的提的元宇宙概念，如果不发展成割韭菜的资本骗局，那么在这方向的产品或许会在未来某个时间节点大放异彩。正如本次软件工程项目组中的头发茂盛团队所构建的“灵境”平台，也在探索未来人们的社交方式，或许在现在并不是主流，可是在未来会吸引到更多的用户，这种独特的方式可能会在未来更加吸引大学生，在时间维度上或许这种产品算作足够好。

问题二：为什么软件工程师个人能力的衡量中重复性工作更重要？

参见《构建之法——现代软件工程》第3章第1节

软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复性的任务，软件工程的奠基人之一瓦茨·汉弗雷总结说，软件领域可以分为两个方面：一方面是记忆创新的大爆发；而另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%-95%的比例。

虽然软件工程师对于“灵光乍现”的好点子需求并不高，但是我认为这是弥足珍贵的。软件工程师并不是机器，如果企业和团队把每一位软件工程师当作仅仅可以高效、高质量完成任务的机器人来使用，似乎缺少了一点人性化，谁做的快、谁把PM的新需求完成的好谁就优秀（个人觉得有点压榨，且失去乐趣）。当然高质量和高效率的工作是一个优秀软件工程师的基础，我认为更重要的是基于“基本功”的创造能力，我心中的优秀软件工程师是满足质量和效率之后，具有跳脱框架束缚能力，能够创造更加深远价值的技术人员（这里的价值包括个人价值、团队价值、企业价值、社会价值等），毕竟很少有影响深远的项目不是创建之初就让人耳目一新的。或许在一个一收益为驱动的成熟企业和大团队当中，管理和需求分析已经结构化，软件工程师需要的就是完成重复性工作，来执行命令，在世在小团队的开发中，尤其是我们本学期的软工项目中，我们深刻的感受到idea和breakthrough的重要性，创意和好的点子能推动产品的进化和发展，当然重复行恶代码工作也是必备的，但是显然好的点子在我们五六个人的小团队中显得格外重要，毕竟开发是由需求推动的。

问题四：如何获取需求分析数据

参见《构建之法——现代软件工程》第8章第1、2、3节

在未来不久即将开启的团队合作中我们要进行的第一步就是调研题目并分析需求，然后再设计功能，我们既充满期待由有一些担忧，如果没有开好头或许进展的内容会更加艰难。

在书中老师为我们提供了许多经过广泛验证使用的需求分析方法：

焦点小组
深入面谈
卡片分类
用户调查问卷
用户日志研究
人类学调查
眼动跟踪研究
快速原型调研
A/B测试

问题五：PM的管理范围中是否有团队任务分配

参见《构建之法——现代软件工程》第9章第1、2、3、4节

我经常在Bilibili上看到一些关于PM的搞笑视频，网络中总喜欢把PM喜剧化成一个充满压迫的反派角色，说起来也挺有趣。《构建之法》中专门用了一个章节来介绍这一角色，而没有介绍常见的研发、测试等人员也充分说明了PM在团队中的重要性，在我的理解中PM应该成为团队执行力的核心。同时也是最累的，因为在我们这种校园团队当中PM往往还需要担任开发的角色，就是说PM不仅需要硬核的专业能力，也需要强大的领导力，还需要有规划和敏锐的市场能力。文中讲了很多如何做好一个PM，但是有一点似乎并没有提及，那就是团队的任务分配由谁来做？是PM吗？如果是的话，PM又怎么能做到在任务量和奖励机制的平衡上做到让大家心服口服，而且能充分发挥每个人的优势呢？

这个问题其实要依据团队实际情况来决定，在小的敏捷团队中人物的分配往往是根据团队组建初期的责任承担来决定的，包括前端、后端和测试，对于每一个迭代的需求和任务我们都会通过scrum meeting来进行讨论，依据每个人的任务量和相关程度进行分配，当然PM是分配人物的主要策划人。其中最难的就是任务的量化和奖励机制了，在企业中往往个人利益和团队利益相关性较强，体现在产品收益和业绩回报方面，二课程团队中这种收益显得不是那么明显，所以奖励机制的效果稍有欠缺，而且任务量化当中较难达成一致，因为小团队中每一位成员都有一定的话语权，哪怕是提前敲定的考量方案也会根据实际情况和变动二改变，也有一部分任务难度和时长的对应关系的复杂性。

问题六：尚未解决的问题

在PM的的工作和职责方面其实并没有很深刻的理解到，企业环境的利益驱动和绩效奖励和课程环境中的利益驱动差距较大，在《构建之法》和实际工作中部分PM的工作方式并不完全适用于课程团队当中的PM。企业中侧重领导，在项目的各方面领导团队推进；而课程的团队侧重的是沟通，因为在利益驱动当中PM和团队成员完全一致，在团队中有规划的通过scrum进行协商，调动团队成员的积极性，合理的分配任务和计划并设计新的需求。在课程团队中有核心的PM实际上每一位成员夜是小小的PM，这种求同存异的合作方式能够很好的推进课程项目。企业中的方式或许更加的具有计划性，流程更加清晰，职责分配更加明确。

三、知识点学习

需求：软件产品需求分析的内容

需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。

具体分为功能性需求、非功能性需求与设计约束三个方面：

功能性需求

功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。

功能性需求是软件需求的主体，开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。

非功能性需求

作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。

主要包括软件使用时对性能方面的要求、运行环境要求，软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。

设计约束

一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。

例如：要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。

设计：设计流程

确定产品的整体架构：

我们在做需求分析的时候，都会把几个主要的功能点抓出来，这几个功能点就可以浓缩一下形成产品的初步功能结构
确定产品的布局排版：

布局其实一般都比较固定，以下三个部分组成：
- 导航区域（Logo、导航菜单）；
- 功能区域（账户信息、系统消息、退出登录）；
- 内容区域（数据列表、录入表单）；
确定产品的功能模块：

具体采用什么样的交互效果来实现功能块要求展示的内容，取决于产品设计人员的把握、用户的需求及用户体验

实现：用一张图来总结

测试：方法

–兼容性测试–测试人员

兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。

–用户界面测试-UI测试 --测试人员

用户界面测试，英文是User interface testing。又称UI测试。

用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

–随机测试–测试人员

随机测试，英文是Adhoctesting。

随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressivetesting)一起进行。

–黑盒测试（功能测试）–测试人员

黑盒测试，英文是BlackBoxTesting。又称功能测试或者数据驱动测试。

黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。

–性能测试

性能测试，英文是PerformanceTesting。

性能测试是在交替进行负荷和强迫测试时常用的术语。理想的"性能测试"(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。

发布：发布要求满足以下几点

Specific【明确的（不是空泛的）】
Measurable【可度量的（不是定性的或主观的）】
Attainable【可实现的（不是一对不可能实现的目标）】
Relevant【相关的（与客户要求和业务目标相关联）】
Trackable【可跟踪的（在整个项目过程中可以进行监控）】

维护：维护工作类别

（1）改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。

（2）适应性维护：在使用过程中，外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。

（3）完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为满求了足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。

（4）预防性维护：采用先进的软件采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

总结和心得

什么是好的软件产品？我想我们都有了自己的答案，或许软件工程课程希望我们找到一个统一的答案，我想这个答案很难统一，它或许是当下的或许是未来的，或许因为符合用户的需求，或许因为给用户带来了需求，它随着时间变化，随着企业的立足点变化，也随着社会时代而变化。我想只要它能体现出自己的价值，那么就是好的软件产品。抛开企业需要的收益不谈，只要能输出情绪价值就算是好的软件产品，正如我们所说的字画，软件产品也可以算作一件艺术品，因为表达着创作者的情绪和艺术理解，用户也会对它产生自己的价值理解。似乎我们需要的是能盈利的软件产品，能给团队带来收益的，能给公司提供价值的，这也是我们一直迷失在其中的原因。我们要满足用户的社会活动需求以及精神活动需求，或许在未来我们可以构思出更好的软件产品，来带领人类社会的社会活动，指引大众的精神需求，如果是有利于人类文明发展符合进化规律，我想这才是好的软件。我认为本学期课程中每一个团队或多或少都做到了我所认为的好的软件，因为每一个团队没有过多的被收益岁限制，保持了本心，坚持表达团队的情绪价值并且目的是去满足用户方方面面的社会活动和精神需求，或许立足点有大有小，或许完成度有高有低，但，都是好的软件产品。如何实现好的软件呢，我想并不算难，只要心中有了自己认为的那个“足够好”。

回首惊叹，原来这一段路途已经走到了终点。再次打开从前的博客，又回忆起当初的期待和欣喜。从打开《构建之法》这本书开始，我们也打开了罗老师和任老师所著的‘软件工程’这本书；当我们伴随着收获和成熟合上这本书时思绪万千，既感慨这一学期时光的飞逝，也感慨自己在青春时光中的成功和挫败。很开心遇到两位老师在每周的课堂中总能耐心的指导每个团队的项目管理，也很开心遇见命劫开发团队的每一位同学，也很感谢一同汇报的其他组同学。最让我印象深刻的就是beta汇报阶段和每一组的大佬们的交流，从安全问题到成本考量、从UI设计到法律界定，再到os和oo的版权之争，这一次的交流很有趣也收获不少，希望我们都能在自己喜欢的方向上绽放青春！

从阅读《构建之法》开始，我们就已经在系统架构的了解软件开发的内涵，并不是我们曾经理解的写代码+debug那么简单，这是一门复杂的学科，也是一种庞大的工程。软件开发涉及到管理学、计算机科学、经济学、心理学等诸多内容。我们也曾站在需求者的角度体验成型的软件开发产品，体验产品功能、调研产品市场再到测试产品BUG，这门课程从一开始似乎就留给我们两个问题：什么是好的软件产品+如何在事件中开发一个好的软件产品，这两个问题也组成了一个产品产生的路途，我们这一学期都在思考并实践这两个问题。很荣幸能和濡冰组队开启快乐的结对编程，我们使用C#优化算法、编写覆盖测试并设计UI，这一段体验是很棒的，虽然是很小的产品但是我们却对它十分满意，也为我们后续的团队开发进行铺垫，在快乐的编程中一起学习成长。

团队项目有很多老搭档了，我在团队中担任了PM一职，很遗憾也很抱歉，因为我自己还投入在自己的科研和paper当中，并没有在后期尽到一位合格PM的责任，也感谢团队成员们的包容，大家都积极站出来出谋划策，在一个一个会议中讨论完善我们的项目，从需求分析到架构设计再到功能实现，我们的开发过程还算顺利，也接触用户积极听取反馈意见，接收其他小组大佬们的批评和建议，最终完善了我们的产品。每次我们遇到奇怪bug之后哭笑不得，难熬的夜晚欢欢喜喜的交流沟通，修改代码，或者一起在楼下超市度过一个又一个的下午，除了对软件工程的更加深入理解我更想感慨的是团队之间的协作和相互鼓励，也感谢每一位成员对团队的贡献，这短暂的经历我想也会很难忘。感谢其他4位6系的老伙伴，感谢啸天，感谢子萱（特别感谢子萱对以后本人打算深造phd的建议），也祝啸天工作顺利。

当我们结束汇报，敲下最后的文字时，夜也深了。教学楼的蚊子也在夏夜闷热的气氛中难掩寂寞，树叶随着暖风抖动，也抖落出一些不舍，是对这门课程的不舍，也或是对每个团队每段故事的不舍，也有可能是对本科生活的不舍，这样想来觉得自己还有很多事情没有做，很多事情没有实现。回首再顾，感觉自己对SE的付出还不够，略带遗憾。还记得诺兰导演在电影星际穿越中刻画的角色，坚定的探索在深空，’Rage rage against the dying of the light‘，希望我们都坚定探索在深空。