近期的一些思考

[classicemi]

今天第一次这么晚才下班，原因是静态资源需要发布。现在临近双十一，虽然公司业务没有某A和某东那样的规模，但毕竟也算是比较大的电商，这个节骨眼上对任何发布操作都会限制比较严格，以免出错。令人无语的是新系统的静态发布功能居然还没有，只能全部打包上传，因此第一次的发布单被驳回，需要重新提，才弄到这么晚。虽然人不能走，但实际上并没我什么事，这个点已经比较疲惫，也写不动代码了，干脆就把这段时间以来在公司做的事情回想了一下，算是有了一点思考。

打车到家，洗完澡躺在床上，想想还是把一些想法记录下来比较好，于是再次打开电脑码起字来。对于进入苏宁的这三个多月，概括起来还是对自己比较满意的，时间都没有浪费，无论是在工作学习上还是在生活上都安排得比较好，我想一部分原因还是在本地工作，吃住还在家里，生活多少比较规律吧。

工作

重点还是应该放在工作上。总结起来，在易购的这段时间，做的事情主要是以下这几个方面：

• 打酱油参与的项目，包括门店频道和在线客服。所谓打酱油就是只做了其中部分页面的前端开发和改版工作，没有跟进完整流程。
• 部门内部项目。组件库项目的开发和项目架构。
• 长期跟进项目。异步更新价格组件开发维护。
• 需求变更项目。门店预约过渡方案。（也就是今天上线的这个项目）
• 独立承担的较大型项目。苏宁V购二期项目。
• 一些个人项目，比较杂，就不罗列了。

  打酱油项目

这些其实没有太多想说的，因为真的只是打酱油，而且距离现在时间有些远了，具体的细节有点记不清。在述职报告中，我是这么写的：通过这些项目，我了解了公司前端开发的流程，为以后更好的参与工作打下了良好的基础。

组件库开发

这个东西是个很重要的东西，不得不承认，苏宁现在的前端开发形态还是比较原始的，就连通用组件这方面都比较薄弱。老版的组件虽然也能用，但是我看过组件的代码，复用性很低，基本上只是把DOM结构，各种事件响应的代码进行了一层封装，无法扩展和二次开发。在这方面，苏宁有必然的劣势。不过凡事都有两面性，易购的建立没几年，前端开发规范化的历史更短，这些现状一定会改变，从最近的组织架构调整就能看得出来，领导层对这块是有想法的。而对我来说，就有机会能参与其中。对于一些在大公司里面的人来说，公司前端的架构成熟先进，工具完备，人才济济，那么更多的时候则是老老实实使用这些工具框架，一天一天的做着业务。倒不是说做业务不好，只是我觉得，每个公司都有业务给你做，但不是每个公司都能这么快让你参与到基础架构和工具的开发中去的。所以说压力与机遇并存。

在组建库的开发中，我体会到这种项目最难的并不是怎么去写代码，代码慢慢写总能写得出来，而且会越写越好。难的是这样的项目，毕竟不同于单兵作战，需要集合众人的智慧来完成，怎么统筹各个开发者，代码管理，包括git的使用，不仅仅是简单的add, commit，还有各种分支，合并。代码的统一规范，构建发布，这些东西平时看得不少，真正自己去做还是会有困难，有时间还是要向别人取取经多学习学习。

异步更新组件（脚本）开发维护

运营总部搞各种活动页的页面价格都改成了异步更新的方式，原来是有一段脚本的，老大把这项工作交给我以后，我根据业务需求对原来的脚本进行了一次比较大的重构，几乎是重写了一遍。重构后的代码扩展性更高一些，后来接到的需求变更基本上都能很快的在原基础上完成开发。由于这段脚本全站通用，我又是现在唯一的维护者，因此跟这方面有关的任何需求都会打到我这边来。在多次跟运营总部的人对接的过程中，我体会到，不论是什么样的公司，即使你再标榜自己尊重技术，但终究是运营主导，运营的需求无论你用何种方式都必须要实现。技术的最终服务对象仍然是需求。

至于组件开发的一些细节，我在另一篇文章中说到了一些，尽管现在的组件和写文章时的状态又有所不同了。

苏宁V购二期

这个项目是现在还在进行中的项目，目前的进度是页面开发已经完成，虽然产品和视觉评审后还有一些地方要改，但不影响开发流程，下一步就是开发套页面，进入前台开发阶段了。说起独立承担的项目，这个应该是第二个，上一个还是在从网实习的时候做的七夕活动页面。从技术的角度来说，并不会有特别困难的地方，毕竟技术能力方面比起去年提高了不止一点点。难点还是在项目的整体把控上，毕竟独立承担大型项目的经验还欠缺，可能会出现的各种问题现在还不是完全心中有数，只能说尽我所能做到最好。等到项目结束之后我再做一个完整的总结。

个人项目

个人项目也启动了不少，目前还没有完全完成的，有一些即将完成，有一些才刚刚开头，具体是什么不重要，做好了再写。为了这些个人项目，我看了大量的书，阅读了大量的源码，也使用了各种工具，但是有点郁闷的是，对自己的要求越高，对做出来的东西就怎么看都不满意。不过我想这是个提高的过程，也就不怎么在意了。过去的我总有点咋咋呼呼的，看到点什么学到点什么都喜欢各种表示一下，现在感觉挺没意思了，自己有提高就好，对外一概保持低调，有句话叫如人饮水，冷暖自知，也不知道放在这里合不合适。

我发现自己是个比较慢热的人，与他人相处是这样，总要一段时间之后才能放得开。在前端学习方面似乎也是这样，一开始也没有特别高的热情，只是作为一个兴趣爱好一直在保持关注，但是随着时间的推移，热情好像慢慢被激发，从早坐到晚写一天代码并不是什么困难的事情（但是这样对身体很不好，尽量不要）。接受新知识的速度也越来越快，我能做到一个什么样的程度，time will tell. 给自己一点鼓励吧。

生活

生活方面，写不了上面这么多，因为没有那么多具体的事情去写。生活是碎片化的，事情都是小事，带来的改变是内心层次的东西，文笔笨拙也描述不出来，还是列几个方面出来吧。

• 保持自己的兴趣爱好，好好弹吉他，有机会去酒吧驻场一次（这个好像得请教凯哥）
• 学英语，在字幕组里面活跃起来，多多贡献力量。技术文章有精力也多多翻译吧，可以先中译英，以后尝试用英文写博文。
• 锻炼身体，好好跑步。争取在明年实现马拉松的愿望，现在10公里无压力。
• 学摄影
• 多陪父母，多陪妹子。

夜已深了。

更新于2014年11月1日

目前开发方式的思考

最近的苏宁V购项目，包括之前的一期过渡方案，都是和同一个开发对接，在对接的过程中，对于开发方式上有两个方面的问题让我感到很不舒服。

首先是前后端分离的问题。这个问题也不新鲜了，从今年的D2上有这么多关于前后端分离，Node.js相关的议题就能看得出来这是目前前端圈子里非常热门的话题。现在在大多数公司里面，前后端仍然是不分离的，前端工程师完成前端稿后，把 html 文件扔给开发，开发去套页面，至于 css 和 js 这些静态资源，前后端约定好开发不能动，只有前端有权改动。那么在这个过程中，页面模板，包括页面中所有数据在服务器端的填充渲染逻辑实际上就是由开发来控制。但这种方式真的合理吗，我认为开发的工作职责范围应该只限于服务端所有内部数据的逻辑，对数据库的增删改查等操作等等，一旦数据由接口吐出，就不应该再受到开发的控制，而是由前端工程师来接管，进一步进行页面渲染等工作。

这样的工作方式无疑会增加前端的工作量，但是增加没有关系，走出第一步，会给整个开发流程带来非常好的影响。前后端分工明确，一直到上线为止前后端的工作内容都互不干涉，唯一要做的就是约定好接口和数据结构而已。再者，前端技术涉及的范围越来越广，在不久的将来根据不同工程师的技术特点进行再分工也是必然的趋势，现在一些公司已经有了Node工程师这样的职位。前端工程师对前端的各种技术都有涉猎，又各有所长，这是比较理想的状态。

令我感到不舒服的第二个问题不具有普遍性，大多数公司不存在，但是在苏宁存在的，就是前端和前台的割裂，而且是一种人为的割裂。老实说在进入苏宁之前我是没听说过前端和前台之分的，可能有的地方会把前端称作前台，但应该只是一个称谓不统一的问题，本质意思是一样的，但是前端和前台同时存在，我时第一次见到。

那么这个前台是做什么的呢，我也是问了之后才知道，原来前台的工作职责就是套 html 页面，外加写前端跟数据交互相关的逻辑，比如 ajax！没错，ajax。原来公司里面前端工程师一般是不写 ajax 的，除非你主动去参与前台的工作，否则你不想写是可以不写的。

但怎么能不写呢，不写ajax的前端还是前端吗？前台存在的不合理性我认为有两点： 1、 css 和 js 本身都是前端技术体系中的一部分，只会 css 和只会 js 都是不太合理也是挺奇怪的一件事，你可以不擅长，但是不能不懂。公司所谓的前台，实际上都是开发，开发是写 java 的，有 java 的基础，会 js 本身是件挺好的事情，可以有助于他们理解前端工程师的代码，但是由他们完全接管 ajax 这样的工作真的好吗？因为数据请求过来了还没完，还要面临着怎么处理数据，如何构建元素，各种 DOM 操作，事件操作等等，没有前端开发的技能，这些事情都是做不好的。 2、 前端跟前台的分裂实际上就是页面视觉效果交互和数据交互的分裂。前端工程师把页面视觉上的交互写在一个js文件中，前台要做数据交互了，就在页面中新引入一个 js 文件，再把自己的代码写进去。性能问题之类的我就不说了，毕竟这些问题不会影响到开发，我来举一个会影响开发的例子。

假设页面中有这样的模块：

模块中城市名列表并不是页面构建时就渲染好的，而是通过ajax异步加载的，前台用ajax去调用接口取得城市数据，构建成一个html字符串，然后插入页面中合适的位置，应该没什么问题，但是视觉交互呢，选中城市以后城市名称的样式变化是通过修改元素class实现的，绑定click事件的逻辑可都是写在前端的js文件里啊，绑定事件的操作在dom ready的时候就执行了，而异步的ajax这时候可能连请求都没发出去呢，结果就导致点击城市名视觉样式没有任何变化，然后测试就找前端了，说你这个有bug啊，前端就说怎么会是我的问题呢，你试过关机重启没有~~绕了一圈最后才发现是前台的问题，如果这部分模板又是写在一个MV*之类的前端框架里面就更麻烦了，view层在modal更新的时候刷新模块，元素的class每次都会被刷成初始状态，看起来又是事件绑定的问题，然后测试又找前端了，从此测试前端就幸福的在一起了。

这还没完，为了修改这些问题，必须要去动前台代码，很多时候为了交流便捷，毕竟前端前台工位都不在一起，前端就干脆跑到前台的机器上去修改代码。这一改，开发机器上的代码和前端提交代码的SVN上的代码就不一致了，SVN上的代码就废了，每次修改都要跑到开发机器上去改服务器上的代码。如果项目一次完成也就算了，很多项目往往要长期维护，可能一年之后要添加个新功能，原来的参与者甚至可能都离职了，接替者又不知道当初还有这么一出，结果就发现拉了SVN上的代码怎么不管用啊，然后噩梦就开始了。。。

所以，对于前台开发这个神奇的岗位来说，我觉得一定要进行指责拆分，不谈前后端分离的前提下，套模板的工作通通丢给后台开发，而ajax之类的工作由前端控制，前台从此不复存在。好在前两天听到组织架构的调整，前端将要把前台的工作接管过来，我心里在想，早干嘛去了。也许这样的现状是有历史原因的而我不知道，但是无论如何，作出改变已经不能再等了。我们的开发模式没有达到先进没关系，但是不能落后啊。

[lwbjing]

一个不会思考的切图仔路过点赞。。

[titanew]

写模版和ajax的操作,其实都是属于业务方面的, 这两个也不能分.但是按照网购当前的前端人员配比,完全做不到来接前台,因为接了以后就不单单是写完业务那么简单,整个流程里前端的工作就变成了最多的了,从需求评审分析,到前端(包括前台业务),到测试,发布.每一步前端都要跟进.工作量几乎是原来的几何倍.从这一次的我做的在线客服来看,前端配备3个人,目前项目进行2个多月,有一个半月的工时是超过996,最后阶段几乎没休.如果我们只是做前端,前端配备1个人,周期半个月几乎就可以完成.所以说前端接受前台业务是需要大量人力的和过度时间的. 我司起步晚,不过庆幸的是领导已经开始重视. 莫大也在积极推动.应该说挑战和机遇并存. 加油吧,小鲜肉,看好你.

[classicemi]

@rubyless 5++么么哒，之前在人人做V7的页聊工具就是这样，开发几乎没什么事情做，再加上是个纯前端项目，服务端连模板都没有，天天加班非常辛苦。

[zhuxiaojian]

一切都是朝着好的方向发展的,这么多人在推进公司整体前端的发展,作为其中的一小份子,这是一件很值得去做的事.我曾经只身一人支撑整个部门的所有问题长达半年之久,所有技术方案,技术突破,技术创新都是从我这边产出,俨然成为部门的天花板,这一点我很羡慕你们那边,那么多的天花板可以比高,而我这边只能冬天喝冷水,冷暖自知. 后面发展加速度的时候必定和你们会有很大的交集,我希望更多的天花板在期间迅速出现,然后一起提高公司高度.

[classicemi]

@zhuxiaojian 你们这些前端的老员工都很不容易，现在队伍越来越壮大，可以让你们有更多的时间去优化整体的技术架构，是时候让公司的技术更进一步了。