Dcard 讀書會如何進行？
在 Dcard 每個團隊會各自舉辦讀書會，分享近期的新知，當然開發團隊也不例外。事不宜遲，來看看 Dcard 的工程讀書會都在做什麼吧！
為什麼 Dcard 需要讀書會
在快速變化的環境下，不論在哪個團隊都會需要吸取新技術，持續優化、迭代產品，也避免被淘汰。
另外，舉辦讀書會也提供遇到技術困境的夥伴一個能夠定期討論的場合，除了能碰撞出新的解法外，也讓夥伴們能同步其他專案團隊進行的專案。透過讀書會，夥伴們能夠有機會融合彼此的專業，即便在同一個 function team，每個人所專精、有興趣的領域仍會有不同，這也讓讀書會成為分享自己專長、互相學習的場所。
讀書會的形式
在形式上，讀書會並不會有硬性的規定，因為讀書會的主要目的除了迭代新技術，也是為了促進內部分享；因此，分享的內容也會根據不同團隊或不同主題內容而有些微的差異。通常在讀書會前，都會先請一位夥伴調查相關內容，整理成一份簡報或文件，並在讀書會上分享，和其他夥伴討論、激盪出新靈感。
我們期待夥伴們在讀書會前，事先準備好完整的分享內容，把握每場讀書會的時間，讓夥伴們不論是關於近期遇到的困境，還是新的技術能否應用到近期的專案，都能有充分的討論。同時我們也期望夥伴們能在讀書會主動拋出問題，激發一些新的觀點，累積更多想法，在未來也許能幫助團隊更順暢的開發產品！
接著，就來談談在 Dcard 常見的各種讀書會形式
書籍分享
提到讀書會，也許腦袋中第一個浮現的會是大家一起討論一本書的內容。在 Dcard，只要是夥伴有興趣的技術或是書籍，就有可能成為讀書會的討論主題！團隊也會根據需要用到的技術需求，選擇適合的書籍，在讀書會研究如何把技術運用到專案上。
夥伴們會挑選書中章節，在讀書會時輪流分享學到的知識以及讀後感想，並思考是否曾應用在專案上，將書中學到的與工作遇到的難題結合，碰撞出更好的解法！
近期 ML 夥伴另外開了讀書會，一起研究 Clean Architecture 這本書。夥伴會先分享書中提供的原則，並思考現有專案是否符合這些原則或是 python standard，並不斷反思自己的程式、持續演進系統架構；此外我們也會嘗試把書中概念套用到新專案上，切分專案的業務邏輯與實作細節，讓後續開發時可以更彈性的切換實作！
以書籍作為讀書會的主題，其實準備的時間門檻較高，因此除了研究技術書籍，我們也會分享近期 Conference / Meetup 的內容，或是直接以近期專案遇到的問題作為討論的主題。
Conference
每個領域知名的 conference 並不多，開發團隊每年都會關注 conference 的舉行，迭代新的技術，我們常關注的 conference 有：
- Machine Learning： www、Recsys、SigIR
- Data Infrastructure：apply()、data@scale、spark + AI summit、Airflow summit, …
- Android：Google I/O
- iOS：WWDC、iOS Conf SG
因為新技術不斷推陳出新，開發團隊必須持續關注新推出的技術，才能持續的保持在優勢當中。
其實參與一場 Conference 或 Meetup 所帶來的成效，並不會讓個人和團隊在一夕之間就有翻倍的成長，但有助於夥伴吸取靈感，參考其他團隊的做法，在未來專案上就會有更多的刺激。這些成長更多是淺移默化的，也許不會直接體現在工作上，但在思考層面肯定是有幫助的。
我們通常會特別研究 Conference 提供的官方素材，就 Google I/O 而言，在 Conference 中除了發表新技術，也會針對網路上素材及教學資源較少的主題提供官方教材；Android 團隊在 Conference 結束後，會各自負責會議中自己有興趣的主題，再繼續做研究。疫情期間有些 conference，像是之前參與過的 www，由實體轉為線上舉辦，當時的 ML 團隊就一起待在會議室裡 2、3 天，跟著會議一起學習，有問題也能隨時跟夥伴討論！
專案 Case Study
平時大家都埋首在自己的專案團隊中，較少關注其他專案，因此團隊常常會藉由讀書會，讓 function team 的其他夥伴互相交流、切磋不同產品領域運用的新技術，透過夥伴們的討論，團隊也能針對專案問題激盪出不一樣的解方。
由於夥伴會根據每季 OKR 規劃專案內容，所以在讀書會的專案 case study 通常會與 OKR 相關。負責準備分享的夥伴會先做大量的調查，從官方素材、同業做過的研究、 paper 或是工具等地方尋找，再思考如何在專案上進行運用；在過程中也許會遇到一些工程或技術上的困難，經過吸收消化後，就能在讀出會上分享給 function team 的夥伴們，另一方面，夥伴們也透過討論一起激發出新靈感，提供新的 input，從不同角度找出問題盲點。
另外，因為團隊隨時都在考慮將來可能會碰到的問題，開發夥伴們創了一個 slack channel，互相分享近期技術相關的新聞，並挑選其中的議題，在讀書會中與夥伴們一起討論、尋找更多可能性。Android 團隊也換利用讀書會的時間整合團隊 refactor 既有的 usage，盡可能使用最適合、最新的技術，並定期對焦團隊的 coding style 或是原則。
其他有趣的分享
很多時候讀書會的內容都會探討與 function team 相關的技術，但我們並不會規定夥伴想分享的內容，有夥伴分享過Leetcode 的刷題心得、統計相關的知識等，他們也許跟任何 function 都扯不上關係，對團隊沒有立即性的影響，但只要是覺得有趣的技術，可以提出來分享！
讀書會，然後呢？
其實每次從讀書會的討論到實際做出成果、看到明顯的 improvement，都需要長時間累積，把每次的結果一點一點堆積起來，半年、一年才能看到真的不錯的收穫。
隨著團隊不斷成長，專案變得更複雜、在團隊不停改變下，我們也不斷透過定期的讀書會討論、激盪，尋找更適合團隊的工具，提升開發的 productivity。
例如近期 iOS 的夥伴在讀書會上分享到優化 flux 的經驗、寫出第二代的 code，進而解決 SSOT（Single Source of Truth），幫助大家打程式更順手、嚴謹；至於團隊相關的新技術，近期 Android team 的夥伴積極的嘗試 Kotest 相關的測試，以往的 unit test 其實並不多，但經由夥伴的研究，我們就能用新的 framework migrate 既有的 unit 測試，讓大家更容易地寫測試，提升測試的比例。
如果你也想參與開發團隊的讀書會，快來加入我們，一起成長吧！
職缺詳細資訊：https://dcard.link/yzZNx4
