基於這專案不是開源，是公司專案，所以抱歉我就無法公開source code，本篇文章主要是紀錄過去一年的計畫和開發這個專案的經驗。
從得知要做這個專案的時候，覺得是一個挑戰，我不是指技術上，是我的睡眠時間上，因為我本身還必須維護和開發Web專案，雖然都是web base專案，但某程度我都必須再寫一套，無法很完美的做到共用，更何況web app已經上線了2年，用戶也不少。
抱怨完畢之後，來簡短的說明一下，這個專案粗略分成三個階段。
階段一
問題很多，無從下手嗎？我都會先設類似以上的表格，把一些前後關係的dependency想好。
首先我們必須知道這個專案的最低配置是什麼，尤其是當我們人手不足的時候；然後了解這專案的商業目標是什麼，這些基本東西都是專案確定設立的時候應該會有的東西，也是比較確定好的事情，知道這些事情以後，我們就來進入討論議題。
這一次要做的是webOS app開發，不知道什麼是webOS嗎，那就上網做一下功課。了解以下行業生態。以下是做一切討論之前，自己要先做功課的事情。
1，webOS是什麼？
就是一個開源系統，有自己的Content Store，目前幾乎都是LG smart TV系列內建的系統。
2，webOS的app可以怎麼做？
一般上電視平台都可以用原生或web base，既然我是web dev當然選擇後者，在我做這個專案的時候，基本上網路上的中英文資料都不多，但是最近發現github上面也有一些人很熱心的整理了一些電視web app的資料。參考網址：
https://github.com/vitalets/awesome-smart-tv#cross-platform-frameworks
3，電視機的app可以做到深入？
這問題就是，在一個web app設計者的傳統想法上，很常會想說直接把web複製到電視機上，但是你家的電腦和電視機的比，你家的電視機根本無法跑的動。
舉例，我一開始試驗的是webOS 2.0，一個簡單的slider，就卡住了。目前webOS已經到4.0，支援度已經好很多。
結論就是，電視機app，越簡單越好。
4，效能和限制。
我做的是一個會需要播放影片的app（播放影片的部分是另外一組同事做，我這裡主要是播放的接口和UI），所以一開始就必須要測試了以下的基本項目。
－測試播放效果
－設計了五六個畫面試跑，看一下哪一種比較順暢
－不斷的增加效果和功能，看一下差別在哪裡。
5，工具。
官方網站上，直接下載SDK安裝包，http://webostv.developer.lge.com/sdk/installation/
模擬器就罷了，直接用web跑吧，然後在跑在真機上。安裝完SDK之後，你應該可以在Terminal上跑指令。
參考網址： http://webostv.developer.lge.com/sdk/tools/using-webos-tv-cli/
如何測試demo app
以下測試demo app的菜單，
1，安裝完SDK，跑指令 ares-setup-device，註冊一個新 device。
2，如果你是測試LG電視機，主要要填寫的主要是IP 和 名字，其他的都是預設應該沒差。
－－－IP：打開你電視機的 開發者模式，在開發這模式上有IP顯示，註冊的device必須對應電視的IP
3，然後按照這個教學，做一個最陽春的 web app：http://webostv.developer.lge.com/develop/building-your-first-web-app-webos-tv/
4，然後安裝 ares-install –device （剛剛device的名字） com.example.sampleapp_0.0.1_all.ipk
噠噠，應該會看到電視機啟動了。
階段一的最後，我們必須要確定了基本的事項，然後進入第二階段的開發。
1，基本的app操作方式（flow）
2，開發方法學習完成。
3，app結構設計構想（這個沒細說，不過基本上等下會提到）
4，不可以做的事（例如很華麗的動畫，很複雜的畫面等等，呼叫API的限制，跨域等等）
階段二
經過了一番折騰，我把這個專案需要設計的區塊分成：
1，UI－官方有2套UI系統 enyojs 和 enactjs，但是因為風格和自家產品差太多，所以決定自己寫一套。
－－ React base
－－ storybook
Component都只接受數據，不處理數據，然而我這樣切分最後也有三十幾個模組。
2，container模板－也就是每個頁面的串連方式，串連來自API的數據，處理它，和其他不同模組傳來的資料的整合。
－－ i18n是自家做的json編譯
－－ 套用自己設計好的UI
－－ 處理一些商業邏輯
3，多語系系統－webOS app基本上是web app的移植，所以資料已經有了，只是太肥大。
－－ 只挑選有的翻譯，（是的，web上有很多已經沒有使用的翻譯，但是還在裡面的）
－－ 極簡化的提取，用一些npm套件的i18n工具很方便，功能很強大，但是因為太強大所以也很肥。基於效能限制，我們也捨棄了用套件。
4，API接口，API接口是獨立的一塊，他直接對Container。
－－ API接口可以使用Apollo graphql或redux store等其他方式，也就是我們不設API的攝取方法，方便日後切換（目前實作是redux，Apollo graphql只是測試過）
5，操作系統，就是你遙控器上的上下左右。
－－ LG smart tv 麻煩的地方是，它有滑鼠！你沒聽錯，它有一個假滑鼠，基本上他會觸發所有mouseevent。
－－ 官方API會提供你方法，告訴你目前是 滑鼠 還是 鍵盤模式，但是在我開發的時候，官方並沒有這個東西，那問題就大條了，當你一開電視，操作系統會按照你的模式，來切換瀏覽方法，但是一開機，如果你一直不切換的話，我就會處於undefined的狀態。
－－ 預設值可以解決嗎？不行，因為不管你預設user 一開始是 鍵盤模式 還是 滑鼠模式，都可能會是錯的。
－－ 反正也就是一個坑，直到最新一版的API，不需要切換，就可以get user 目前的電視操作模式。
6，DEV flow
－－ Web base 就是快，要設計一個SOP快速的deploy到主機上。
－－ 其實這事情相對簡單，只是在一開機的時候，做了一個switch，檢查以下般本和在線狀態，OK的話，就pass。
這樣的分工基本上就可以解決我剛剛提到的第二階段的問題，那一個環節出錯，基本上都可以馬上知道從哪裡下手，因為從一開始，我們的資料處理和提取都是分開的，所以首先判斷是資料出錯，還是操作出錯，還是邏輯出錯。舉例：
1，app首頁應該看到五個list，但是出現六個，那就是container出錯機會最大。
2，某個card的圖片怎麼都跑不出來，那就是component出錯
3，打開app的時候，語言出不來，那就是init 語系的時候出錯，那就是client entry point的時候出錯。
4，打開鍵盤，input沒有focus，那就是component和操作系統都可能出錯。
這樣做的另外一個好處是，我們可以獨立只開發某個環節，我們可以只針對API做優化，或者只針對dev flow優化，只要確保接口正確，其他部分操作都不會有太大問題。
而這個app當中比較知道標記的是，極可能減少props的傳遞，也儘量使用react functional components，細節可以參考 (Netflix UI Engineering)。基本的優化項目也有，圖片的解析度也是最重要的關鍵，圖片越大速度越慢（好像廢話），在web上可能不太明顯的變化，在電視上會很明顯。
最後一個點是，我們把react 換成 preact
階段三
到了階段三，基本上就和開發沒有多大的關係，主要都是執行和管理，從第一次submit app到真正審過花掉了大概大半年的時候，比我開發app的時間還久。
好在一開始的時候，就已經把debug的流程和方法想好，所以之後每次發現問題，我們都可以即時作出反饋和修正。
整個過程最大感觸時，在接觸過很多RD之後，有一些RD對與改變spec這事情很反感，我當然也是其中之一，但是只要你深入了解，你會理解為什麼？
那就是為何從階段一，我就很積極的參與和把一些事情考量進去，在實務上，我們很難遇到什麼東西的spec是不會改的（尤其是這種從無到有的階段），尤其web，是的尤其是web。
web和其他平台的生態有一個很大差異是，web沒有一個標準，不像ios或android，目前每個平台對於自家的app都有一定的規範和限制。但是web就是個多姿多彩的世界，吃一頓飯，有幾十種方式，最近FB社群上還出現，「我要吃飯，請問用左手還是用右手好？」的問題
而這一次的webOS app開發更是一個 不僅僅沒有規範還有一堆效能限制的時候，即使修改可能就是設計這個程式的關鍵。
而這個修改的靈活性，恰是持續性開發的重點所在，如果我們開發了一個無法修改的app，那麼它是如何做到升級和迭代呢？每次都重做一次嗎？
所以SPEC對我而言，只是商業需求，不是程式設計需求，我可以大膽的推測說，他們只管我們有沒有把功能做出來，是不管我們怎麼做的！
那對設計者而言，就是思考如何進行專案的同時，那些spec都在射程範圍之內就好。
