[BUAA 软工]提问回顾与个人总结

项目 内容
这个作业属于哪个课程 北航软工
这个作业的要求在哪里 提问回顾与个人总结
我在这个课程的目标是 学习如何以团队的形式开发软件,提升个人软件开发能力
这个作业在哪个具体方面帮助我实现目标 督促我阅读《构建之法》,了解软件开发的具体含义及流程
提问博客地址 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很愿意与大家沟通,在组会的时候我们每个人能很好地交流工作时遇到的困难、自己独特的解决方案、吐槽队友

你可能感兴趣的:([BUAA 软工]提问回顾与个人总结)