职责拆分：gulp相关构建代码的重构方案

职责拆分：gulp相关构建代码的重构⽅案今天在读微信⼩程序项⽬的代码，主要看了构建的部分，在读这部分代码和画架构图的过程中，发现了⼀些不是很合理的地⽅。我们的⼩程序构建⽅案scss来做css样式的管理，使⽤babel解析js的es6、7和flow语法，使⽤单⽂件组件（sfc）的形式整合wxml、wxss、js等。构建的最终产物是⼩程序的原⽣代码，然后经由⼩程序开发者⼯具再次打包和构建。我们构建使⽤的是gulp。因为只是⼏种资源的处理，不涉及到模块解析，所以gulp⽐webpack更合适。构建相关代码的结构插件、配置和⼯具等通⽤代码这3部分。项⽬中对应的⽂件有5个，根⽬录下的gulpfile.js和build⽬录下的compile、util、config等⽂件。他们之间的关系如下图：命令⾏使⽤build、dev、qa、sgb等npmscripts会对应的执⾏build、default的task，两者各⾃有⾃⼰的处理流程。处理过程中会⽤到我们扩展的解析单⽂件组件的gulp插件。图中绿⾊部分是可复⽤的utils、config代码，红⾊部分是task相关的代码，⽽橙⾊部分是我们所扩展的gulp插件。他们之间的关系如图所⽰，但从代码的⽬录结构中并不能清楚地看出这种关系，需要具体去看代码才能逐步理清。构建代码重构的想法现在的⽬录结构没有清晰反映出task、plugin等的关系，⽽且命名也达不到见名知意的要求，于是我有了重构的想法。我按照之前分析出的代码职责调整了⼀下⽬录结构：tasksflowcompile-sfc.jsclean-distDir.jscompile-sass.jscompile-js.jshandle-config.jscopy-otherFiles.jsproduction-task.jsdev-task.jspluginssfcindex.jsmy-script-compiler.jsconfigindex.jsutilsindex.jsindex.js⾸先拆分出了tasks、plugins这两个⽬录，config、utils考虑到后来的扩展也改成⽬录的形式了。tasks下⾯是production、dev两种环境下的任务，他们的实现流程需要组合flow下的细⼩步骤实现。plugins下明确封装了解析sfc的gulp插件，包括解析sfc中js代码的部分。除这些以外，还应该把gulpfile移到build⽬录下，因为gulpfile也是build的⼀部分，放到build下更合理，就像vuecli脚⼿架⽣成的代码把webpack.config.js放到build下⼀样。src下的代码也不应该引⽤build的代码，应该通过环境变量、全局变量等⽅式。这样的重构只是静态代码结构的变更，对代码的运⾏并没有啥影响，但代码的易理解和易维护性会增强⼀些。总结总结为了更便捷的开发、更好地代码可维护性，我们使⽤了scss、babel等预处理⼯具，使⽤单⽂件组件（sfc）的⽅式整合页⾯相关的wxml、wxss、js代码，相应的也就需要把这些资源的处理增加到构建流程中。经分析，使⽤gulp是⽐较合适的。读代码结合画代码结构图理清了代码从逻辑上的职责划分，也发现了⼀些命名⽅⾯不太合理的地⽅，于是也就有了重构的想法。主要⽅向是把不同的职责的代码（⽐如task、flow、plugin）放到不同的⽂件和⽬录中去，⽽不要都堆到⼀起。于是，按照代码的不同职责分出plugins、tasks和utils、config⽬录，把gulpfile也放⼊build⽬录下，把task的执