現在做的web shop隻有一套代碼，裡面是一些generic的邏輯，不能出現任何Nike Adi之類的寫死。目前啟動web shop的執行個體，具體是for Nike 還是Adi，通過啟動時傳入的參數指定。當時我拍腦袋說的是通過指令行，當時你問能不能用url，我說也可以。
但是現在的代碼裡，還是分别為Nike 和Adi各自做了一套UI啊。想一下将來假設CSO的同僚為了突出demo效果，想同時開10個web shop，那麼除了現在做好的Nike和Adi外，我們豈不是得複制粘貼8次？
想一下比如要遵循QDPR之類的規範，demo時不能出現真實客戶名字，而是用ABCDEFGHIJ你做了10個 XX.vue, 豈不是每一個.vue檔案進去後都要手動把真實客戶名字改成ABCDEFGHIJ？
一個best practice：盡量把不變的東西抽象出來，固化到代碼裡，把易變的東西抽取出來，放到配置檔案裡。最理想的結果就是：無論老大們的需求怎麼變，developer隻需要修改配置檔案即可應對，不需要修改代碼，也不需要重新編譯程式。
你現在這種為每個site做一個.Vue的做法，應對現在的demo我覺得也ok，隻是我擔心将來demo需要展示的web shop數量超過3個後，每次需求改動都會引入一些額外的本來可以通過更好的程式設計技巧去避免的工作量。
現在adi這個web shop ： 支援的這些字段是寫死的。
理想的情況是下圖右邊，你用#3 這個API詢問背景，adi支援哪些字段？然後背景告訴你，你根據結果動态繪制vue頁面。
如果覺得用vue實作這種動态繪制效果有難度，可以先按照現在這種程式設計方式做。但是缺點以前郵件提到過了，後期随着需求變動可能會帶來一些體力活。
