标签：考核 使用 代码 oid 简单 看到了 课程 服务器 重要性
软工课程终于快要结束了，确实有许多这样那样的感慨。由于是个人总结，吐槽的成分会比较多，可能写的比较凌乱，见谅。
虽然软工课程更多是关于管理与合作的课程，但作为从头开始学习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代码编写部署，一个负责安卓，一个负责服务器数据库。这段时间编码是非常舒服的，和别人只有接口上的关系而没有工作的重合。以后有类似的工作的时候，也需要明确的分工才能发挥最大的作用。
另外，作为组长，我们之后一段时间有一点懈怠，个人觉得需要负起责任。在大家都比较忙的时候，更应该由我来组织安排，这才是组长的重要性，但是我做的不够好。
标签：考核 使用 代码 oid 简单 看到了 课程 服务器 重要性
原文地址：https://www.cnblogs.com/jennawu/p/9411158.html
