截止目前為止，自己開發過不下十款小程序。算是有些經驗，其實對于一個熟悉了前端開發的工程師，小程序的入門會非常簡單，無非是要多熟悉些API和小程序的開發工具。本質上和寫一個H5頁面沒有什么區別。

抽象化

做的越多，就越覺得其實每個小程序都差不多。慢慢的就能夠抽出一些通用的代碼，作為公用模塊。但是小程序的一個限制就是，代碼必須在項目的根目錄下。這個是由于小程序框架的限制，如果在根目錄之外，require模塊的時候，會找不到對應的文件，因為路徑會解析失敗。

這樣帶來的問題就是，需要借助其他方法來做到模塊甚至頁面的復用。A、B兩人獨自開發一個項目，A、B共用的模塊C。兩個人開發還好，如果有四五個人，項目也很多，各自拷貝C模塊就違背了軟件開發的DRY原則。C模塊的迭代會導致代碼管理很混亂。因此需要設計合理的框架來滿足開發需求。

按照流行的套路，把生產環境與發布環境隔離。我們需要新開辟一個空間，專門在這個地方寫代碼，然后需要用到的公共組件都從同一個地方取，并且生成最終可以在小程序上運行的代碼。這樣，對于公共組件，我們就可以只用維護一份代碼。

 

實現

具體實現起來會遇到一下幾個問題

 

1、require路徑解析問題。

common目錄下的代碼最終會構建到每個項目中，如App1/common。App1/pages/index/index.js 需要依賴common目錄下的模塊，就需要寫很長的相對路徑（小程序只支持相對路徑）。所以我們建立一個規則，凡是依賴common目錄下的模塊，就直接寫common/xxx.js，由構建工具來解析路徑。

2、組件依賴問題

組件之間的依賴用相對路徑

3、wxml與wxss的同步問題

由于小程序不像vue一樣，三個文件整合在一起，而是分開了。但使用組件的時候，需要將這三部分分別require/import一次，顯得有點繁瑣，尤其是依賴的組件有點多的時候。依賴構建工具，一旦發現組件下有wxml與wxss文件則自動同步到項目下，并且在項目的wxml注入相應的依賴。

4、頁面級的復用

調用組件的方式還是太繁瑣，有時候我們需要直接復用頁面。直接從common目錄下拷貝一個頁面到項目中，并自動在app.json插入配置。

{
  "pages":[
    "pages/index/index",
    "pages/common/common" // auto insert
  ]
}