這里的OLPM，是指scrat 里面的olpm模式。
為了更好理解我接下來要講的內容，希望你可以先閱讀一下這篇UC大神的文章。
1.什么是OLPM？
OLPM簡單地說，其實就是一個多組件的模板，這個模板里有各種預置的組件，你可以選擇用或者不用。使用這個模板，你可以無限地產生頁面。頁面就是由組件拼接而成的。
所以，無論生成多少個頁面，它們必定是相似的，因為都是由預置的組件組成。這里所說的組件，其實就是上面鏈接里說的模塊。
2.OLPM的適用場景
既然它是一個產生頁面的模板，那就表明了它只能用於單頁面的應用，頁面模塊組成比較簡單而且分明。值得注意的是，產生的頁面之間是一種平行的關系，也就是頁面之間是沒有交集的。
如果產品的需求是有幾個頁面的那怎么辦？
方法1：可以把所有的組件寫在一個模板里，生成頁面的時候讓運營自己挑組件，這樣是比較優雅的方法，但可能會存在一個問題：同一形態卻有不同的統計方法，這樣的話，就要靈活處理了。
方法2：一個頁面一個OLPM工程，這樣看起來有點惡心，但是它是比較分明的，不用與其他耦合在一起，而且對於統計是非常方便和清晰的，維護也會變得簡單。
3.OLPM還需要后端配合嗎？
OLPM的主力開發都在前端了。基本上，如果產品要求不太嚴格的話，流程到前端那里就可以結束了，不需要后端的配合。但是如果產品要求比較嚴格，例如投票頁面需要防止刷票，雖然我們知道懂得刷票方法的人基本都是高級用戶而且是很少的一部分，那沒辦法了，這個時候必須后端配合。畢竟前端能做到的還是有限的。
讀到這里，也許你會疑惑。那不需要測試工程師嗎？誰來部署上線？頁面誰來生成？
1.你開發的時候其實也自測了。如果產品沒有要求嚴格的話，基本上都是自測后，交給產品再測試體驗。OK了就可以上線了。
2.因為已經有一個OLPM平台了，當然自己動手豐衣足食了。沒錯，就是前端開發人員來進行部署上線的。
3.因為前端開發做出來的只是一個模板，頁面當然是由產品或者運營同學自己去生成了。
4.OLPM的工作流程是怎樣的？
需求文檔------> 設計師出設計稿 ------> 前端開發(這過程必定是大量的溝通) ------>自測、他測 ------> 部署上線 ------> 手動生成頁面
前端在開發的時候注意，因為需要接入各種平台，所以注意提前申請好各種權限與ID，不然會拖慢你的開發速度。
待續。。。。。