CodeFarmer 技術週報 #22 - 工作日誌：前端踩坑紀錄 x 敏捷開發課程筆記
分享上一期忘了提到在前端技術選型踩坑實際案例，另外也記錄一下今天上的敏捷開發 (Agile) 課程精華筆記
嗨嗨大家，歡迎閱讀第 22 期 CodeFarmer 技術週報。
又是不小心遲了一天的週報。最近幾天因為上週提到踩到技術選型的坑，不小心加了幾天班，詳情可參考上一篇文章：
這裡也分享下後來解決問題後記下的心得，想到上一篇的最後好像忘了補上我實際遇到什麼問題，就順便放在這期「水」一下，也同步補進上一篇的後記中。
然後剛好今天一整天上了公司關於敏捷開發相關的課程，雖然在課堂上沒做什麼筆記，就趁著記憶還鮮明來分享一些學到的思維記錄一下做個大雜燴，直接把這期週報變成一個工作日誌的概念。
前端 chart 套件選型踩坑紀錄
原本在開案前我也進行了一番 survey，但當初不夠了解 chart 套件 SVG 渲染與 Canvas 渲染的差異，也在一開始的釐清需求時漏掉其實需要支援巨量資料，因此一開始在簡單試了幾套的基本 demo 後，選用了甚至不在上述這張表上的 AG Charts，原因是因為美觀且功能豐富、文件齊全，且最重要的是剛好需求都對得上。
實際開發起來也真的算蠻順暢的，且 TypeScript 的型別定義上真的是比 ECharts 完善許多。
但實作到後期才發現因為只支援 Canvas 渲染，在做部份客製化需求 (toggle data point 等) 時其實不太方便，雖然最後仍然是找到一些 context API 完成了，但最棘手的效能問題卻仍然是硬傷。
在渲染十幾二十個折線圖、且每個 chart 約 7000 多筆的點資料時雖然 DOM nodes 因為 Canvas 渲染的關係不會飆升，但記憶體使用量卻會逐步升高直至瀏覽器 OOM 而 crash，嘗試過一些 React 優化手段後仍然體驗不佳，原本跟其他資深同事討論後也考慮要從後端改限制 query 點資料的 SQL 來做 workaround，但想想畢竟效能問題並非發生在後端這樣解實在也是下下策。
因此最後在一個神清氣爽的早上一口作氣把原本做完的各種功能都遷移變成了 ECharts，原因是因為在上次週報研究後發現原來 EChart 同時支援 SVG 渲染、Canvas 渲染的彈性，又原生支援開啟各種 downsamping 的 options，實際拿巨量資料測試後發現效能問題直接無痛解決了，甚至也實測了下開 SVG 渲染 (理論上因為 DOM nodes 增加會影響效能) 也是可以順暢操作網頁上其他功能，不愧是如此多星星數的開源套件。
另外因為我是使用 React 開發，看到 NPM 上也有人實作 echarts-for-react 可以無痛使用，但因為看 github 上已經四年多沒維護所以就只有參考他的原始碼自己另外實作。
總之算是因為沒有全盤考量後就開發而踩了大坑，也只能摸摸鼻子多加幾天班解決，畢竟工作專案還是不能得過且過，以免交出去的品質不佳仍要有後續的更多溝通成本，還不如一勞永逸實在些。
敏捷開發課程筆記
身為一位在軟體業打滾多年的老碼農如我來說，也經歷過各種不同的開發模式像是敏捷、瀑布流、甚至是「隕石式開發」也是家常便飯，其中應用的場景有全新產品的 3~6 人小團隊、全新產品的 20 人團隊、大型產品的 feature team 需求迭代等等，但倒是從來沒上過一門正規的相關課程，因此也算是一種全新體驗。
聽講課的 Agile Coach 說理想上敏捷開發 (Agile) 是一門為期 3 天的課程，但因為不太可能找不同團隊的所有新人都花這麼多天來上課，所以濃縮成基本版在 1 天內上完，涵蓋的範圍大概從敏捷的歷史跟精神、Scrum 的 353 運行方式以及兩個有趣的小活動組合而成。
以下因為我也不是這方面的專家，就簡單用條列的方式列出一些覺得蠻不錯的精華筆記：
敏捷 (Agile) 是一種思維，Scrum 是其中一種實踐敏捷開發的做法，且算是市場上比較主流的做法，其他比較有名的還有像是 Kanban。
實際理解敏捷理論前先分組玩了 4 輪的 Agile Ball Flow Game (實際運作可參考這個影片)，簡單說就是 10 個人要互相討論如何把 1 顆球傳到不同人手中，且盡可能傳更多顆球。是一個拿來快速模擬一群人面對不熟悉的需求時，從討論、brainstorming 到逐步改善流程、提升產能到達成一開始聽到需求時無法想像的產出的遊戲。
關於敏捷 vs 瀑布流 (waterfall)
想像有兩種光譜極端值的需求種類：
第一種：需求明確、例行公事 (不管怎麼討論結論都差不多)、或沒辦法只做一半請 stakeholders review 的專案
第二種：需求模糊，stakeholders 也不確定最後需要的是什麼樣的軟體，過程中會需要更多探索與因應市場快速變化去迭代需求
不需為敏捷而敏捷，敏捷與 waterfall 兩者其實都有其適合的應用場景。對應到上面的兩種需求，waterfall 用在第一種、敏捷用在第二種可能更適合。
敏捷沒有比 waterfall 快，但能避免東西最後做出來做歪，是一種面對未知且可變需求時，相對比較適合的精神與方法論：
參考上圖，假如今天要來做一個專案，最終目標可能是 A、B、C 三種，時程長度是箭頭的長度。
如果一開始就確定目標是要做成像 B 的樣子都不會變，理論上兩點最短距離是直線，用 waterfall 幹就完事了。
但如果目標像藍箭頭的方向一樣，一開始 stakeholders 跟你說他想做的像 A，過幾週後因為市場商業需求變動需要多一些 C，偏來偏去最後結果做成 B 就成功 release 了。
如果只看開始、結束會發現 waterfall 比敏捷還快上不少，但也可能只是剛好歪打正著，有可能最後做了半年後發現其實應該做的像 C，那 waterfall 的走法就只能打掉重練了。
Scrum 的 353 運作方式：
3 個 role：Product Owner (PO)、Scrum Master (SM)、Developers (Devs)
5 個會議：Product Backlog Refinement (PBR)、Planning、Daily、Review、Retrospective
3 個產出物 (Artifacts)：Product Backlogs、Spring Backlogs、Product Increments
實際玩 Lego4scrum 遊戲，用樂高積木蓋模擬城市的方式快速體驗小組如何依照 3 種不同角色做分工，並實際運作每個 sprint 週期的 5 個會議。
以前沒聽過 PBR 這個會議，在實際類 scrum 的開發流程中也很少跑過這樣的會議，看起來是因為有一部份的精神被融進了 planning 中，簡單說就是拿來做 epic 拆成 user stories、估算 story points 的會議，讓團隊成員能充分理解專案需求與目標而達成共識。
以前一直聽過 Scrum Master 這個詞，但一直不知道是做什麼的，因為過往的團隊中不曾出現過這樣的角色。覺得課程中的比喻很生動，如果以划龍舟這件事來比喻的話，船尾的舵手就是 PO 負責去釐清產品需求跟願景與 stakeholders 們的期待、船首的鼓手就是 SM 負責關照每位在划槳的 Devs 士氣如何、怎樣可以協助他們排除困難與做得更快。
小結
以上就是上完課後覺得跟原本認知比較不同而有所收穫的部份，雖然實際聽完了許多理論、背景甚至是傳說中的 Scrum Guide、敏捷宣言等等各種框架與方法論後，總覺得真的是理想很豐滿、現實很骨感，在各種不同團隊規模、產品規模、產品領域與市場變動性等等這些脈絡不同的狀況下，實際運作怎樣的開發模式更適合團隊才是比較重要的，但能借用其中的一些精神與方法漸進嘗試也算是一種比較務實的方式。
就像 Agile Coach 提到一個比喻也蠻精闢：「有一個詞叫做素食恐怖主義者，就類似非常激進地倡導大家要吃素救救地球環境不然世界就要毀滅的一群人。假如今天要說服一個大魚大肉的人可以吃素，對方也願意讓步說那我每天禮拜一晚餐吃素，此時素食恐怖主義者會說：『不行！你這樣不是在吃素！』」
另外也分享以前看到一篇 PJCHENder 大討論關於敏捷開發的一個心得文 (連結)，對這個議題有興趣的讀者也值得一讀。
以上就是這期週報的所有內容了。若內容有什麼問題與討論也都歡迎透過以下管道與我交流，或直接留言與回覆這封電子信我也能收到：
Email：codefarmer.tw@gmail.com