今天在读微信小程序项目的代码，主要看了构建的部分，在读这部分代码和画架构图的过程中，发现了一些不是很合理的地方。
我们的小程序构建方案
我们小程序使用的是原生的方案，小程序自带了构建打包的过程，在其上增加额外构建过程是为了使用各种资源的预处理工具，比如使用scss来做css样式的管理，使用babel解析js的es6、7和 flow语法，使用单文件组件（sfc）的形式整合wxml、wxss、js等。构建的最终产物是小程序的原生代码，然后经由小程序开发者工具再次打包和构建。
我们构建使用的是gulp。因为只是几种资源的处理，不涉及到模块解析，所以gulp比webpack更合适。
构建相关代码的结构
我梳理了下构建的代码，主要包括各种任务的定义、自己扩展的gulp插件、配置和工具等通用代码这3部分。项目中对应的文件有5个，根目录下的gulpfile.js和build目录下的compile、util、config等文件。
他们之间的关系如下图：
命令行使用build、dev、qa、sgb等npm scripts会对应的执行build、default的task，两者各自有自己的处理流程。处理过程中会用到我们扩展的解析单文件组件的gulp插件。
图中绿色部分是可复用的utils、config代码，红色部分是task相关的代码，而橙色部分是我们所扩展的gulp插件。他们之间的关系如图所示，但从代码的目录结构中并不能清楚地看出这种关系，需要具体去看代码才能逐步理清。
构建代码重构的想法
其实，理想状态下目录结构应该能清晰地反应流程和所涉及到的概念的关系的，具体看代码的过程只是对这个结构的补充，而不是在读代码过程中梳理结构。
现在的目录结构没有清晰反映出task、plugin等的关系，而且命名也达不到见名知意的要求，于是我有了重构的想法。
我按照之前分析出的代码职责调整了一下目录结构：
tasks
flow
compile-sfc.js
clean-distDir.js
compile-sass.js
compile-js.js
handle-config.js
copy-otherFiles.js
production-task.js
dev-task.js
plugins
sfc
index.js
my-script-compiler.js
config
index.js
utils
index.js
index.js
首先拆分出了tasks、plugins这两个目录，config、utils考虑到后来的扩展也改成目录的形式了。tasks下面是production、dev两种环境下的任务，他们的实现流程需要组合flow下的细小步骤实现。plugins下明确封装了解析sfc的gulp插件，包括解析sfc中js代码的部分。
除这些以外，还应该把 gulpfile移到build目录下，因为gulpfile也是build的一部分，放到build下更合理，就像vue cli脚手架生成的代码把webpack.config.js放到build下一样。src下的代码也不应该引用build的代码，应该通过环境变量、全局变量等方式。
这样的重构只是静态代码结构的变更，对代码的运行并没有啥影响，但代码的易理解和易维护性会增强一些。
总结
为了更便捷的开发、更好地代码可维护性，我们使用了scss、babel等预处理工具，使用单文件组件（sfc）的方式整合页面相关的wxml、wxss、js代码，相应的也就需要把这些资源的处理增加到构建流程中。经分析，使用gulp是比较合适的。
读代码结合画代码结构图理清了代码从逻辑上的职责划分，也发现了一些命名方面不太合理的地方，于是也就有了重构的想法。
主要方向是把不同的职责的代码（比如task、flow、plugin）放到不同的文件和目录中去，而不要都堆到一起。于是，按照代码的不同职责分出plugins、tasks和utils、config目录，把gulpfile也放入build目录下，把task的执行中的每一个小流程拆分成单独的文件等。
理想中目录结构是能直接反映出代码整体的结构和相关概念的逻辑关系的，虽然运行时都一样，但是易理解性和可维护性却是差别很大的。
网友评论