记录一下近一年来我对部门的影响

正值入职鼎微两周年，记录一下近一年来我对部门带来的改变，顺便过个节

一.gerrit代码审核系统

1.代码过于分散

此前的代码都分散地暴露在服务器不同地目录，问题都是随着平台的增加而越来越严重，记得我刚来公司那伙，找分支找代码就找得很恼火，一来有时不清楚某UI是什么分支名，二来又不知道在哪里放着，

而且有的相同的分支名居然同时存在几个git仓库里，甚至出现过两边异步更新的情况。

所以gerrit第一个作用就是将代码整合起来，兼容平台，统一更新。

2.代码并没做保护和备份

随着代码量的膨胀，之前存代码目录又分散，加上负责的人员的流动，代码有时真的就再也找不到了，只剩个apk，这时对应负责的人员如果要改问题，就必须得重新做一份，

加上代码没有备份，是有出现过误删的情况，而且服务器里的东西，你删了就真的没了。

所以gerrit第二作用就是做了保护和备份

3.提交代码随性发挥

程序人员的技术风格参差不齐，导致提交的代码风格迥异，解决的方案没一个标准，提交的次数也是随性发挥，没有基于后期维护的考量

gerrit的第三个作用审核作用就是发挥用处了，首先划分不用的项目的负责人，提交的时候由负责审核通过

4.分支命名不友好

之前的分支命名也是厉害，平台+客户缩写，换个平台，就多一份代码，多一份代码就多一份维护，多一份维护就多消耗一部分人力

所以gerrit上的代码就要求要做到兼容平台，命名规则为客户缩写，利于后期的UI的查找

二.UI网站

之前我们部门的UI效果图是存在一个表格里，随着UI量越来越大，表格的性能就堪忧了起来，而且越来越大。

所以我利用仅有的一些网页知识，给部门在局域网里部署了一个专门用于查看UI的网站，性能极好，随点随到，查看也方便，广受部门和其他部门好评

三.应用部组织框架

最近一年来，部门组织框架变动很大，而且每次改动都不能坚持很久，我感觉到一些危机后，给老卢建议了这个框架思想，核心思想是组织框架不宜频繁变动，通过各小组之前的人员流动来解决问题，

人员流动这一块目前已经在实行。

四.日常报表

该报表是分组后，为了利于组内管理而草拟的，主要用处是

1.接任务

2.分配任务

3.监控任务

4.积分和总结

该报表目前已经推广到其他小组，并已经执行了一段时间，可以说完全能达到目前需求，已经作为部门日常管理的主要文档了。