概覽

上週末，PyTexas 邀請我在德州奧斯汀舉行的年度研討會上發表演說。

這趟旅程很有趣，我也學到很多。不過無論是金錢還是時間上，花費都不小。我寫下這些筆記，一方面想分享所學，一方面也想幫助自己判斷參加研討會的收穫是否值得付出這些成本。

精選演講

刻意部署：Feature Flag 管理的最佳實務

講者：Caitlin Rubin（凱特琳·魯賓） 來自 Optimizely

Feature flags(功能旗標) 能讓軟體團隊在執行期間改變應用程式的行為，而不需要推送全新的部署。對於較大幅度的變更，你通常會想採取漸進式推出，先對 1% 的使用者啟用，然後是 5%，再到 25%，這樣才能在變更於正式環境中出問題時，將損害降到最低。團隊經常透過 Feature flags 來實現這種緩慢的推出。

Feature flags 存在 公地悲劇 的問題。對個別開發者而言，為新功能新增一個旗標很容易，但如果每個人都不斷加入新的 Feature flags，應用程式就會累積過多的執行路徑，導致難以推論程式的行為。此外，一旦團隊全面啟用某項功能，開發者就幾乎沒有動力去做那些繁瑣的工作，也就是移除分支邏輯並清除旗標。

這場演講簡潔地說明了 Feature flags、它們為何會造成問題，並分享了預防這些問題的具體步驟。我特別喜歡凱特琳提出的「WIP limit(進行中工作數量上限)」——也就是 work in progress limit 的概念。如果團隊將 WIP limit 設為二，那麼在任何時間點就只能存在兩個 Feature flags。這能促使開發者在決定使用 Feature flags 時更加審慎，並確保在應用程式不再需要分支功能邏輯時，開發者會將旗標移除。

其他我喜歡的地方：

• 投影片簡潔，不會用大量文字讓觀眾喘不過氣
• 投影片每隔幾秒就切換或更新，節奏明快
• 凱特琳在台上顯得自在，語調清晰平穩
• 整場演講穿插了恰到好處的幽默

用 mypy 讓你擺脫 ORM 的束縛！

講者：Thomas Stephens（湯瑪斯·史蒂芬斯）來自 uStudio

我一直對 object-relational mapping(物件關聯對映)（ORM）框架抱持排斥。這些框架讓開發者不需要手動實作大量的序列化與反序列化邏輯，就能將應用程式物件移入、移出資料儲存區。湯瑪斯·史蒂芬斯清楚說出了我一直以來對 ORM 系統的不滿，卻始終無法準確表達的問題：它們把你的物件模型綁定在 ORM 框架上。

我之前也看過 mypy，也能理解它的吸引力，但大約一年前我在自己的專案（大多是 Python 2.7）上試用時，很難讓它正常運作，所以就放棄了。如果你還沒看過，mypy 是 Python 的靜態型別檢查器。它會讀取你程式碼中的 PEP 484 型別提示，並在你違反這些提示時提醒你。

這場演講對 mypy 做了平易近人的介紹，並點出使用它的一項深遠好處。也就是說，你可以不費太多功夫，就自行實作資料的序列化與反序列化。湯瑪斯·史蒂芬斯示範了如何大量仰賴型別檢查器來預防常見的序列化錯誤。

其他我喜歡的地方：

• 清楚闡述他想解決的問題
• 簡單易懂的現場實作程式碼
• 程式碼優雅且清晰

當布林值不夠用時……該用 State Machines(狀態機)嗎？

講者：Harrington Joseph（哈靈頓·約瑟夫） 來自 Netflix

投影片

應用程式經常使用布林值來追蹤物件的狀態。由於哈靈頓任職於 Netflix，他以影片播放器為例，很好地凸顯了這個問題。影片可能處於播放、暫停或停止三種狀態。天真的做法會用 is_playing 和 is_paused 這類布林值來追蹤。

這樣管理狀態會給開發者帶來沉重負擔，因為他們必須花很多功夫來推斷狀態。要推斷「已停止」狀態，就必須檢查 is_playing == False and is_paused == False，這相當迂迴。這也讓開發者必須費力檢查不合法的狀態轉換。舉例來說，你不能暫停一部已經停止的影片，因此要強制執行這項限制，就會讓程式碼變得雜亂。

哈靈頓展示了 pytransitions library 如何優雅地解決這個問題。它讓你用簡單的狀態清單來定義應用程式的狀態轉換——接著函式庫會幫你管理所有的轉換。你可以檢查目前處於哪個狀態，而函式庫會在任何不合法的狀態轉換時拋出例外；你不需要手動撰寫檢查程式碼。

其他我喜歡的地方：

• 精美的投影片
  • 深色主題效果很好
  • 全螢幕的程式碼片段搭配語法突顯，易於閱讀
  • State Machines 的圖解很棒，容易理解
• 清晰的程式碼範例
  • 省略了與核心論點無關的程式碼，讓一切都更容易理解

其他值得注意的收穫

有給散文用的程式碼審查工具

這件事和 Python 無關，是我偶然和另一位與會者聊天時意外挖到的寶。

我對未來有個專案構想，是想打造一個像 Reviewable 那樣，但針對散文內容而非程式碼的工具。我曾搜尋過這類工具，但只找到針對大型出版商的重量級工具（例如為報社設計、針對有多位審核者的複雜流程優化的工具）。當我和凱特琳聊到時，她提到她知道一個叫做 Penflip 的類似工具。

我第一天嘗試造訪 Penflip 時，即使重試多次，仍收到 502 gateway 錯誤。隔天頁面總算載入，但速度極慢，最終還是出現無法復原的伺服器錯誤。所以，看起來它可能已經不是仍在營運的產品了。

不過，有了一個產品名稱，就讓我有了搜尋其他產品的立足點。顯然，外面有一大堆「針對內容的程式碼審查」產品都已經失敗了：

• Draft：一款少數仍可正常運作的編輯應用程式，但似乎不太支援審查功能。
• Editorially：這曾是一款據說深受喜愛的免費工具，但在 2014 年關閉了。我找到許多悼念它關閉的文章。
• Typewrite：網站還在，但功能已經損壞到我甚至無法註冊。最後一篇 Twitter 貼文是在 2014 年，所以我想它已經停止營運了。
• Poetica：我曾看過有人提到它，但現在已經消失了。似乎不是特別受歡迎。

Python 之禪

好幾位講者提到了 The Zen of Python（《Python 之禪》），這是一份著名的 Python 指導原則清單。我以前從未看過這份清單，但很值得了解。只要在任何 Python 直譯器中輸入 import this，就會看到它們。

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

PyCon 是件大事

好幾個人對 PyCon 讚譽有加。PyTexas 是小型的地區性研討會，但 PyCon 是全國性的——屬於大聯盟等級。聽起來演講品質很高，也能遇到更多能提供幫助的人。我原本都靠 PaperCall 來查看即將舉行的研討會，但我覺得 PyCon 似乎沒有使用它，所以我錯過了投稿截止日期。我得把它加到明年的行事曆裡。

什麼讓演講有效

• 講者自在
  • 最棒的演講，都是講者感到自在、從容不迫的場次。
  • 最好的例子是 Adrienne Lowe（艾卓安·洛）的專題演講，「The Zen of Python Teams（《Python 團隊之禪》）」。
• 個人化
  • 當講者本身就是故事的一部分時，我覺得演講更引人入勝。你想解決什麼問題？你遇到了哪些挑戰？你學到了什麼？回答這些問題，遠比枯燥地總結「你知道有工具 X 可以解決問題 Y 嗎？」更能吸引人。

什麼削弱了演講效果

• 麥克風問題
  • 很可惜，最常讓我分心、無法投入演講的，竟然是音質這種既基本又乏味的問題。
  • 研討會使用的是 Tony Robbins 式的耳掛式麥克風，許多講者很難正確調整位置，所以聲音經常時大時小、斷斷續續。
  • 其他講者選擇手持式麥克風，但很難把它拿得離嘴巴夠近，或講得夠大聲讓麥克風收得到。
• 投影片呆滯
  • 最優秀的講者會讓投影片節奏明快。他們至少每 30 秒就會換一張投影片或讓一個新的項目符號出現。當講者讓同一張投影片停留 60 秒以上、毫無變化時，我就會感到一種「卡住」的感覺。
• 照稿念
  • 參加現場研討會的樂趣之一，在於你身為聽眾，也是演講的一部分。講者會回應你的能量並據此調整演講內容。當講者有很長一段內容是照著稿子逐字念出來時（更糟的是，整場演講都是照著固定稿子念），你就失去了現場演講的樂趣。
• 動態 GIF
  • 我覺得這些很干擾，尤其是當它們在螢幕上循環播放超過幾秒鐘時。
  • 我常常覺得那種廉價的笑點反而削弱了講者的論點。
• 「這是一張舊投影片。」
  • 有幾場演講包含了過時一兩年的資訊，因為它們是從之前的研討會回收再利用的。講者以「這張投影片有點舊」來帶過，但總讓我感到失望，覺得講者不夠重視自己的演講，沒有事先完整演練一遍來發現這些問題。

評析我自己的演講

講者：Michael Lynch（麥可·林奇）（我本人）

投影片

• 表現好的地方

  • 準備充分：我在演講前幾週進行了 5 到 8 次的完整演練，所以對內容感到熟悉自在。
  • 投影片節奏：回顧影片時，感覺我避免了投影片呆滯，並以良好的節奏推動演講進行。
  • 我對 Java 的揶揄（見 16:15）引來一陣笑聲。

• 需要改進的地方

  • 放慢速度：我講得太快了。我忘了把計時器開著，所以有點慌張地想趕快講完。彩排時大約是 27 分鐘，但在正式演講時，我講得太快，只用了半小時時段中的 22 分鐘。
  • 多抬頭：我花太多時間低頭看螢幕念內容，而不是與觀眾互動。
  • 「在測試程式碼中使用魔術數字是沒問題的」（在 19:58）
    • 這句話需要更多說明。幸好有人在問答環節問到這個，所以我有機會補充，但這本來就應該是演講內容的一部分。

其他想法

以講者身分參加比以一般來賓身分更有價值

在考慮是否要參加更多研討會時，我曾猶豫是否應該以聽眾而非講者的身分去參加一些。我覺得以講者身分參加的價值，大約要高出一個數量級。

人們更願意以講者的身分與你交談。即使在你演講之前就是如此，因為會有一種「喔，你一定在某方面很厲害」的感覺。而在你演講之後，想認識你的人也有了輕鬆的話題可以和你聊，因為他們至少知道一件你熱衷的事。

我也發現，比起其他與會者，講者給我的印象更深刻。我和許多有趣的人交談過，但幾天後仍留在我記憶中的，是那些上台演講的人。

我應該要提出請求

每位講者在演講中實際上都得到一次免費的「行動呼籲」機會。對大多數講者而言，那是邀請大家加入他們的公司或使用他們的產品。我目前沒有在徵人，也正處於 專案空檔，所以沒想到要做行動呼籲。

在演講結束約一小時後，我才想到：「啊，我應該請企業把他們的痛點寄給我！」我猜想許多 PyTexas 的與會者，在日常工作中都有某個環節會想：「我討厭做這件事。為什麼沒有代管服務來幫我們處理這個？」許多這類問題之所以未被解決，是因為產品打造者很難與有未滿足需求的小型企業建立連結。PyTexas 或許是個好機會，可以直接說：「嘿，來找我聊聊，也許我會為你打造那個服務。」

單軌研討會有不同的氛圍

這是我參加的第一場 single-track(單軌) 研討會。我的意思是，在任何時間點都只有一場演講在進行，所以與會者永遠不需要抉擇要參加哪一場，因為永遠只有一個選擇。

單軌的好處在於每個人都看了相同的演講，所以你可以和任何人討論任何一場演講，對方很可能也看過。身為講者，能讓 100% 的觀眾看到你的演講也很棒。

缺點是 single-track 活動缺乏 multi-track(多軌) 研討會自然產生的流動。在多軌研討會中，大多數人在每場演講後都會移動到不同的房間，最終會遇到新的人。在 PyTexas，大多數人整天都坐在同一張桌子旁，所以交流的機會比我在其他研討會看到的要少。

花費

結果我為參加這場研討會花的錢比預期的多：

除了金錢上的花費，時間上的成本也很高。這是一場為期兩天的研討會，卻讓我大約五天都無法好好運作。來回交通各花了我大約一天，然後又花了一天來補做離開期間錯過的私事。除此之外，我還花了 20 到 30 個小時準備投影片並反覆演練。

結論：繼續參加，但要有策略

年初時，我 設定了一個目標，要在 2019 年於三場研討會上發表演說。PyTexas 是第二場，所以我覺得今年再參加一場就差不多了。

對我而言，收穫在於認識新朋友、接觸到原本不會接觸到的工具與技術，以及練習公開演講。其中最大的收穫之一是認識了 Penflip，這完全是意料之外的收穫，但透過避免重蹈他們的覆轍，可能為我省下大量的時間與金錢。