关于前端一些想法

学前端也有一段时间了。偶尔会看看一些文章,最近来到新的公司实习,看了跟之前老公司的对比,还是有点感触的。

##1. 前后端分离##
感觉这个词汇貌似是从node开始火了之后,开始慢慢出现到我们眼前的,新公司的这边的前段端感觉分离的还是相当的彻底的,这边的前端开发完全可以不依赖与后端,开发的流程完全可以前端先行,对于数据的依赖程度现在已经有一些比较成熟的工具可以来替代,比如mock.js,或者grunt里面也有类似的插件,通过拦截类似jQuery的ajax的方法,通过不修改借口名字的方法,去读自己的模拟数据。这边不同于以前,可能要做的一点就是接口先行,前后端的同学需要把彼此的接口的名称还有相关的数据字段都定义好,这样到时候两边同学的联调可以基本不用修改原有的代码,比较方法。
关于模板,现在的公司这边模板的东西是由后端进行维护的,感觉不是很好,前端做完demo之后给后端,然后有时候后端会问,这个页面里面那些地方前端进行了修改了,要是修改的地方少,那也还好,要是多了则该起来相当不方便,前后端关于模板修改的交涉就要花费一些时间。
而在老公司那边,前后端没分离的那么彻底,前后端的代码都是在一个仓库里面,经常更新代码之后本地启服务会遇到服务挂掉,这样都相当影响前端的开发效率,还有一点就是每次本地起服务的时间也是需要一定的代价的,其实前端关心的不是后台服务能不能跑起来,前端只管输入url后可以看到相关的页面可以展现出来。所以这样的开发模式会需要消耗很多的事件在等待后端上,不过那边好的一点就是模板引擎freemarker是由前端进行维护的,这让前端很爽,我们只要知道后端这个control中会填哪些数据即可,从页面在后端渲染完之后都是由前端来进行控制。省去这个模板维护的代价。

##2. 代码的复用
原来公司用的一个前端框架算是内部的一个框架,应该除了公司以外其他的地方很少有人用吧,但是说实话,我觉得真的很厉害,算是一条龙的服务都有,好了回归正题,来谈谈代码的服用的一些想法。
理论上,代码要尽量可以做到复用性,为啥呢。其实最可以理解的就是不要重复造轮子,要把时间会在刀刃上,还有的一个好处就是要是进行组建的全局的修改只需要修改一个base的组件即可,但是要做到很好的复用性其实还是比较费时间的。你可能需要更多的时间放在这个组件的设计上,要做到一个比较好的可扩展性,特别是那些作为基础的组件尤其重要,这也非常考验写代码人的思维,既好用又可扩展性强,那真是爽了,问题是所有这些东西都是需要做一个权衡的,在可用性和扩展性,我个人感觉其实还是需要有一个权衡的,要是把一个组件设计的跟业务粘合的很紧,那么开发可能是爽歪歪了,一调用就解决问题,但是这样的组件一般可扩展性都会受到约束。
其实这里就是涉及到你对一个功能的拆分的粒度的细分,个人觉得还是很纠结的有时候

##3. 代码工程化
感谢node的出现,多了grunt还有gulp,让前端的很多工作都可以解放出来,只需要在搭建整个工程的开始阶段费的时间陪下各个工具还有相关的参数,当完成之后,每次跑工程只需要一个命令就可以一键到位,还有watch liveload也真是大大帮忙了。
还有一些工具,比如git,做的好的话可以当开发者每次push自己的代码的时候就讲这类代码发布到cnd上,只要按照一定的命名规范,还是可以相当方便的。

##4. 分层思想

工程项目一大,代码的维护量就会呈现很陡的曲线上升,特别是大的项目一般不会是仅仅一个人做的,所以同样的代码很可能今天是你写,过几天由别人来修改你的代码,这里就是涉及到了代码的注释可维护性的问题了。
我看了下原来的部门跟现在的部门,可能两边做的项目的性质的不同,一边是多人做一个项目,一边是基本一个人会长期维护一个项目,所以在代码的层次结构上面可以比较明显的感觉到原来的部门的规范性,一般你只要知道他们习惯,你可以很容易的找到定位到相应的代码目录还有具体的文件内容。
说白了就是代码还是要规范点好,别让别人来踩你的吭,至少也要让别人好找你挖的吭

##5. 阻止前端进步的兼容性
这是个头疼的问题,要是没有兼容性问题,也许世界会更加的美好,可惜就是这么多浏览器,不过比较好的事情就是微软现在貌似慢慢和中国的一些公司合作,慢慢吧一些老的XPIe淘汰。他们也准备使用新的浏览器了,虽然可能需要兼容新的浏览器了。。但是我觉得应该还是比IE好把。这也是一个福音
新老部门里面最大的差别应该就在这里了,这边可以尝试的东西还是超级多的,很多新的特性在原来的部门是没机会用的,这边还是提供了很多的机会来尝鲜的,这个真心不错

##6. css的一点想法
其实在前端领域里面,感觉css是一个比较蛋疼的块,不想其他程序语言一样有着正规的程序逻辑可言,很多东西完全只是一个规则,没错,就是规则,至于为什么,答案就是。规范里就是这么规定的。我竟无法反驳

个人觉得网易的那套nec还是相当不错的规范,模块,组件的命名规则,以及一些类似功能性的css,比如f-cb就是清除浮动,f-fl就是向左浮动
今天下午跟带我的师兄进行了一些讨论,讨论的结果当然是谁都没说服谁,其实这个根本就没有一个固定的答案,只是两种 解决方案各有好坏。我的一个想法就是将整个页面中的一些例如f-cb这样的css抽取出来,放到页面的节点中去,我先说下几点好处

  1. 这样理论上可以做到,在整个打包完的css文件中可以只有唯一的一个float:left。最简单的就是打包完的css比较简洁嘛
  2. 把这些带有明显语义化的类放到标签中去,带来的好处就是一看这个class我就知道他是什么结构,其实有点语义化比较好的感觉
  3. 还有一点比较扯淡的就是这样的话有点可以对节点的样式进行拆分组装的感觉

不好的地方:

  1. 挺折腾的。师兄觉得类似那类清除浮动的直接可以写在类似less或者sass的minxin中去,直接作为函数来引,反正预处理什么的问题都是工具来做了,
  2. 至于css可以变小,其实说实话小不了多少,而且全部这类放在html结构中,本身页面也会变大,而且,有时候可能需要用到多个f=*的时候,一个class后面会跟一堆,书写一不方便

最后

无论什么东西都没有一个最好的银弹,每个解决方案都是需要最一个折中的处理,有舍有得,做好选择,而且每个人判断的方法也不一样,做出的选择还是有区别的。

前端是个造轮子神马最快最多的地方,东西也是井喷似的出现,所以需要调整好心态,抓住不变的来迎接万变。