CMS Next

從 CMS 開始出發，在這領域上確實是發現不少的可能，CMS 核心在於內容管理，說穿了也就是如何幫助用戶把數據轉化為可見的東西並產生價值，數據來源可能是用戶創造，也可能是引入其他的數據來源，核心就在於如何把價值最大化。

一切從前端開始，最初這套 CMS 目標是解決前端人力資源問題，頁面中所有的東西需要由前端來將數據與設計結合展示給用戶，因此開發出很多的模塊，模塊把業務邏輯成載於其中，並且定義出標準數據源規範來對接各種不同的數據；確實有效了解決人力資源問題，因此前端開始更專注於頁面使用體驗，如何把性能變更好、滑動更順暢、各種監控與業務流程跑順；如果沒定下標準，現在肯定還是在收需求、做需求，無法深入到商業更核心的點。

到今天體驗已經不再是問題，透過整體優化已經能做到 app 內 96% 平均 1 秒內用戶可操作，這概念就像是 96% 用戶訪問在偷喵隔壁走過來正妹的同時頁面已經可用，並且能在穩定性與滑動體驗的都能保持順暢，以上好的體驗當然還是靠 Weex 達到，並且端上各種黑科技支持；那麼解決完這塊後下一步是什麼？目前我們理出兩個方向需要來再深挖，第一是 CMS 能力下沈為框架，這套體系確實完整，但仍然無法快速支持不同類型業務拓展，CMS 設計再好也無法解決所有的問題，通用只能解決最大公約數，但製作內容的流程與效率取決於組織人員配置與職責，尤其在業務不確定並且快速發展的狀態；第二是介面個性化，過去在內容數據上做了各種不同個性化，介面上僅有少數透過 ABTest 或定向投放來做測試，確實在 ABTest 下我們知道不同類型用戶給予不同 UI 樣式能讓點擊、轉化有所提昇，但無法像 Bandit testing 的方式能夠讓 ABTest 同時動態調整分桶比例，讓效果不好的部份即時減少流量，確保每次調整都能保留好的部份。

介面個性化這事讓我想起當年在學校談的衍生設計，當數據已經有穩定的算法優化後如何讓這些數據自己找到最適合的 UI 給到適合的人，人貨場是新零售所談的實踐之一，每個人對這三個字的解讀也有所不同，就我自己來看人貨透過數據已經有算法在背後努力，場就是由 CMS 生成適配，初期可以由數據自動找到適合的模塊，中期可以再進一步找到對應模塊後把模塊內可展示的內容個性化，長期來看就是設計一套語言來根據數據找出適合的介面。

這步完成後 CMS 在其中所代表的就不再僅是前端效率提昇或設計師落規範的應用，而是商業、設計、開發共同協做的 framework，CMS 也不再僅是某個端的範疇，提供的是一套端到端的服務。

感覺很多事還想的不是很透，後續該好好疏理下...

以人為中心的管理模式

這陣子打算在團隊中引入敏捷開發，在推進過程中受到了些阻力，確實也是些不同的觀點值得參考，整件事背景源自於某個產品忽然人都被抽調走，由原本的 8 人剩下 2 人，試想原本 8 人的工作變成兩人來承接該怎麼辦？

先來看看原本 8 人的配置方式，每個功能指派給 1 個人負責，把整個系統拆成 8 大功能，好處是任何功能出錯了都可以立即找到對應的人，對於每個人都有長期可延續的事，並且也可以開始學習規劃自己的產品；看似非常棒，並且這模式也跑了 2 年之久，但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。

產品主從關係沒了，每個功能負責的人都認為自己是主，就像一場電影中每個人都不顧劇情一直搶鏡，其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來，可以想像觀眾的感受是如何，當然這也可能是種特色，但這種特色作為個長期的產品來看簡直無法想像，首先影片好不好看完全取決於角色，如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向，確可能造成因為人的能力不同，某些淺在重要功能就這樣被搞砸而造成走偏。

KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫，站在管理角度也很好打分，然而管理者放任這種發展就是對產品的不負責，變為以產品開發者為中心，好聽點叫由下而上的工作模式，實質造成產品發展與人強關連，並且產品功能間不互通，某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。

收回原本的問題，產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半，然後還是一樣各幹各的，頂多是出現重要緊急的事才會有合作的時候出來，產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責，由一個人來規劃產品，可以讓每個人盡量做相同方向的事，但優先級是以整個產品來思考而非單一功能，以用戶需求唯出發點而不是以功能該如何支持用戶。

每個產品需求新增的同時必須來思考如何刪除，尤其是容易跟業務掛勾上的產品，業務邏輯隨時在變，然而一個不小心可能產生大量歷史業務邏輯在系統中，長期下來就形成了技術債，嚴重的話就會變成系統重寫。

屁話一堆...簡單總結就是
 1. 產品的走向應該統一規劃，而不是依賴每個人負責一小部分，管理者必須把產品功能、開發流程疏理清楚
 2. 傾聽用戶的聲音，明確產品定位，業務邏輯必須抽離主架構中
 3. 上新功能前先想好如何刪除，確保產品核心功能不受影響

國泰世華銀行

國泰世華銀行 從我開始上班以來就幾乎是一直是最常用的選擇，也因為在趨勢時期更是因為公司長期與國泰世華銀行合作，因此在兌換外幣等服務上甚至免手續費，所以後來也慢慢把其他銀行結清掉，全部統一到一個銀行來，使用上也很方便順手。

但是我申辦的是 combo 卡（信用卡、悠遊卡、提款卡），因為這卡質不是很好，因此常常會有上面塑膠膜脫落，嚴重點讓卡片都有問題，因此需要換卡，過去大多時間待在台灣其實還算方便，但是現在只有少部分時間帶在台灣，因此換卡這事情變得格外麻煩，首先換卡需要先致電銀行客服幫你轉到卡片相關部門，在確認後你必須把卡片先寄回銀行指定的地址後新卡才會發放給你，新卡必須再去國泰世華銀行 ATM 開卡，開卡同時需要一個 4 位數開卡密碼，如果你不是在銀行分行開卡就必須找到上次開卡時候的4位數密碼。

問題來了，現在大多時間不在台灣，因此換卡只好直接去分行直接把卡片交回給分行櫃檯，等收到卡後再開卡，但是…把卡片交回前已明確告知我馬上就離開台灣沒辦法等到卡片送回來，並且下次回來就是過年前，因此卡片必須要可以用，不然過年就哭哭了，行員表示沒問題後就開始悲慘的開始…

2/6 晚上大約11點多到家後馬上衝去銀行開卡才知道需要開卡密碼，並且開卡密碼是什麼我根本不知道，並且銀行早已全關，隔天就開始過年肯定沒辦法到分行處理，在 ATM 旁開始查國泰世華銀行客服電話後找到 ”02–23831000”，連續打了兩次都馬上被接起，然後就沒聲音，回家後馬上改撥打 ”0800–818–001” 總算語音有接了，但是客服等候根本沒人接，也不知道還要排多久，等了兩次 10 多分鐘後最終放棄，隔天再試。隔天一早撥通後客服表示：「這開卡密碼如果要重設一定要本人到分行櫃檯，現在必須要等年後才可以處理」，FXXK!! 難道我必須要過這沒半毛錢的年？這將會是有生以來最難忘的年….

到這邊有幾個問題點： 1. 當時到分行換卡為什麼沒告知必須要有開卡密碼？ 2. ”02–23831000” 這客服電話壞了為什麼還要擺在網路上 3. ”0800–818–001” 這語音為什麼不能讓等候的人知道前面還有多少人在等？如果太多我就換個時間再撥打 4. 國泰世華銀行 不光 ATM UI 設計不良，網站也是原始人等級，各種訊息引導簡直爛到不行

後來因為太火大就寫信到客服，很開心的 6 天后電話回復了，告訴我兩件事： 1. 開卡問題只能重回分行辦理 2. 可以幫你先把卡片的預借現金功能開啟，讓你先有現金可以用

聽到這更火大了，原本只是知道我需要過一個窮苦的年，年後可以去分行解決，現在還可以預借現金，然後再來還利息就好，這樣銀行更賺錢 ^.<~* (啾咪)，神經病！客服還再三跟我說這方案很好，馬上就有現金可以用，解決我的問題，這真的有站在客戶的角度了思考該如何處理問題嗎？還是只站在銀行的角度處理？

現在滿腦子只有該如快速的結清戶頭，並且把以前的代扣快速轉移到其他戶頭，完全不在乎如何解決卡片問題，感謝客服、感謝分行重辦卡的櫃檯，對不起沒辦法幫貴公司賺錢，並且讓我過了這難忘的過年。

記帳

記帳是個好習慣，長期下來可以知道到底過去花了多少錢，未來有什麼改進空間，有了記錄才知道該從什麼地方開始節流，不僅是幫助自己也是幫助家人。

記帳最大的敵人就是懶惰，往往是懶惰殺死了記帳，就從懶惰這點看來最大的問題點就是工具，想想大學時代買了 MAC Money，還是從露天拍賣上買的，現在光想想就不可思議，當時遇到最大的問題就是必須在 MAC 上使用，外出也不太可能吃完馬上掏出 MAC 來記帳，每天晚上回家後開始記著回憶錄，雖然是很不堪的方式，但也確實讓我知道花在零食、飲料的花費有多少，一個月減少下來就多了 2k 左右，一年下來也省了不少，MAC Money 就這樣陪伴我到當兵結束。

後來買了第一隻 iPhone 開始使用了 cashbase，有效解決了要回家才可以寫回憶錄的問題，並且把MAC Money以前記錄過的一起匯入，並且還有 Web 版，讓我隨時隨地更新一些小到不行的流水帳，可以讓我在微薄的薪水上得到良好的控制，但馬上遇到下一個問題，cashbase 必須有網路才可以記帳，記帳後雖然有 Web 可以很清晰的查閱，但始終無法突破手機當下沒網路的點，在無法忍的狀況下開始了查詢新的方案，並由這次經驗知道符合我的記帳習慣軟體該具備什麼：

1. 簡單操作的介面，最好一打開就可以記
2. 手機上必須有 App，最好也有 Web 版
3. 可以建立支出、收入分類
4. 區分多個帳戶，每個帳戶必須支持獨立的貨幣
5. 可以導出過去記錄的數據，避免被這軟體綁架
6. App 絕對要支持沒網路下仍然可以正常運作，到有網路狀況下自動同步
7. 有報表、圖表
8. 可以搜尋、fliter 出過去的消費記錄
9. 預算功能，給自己每個月預算，當超過後能提醒，預算最好還能針對支出類別分別計算
10. 支持多國貨幣，並且能直接展示出 日/週/月/年 等消費（直接以匯率作為計算）

經過這一連串要求後最後選擇了挖財，Web/iOS/Android 都有 App，並且在支持以上功能，尤其在多國貨幣上真的幫上大忙，手邊常常有美、日、人民幣、港幣、台幣流動，能夠同時支持真的是非常方便，並且也把過去在 cashbase 記帳一併匯入，可以讓長年的累積不中斷，挖財 最大問題就是 90% 功能是不需要的，裡面為了深入分析你的花錢狀況甚至常常會要求你把銀行帳戶做綁定，或是信用卡，常常會推銷給你一些用不到的理財產品、基金、保險，這些確實讓人很頭大，但在我的需求基本用途上真的是幫了大忙。

時代不斷在演進，過去需要人工記帳的部份現在也讓我也新的想法，在杭州食衣住行 70% 以上都可以用支付寶，小到路邊攤，大到各種便利店、超市、高級餐廳都支持，所以一般出門也很少在帶錢包，支付寶上所有花費都已經幫你分類好，或許未來也不再需要記帳這行為也可以知道過去的消費習慣。

這邊簡單分享一下當前記帳的方式，其實就記住兩個要點：簡單、快速，這工具要讓你快進快出，最好可以不需要思考，因此在支出上主要分類為：

1. 禮物
2. 醫療/健康
3. 娛樂
   1. 一般娛樂
   2. 電影(因為太常看，長期下來也是不小的花費)
   3. 旅遊
4. 吃飯
5. 悠遊卡/各種電子儲值卡
6. 住家/生活繳費
   1. 一般住家、生活
   2. 手機電話費
   3. 電費
   4. 水費
   5. 瓦斯費
   6. 住家網路費
   7. 房租
7. 交通
   1. 一般交通
   2. 自行車(因為太常買自行車零件…因此需要獨立出來)
8. 服飾、搭配
9. 教育
10. 3C
11. 其他

其中幾個點特別重要

1. 吃飯、交通(Uber/機票/火車票)非常常用，因此可以建立出快速模版
2. 悠遊卡、儲值卡類，當已經儲值進去後的花費就千萬不要再另外記，不然記錄上會變得異常複雜（例如你儲值 100 然後用悠遊卡買了一杯 20 元飲料，是要記兩筆還是一筆？）
3. 銀行間轉帳最好也記下來，或是把悠遊卡/儲值卡類的也當作一間銀行來記錄

收入部分就是簡單記了，基本上就分三類”薪水、銀行、其他”，其中薪水不需要多說，銀行這分類是偶爾有比較大筆的利息收入等再記錄，基本上也可以省略，其他大概就像是超爽 der_撿到 100 塊，或是意外參加抽獎中獎類的，基本上就是這些。

f2e-interview

最近面試好多前端，就來寫下這面試的感覺吧，不得不說前端這領域相對其他領域還是個新的領域，百家爭鳴，不像後端一樣，幾乎已經在各觸最佳實踐（又或者我接觸還不夠深）。

框架

但就我自己的看法來看目前所有的框架，到最後還是圍繞著幾個點： 1. 架構是否足夠彈性、有結構、組件化 2. 學習成本 3. 活躍社區

我認為一個好的架構不是能夠讓你少寫多少行 code，而是更結構化的幫你快速切入，讓整個團隊協同開發同時能有個中心思想，別讓樓越蓋越歪。常在面試聽到我之前用 XXX 框架開發結果性能很差，現在換了 XXX 後變好快（考試都考 100 分了 ^.<~* 啾）。其實不管什麼框架，只要你能夠有時間重構一次幾乎都會比原來更快，很簡單的道理，當你熟悉當前的業務邏輯後當然可以比起剛開始設想的更加周全，各方面自然就好起來了。

但框架不是一切，更重要的是了解這框架的實際運作方式以及前端所在容器的特性，例如在 PC 瀏覽器、手機瀏覽器、webview、各種 webkit 抽象出來的容器…等，能夠完美跟容器結合的就是最好的框架，能夠摸透框架、容器運作原理就能夠寫出做完美的結構。當前也是有許多優秀的框架，如 Reactjs, Angularjs, polymer, vuejs, … 等，每個框架設計上自然有他適合的場景，也會有他不適合的場景，能夠依照當前的需求做出最完美的配合自然是好框架。

近來如 Reactjs 發展出了 React Native，阿里造的 WEEX，也是框架上的另一種突破，讓除了熟知的 web 容器外更延伸到了 Native 重新打造一個容器，但說這個真的有未來市場在這我還是保持懷疑的態度，回想起幾年前的手機瀏覽器也是如此的不堪，近來硬體運算能力越來越強，手機瀏覽器的問題也少了。你說 React Native 是用 Native 渲染，速度很快，比起 Web 體驗好很多，接近 Native 體驗，就我目前看來都是個階段性產物，最終還是會回歸到 Web。但你說這些嘗試都沒意義嗎？其實不盡然，沒有這些創新的演進還是無法解決當前手機瀏覽器內的效能不佳問題。

專案管理、開發、測試、發佈

專案管理這邊應該指的是如何管理你的 source code，很多人或許會說直接用 git 不就好了，git 確實解決了本地開發、團隊協同開發上的問題，但在多人開發同時該如何用 git 控制好品質才是這根本問題，團隊人多，每個人的開發習慣也不同，是否在 pre-commit 進行 lint 就能夠把持？pre-commit 要跑的 lint 該如何即時同步？是否有 CI 機制保障穩定性？是不是該每個需求都切分支出來開發？是否養成送 PR 的好習慣？任何小改變該如何同步給所有人？該如何自動化？git, svn, perforce 這些都是工具，幫助開發、多人協做的工具，絕對命令行多會幾個考試就會考一百分。

管理好 source code 下一步就是該如何同步、自動化的本地開發環境，在這很多人會說用 gulp, grunt, npm, make … 等，但這又回到了工具問題，這些工具很棒，隨便 google 也可以知道很多 plugin，但我更想知道的其實是你如何用這些工具，做了哪些事情？JS 是否 lint, minify, 去除 debug 訊息…等？CSS 用什麼 preprocessor？進行了什麼處理？html 有沒有做什麼樣的處理？用了什麼模版引擎？本地模擬 API 還是統一的測試 server 模擬 API？每次 build 是如何管理版本？圖片是否壓縮？圖片以什麼方式壓縮？哪時候壓縮？…… 等等等的一堆事情，這其實才是這核心所在，絕對不是我用 gulp 管理本地環境一句化就結束。

測試應該是目前遇過最少有經驗的，10 個裡面大概有 8 個沒經驗 1 個瞎掰 1 個有簡單的經驗，這邊要特別感謝過去在趨勢有龐大又有經驗的測試陪伴著我成長，測試絕對是必要的，一個好的 RD 必須能完成三件事才算是優秀，開發完專案、高覆蓋率的測試、線上監控，能夠把視覺搞完美還原這頂多是 60 分，也就是一個入門程度，做到測試再加20，做到監控再加20。詳細測試還有很多細節就不再一一贅述，基本如果能做到 TDD…這我只能膜拜了，因為你做的事情應該跟業務已經脫節或產品週期很長。但坦白在我心中團隊中是不需要有 ”測試” 這角色，養成良好的寫測試習慣絕對有助於增加品質減少測試人力。

發佈這就又是另一門大問題，現在基本聽過的是 FTP 直接上傳 server，git/svn 直接傳，有轉職人員幫忙（好耳熟…閃開！讓專業的來！）等，其實比較想了解是整個出 build 的流程，是否用 build server 打包？打包完是人肉發還是自動發？出完 build 發上線後是如何運作？直接放上 CDN 做靜態資源還是透過模版引擎解析？

效能、兼容性

這應該是整體來說非常重要的一環，尤其在體驗上更是致命的重要，基本的 js/css/html 要 minify，減少請求數量，圖片要壓縮，icon 可以用 iconfont 或 image sprites，進階一點大概到圖片要針對不同環境載入不同壓縮品質、尺寸，打開頁面後有多少請求，總共多少 k，dom 數量如何最簡化並且控制數量，圖片不在畫面中的不要提前載入，適時使用 loader 來載入 script，該如何有效控制記憶體避免 app crash，長 list 該如何做到最好的效能，css3 的新需求要小心使用減少 render 層，cache 該如何有效應用，app 內的 webview 該如何有效利用 app 特性來 cache，預載 …等，這些東西講起來都很簡單，但就目前為止所有收到的履歷上沒有一個做到好，很多人會說這些我都知道都會，但是該如何讓大團隊也能運行起來就是能否從 junior 到 senior 的關鍵。

AMD, CMD, Commonjs 這也是我常問的一個問題，雖然也是很基礎，但我覺得蠻重要的，因為搞清楚著些組件化的方式對於整體架構上非常有幫助，在按需載入上也是重要的一環。

判斷在不同裝置、容器下做出最好的體驗，在 ie6 等較舊的瀏覽器該如何做最好的降級處理，使用哪一種寫法可以有效的兼容不同平台，用上最少的 hack，不斷使用 hack 方式只會造成越來越難以維護。

網路、安全

網路方面最重要就是跨域問題，問到很多人都回答用 jsonp 就好啦，但卻不知道 jsonp 實際上是如何運作，以及 CORS 在 http response header 該加上些什麼？http preflight 用途是什麼？200, 204, 301, 302, 400, 500, … 這些 error code 用途是什麼？哪些點可能有安全風險？該如何避免 XSS 攻擊…等。

open source

開源也是我常問的點，我相信喜歡參與開源專案的小孩不會變壞(誤，常參與開源的人大多有幾種狀況，喜歡分享，喜歡與人討論、協做，我認為這部分對於在企業內是非常加分的，分享不但可以知識沈澱還可以推廣給更多人，對於團隊長期來看是非常重要的要素，唯一要小心的就是怕把公司內部的資產也 open source 出去…

未來、新技術、設計

對於未來的眼光、敏銳度，關心 W3C 標準或更深入參與 W3C 標準定義，看到未來的技術走向並且能夠提前帶領團隊移動到這條軌道上。保持新技術的探索，就算不能參與也要保持觀望，別讓自己成為最後被通知的人，不然當你需要時永遠處於被動。對於設計、體驗要能夠感同身受，試想用戶使用的場景，不是一昧的把視覺搞、產品需求拿到就開始做，前端就是產品到用戶的最後一哩，你掌握著用戶看到這產品後的體驗，每個字大小、間距、行高或許你會比設計師更有感覺，API 慢了也要做點過場掩蓋掉，千萬別小看自己所在的這位置的重要性。

總結

剛好想到什麼就寫了什麼，簡單羅列一下，當然還有很多細節魔鬼在其中，這些是我做前端以來的一些簡單心得，也是小魯我認為身為前端該有的部分，想當年小魯我也是被老闆說了一句「你如果還想待在這家公司就轉前端吧，這邊沒有 iOS 的缺了」一個誤闖誤入，現在是相當感動當時這句話讓我更開拓新的一條路出來。

最後想說的就是…歡迎加入 天貓前端，看我們在 2015 雙11的 912 億人民幣背後做了多少準備，歡迎把履歷寄到 taicheng.htc@alibaba-inc.com