个人项目总结

Posted jennawu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了个人项目总结相关的知识,希望对你有一定的参考价值。

软工课程终于快要结束了,确实有许多这样那样的感慨。由于是个人总结,吐槽的成分会比较多,可能写的比较凌乱,见谅。


关于技术

虽然软工课程更多是关于管理与合作的课程,但作为从头开始学习android开发的人,和许多其他从头开始学习技术的人一样,技术才是最糟心的点。

这个学期以来,我做的工作主要是:负责本地数据库部分的一部分工作;本地数据库部分结束、开始部署服务器后,负责安卓端相关的工作,包括向服务器发送请求、存储用户信息、协议的安卓端实现等。其中,涉及到的技术包括:安卓开发所需要的java与android studio,数据库加密需要的sqlcipher,orm框架,http,谷歌的sync adapter框架,sha1 des等加密方法,等等等等(应该不止,一时想不起来了)。

这里面大部分,包括java,都是我第一次接触,少数是我有所耳闻但第一次尝试使用(至少第一次在java下使用)。在这种情况下,其实个人觉得有一点矛盾;如果学习到非常清晰才开始工作,势必会浪费很多时间;而如果随便看看就开始工作,往往会走很多弯路。在这中间必然有一个平衡点,但我还没有很好地找到。另外,对于初次接触的技术还有一个问题,就是很难估计消耗的时间。如果此时此刻让我估计一个我已经较为熟悉的技术,实现一个我很了解的功能,我能够较为准确地估计即将耗费的时间,然而对于陌生的技术却真的很难估计,也很容易遇上一些简单但是因为不了解所以就是调不出来的bug。

之前在某群水群的时候,某人说一般而言软件工程课程是在已经掌握相关技术的时候开始的,而我们完全没有技术,老师也没有给予足够多的技术帮助,也许这就是为什么大家软件工程都学习得这么痛苦吧。


关于开发过程

在开发过程中,我学到的最深刻的技能是查资料的技能。

以前的我有时候会吐槽很多人不会查资料,但其实自己查资料的技能也不是很充足。一个学期的开发下来,有了各种各样的查资料的经历:需要查官方文档的,需要google的,需要百度的……官方文档真的很好,但是有时过于简略(比如我这个学期一直挣扎着想看懂的google家android文档),有时又太长,而且很难对于一些问题进行针对性的解答;相比之下,很多常见问题都在stackoverflow上问了很多遍了,也有很多人会踩坑之后发博客,快而直接,可读性比官方文档强;但是对于一些比较冷门的问题或者api,搜索引擎就真的没什么用了,还是只能回头看文档。关于搜索引擎,google功能上确实比百度强太多,之所以有的问题需要百度而不是google,是因为有的问题是中国特有的,如GFW问题啊、utf编码问题啊,还有一些第三方包基本都是中国人在用,如阿里巴巴家的fastjson。另外,对于一个问题,要如何去整理关键词进行搜素,有时候要搜索error code,有时候要搜索错误发生的情境,如何遣词造句,这些都是大麻烦。

另外学到的一件事情,是debug的能力。安卓开发没有那么容易debug,一方面是IDE太重debug很麻烦,另一方面是有时候遇到多线程的问题无法debug。被《第一行代码》推荐也被我一直使用着的一个debug方式,是打印log。打印log不仅不会受限于线程问题,而且能够提供出现bug的时候的情境的信息,也方便复现。也许打印log的唯一缺点是安全性,发布release版本需要把log一个个关掉。

还有一个比较痛苦的事情,是写与服务器相关的代码的时候,每次都要等到服务器的代码部署完毕才能测试,其中发现问题也很难确认是哪个部分的问题,需要两人协调才能解决,这个过程真的极端痛苦。也许这是因为我们接口定义不恰当?总之下次引以为戒。


关于开发规范

在整个项目中,也许是因为我的完美主义,我认为规范性并不是很好。更多的是总结自己犯下的错误,从而以后引以为戒。

首先,我写的注释确实是不够的。这一点我后来也意识到了,有意识地再努力写注释,但之前写的那些没有注释的代码已经彻底变成了除了我谁都看不懂(大概我也看不懂)的代码了。

其次,虽然我确实使用了很多单元测试,但测试与测试之间的耦合有点严重。虽然不至于一个测试覆盖好几个类,但是有的测试同时测试了好几个接口和功能,有的功能被好几个测试都测试到了;因为一开始的时候想起来要测试什么就直接测试了,而没有经过很好的分解(也许也和我们接口分解得不够好有关),因此到最后变成了杂乱的一大堆。到后来我也有意地在解耦,但一开始的那些东西真的已经很难挽救了,很难全部重新构造一遍。另一个问题在于单元测试似乎覆盖不够;之前看书的时候看到了测试需要覆盖各个逻辑分支、各个调用情景,但写测试的时候发现这些真的太多了,如果每个都要覆盖的话测试数量会指数级增长(我现在的测试代码量可能已经占了我的总代码量三分之一了)。因此很多情况没有覆盖到,也因此出现了很多问题。对于更大的项目来说,测试的完全覆盖真的是可能的嘛?……我其实现在很疑惑。有一些自动生成单元测试的工具,也许我以后应该了解一下。

然后,开发的时候,解耦性、模块化等等确实做得不够。这个倒是反过来了,一开始的时候殚精竭虑想办法解耦、想办法优美地设计,到后来ddl快到了,反而觉得算了随便写吧,不优美就不优美、硬编码就硬编码吧,先能工作就行。……虽然每次这样想都是挖了个坑自己后来填,但压力之下确实很难顾全。现在想来,为了解决这个问题也只能一开始规划好,按时执行计划,不要让自己陷入一堆工作在手却时间不够的境地。

最后github真的好用!


关于开发流程规范化

就个人的感觉而言,开发流程规范化确确实实是有用的。尤其是每周例会,对个人的监督作用很大。

然而,燃尽图、任务墙、绩效考核这三个东西,在实际情况下,它们发挥的作用没有那么大。首先是说过了很难估计进度,其次是绩效考核很容易碍于面子。不过这些上次的博客都说过了,也没什么好说的了。

(哇,这条好简单……我都有点愧疚……)


关于团队合作

在一开始的时候,因为大家分工不是特别清晰,我们数据库部分三个人负责同一个工作,所以个人觉得比较混乱。到后来,我们三个人分工变得非常明确:一个负责tomcat代码编写部署,一个负责安卓,一个负责服务器数据库。这段时间编码是非常舒服的,和别人只有接口上的关系而没有工作的重合。以后有类似的工作的时候,也需要明确的分工才能发挥最大的作用。

另外,作为组长,我们之后一段时间有一点懈怠,个人觉得需要负起责任。在大家都比较忙的时候,更应该由我来组织安排,这才是组长的重要性,但是我做的不够好。






以上是关于个人项目总结的主要内容,如果未能解决你的问题,请参考以下文章

个人项目总结

搜查令——项目个人总结+个人自评

MucMuc项目 个人总结

个人项目总结

个人项目总结

软工2019_MucMuc项目个人总结