總覽

這個週末，PyTexas 邀請我到他們在德州奧斯汀舉辦的年會上演講。

這趟旅程很有趣，也讓我收穫良多。不過不論是在金錢還是時間上，花費都不小。我寫下這些筆記，一方面想分享所學，一方面也想幫自己釐清，參加研討會帶來的收穫是否值得這些付出。

最喜歡的幾場演講

策略性部署：功能旗標管理的最佳實務

講者：Caitlin Rubin，來自 Optimizely

功能旗標讓軟體團隊能在執行階段改變應用程式的行為，而不必重新部署整個新版本。對於比較重大的變更，你通常會想採漸進式推播，先開放給 1% 的使用者，再來 5%，然後 25%，為的是當變更在正式環境中出問題時，能把災情控制在最小範圍。團隊經常就是利用功能旗標來達成這種緩慢推播。

功能旗標有 公地悲劇 的問題。對個別開發者來說，要為自己的新功能加一個旗標很容易，但如果每個人都一直新增功能旗標，應用程式就會累積出太多不同的執行路徑，讓人難以推斷程式的行為。再者，一旦團隊已經全面啟用某個功能，開發者就幾乎沒有動力去做那些吃力不討好的清理工作，把分歧的邏輯和旗標移除。

這場演講簡潔地說明了功能旗標是什麼、為什麼會造成問題，並分享了預防這些問題的具體做法。我特別喜歡 Caitlin 提出的「WIP 上限」——也就是進行中工作數量上限（work in progress limit）的建議。如果團隊把 WIP 上限設為兩個，那麼同一時間就只能存在兩個功能旗標。這會促使開發者更謹慎地思考何時該使用功能旗標，也能確保當應用程式不再需要那些分歧邏輯時，開發者會把旗標移除。

其他我喜歡的地方：

• 投影片版面乾淨，從不會用大量文字轟炸觀眾
• 投影片每隔幾秒就會切換或更新，讓節奏保持流暢
• Caitlin 在台上顯得從容自在，語調清晰沉穩
• 整場演講穿插了恰到好處的幽默

用 mypy 讓自己擺脫 ORM 吧！

講者：Thomas Stephens，來自 uStudio

我一直對物件關聯對映（ORM）框架有點排斥。它們讓開發者不用手動實作大量序列化和反序列化邏輯，就能把應用程式物件存進或取出資料儲存區。Thomas 把我一直以來對 ORM 系統的不滿、卻始終說不清楚的問題講出來了：它們把你的物件模型跟 ORM 框架綁死了。

我也早就看過 mypy，能理解它的吸引力，但大概一年前我在自己的專案（大多是 Python 2.7）上試著導入時，一直搞不定，最後就放棄了。如果你還沒看過，它是 Python 的靜態型別檢查工具。它會讀取你程式碼中符合 PEP 484 的型別提示，並在你違反這些提示時提醒你。

這場演講對 mypy 做了溫和的入門介紹，並點出使用它的一個深遠好處：那就是你可以不用太費工、也不用太依賴其他東西，自己實作資料的序列化與反序列化。Thomas 示範了如何大量倚賴型別檢查器來避免常見的序列化錯誤。

其他我喜歡的地方：

• 清楚地闡述他想解決的問題
• 簡單的現場實作，容易跟上
• 程式碼優雅又清晰

當布林值不夠用時……要用狀態機嗎？

講者：Harrington Joseph，來自 Netflix

投影片

應用程式常會用布林值來追蹤物件的狀態。由於 Harrington 任職於 Netflix，他用影片播放器當例子，把問題點得很清楚。一部影片可能是播放中、暫停或已停止。比較天真的做法會用像 is_playing 和 is_paused 這樣的布林值來追蹤。

用這種方式管理狀態會給開發者帶來沉重負擔，因為他們得花很多力氣去推斷狀態。要推斷出「已停止」這個狀態，就得檢查 is_playing == False and is_paused == False，相當迂迴。也讓開發者得花很多工去檢查不合法的狀態轉換。舉例來說，已經停止的影片不能再按暫停，要強制執行這個限制就會讓程式碼變得很雜亂。

Harrington 示範了 pytransitions 函式庫如何優雅地解決這個問題。它讓你用一個簡單的狀態清單來定義應用程式的狀態轉換，接著函式庫就會幫你管理所有轉換。你可以查詢目前處於哪個狀態，而只要發生不合法的轉換，函式庫就會拋出例外，你完全不需要自己寫程式碼去檢查。

其他我喜歡的地方：

• 漂亮的投影片
  • 深色主題效果很好
  • 全螢幕的程式碼片段加上語法突顯，很容易閱讀
  • 狀態機的圖解很棒，一看就懂
• 清晰的程式碼範例
  • 省略了與核心觀點無關的程式碼，讓一切都更容易思考

其他值得注意的收穫

有專門給文章用的程式碼審閱工具

這跟 Python 無關，卻是我跟另一位與會者聊天時意外挖到的寶。

我對未來專案的一個構想，就是打造一個像 Reviewable 那樣的東西，但對象不是程式碼，而是文章內容。我曾搜尋過這類工具，卻只找到一些針對大型出版社設計的重量級工具（例如給報社用的、為擁有多位審核者的複雜流程最佳化的工具）。跟 Caitlin Rubin 聊天時，她提到她知道一個叫 Penflip 的類似工具。

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

不過，有了一個產品名稱，總算讓我有個立足點去搜尋其他類似產品。結果發現，外面有一大堆「針對內容的 code review」產品都已經失敗收場：

• Draft：少數還能正常運作的編輯應用程式之一，但似乎不太支援審閱功能。
• Editorially：這曾是一款據說深受大家喜愛的免費工具，但在 2014 年就關站了。我找到很多為它的結束而惋惜的文章。
• Typewrite：網站還在，但功能已經壞到我連註冊都沒辦法。最後一篇 Twitter 貼文停在 2014 年，所以我想它應該已經掛了。
• Poetica：我曾看過有人提到它，但現在也已經收掉了。看起來似乎不是特別受歡迎。

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」。
• 個人化敘事
  • 當講者本身就是故事的一部分時，我覺得演講更吸引人。你想解決什麼問題？你遇到了哪些挑戰？你學到了什麼？回答這些問題，遠比乾巴巴地總結「你知道有個工具 X 可以解決問題 Y 嗎？」來得引人入勝。

什麼削弱了演講效果

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

檢討我自己的演講

講者：Michael Lynch（我本人）

投影片

• 表現好的地方

  • 準備充分：我在演講前幾週演練了 5 到 8 次，所以對內容感到自在。
  • 投影片節奏：回頭看影片，感覺我有避免投影片停滯，讓演講以不錯的步調前進。
  • 我對 Java 的調侃（見 16:15）引來一陣笑聲。

• 需要改進的地方

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

其他想法

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

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

大家對跟講者聊天更有興趣。就算在你演講之前也是如此，因為會有一種「喔，你一定在某方面很厲害」的感覺。而在你演講之後，想認識你的人也有了輕鬆的開場話題，因為他們至少知道一件你熱衷的事。

我也發現，講者比其他與會者更讓我印象深刻。我跟很多有趣的人聊過，但幾天後還留在我腦海裡的，都是那些上台演講的人。

我應該要提出一個請求

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

演講結束大約一小時後，我才想到：「啊，我應該請大家把他們的痛點告訴我！」我猜很多 PyTexas 的與會者在日常工作中，都有某個時刻會想：「我討厭做這件事。為什麼沒有一個代管服務幫我們處理掉？」很多這類問題一直沒被解決，是因為打造產品的人很難跟有未滿足需求的小型企業對接。PyTexas 本來會是個很適合說「嘿，來跟我聊聊，也許我可以幫你打造那個服務」的地方。

單軌研討會有不一樣的氛圍

這是我參加的第一場單軌研討會。我的意思是，任何時間都只有一場演講在進行，所以與會者永遠不用煩惱要選哪場聽，因為永遠只有一個選擇。

單軌的好處是每個人都看了同一場演講，所以你跟任何人都能聊任何一場演講，對方大概也都看過。對講者來說，能讓 100% 的觀眾都看到自己的演講也很棒。

缺點是單軌活動少了多軌研討會自然會產生的那種流動感。在多軌研討會中，大多數人在每場演講後都會移動到不同的房間，因而有機會認識新朋友。在 PyTexas，大多數人整天都坐在同一張桌子旁，所以交流的機會比我在其他研討會看到的少很多。

花費

參加這場研討會的實際花費比我預期的多：

除了金錢上的花費，時間成本也很高。這是為期兩天的研討會，但卻讓我有大約五天無法正常運作。來回交通各花掉我大約一天，然後又花了一天去補處理離開期間沒辦完的私事。除此之外，我還花了 20 到 30 個小時準備投影片和演練。

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

年初時，我立下目標要在 2019 年到三場研討會演講。PyTexas 是第二場，所以我想今年再參加一場就差不多了。

對我來說，收穫在於認識新朋友、聽到那些原本不會接觸到的工具與技術，以及練習公開演講。其中最大的收穫之一就是認識了 Penflip，這完全是意料之外的發現，卻可能幫我省下大量時間和金錢，讓我避免重蹈他們的覆轍。