2014 年工作总结

2014 马上就要画上句点,回首这一年,感慨良多。最大的感受是工作上的充实:今年公司自创业以来业务量最多的一年,真是锻炼人的一年呐。

成长

自去年网上开户的项目开始没多久,自己便开始尝试编写自动化构建脚本,自动部署至公司服务器提供预览,自动上传提交,效率有了质的飞跃。今年在其他项目上,采用了更加流行的且学习成本更低的 gruntgulp 来做 workflow,现已成为了我们团队的标配。

今年下半年开始,我逐渐将精力转向网上开户移动端的项目开发,开始尝试的两个版本都很不理想,在第三版启动时,我在大家的质疑声中力推市面上最新的 HTML5 移动框架 —— Framework7,当时不被看好。这套框架在当时不要说没中文资源,连英文文档也只有寥寥几句。而且由于其只针对 iOS 系统而在 Android 下坑不断,我花了不少的力气在兼容性上填坑。好在 F7 是开源的框架,遇到实在难以解决的困难我就上 github 用英文给框架作者提 issues,甚至有时也推送自己的解决方案代码。在我的坚持下,随着项目进展也随着框架自身完善与文档逐渐丰富,其优势渐渐显露出来,我们也借此机会打败了我们的竞争对手重新赢得了客户信任。目前 F7 已成为了我们移动端前端开发的主力框架。

在这趟移动端开发之旅中,我也尝试了新的开发模式,按照 MVC 的思想将前后端的代码尽可能进行了分离,将后端业务操作的 JS 代码锁定了在 Controller 这一层,而对应的 View 层,主要是一些 DOM 操作,交给更加专业的前端来做。页面模板的渲染不同于传统做法放在了客户端来做,一开始采用的是流行的 MustacheHandlebars,后来用 F7 自带的 Template7。只需前后端将数据结构名称等约定好,前端开发用本地模拟数据,交付给后端后再换用真实数据,这样就完全地干掉了 JSP 等这些服务端的模板。目的很简单:让专业的人做专业的事

困难

这个项目做下来,很大的感受是让我们公司的 Java 开发们接受新事物比较困难。他们的理由有这么几点:

  1. 能用就行,这个没必要吧;
  2. 这个不稳定吧,别把原来的给搞坏咯;
  3. 这个不是太懂,感觉还是原来的好用(不想学习)。

后端相较前端而言,特别是金融行业,更加追求“稳定”二字,思维也更加封闭。

好在我的坚持与据理力争,才使得目前公司移动端的项目从代码质量与开发效率这两个层面上都有所提升。可惜在推动分布式版本管理软件 Git 上我失败了,可能是自己没准备好,也可能是 Git 的学习成本真的太高了。但我还是不死心,我打算明年继续推动,不能像以前那样想一步到位了,先在自己负责的前端组全面实行,再推广到全公司。

随着券商客户的不断增加,项目的版本日渐增多,管理维护愈发的困难。版本管理,无论对前端还是后端,都是一个巨大的挑战。特别是前端,因为我们的后端服务,大部分是可以共用的,而前台界面,不仅要适应不同券商的不同功能而改动(后端需要改动),还要适应券商的个性化表现层的需求,比如字体颜色文字修改等等(后端无需改动)。

前后端之间的衔接通道不畅通,这是就目前为止最令人苦恼的一件事了。目前我们的配合模式有两种:

一、前端们安装后端环境,跑后端服务来写前端页面。我是比较反感这样的做法的:

  1. 后端环境往往很重,配置依赖颇多,没有后端开发经验的话,难以驾驭;
  2. 对前端开发调试不友好,由于基于后端提供的数据,不如自己模拟数据来的灵活;
  3. 后端跑的 http 服务一般是 tomcat,这跟前端们自己的服务还是有差距的,缺少了比如 less 编译、浏览器 live reload 等功能,非常的不方便。

二、而如果不这样做,前端后端拥有各自的开发环境,缺点也很明显:

  1. 这样一来,前端的产出物往往要通过后端二次包装(嵌套为 JSP,静态资源引用加版本号避免缓存等),一些前端资源的合并压缩,被放到了后端来做,做的不好不说,有时候甚至压根就没做;
  2. 效率也很低,可以想象,每次前端的改动,无法直接应用到最终产品端,都要由后端通过前端的提交版本比对来进行修改。有时如果 SVN 出了点问题,历史版本被清空了, 就会变得比较棘手了。
  3. 随着时间推移,后端加入了许多自己的代码,将许多的页面和 JS 都改的面目全非,与前端的版本越来越分离,会搞成后端不想动前端不想改的烂摊子。

写代码的人很多,写文档的人太少。优先面向机器还是面向人,这是一个问题。

太过追求开发速度,不注重代码质量导致后期的 debug 成本过高。

期望

对于刚起步的创业公司而言(如果三年也算刚起步),我觉得以上几点困难有些不是那么的要紧,毕竟“快上线”和“占领市场,占得先机”才是关键。但是要想做强做大,我相信迟早都是要直面这些问题的。

版本管理的问题,有 Git 这把利刃。

前后端分离,今年开始变成了一个热门话题,目前还都在实验阶段,比如淘宝的“中途岛”项目。相关的一些资料还比较少,我也是在摸着石头过河,希望明年能有一些突破。而突破的前提,看来是要多招一些能写好的 JS/NodeJS 的小伙伴们。

目前我们公司的开发们不仅要写服务端代码,而且还要写很大一部分客户端代码。估计一个项目中有一半的 JS,都是由后端开发写的。这算不算又是一个典型的让专业的人做专业的事的反例呢?

关于 JS 这块,需不需要专业的人来做,还有待评估。

这个问题也直接关系到位于客户端的业务逻辑代码,要不要由前端来介入甚至接管的问题(我相信在很多互联网大公司,这是理所当然的事情,这也是作为前端工程师的很大一部分的价值体现,所以他们的薪资一般也与后端开发们相当,这也是我目前最渴望招到“前端工程师”)。

看来其实核心问题是:要不要加钱加人在专业性上更上一层楼。当然这个是否必要,也看公司的具体情况,因为我也不敢保证,专业性上去了,公司的效益是否也能成比例增长,这个很难讲(至少“效”会提升吧?)。

加钱招人是一条路,但斯以为,人海战术固然可行,可在开发效率上提升一些岂不是更好?打一个比方:测试MM抱怨出包繁琐,容易出错。是否有人愿意跳出来,写一个自动化的打包服务造福于团队?

团队

今年新招的应届生MM,我还是比较满意的。思路清晰,一点就通,平日里也较积极主动,就是有时候比较马虎。比如有一次跑来问我:为什么 rake generate 的命令报错。我一看原来是 generate 的单词她拼错了。

另一位前端GG,稍令人担忧一些。老请假是一方面,解决问题的思路也是不尽如人意,依赖性太强了。好在底子还可以,这一年通过网厅的项目,也得到了不少的锻炼。

带人对我来说也是一项挑战,我总是跟我的组员强调,要有工程师的思维,要有解决问题的能力,要有自身的价值体现。我希望我的组员不仅仅是制作页面的“切图仔”,要对得起“前端工程师”的名号。

View on GitHub