提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	提问回顾与个人总结
第一次作业链接	第一次个人博客作业

对第一次作业中提出的问题的回答

1.为什么可以得出"显然，从学生到职业程序员，并不是更加没完没了地写程序—花在写代码上的时间反而少了许多"的结论

​ 对于一个软件工程师来说,不管是代码能力还测试能力都比学生高出不少,尤其是一个软件工程师所积累的编程的经验往往是一个普通学生所不能比拟的。多以同样的面对一个项目,软件工程师可能很快就想到了实现的方案,这是最基本的要求。在基本的要求没有压力的情况下,软件工程师会更多的去考虑代码之外的问题,包括如何更加复合需求,如何进行完整的测试以保持软件的稳定性,或者是如何尽可能的体高性能和鲁棒性等等。那么,对于一个学生来说呢,由于代码能力和编程经验的不足,首先摆在其面前的一座大山就是如何实现基本功能,他往往是无力,或者说是有心无力去考虑更多的测试等问题的,因为要保证基本功能的完好,他是没有余力分配给测试太多的时间和精力的,否则一昧的考虑测试,反而会导致不良的后果。

2.是否只要有助于程序逻辑的清晰体现，什么方法都可以使用?

​ 我觉得,这里指的是我们要学会变通,并不是真的为了程序逻辑的清晰表现就可以不择手段了,它的意思应该是讲,在一些时候,我们用一些"不一般"的方法可能会有利于程序逻辑的体现,这里的不一般可能仅仅指的是不太常用,我们不能总是在所有地方都只用一套方法,而是什么有助于程序的逻辑表现,我们用什么,但是要杜绝使用一些极其危险的方法,这些方法可能会导致程序崩溃等一系列问题。

3.关于敏捷开发原则,面对面的交流始终是最有效的沟通方式吗?

​ 我之前以为,面对面交流可能反而有可能会阻碍彼此之间交流,但是经过一学期的软件工程实践之后,我才切身体会到面对面交流的好处。在这个学期中,我们几乎两三天,任务紧的时候甚至每天都开,在会议中可以随时交流,并且相对于打字要来的更加便捷,表达也更为清晰,也可以随时指导另一位成员写代码,可以几个人一起讨论,可以进行头脑风暴......等等。所以,目前看来,根据实践是检验真理的唯一标准的原则,关于敏捷开发,面对面交流的确是最有效的沟通方式。

4.是否所有的项目都必须基于其商业价值?

​ 大多数的项目是都必须要基于其商业价值的,因为如果没有了商业价值,就没有资本流入,没有资本流入,就缺少管理人员,开发人员等项目开发不可缺少的角色。同时,失去了商业价值,项目就缺少了外在的开发动力和目标,缺少了前进方向和迭代更新的动力,早晚会走向毁灭。但是,同时有一些项目的确是不以商业为出发点的,例如大名鼎鼎的linux系统最初就不是企业开发的商业级软件,同时我们这个学期开发的项目也都大多不是商业性质的,同时还有一些公益性的软件等等。所以,综合来讲,大部分项目是基于商业价值的,但是项目不是绝对必须基于商业价值的。

5.C在RASCI模型中具体承担的工作

​ C就是指的顾问,也就是负责为各个相关的角色提供咨询服务。在软件开发的过程中顾问是非常重要的角色,不管是面对技术问题,团队会议还是项目的重大决策都需要顾问参与其中,在项目过程和决策环节提供意见,在项目开展前提出建议等。

产生的新的疑问

1.在本学期理论课上虽然学习了相当多的敏捷开发知识,但是不知道如何应用,如果直接用又太过生硬,只是为了用而用,偏离了敏捷本身的意义.

2.在个人项目和结队项目中,题目的难度是否过大,而且更像是一个算法问题,这样会不会偏离了初衷使得学生疲于改进算法,实现更能而不去关心如何在事件中应用敏捷开发的相关知识。

在项目的 需求/设计/实现/测试/发布/维护阶段中都学到了什么“知识点”

• 需求阶段

​ 在需求阶段学习并使用了NABCD需求分析法,通过实践切身体会到一个道理,那就是开发者所想的需求和用户的实际需求往往是有较大区别的。

• 设计阶段

  设计对一个项目的影响往往要比实际的开发要大得多。一个好的设计可以使得开发变得容易的同时用户体验也能提升,加快项目的开发进度。而一个坏的设计会使得开发过程步履维艰,不仅难以开发而且效果还要更差。

• 实现阶段

  首先,良好的分工可以使得项目的开发变得更加容易。在项目的开发过程中,我们将项目的功能分为五个大的模块,每个人各负责一个模块,每个模块之间的联系较少,这样每个开发者就可以不用太关心其他人实现的模块,可以专心于开发自己的模块,自己的开发进度也不太受其他人的制约。在这样的分工之下,我们整体的项目开发全程都变得十分的流畅,没有出现过因为团队配合导致的问题。

• 测试阶段

  在开发的过程中,每个开发人员都需要自己进行单元测试,这样不仅能更早的发现问题,而且可以更为精准的定位问题发生的位置。同时,对于一个大的软件项目,仅靠人工测试显然是有点力不从心的,需要依靠一些成熟的软件测试的工具,同时要有好的用户反馈机制。

• 发布阶段

  在发布阶段首先切身体会到了一点,就是发布平台的重要性,基于种种限制我们的项目只能放在网盘中,通过链接的形式下载,推广也就只能在班级群内进行推广,这样就完全吸引不到广大社会中的用户, 导致我们的下载用户仅仅局限于很少的一部分人,下载量也是非常的少。

• 维护阶段

  在维护阶段,需要认真研究广大用户的反馈,并且针对用户的反馈对产品的bug进行修复,根据用户的反馈对功能进行适当的删减,同时要证据进行自己的测试,尽早发现错误,及时修复bug。

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

• 个人项目

  测试在开发的过程中的确是起到了至关重要的作用。在完成了基本的开发之后,经过自己一些测试,我觉得已经写的没什么问题了。但是,后来,我又对其进行了强度更大的测试,从中发现了许多的问题,而这些,很可能是我靠检查代码是永远也发现不了的问题,于是赶紧进行了修复,。开发时,往往伴随着高强度的脑力活动,在这紧张的节奏中,很容易会犯一些错误,对一些方面没有考虑完全,那么,这个时候,就需要测试来发现这些问题,而且是尽可能充分的测试。

• 结队项目

  在结队项目的开发过程中,我应用并切身体会到了结队编程的妙处所在。在较好的配合之下,两个人可以优势互补,互相提出建议,互相发现问题,互相给予帮助,互相进行监督,互相进行督促,达到一加一大于二的效果。同时,也锻炼了阅读和理解另一位开发者代码的能力,我觉得这是一项不亚于开发本身的极其重要的能力。

• 团队项目

  在团队项目的开发中,我首先体会到沟通对一个团队开发的重要性。我们团队在两个阶段的开发过程中均保持了频繁的沟通交流,应用了"面对面交流始终是最有效的沟通方式"的敏捷开发原则,使用了线上会议的方式对项目的开发测试等进行了小组讨论,并且进行了会议的个人汇报,会议总结等。

  另外一点就是认识到了PM对于团队的重要性,PM将整个团队联系在了一起,解决了在开发过程中遇到的许多的大大小小的麻烦,大大加快了开发进度。

  此外,我还切身体会到了一点,就是千万部要低估ui设计工作,在ui设计方面,我们一开始以为只是小问题,但是到真正上手的时候,才发现里面藏着不小的学问,很多时候实际开发的效果和心中所想完全不一样。