KKStream KH Intern 心得分享（中篇）
前言
這篇將會寫我在實習期間所做的工作，以及簡單提過所學到的技術，而我也會放上一些我在學習過程中所找過、看過的參考資料，如果你也想學這些東西的話也可以參考看看 XD
一樣會是輕鬆一點的語氣，以免跟現實的我落差太大（誤
蛇吃了紅寶石產下含硒的小黃瓜
這段主要是在講我在前篇所提到的，對兩個產品寫的 Automation Test 所使用的技術，包含 Python, Ruby, Selenium, Cucumber，而這個標題是我絞盡腦汁想把這四個東西弄在一起的美麗錯誤（誤
Automation Testing
先來講講什麼是自動化測試，這是我自己白話文的定義：
讓電腦模擬使用者的動作，藉以測試產品的所有功能皆正常
Testing 是一個產品很重要的一環，RD 在開發完一個 feature 之後，交給 SQA 測試「整個」產品。為什麼不是單獨測試那個 feature 呢？寫過程式就知道，有可能這個 feature 牽涉到很多地方 code 的改動，而這些 code 也有可能與其他 feature 有關，除非模組化做得很好，否則當一個新 feature 上架前是要對產品做全面的測試的。為了能快速地對整個產品進行測試，將過程自動化就顯得節省時間與人力成本。
而一個產品不可能所有功能都靠電腦自動化測試完成，一定有些地方需要人工（手動）測試，但我們今天的重點著重在自動化測試上。
CMS
剛開始實習時，第一個要進行測試的產品是 KDDI 的 VideoPass ，的 CMS 。
CMS ，內容管理系統，可以想像成 YouTube 的創作者工作室，藉由這個系統，我們可以自訂自己的頁面上要有哪些東西。不同於 YouTube，我們的 CMS 則是可以自訂整個產品的頁面上要有哪些東西。
引進 Jenkins
在一開始的時候，我都是手動去 run testing code 去測試，而在完成大部分的 test case 之後，為了讓測試的流程變成 routine 的工作，以及讓 SQA 可以輕鬆地去觸發測試，我們引進了 Jenkins。
Jenkins 提供了軟體開發的持續整合服務 (CI)，他可以將一些 routine 的工作，或是一些需要結合不同步驟、依序觸發不同程式來完成的工作，寫成一個 project，當需要觸發的時候只要按一個按鈕就可以完成。如果你熟悉批次檔或是 shell script 或是 makefile，大概就是那種感覺，只不過 Jenkins 更強大。甚至可以透過 webhook 的方式，使 Gitlab 在收到 push event 的時候觸發工作。
流程
整套測試的流程為：
- RD 開發完 feature
- RD 通知 SQA
- SQA 觸發 Jenkins 進行測試
如果套上 Git flow 跟 Gitlab CI 就會變成：
- RD push 新的 feature 上 remote (Gitlab)
- Gitlab CI 觸發 Jenkins 的 webhook 並做自動化測試
- 測試完成後若是有達標準，再 merge 回 develop branch 或是 release 到 master branch
在這裡， feature 的開發與 SQA 的測試 code 是一起完成的（甚至 SQA 要先產生測試 code，這就是 TDD），而因為有了 Jenkins 與 Gitlab CI 的幫助，SQA 幾乎就只要專心在寫測試 code 上
Ruby with Selenium and Cucumber
在 CMS 的產品測試上，因為前輩是用 Ruby 撰寫的，所以我就延續使用這項技術。
Cucumber 是一套條列測試步驟的套件，通常會與 Selenium 結合實作各項測試步驟。在這裡，我們是根據不同的 page 區分每個 feature (Page Object Pattern) ，每個 feature 檔包含三個部分： Feature, Scenario 以及 Steps。
Feature: Video player
一個 feature 裡面包含多個 scenario （情境），每個 scenario 代表使用者面臨的情境，比如說我點進一個播放清單並且播放一部影片，這樣就是一個 scenario。
Scenario: As a user, I want to watch a video in a playlist
而一個 scenario 裡面則包含多個 step （步驟），我們將一個 scenario 拆分成很多個步驟，而這些步驟都是模擬人類的行為。以上述的 scenario 為例，我們可以拆成：
- 使用帳號
user登入 - 點擊播放清單 A
- 點擊影片 a
而為了確認步驟有沒有成功，我們將會插入一些驗證的步驟：
- 使用帳號
user登入 - 確認登入成功
- 確認播放清單 A 存在
- 點擊播放清單 A
- 確認進入播放清單 A
- 確認影片 a 存在於播放清單 A
- 點擊影片 a
- 確認影片 a 有在播放
而這些 steps 則會在 steps 的目錄內用 selenium 的語法撰寫。
撰寫 Automation 的流程大概就是這樣，如果對詳細的技術有興趣的話可以參考這篇之前的實習生寫得超棒的文章，在這裡我就不多贅述了。
跟馬叔叔一起搖滾學吉他
在 OTT 市場之中，聊天機器人是很常見的一個服務，我們同樣也獲得了這個機會 — 與馬叔叔合作推出的「影音教材販售聊天機器人」服務。
有看過馬叔叔的人一定知道，他是位以吉他、烏克麗麗教學影片聞名的 YouTuber，因此這個 chatbot 所販售的也是他的影音教材。
而會選擇 Facebook messenger chatbot 這個平台，也是因為馬叔叔最大的粉絲來源都是在 Facebook。
在這個產品所做的 Automation，是由 Python 撰寫，所使用的 Framework 為 Behave （相對於 Ruby 的 Cucumber ）與 Selenium，但撰寫的方式與 Ruby 差不多。
參考資料
- Ruby 官方手冊
- Cucumber 官方手冊
- Selenium GitHub
- Behave 官方手冊
- Selenium with Python
- 萬能的 Stack Overflow
延伸閱讀
Facebook 打造跨平台 APP 的利器：React Native
也許跨平台開發者的元老們最先聽過的是 Cordova，但身為一個處在學界沙漠中的學生，在枯燥乏味的眾多課程之中讓我遇見曙光的則是這套神器 — React Native。那年我大三，在修習張天豪老師所開設的「使用者介面設計與開發」課程中，知道了這套工具，那時候就覺得「太神啦！」，但礙於如果要一起開發 iOS 平台則必須要有一台 Mac，窮學生如我只好投向 Android Studio 的懷抱。
在軟體公司工作 or 實習的好處就是，幾乎所有公司的標配都是一台高效能筆電，而 KKStream 更是不吝嗇的每人配備一台 Macbook（實習生也有真的挺讓人驚艷），而剛好也有這個機會讓我相繼跟兩位大神 Eddie Hsu 與 Arthas Tseng 學習這套 framework。（關於一些其他跨平台的 framework 可以參考延伸閱讀）
React Native 簡單來說就是「用 JavaScript 寫 Native APP」（咦？JavaScript 這名字好像快不能用了 QQ），你沒看錯，不是 Web APP 也不是 Hybrid APP，而是 Native APP。剛開始學的時候我以為它不過就是一套 compiler，將 JavaScript code 編譯成 native code，但事實上我錯了。React Native 的概念比較接近「用 JavaScript 控制 native」，透過一個很神奇的東西 — RCTBridge 去讓 JS 跟 native 溝通。這樣一來，就算 React Native 提供的 API 或 component 沒有你想要達成的功能，你也可以進到 native code 裡面去寫你自己的 component。而其實對於初學者或是沒有很複雜的產品來說， React Native 提供的包山包海的 API 已經堪用，更何況還有廣大的社群支援，在網路上幾乎都能找到你要的功能（當然如果你不滿意人家寫的也可以自己刻一個）。
React Native 的核心理念是 “ learn once, write everywhere “ ，很多人會誤以為是 “ write once, run everywhere “，的確對於兩套系統 (Android, iOS) 都有的 components 會讓人有只要寫一份 code 的感覺，不過一但產品的規模開始擴大，會需要拆開的部分也會越來越多。
而要如何開始撰寫呢？你可以參考官方手冊的 Getting started，裡面將會手把手的帶領你進入 React Native 的世界。而關於這部分的技術文章太多了，我就不班門弄斧，在這邊釐清一些小問題：
- 我需要先會 ReactJS 才能寫 React Native 嗎？
基本上是的，因為在寫 React Native 就等於在寫 ReactJS，只是有些 tag 的語法上會不同，但他們的架構、生命週期基本上是一樣的。不過小弟是零基礎兩個一起學，也許你也可以嘗試看看！
2. 我需不需要會寫 native code？
在初期可以說是不用，而且若你的產品不複雜你有可能從頭到尾都不需要寫 native code，但我一直秉持著多學一點沒有壞處的想法，學學又何妨？XD 當你需要做底層優化的時候，native code 是你的好夥伴。
3. 我完全沒有前端或 APP 的基礎，我可以學 React Native 嗎？
我猜你會學得很痛苦（誤），因為對我來說從原本寫 web 的習慣轉換成這種以 component 為概念的開發方式花了不少的時間。不過也有可能你會因為當成一種全新的東西來學，而學得比其他人還好也說不定。反正，想學一個東西就學嘛 XD
那如果你開始學 React Native 之後，發現你並不喜歡這樣的框架，沒關係，你還有很多選擇（可以參考延伸閱讀），工具不會只有一種，也不會只有最好的一種，找到適合自己的才是真愛（？
參考資料
延伸閱讀
Google 的新世代 C 語言：Golang
終於我們要跨入後端的世界了。在選擇一項開發產品的技術時一定有它的理由，選擇 Golang 的其中一個理由非常強而有力：效能。在效能上，Golang 比現在當紅的許多（會用來開發 Web 的）語言如 PHP, JavaScript, Python 快上許多。至於為什麼會說是新世代的 C 語言呢？因為他的寫法實在跟 C 語言太像啦～
而提到 Golang，就不得不提到他強大的 goroutine，透過 goroutine 可以輕易的做到並行處理（concurrency），在這裡許多人會以為是平行處理（Parallelism），想了解不同之處可以參考延伸閱讀。以下是簡單的 goroutine 範例：
接下來講講 Golang 的缺點，有寫過 Golang 的人應該都知道，它的 error handling 很差，雖然每個 method 都可以丟一個 err 出來給你接，但是你卻要自己寫一堆 if else 去判斷一個個 err，相較之下， Java 或 PHP 的 try catch 就方便多了。再來就是，一直到 1.9 版才有官方的套件管理程式，在這之前都是非官方的開發者自己受不了寫了一個出來 XD
不過這些缺點應該是瑕不掩瑜，乾淨簡潔的程式碼，強型別讓你的 code 更安定，對於從 C 入門的開發者來說更是友善的語法，總而言之我寫 Golang 寫得還蠻舒服的（笑）
參考資料
延伸閱讀
後記
不知不覺距離上次的 KKStream KH Intern 心得分享（前篇） 過了兩個月了，就知道我有多會拖稿（欸
其實自動化測試、前後端框架有千百種，這篇也只有寫我在公司所學會的，如果這些都不是你想要的，不妨多注意一些科技新聞平台，或是一些 Facebook 社團，去探索自己想學的東西。
而其實在這段時間（開始實習到寫《前篇》前）除了上面這些技術外，我還學了許多東西的皮毛，包含 AWS 的各種服務、如何把 infrastructure 從頭架起來等等，但這些的應用跟我之後（現在）要做的事比較相關，所以我想留到後篇寫，大家可以期待一下 XD
如同一位我很崇拜的學長 Huli 所說：「工作果然是練功最快最有效率的方法，選對公司還有種一年經驗抵 N 年的感覺」（他是說兩年但我覺得抵了蠻多年的哈哈），我覺得我來到了一間很好的公司，一間勇於嘗試、也很有能力嘗試新技術的公司（也遇到了一位能容忍我任性地想學東學西的主管 XD）。
而旅程依舊會繼續，地球依然轉動，我也依然有許多需要學習的事物。
在後篇出現之前，我應該會寫一些關於機器學習、深度學習、強化學習的心得筆記，這些是我正在念的碩士所學習的領域。雖然這類文章很多，但還是希望能帶給一些人幫助，也順便檢視、複習自己所學，畢竟要知道自己有沒有真的學會一樣東西，講到別人聽得懂是最佳的驗證方式。希望我不會拖稿 XD
工商時間
最後的最後了 XD 不免俗的要來工商一下
很多認識我的人知道我在 KKStream（或更多人知道的 KKBOX）實習，跑來問我最近公司發生的事情，說實話我不知道，也是你們問了我、跟我說了外界怎麼說的我才知道這些事 XD（是不是我太邊緣 QAQ）
我只能說，對，我們公司正在經歷一個艱困的時期，也就是大家所說的「出走潮」，詳細原因外界跟內部都有很多說法，我也沒有去探究或證實。也許有人說的很難聽，但是對我來說，KKStream 依然是一間勇於嘗試，有許多創新想法，而且不斷在前進的好公司。而以實習生的角度來看，在這裡有很多很強的前輩，絕對是值得來的好公司。
話盡於此，如果你想加入我們，不論是被我前一篇所寫的環境（販賣機！？）所吸引，或是想挑戰各種不同新技術卻又不失能夠打造真的給數十萬甚至數百萬人使用的產品，又或是認同我們的理念想跟我們一起奮鬥，都歡迎前來挑戰：https://jobs.lever.co/kkstream/
我們密切合作的夥伴 KKTV 也同時在廣召人才：https://jobs.lever.co/kktv/
即便你是還未踏入社會的學子，想跟著一群大神一塊學習，也歡迎來應徵實習工程師
如果這篇文章有錯誤的地方，歡迎在留言指教 :)
