[心得] 2020JSDC 線上研討會

今天的 2020JSDC 因為疫情原因，改成線上研討會的方式進行，這次也感謝 ALPHA Camp 的部分贊助

本來打算用流水形式記錄這次研討會，但下半場的 TypeScript 十分精彩，會改為上下場各挑一場，重點紀錄描述心得。

開始前聊聊線上最大好處 …

1. 9點開始，可以起床盥洗，然後去 7–11 買個早餐，回來看影片，小遲到也不用擔心，可以快轉 1.25 倍跟上議程。
2. Gitter 聊天室內閒聊，不怕打擾到其他聽議程的人。
3. 更即時可以線上做共筆或筆記，不用擔心沒有座位或桌子。
4. 影片一周內可以重複觀看複習。

缺點也是相對的…

1. 如果不夠專心，很容易恍神打瞌睡 (望向剛吃飽的下午議程)。
2. 少了很多和大神交流免費顧問(?)的機會，下午場保哥有提到很多人現場討論 TS 導入的疑難雜症，這些就不會被收錄在直播中。
3. 少了很多和其他社群朋友及時討論或是想法分享的機會，會變成邊看議程邊 Message or Line 。

上半場『道場』

「道場」著重於系統性、原則性，主要脈絡以職崖發展，技能方向掌握， Web 應用技能掌握深度等議題進行探討，邀請各方資深開發工程師，資深技術主管進行經驗分享，透過前人的經驗，讓我們更能掌握未來的脈絡。

• Remote Team

目前疫情，越來越多人開始嘗試遠距辦公，但其實很多時候，各位都身處遠端環境。

以我目前公司為例

1. pm 在上海，營運在內湖，工程師在台北，需要三地遠距溝通、交流
2. 可以 WFH 時，也是遠距工作最典型場景
3. 臨時有產品問題，需要有人及時解決 (ops, backend, 各式大前端 app, web)
4. 疫情預演 … etc.

這些時候其實都使遠端工作。
TonyQ 分享很多把這些思考方式如何釐清。

比如說，我們公司很仰賴群組來讓遠端的團隊來討論，所以可能每次 Feature 或是營運活動都會有一個討論的群組。
我們討論時，「總機」的角色比較像是各 Team 主管，都是直接把問題丟到群組讓相關主管去找人。

因為多數時候都是文字討論，有很多慣用語或文字使用習慣，不同的文化背景或生長環境還是有所差異，所以溝通時會減少簡稱、縮寫、標點符號也會合理使用( 台灣很多人使用 IM 是用空白當作標點符號)。

最後，減少一對一私下溝通公事。

twitter 上面看到的 因為沒有和本人確認可以貼先拿掉人名

順帶一提，補充一個之前實習的經驗與特別的文化。
當時也是全遠端環境，但每一週有一個 「5分鐘分享你這一周非工作上有趣的事」，
雖然沒有在同個辦公室，但確實比工作到現在還要容易了解工作夥伴的個性或風格，蠻有趣的文化。

最後，這個議程沒有講到個人獨立接案的遠距工作形式，對這方面有興趣可能要參考其他資料。

下半場『術場』

「術場」著重於功能性、技術性，主要脈絡以技術深度，技術架構方向為主，適合於對於 Web 已具備 Web 開發經驗，並瞭解 JavaScript 生態與框架名詞等開發人員，資深工程師或團隊技術主管，本次將以 JavaScript 在不同應用情境，以及開發經驗分享深入瞭解 JavaScript 技術演進。

• 技術座談 — 現代專案，該不該導入 TypeScript ？

最開始接觸前端，我第一個學習到的框架就是 Angular2 + ，當時框架就是 TypeScript + Rx.js 起手。
目前轉以 React.js 為主要領域，或許可以相對中立的來分享我看的到優缺點與座談心得。

講者簡介：

保哥主要是在台灣，本身公司接案之外，也為各式中大型應用程式提供技術顧問需求，通常是會給出比較全套的解決方案與工程師培訓，在這樣的背景下去做技術選型。

Jeremy 大神也是在中文技術社團很早開始推廣 React.js 的傳道者，工作環境是在有 50000+ 新創公司的美國，在各式新創公司尋求開拓市場或是驗證產品的背景下，需要的是足夠靈活的變化與相對較高的技術實力才有機會在矽谷佔下一席之地。

為什麼使用 TS ?

1. 使用 TS 可以減少打錯字這類的 低級錯誤
2. 強調有一定規範的程式碼，按圖(interface)施工
3. 強調事先規劃與設計，讓團隊有一定程度的規範，在團隊在多人或是快速開發也可以保持一定程度的 code base 整潔。
4. DOCS : code 即文件 (永遠會更新的文件)，有完整型別的 code 提供很多資訊減少開發者與文件同步的需求。
5. 對於長時間維護的專案，提供 code trace 的資訊 ( 如: 物件傳入 function 處理)。
6. tooling : 透過和開發工具整合，提高開發效率 (並非全部工具或框架都可以享受)
7. 又夯又潮

為什麼不使用 TS ?

1. 使用 TS 並不能完全確保不會出錯 (non-soundness)
2. 限制很多寫作程式碼的技巧 (或是要花費至少多 50% 的時間完成)
3. ts 還是需要維護宣告檔 (對於開發套件的開發者)
4. ts 對複雜型別檢測總是有缺點，或是會失敗
5. 開發時間明顯變長 30~50% (甚至 100%)
6. 會需要針對 ts 檢測寫特殊語法或規則 (不過總量隨語言進化越來越少)
7. 複雜型別造成視覺雜訊，使可閱讀性降低

大亂鬥

1. 不使用 TS 學習 functional programming 或是其他語言(Haskell、Rust)的成本會不會更高?
2. TS 可以是漸進，不一定要 ALL IN
3. 強行別和寫測試完全是兩件事，不要放一起說

小總結:

這次 2020JSDC 彈性變大，然後內容的豐富度也變多，
小可惜是「講師」還是要在現場，否則本來以為遠距形式，講師應該能更自由，有更多與外國大神交流的機會。

大家也理性看待最後一場座談，先思考兩位大神背景，自然會很理解為什麼各自立場會如此分明。
技術選用是靈活的，更需要考量不同公司的業務場景，並沒有對錯，只有最合適。