[BUAA 软工]提问回顾与个人总结2.请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。3.结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

项目	内容
这个作业属于哪个课程	北航软工
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	学习如何以团队的形式开发软件，提升个人软件开发能力
这个作业在哪个具体方面帮助我实现目标	督促我阅读《构建之法》，了解软件开发的具体含义及流程
提问博客地址	https://www.cnblogs.com/KevinJiao/p/10477153.html

1.请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。是否原来的问题还不明白？如果有，请分析。是否产生了新的问题？如果有，请提出

如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？

这个问题在我们的开发过程中就真实的发生了。在alpha阶段的末尾，我们通过django后端，发现我们的数据库被恶意注入了数万个用户，原因是我们的后端接口被暴露了出去，被大量调用。本来，针对接口的安全性防范我们是准备放在beta阶段实现的，但是，出现了这样的情况（对应百万分之一事件的发生概率），我们组的后端同学只能加紧完善接口安全性，并且将数据库恢复至以前的状态。

通过这件事，我了解到，即便在软件工程中极低概率出现的问题，只要它会给整个软件带来危害，就要防范。

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。

针对结对编程的问题，我在后续的团队软件开发中，也使用了我从其中了解到的一些经验。在后端、前端开发的时候，我们组进行了code review的要求。在一位开发同学完成代码开发，进行项目commit之后，我们组会要求另一位开发人员，对已经commit的代码进行复查，帮助同伴检查，以排除一些常见的bug。之后，才会merge到测试分支上，由测试同学进行完整而详细的单元测试。

在这个过程之中，我们利用到了我们在结对编程之所学，同伴的code review可以提升代码质量。

杀手功能/外围功能

针对这个问题，我有了新的思考。过去，我认为产品的功能分类取决于用户的喜好，现在，我认为，产品对于功能的划分，决定了自己的用户群体的划分。例如，OPPO/VIVO，将旗下的手机产品的拍照功能划分为杀手功能，给这项功能的开发分类了许多资源。相应的，它的产品就吸引了大部分的年轻女性。这也就印证了，功能对于用户的吸引。

迷思之三：好的想法会赢

但这里美国仍使用英制衡量制度的例子，我觉得的有些不恰当。并不是只有美国曾经使用过英制衡量制度，最起码英国使用过的。但是现在却只有美国仍在使用。说明别的国家经过讨论，决定更改。而美国不仅自己的国会经过了讨论，并且也知道别的国家的更改制度理由。可以理解为美国接收到了“创新的宣传”，但仍未做出更改。所以，我认为，这里的例子并不能很好地说明观点。

我的问题没有得到解答，我没有形成新的见解。在我的看法中，宣传与好的想法是一对无关的变量，尽管从统计上看，两者可能是伴随出现的，但是，在我的观点中，二者并不存在充分必要条件的关系。就像晚上刷牙与心脏病得病概率一样。

迷思之五：要成为领域的专家、才能创新

这句标题与文中的例子未免都有以偏概全的嫌疑。对于无数的创新过程，书中仅仅以几例就驳倒创新与领域专家之间的关系。而标题更是忽视了可能存在的反例。对于这部分信息，我更想知道的是对于不同的领域，专家和创新之间的关系，是计算机领域的独特性质（早期待发展的部分很多）导致了这种现象么？还是这是一个普适的结论？

这个问题，我有了新的想法，对于创新领域来说，了解的人并不多，在现在看来很多初级的想法，在当时，已经是“专家”级别了。只不过，随着该领域的发展，“专家”的水平得到了上升。这也就解释了，为什么很多在现在看起来，“似乎没什么”的想法，在当时能开创一个时代。

2.请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。

需求

NABCD为，N（Need，需求），A（Approach，做法），B（Benefit，好处），C（Competitors，竞争），D（Delivery，推广）。我在项目的进行之中了解到一个好的创意的产生其实是有方法的，而在软件开发之中，这个方法可以是NABCD。它教会我们从五个方面，系统地分析一个项目的特点，从而更好地抽象需求。

设计

在设计的过程中，我所在的后端开发团队采取了“设计规范”---“接口文档”---”代码“的实现流程。在所有开发进行之前，我们会指定一些简单的设计规范，例如变量、函数名称的大小写，返回值的返回方式（List或者是Dict），一些接口的POST/GET方法。在开发的过程之中，我们在具体实现一个接口之前，也会现在GitHub的Wiki中写好待实现的接口的文档，预先定义好传入传出值，之后，我们才会具体去进行实现。这样的设计方式，虽然在前期的准备工作中花费了不少时间，但是保障了我们工作的高效性，大大提升了我们的效率。

实现

在代码实现的过程之中，我们采取了主流的基于GitHub的多分支开发方式。前端、后端、测试，有着不同的分支（基于前一个发布版本的base分支），在开发的过程之中，属于不同团队的代码不会混在一个开发分支之中，这样的话，方便开发人员查看属于自己团队的开发记录。

测试

我隶属于后端开发团队，所以测试这边负责的工作并不多。但是，我学习到了如何与测试的同学沟通的方式，这也是我之前不了解的内容。我们组的方式是，由测试同学在issue上提出他找到的可能的bug，并提及所有后端的开发人员，在由后端开发组经核实之后，交由负责的同学进行修改，并在commit的时候提及相关issue，汇报给测试同学。经由完整测试后，如果通过，则close掉相关issue，否则重新修改。

发布

发布的时候，我们组根据自身项目的特点，梳理出我们的公客网与“友商”的（指班级中另一个开发公客网的小组的产品）产品的不同之处，着重宣传我们的杀手功能以及差异性的地方。

维护

后端团队的维护主要集中于压力测试的结果。在全部开发完成之后，后端会进行压力测试，根据测试的结果，我们会调整实现的方式，提高并发，保障用户的访问。

3.结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

我在我们团队度过了一段令人回味的时光。在选择任务的时候，我选择了加入后端开发团队，虽然之前对于后端的开发并不熟悉，但是结合前人的代码，同时向团队中的同学学习，我很快就能熟练完成开发任务了。在团队组会的时候，得益于我们组的PM很愿意与大家沟通，在组会的时候我们每个人能很好地交流工作时遇到的困难、自己独特的解决方案、吐槽队友。