从入职第一个项目后,就开始了工程化和组件化的想法。平均每个月1.4个新项目的节奏里,穿插在各个间隙中不断开发修改,直到今日,总算是大致组建完毕……

半年前入的职,看到代码的时候吓得我下巴都不知飞哪里了……

没有任何文档、起码两种以上的编程习惯、顶部漫天的全局变量、莫名其妙的重复方法、格式没有统一规范、上线代码不经过任何处理、项目很小代码量却巨大。出了点问题去问之前的码工,“我不知道…… 这个代码也是之前的人写的。”

……祖传代码

后来做了几个项目后也就大致理解了。不是不做……是根本没时间思考。20人2个月的工作被压缩到现阶段2个人身上,能做的也就是打个逗号,加个对象,一股脑往下写。完全没精力去思考架构方面的东西。

不要跟我说什么架构,拿起键盘一梭子就是干!

我成了一名光荣的页面生成师……

(╯‵□′)╯︵┻━┻ 搞卵子啊!



目录

  1. 需求整理
  2. 技术架构
    1. 自动化处理
    2. js处理
    3. css处理
    4. 静态资源
    5. 归档处理
  3. 具体实现
    1. 模块开发
    2. 产品开发
    3. 模块更新
    4. 依赖修复
    5. 代码归档
  4. 流程合作
  5. 小结
  6. 后续更新

为了能多活两年,这代码是打死我都不能写的。于是组件工程化就势在必行了……

需求整理

入职后主要负责芒果TV移动端节目产品的制作,周期短、工时紧张、项目准备不充分、流程无法保障。

针对以上特点,对工程化计划提出以下需求

  1. 热更新
    • 减少开发和后期需求变动成本,提高开发速度。
  2. 组件化
    • 基本组件样式固定,减少重复劳动。
    • 每个组件独立作用域,便于代码管理
    • 减少了代码之间相互干扰,为日后多人协作提供基础。
  3. 组件、产品双流程
    • 组件开发走严格工程,若代码不符合规范不予以编译,保证代码可读可延续。
    • 产品开发走宽松工程,以最快速最灵活的方式完成产品产出,保证生产速度。
  4. 自动对资源处理打包
    • 提高生产环境产品运行效率,提升加载速度,减少冗余流量。
  5. 对代码进行归档留存
    • 方便下次类似项目改造,也可作为历史项目参考。

技术架构

自动化处理

自动化处理器,主流为grunt、gulp、webpack。主要用于源代码的处理

首先比较webpack和其他两者,grunt和gulp都是基于传统的html、css、js代码处理流程进行处理,最后生产出相对应的文件。而webpack则更倾向于现代化框架的处理,将万物视为pack,一切css、js、img等资源都通过webpack打包成一个js,然后在生产环境进行解析(暂不细说各种plugin和loader,只是简单的说明一下双方的设计思路)。

在该部门的项目中,项目需求不稳定,开发时间短。因此个人更倾向于传统模式的JQ开发而非现代框架。现代框架若盲目用在此处只会产生 设计过度 的副作用。

现代框架的架构思路都是基于数据和视觉分离的思路,故只适合较大项目的开发。在小项目中数据量本来就不大,也不会有复杂的操作逻辑。强行分离只会造成开发成本的无限加大和修改维护成本的剧烈上升。

开发模式确定了,那么自动处理器自然也选择更贴近开发模式的一类。

接下来就是grunt和gulp二选一。

grunt是鼻祖,个人感觉太难用。主要反映在配置文件的语法冗长且不符合日常语言习惯。gulp出现较grunt晚,在配置文件中做了较大改进。故选用了gulp,当然这个选择很大成分是个人习惯所致,并无优劣之分。

js处理

在此个人选用了es6+browserify编写方式。

选用es6很大程度是由于其已经确定为ECMA新标准,迟早都是会用上的,故能将学习成本降到最低。而且其中新特性能够大大提升开发便利程度,严格作用域的控制,优化代码编写阅读体验。

插件的管理使用browserify,通过npm直接下载,直接在js中引用,依赖直接记在package,直观且便于管理。

css处理

css上个人更倾向于使用stylus语言编写,其主要原因是没有大量符号干扰,通过类似py的缩进区分代码块,使得代码更简洁。

况且css作为一个声明试语言,本身也没有复杂的逻辑需要编写。那么个人对于缩进代码块在复杂逻辑下不够清晰这一问题也能得以避免。

静态资源

静态资源从文件夹上被区分为js、css、assets三类。之所以不用image作为第三个文件夹是因为某些时候还会有个别json文件会存入其中,故asset描述上更准确。

每个静态资源下面又分为common和其他文件。common为模块,其中所有内容都是严格按照标准实现开发的,可复用的模块。其他文件则为当前产品所用。

最后在进过自动化处理,打包压缩到生产环境下三大文件夹中。

归档处理

归档处理需要对现有代码进行重命名剪切,gulp暂未发现输入参数改变命令内容的方法…… 故暂用bash替代。通过命令行将生产工程的代码剪切重命名到pit文件夹中。

具体实现

为了配合该部门产品需求快速、多变的特性,特地将代码分成了模块开发文件夹 demo 和组件开发文件夹 build

模块开发

$ npm start

启动开发&编译环境,代码热更新,所有代码必须通过eslint检测。未通过检测的代码将不予以编译。

产品开发

$ npm run build

启动开发&编译环境,代码热更新,代码无检测。以求快速灵活的开发。

模块更新

$ npm run common

将demo文件夹中的模块复制覆盖到build中,从而实现模块更新。

依赖修复

$ npm run fuck

删除并重装开发、生产环境所需依赖。

代码归档

$ npm run poops <name>

将build中的源代码全部剪贴到文件夹pit的子文件夹中,参数 name 为存放代码的文件夹名称。

流程合作

在demo文件夹下开发的主页,内容共为两个部分。

  • 模块部分,其中包含了所有已开发完毕的功能模块调用入口。可随时点击查看效果。
  • 案例部分,将常用的页面以最基础的样式写成页面,供设计和产品参考。

该页面日后完善好了会发布到外网,供产品和设计随时参考。

产品和设计则可根据demo中所有的模块和案例进行产品的设计,以达到设计和开发的简化。

小结

该架构为个人所能想到的,解决当下需求最佳的自动化解决方案。接下来要做的也就是对老代码进行重构和转移,这亦将是个漫长的过程…… 从小项目开始,一点点将这套流程用起来…… 希望将来能看到这个架构的不断成长。

后续更新

新添命令:

npm run shit <name>
将pit里面的代码复制到build中,方便已完成项目继续开发。参数 name 为pit下文件夹名称。