規劃不一樣的 WordPress 網站 – Tenten的方式
從我們收到客戶的需求單的時候，我們就必須做前面的溝通來了解客戶的預算、想法、專案進行時間，去評估這個專案的執行難易度，才能安排我們後期以及整個季的 Forecast。 排除所有的前置溝通後，我們會依照客戶的種類，以及規模，去採取不同的執行方式。
網站的製作不外乎就是這幾個步驟：
- 規劃
- 設計
- 前端
- 後端
- 部署
- 行銷
我們的工作流程
我們在設計發想的流程中會安插好一位工程師來確認有沒有什麼方式可以幫助設計在發想的時候提供解決方式，例如說遇到 Menu 因為東西太多，不太清楚可以有哪些方式解決的同時，工程師可以從他的角度去提供設計更多可處理或執行的想法。
那同時也會讓設計師了解更多 coding 的概念，提高雙方的執行效率以及工作默契，一個很好的例子就是說 BEM Naming 的處理方式，這不止讓前端知道如何命名自己的 code 好讓她自己好維護之外，我們還會希望設計在幫我們設計 component 的時候就可以幫我們想好 element 以及 modifier 的使用情況。
In Trust we believe
我們都一直相信著，客戶並不是這個行業的專業，所以大部分他們想看到的東西都是擬真度八成以上的東西, 而我們也想要一開始的時候提供一個很好的體驗以及非常 impressive 的網站。 信任會間接的影響我們的溝通。而好的溝通等於是好的開始，為什麼？因為溝通幾乎貫穿了每個製作鍊，例如說，設計師會希望可以直接跟客戶溝通，了解更多在專案上的資訊以及需求，而設計師也會希望可以直接跟工程師溝通，這樣才能知道程式大概能製作到什麼樣的程度，會遇到什麼樣的困難，相對的，工程師也可以分享一些製作經驗、最新的技術、動態效果等分享給設計一些不錯的靈感。
所以，溝通非常重要。
設計與前端的結合
設計往往不知道前端可以做到什麼樣的程度，而前端也往往不知道設計在想什麼，為什麼要搞成這樣的設計，實在令人懊惱。 所以中間我們除了安插工程師在設計階段之外，我們也會依賴許多不一樣的工具，以及我對設計的要求。
除了活動性官網跟小網站（大概 7-10 頁以下）之外，一般需要後續維護或修改的網站都會滿龐大的。這時我就會從前端的角度去要求設計師提供 Style Guide 跟 Wireframe 出來，Style Guide 對雙方都有好處，以設計師來說，他更能統一以及了解透過物件要解決什麼樣的問題之外，也避免視覺上混亂的解決方式。而對工程師來說，也不用面對每個頁面都有不一樣的設計而困擾，以 DRY 的方式開發，也方便以後若要增加頁面，可以更快速。
常見問題
那溝通會常見到什麼樣的問題？
這是從我PM的角度，我常常遇到前端與設計合作上會發生的問題
1.為什麼設計師做出來的設計會跟工程師開發的頁面有差別？ 2.因資料改變所以設計跟程式都要改 3.私下解決設計師未提供的設計
開發
我們前端開發的方式基本上有分兩種，一種是實驗型的 (新創產品)，另外一種是穩定型 (品牌客戶/ 上市公司)。多數我們的穩定型就走安全牌，目前我們的客戶都是以大型企業或是跨國品牌導向的公司，一個網站可以遇到非常多不一樣的族群，所以我們在開發的時候並沒有辦法像我們實驗型的那樣可以使用最新技術，例如 React、Vue、Angular 等技術，會擔心客戶無法自己維護，另一方面也是因為一般形象官網也用不到這些技術。
我們的最基本的開發方式是使用引擎模板，搭配 Gulp 自動化來解決需求。 引擎模板的好處是好維護，再加上 Gulp 自動化來轉譯 CSS 跟 JS。同時加上開發時候的 Browsersync 等，都可以讓我們在執行上非常有效率。最後，因為自己也會一些程式，就會在 Gulp 的流程中加入可以自動打包的，讓每次前端做好修改時自動打包，就可以直接寄出給客戶了。 而另外一種方式，是採用最新的技術去研究以及開發網站，這通常只會用在我們自己的產品上，或者評估客戶有額外這樣的需求外。很好的例子就是我們開發中的產品（田田蔬果），這個網站大概是用 VUE2 前端框架配 NUXTJS 去處理 server-side render，在這中間，我們必須維護這個網站的資料，所以請後端在購物後台上製作 API，讓前端可以將後台的資料丟出來。
只是，這樣的處理並沒有比較快，所以要這麼做的時候，請務必考慮清楚再入坑。
客戶在不同的專案有不同的需求，有些可能只需要改改文字，但有些可能要包含購物車、金流、以及其他更多細節。所以後台沒有所謂的最好，只有最適合的。
而我們在一般專案以及官網中，我們最常用到的是 WordPress。
大家再聽到 WordPress 的時候，可能會誤解說我們是不是用套版快速製作？我們並不是，會選擇 WordPress 的原因是因為我們認為後台 UX 跟 UI 是個非常重要的東西，若沒有處理好的話，哪怕你有個很棒的後台，客戶不會使用也是徒勞無功。而 WordPress 的介面可以很容易客製化，又對前端非常容易上手，基本上不太需要透過 MVC 架構即可製作出一個好用的後台出來。
我今天想要分享 roots.io 的開發流程，它包含了 3 個工具，分別為：
- Sage
- Bedrock
- Trellis
Sage 是一個 WordPress 的 Theme，裡面包含了許多現代前端開發者所需要的流程，例如 Sass，Gulp，Bower 等。有了這個懶人包，大概就可以很快上手，不用特別在為了 Theme 去做環境的處理。只是很可惜，因為我們的流程上我們還是會喜歡使用自己的方式，所以到最後並沒有使用這個 Theme，反而是使用一個叫 Timber Start Theme 去開發，Timber 裡面的引擎模板就是 Twig，而 Twig 是有點類似 Pug 的模板，所以在製作靜態頁面跟後台頁面的時候，大致上都可以無縫結合。
Bedrock 則是一個專案框架，他將 WordPress 原本的架構做了些修改，例如原本 wp-content 裡面的 themes，直接拉出來分為 web 跟 app，讓你的 theme 整個跟 WordPress 原生的徹底分開，這樣的好處可以強化安全性，而 Bedrock 的另一個好處是 Plugin 透過 Composer 安裝，環境則用 Dotenv 寫入，可以針對不一樣的開發環境做不一樣的設定。
最後，再透過 Trellis 去製作自動化的主機部署，主機部署是配合 Ansible 處理的，可以透過一個指令就部署到不一樣的主機，可以分為 Development, Staging, 跟 Production。我們也正是因為摸了 Trellis 後，才發現 Ansible 的強大之處，繼而去學 Python，將 Ansible 發揮在我們自己的公司裡面，目前已經導入為我們公司的流程之一。
WordPress 只是我們後台解決方案之一，我們也有使用 Laravel 開發Tenten專屬的 CMS。
我們也因為 NodeJS 的興起以及帶給我們前端工程師的方便，我們開始研究並使用 Headless CMS。
但不管在使用哪個後台的時候，請一定要加後台的設計評估進去，後台的好用不是工程師說了算，而是一般使用者都能很容易上手才是重點。
感言
最後，我想跟大家講的是，設計跟工程師是兩個非常不一樣的天賦，唯有溝通以及好工具可以讓兩個一起合作出好產品出來。
小編註：
_Tenten夥伴間一直是教學相長，一路走來互相切磋、彼此學習。 我們平時很認真的紀錄實驗學習心得、無論是技術性的，或是分享製作專案的經歷，請持續關注Tenten的部落格！那我們下次見囉 !