持续集成实验总结

作者：程嘉梁

持续集成实验是在大帝的框架上完成一个微信抢票公众平台的项目。在这一次实验中我主要负责管理员后端API的编写与将代码部署到服务器，同时也顺手修复了几个前端的bug。收获有很多吧，但是槽点也有很多，我就在这里记录一下我在做大作业过程中的一些感想吧。

收获

1、对于Django框架的回顾与熟悉

虽说在前端小学期的时候有用过Django框架，但是当时只是做了一个很简单的新闻浏览网站，所以对于Django框架也只是学了一些基础的内容。这次实验一方面让我回忆起Django框架的基础组成与用法（短短两个月就已经忘得差不多了QAQ），另一方面也让我从大帝的架构中学习了很多Django框架的使用技巧（比如静态文件、Django自带的user模型等），这些对于我们后续架构学生节晚会小程序都有很大的帮助。

2、熟悉服务器的部署

对于服务器的部署，我在前端小学期也学过一些，印象中当时是很顺利的。但是这次我在部署服务器的时候却踩了无数的坑，后来心态都有点炸了（这也体现出早点总结技术博客的重要性）。不过踩了这么多坑以后，我对于服务器的部署流程更加熟悉了，也总结出了一份部署的技术博客方便日后回顾查看。

3、熟悉Github与Travis CI的使用

虽然我不负责测试的部分，但是由于在提交代码的时候总会看到Travis测试失败，所以不得不去研究一下Travis的工作原理，也就逐渐熟悉了这种持续集成开发的过程。我认为大家对于这些工具的使用也会在后续的工作中变得更加熟练。

反思与吐槽

1、任务安排失误

作为组长，我在这里要做一个检讨。一开始安排任务的时候，我以为在前人框架基础上进行开发的任务量不会很大，就只安排了三个人分担这次任务，让江老板去架构学生节晚会小程序的框架。但是后来发现，测试的任务量远远大于预期，只安排一位同学测试是完成不了的，这时才紧急召唤江老板加入测试的队伍，但是他还需要一段时间熟悉我们已经完成的工作和学习一下测试的方法，这就导致测试进度减缓了下来，以至于最后部署服务器、功能测试一系列环节安排的时间都被压缩，很多想要优化和改善的点都没有做。所幸这次不是在开发我们自己的项目。我也从这次实验中总结出两点：
（a）项目中测试环节也是很重要的环节，其任务量不比开发的任务量小。
（b）在项目开发前对于项目任务量做合理预估是十分重要的，这一点关乎整个项目开发的安排与进展，宁可高估也不可低估。
但是，这次实验中任务安排也有好的一点：彼此之间任务的耦合度较低。每个人负责一整个模块的功能或一整个模块的测试，无论是开发效率还是合并效率都是较高的，有问题只需要找一个开发者对话即可。这些都需要在以后的项目开发中重视起来。

2、短时间内的二次开发真的反人类

大帝的框架当然没话说，思路清晰封装良好。但是，封装太好导致很多接口找不到不会用无法测试orz。而且由于无法直接和框架架构者对话，很多架构者的意图都需要自己去揣测...当遇到bug时，无法判断究竟是我写的后端API的问题还是大帝前端框架自身的问题。前端的几个bug也是在我研究了好长时间js代码之后才大概明白了大帝的用意，找到修改的方式。另一个存在的问题就是，当不同终端跑相同的代码时，有的是错误的有的却是正确的，都找不到是什么原因造成的。（如果可以，我宁愿自己从头架构2333）