概述

上个周末，PyTexas 邀请我在得克萨斯州奥斯汀举办的年会上做分享。

这是一次愉快的行程，也让我学到了很多。不过，无论是金钱还是时间上的花费都不小。写下这些笔记，一方面是想分享我的所学，另一方面也是想帮自己判断一下，参加会议的收获是否值得付出这些成本。

印象最深的几场演讲

有意部署：功能开关管理的最佳实践

演讲者：来自 Optimizely 的 Caitlin Rubin

功能开关让软件团队可以在运行时改变应用的行为，而不必重新部署一个全新的版本。对于比较大的改动，你通常会希望做渐进式发布——先对 1% 的用户开放，再到 5%，然后 25%——这样即使改动在生产环境中引发故障，也能把影响范围控制到最小。团队常常利用功能开关来实现这种缓慢的灰度发布。

功能开关存在公地悲剧的问题。任何一个开发者都可以轻易地为自己的新功能添加一个开关，但如果每个人都不断加入新的功能开关，应用中就会累积出大量不同的执行路径，让人难以推断程序的行为。此外，一旦团队在全局启用了某个功能，开发者就几乎没有动力去做那些繁琐的清理工作——移除分支逻辑、彻底删掉开关。

这场演讲简明扼要地解释了什么是功能开关、它们为什么会带来问题，并分享了预防这些问题的具体做法。我尤其喜欢 Caitlin 提出的“WIP 上限”（并行任务数上限）建议。如果团队把 WIP 上限设为两个，那么在任意时刻就只能存在两个功能开关。这会促使开发者更审慎地决定何时使用功能开关，并确保在不再需要分支逻辑时及时移除开关。

其他亮点：

• 幻灯片简洁干净，从不会用大量文字让观众应接不暇
• 幻灯片每隔几秒就会翻页或更新，节奏紧凑
• Caitlin 在台上显得从容自信，表达清晰、语调平稳
• 演讲中恰到好处地穿插了幽默

用 mypy 摆脱 ORM 的束缚！

演讲者：来自 uStudio 的 Thomas Stephens

我一直不太喜欢对象关系映射（ORM）框架。它们让开发者无需手写大量序列化和反序列化逻辑，就能把应用对象存入数据存储或从中取出。Thomas 精准地道出了我一直对 ORM 心存芥蒂却又说不清的原因：它们把你的对象模型和 ORM 框架绑定在了一起。

我之前也了解过 mypy，知道它的吸引力，但大约一年前我在自己的项目（大多是 Python 2.7）上尝试时，总觉得很难用起来，最后就放弃了。如果你还没见过它，它是 Python 的静态类型检查器。它会读取代码中 PEP 484 的类型注解，并在你违反类型约定时给出提示。

这场演讲对 mypy 做了平缓易懂的入门介绍，并强调了使用它带来的一个深远好处：你可以相对轻松地自行实现数据的序列化与反序列化。Thomas 演示了如何充分借助类型检查器来避免常见的序列化错误。

其他亮点：

• 对要解决的问题阐述清晰
• 现场编码简单直观，易于跟上
• 代码优雅清晰

当布尔值不够用时……要用状态机？

演讲者：来自 Netflix 的 Harrington Joseph

幻灯片

应用常常会用布尔值来跟踪对象的状态。因为 Harrington 来自 Netflix，他以视频播放器为例，很好地说明了这个问题。视频可能处于播放、暂停或停止三种状态。一种简单粗暴的做法是用 is_playing 和 is_paused 这样的布尔值来跟踪。

这样管理状态会给开发者带来沉重负担，因为他们需要做大量工作来推断状态。要推断“已停止”状态，需要检查 is_playing == False and is_paused == False，逻辑十分绕。而且开发者还要花费大量精力去校验非法的状态转换。例如，已经停止的视频不能再被暂停，要强制执行这类限制，会让代码变得臃肿。

Harrington 演示了 pytransitions 库如何优雅地解决这个问题。你只需用一个简单的状态列表来定义应用的状态转换，库就会帮你管理所有的转换。你可以查询当前所处的状态，任何非法的状态转换都会触发异常，无需你手动编写校验代码。

其他亮点：

• 精美的幻灯片
  • 深色主题效果很好
  • 全屏的代码片段配有语法高亮，易于阅读
  • 状态机的图示清晰易懂
• 清晰的代码示例
  • 省略了与核心观点无关的代码，让内容更易于思考

其他值得一记的收获

有针对文字内容的代码评审工具

这件事和 Python 无关，却是我在与另一位参会者闲聊时偶然得到的一个宝贵发现。

我一直有个想法，想做一个类似 Reviewable 但面向文字内容而非代码的项目。我也搜索过这类工具，但只找到一些面向大型出版机构的重型工具（例如为报社设计的、针对多人多级审批的复杂流程优化的工具）。和 Caitlin Rubin 聊天时，她提到她知道一款叫 Penflip 的类似工具。

第一天我尝试访问 Penflip 时，即便多次重试，也一直返回 502 网关错误。第二天页面总算加载出来了，但速度极慢，最终还是陷入无法恢复的服务器错误。看来它可能已经不再维护了。

不过，有了一个产品名称作为线索，我就能去搜索其他类似的产品。结果发现，市面上其实有一大堆“面向内容的代码评审”产品，但都失败了：

• Draft：少数几个仍能正常使用的编辑应用之一，但似乎不太支持评审功能。
• Editorially：这曾是一款据说很受喜爱的免费工具，但在 2014 年关闭了。我找到了很多悼念它关闭的文章。
• Typewrite：网站仍在，但功能已损坏到连注册都无法完成。最后一条推文停留在 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 的主题演讲，“Python 团队之禅”。
• 有个人色彩
  • 当演讲者把自己融入故事时，我会觉得更投入。你试图解决什么问题？遇到了哪些挑战？学到了什么？回答这些问题远比干巴巴地总结“你知道有工具 X 可以解决 Y 问题吗？”更吸引人。

哪些因素削弱了演讲效果

• 话筒问题
  • 遗憾的是，最容易让我出戏的，往往是音质这种最基础、最乏味的问题。
  • 会议使用的是托尼·罗宾斯式的耳挂话筒，很多演讲者没能正确佩戴，导致声音时断时续。
  • 另一些演讲者选择了手持话筒，却没能把它拿得离嘴足够近、说话声音也不够大，话筒难以拾音。
• 幻灯片停滞
  • 最优秀的演讲者会让幻灯片保持轻快的节奏。他们至少每 30 秒就会翻页或让新的要点出现。当演讲者长达 60 秒甚至更久都不换页、没有任何变化时，我就会感到一种“卡住”的停滞感。
• 照稿念
  • 参加现场会议的一大乐趣在于，作为听众，你本身就是演讲的一部分。演讲者会回应你的能量，并相应地调整演讲。当演讲者大段照着稿子念（更糟的是整场演讲都照着固定稿子念）时，现场演讲的乐趣就荡然无存了。
• 动态 GIF
  • 我觉得这些很分散注意力，尤其是当它们在屏幕上循环播放超过几秒钟时。
  • 我常常觉得廉价的玩笑反而削弱了演讲者的观点。
• “这是一张旧幻灯片”
  • 有几场演讲包含了一两年前的信息，因为它们是从以往的会议上直接复用的。演讲者用“这张幻灯片有点旧了”来带过，但每次都让我感到失望——觉得演讲者连提前完整演练一遍、发现这些问题的用心都没有。

复盘我自己的演讲

演讲者：Michael Lynch（我本人）

幻灯片

• 做得好的地方

  • 准备充分：我在演讲前几周演练了 5 到 8 次，所以对内容感到很踏实。
  • 幻灯片节奏：回看视频，感觉我避免了幻灯片停滞，演讲推进的节奏不错。
  • 我在 16:15 处对 Java 的调侃获得了不错的笑声。

• 需要改进的地方

  • 放慢语速：我讲得太快了。我忘了打开计时器，所以一直处于匆忙、担心超时讲不完的紧张状态。彩排时通常要讲 27 分钟左右，但在现场我讲得太快，只用了 22 分钟就讲完了本该 30 分钟的内容。
  • 多抬头：我花了太多时间低头看屏幕上的内容，而不是与观众交流。
  • “在测试代码中用魔法数字没问题”（在 19:58 处）
    • 这句话需要更多论证。好在有人在问答环节问到了这一点，所以我得以补充说明，但这本该是演讲正文的一部分。

其他思考

以演讲者身份参会比以普通观众身份更有价值

在考虑是否要参加更多会议时，我曾纠结过是否应该以普通观众而非演讲者的身份去参加。我感觉以演讲者身份参会的价值要高出一个数量级。

人们更愿意主动与演讲者交流。甚至在你演讲之前就有这种效应，因为大家会觉得“哦，你一定在某方面很厉害”。演讲结束后，想认识你的人也有了现成的话题，因为他们至少知道一件你热衷的事。

我也发现，演讲者比其他参会者给我留下的印象更持久。我和很多有趣的人聊过，但几天后仍记忆犹新的，往往是那些做过演讲的人。

我本该提点请求

每位演讲者实际上都能在演讲中免费获得一次“号召行动”的机会。对大多数演讲者来说，这就是邀请大家加入他们的公司或使用他们的产品。我目前没有在招聘，也正处于项目空档期，所以根本没想到要号召什么。

演讲结束约一小时后，我才想到：“哦，我本该请大家把他们的痛点告诉我的！”我猜很多 PyTexas 的参会者在日常工作中都会有“讨厌做这件事。为什么没有现成的托管服务来帮我们处理？”的时刻。很多这类问题之所以得不到解决，是因为做产品的人很难与有未满足需求的小企业对接上。PyTexas 本来是个很好的机会，可以直接说：“嘿，来找我聊聊，也许我就能为你把那个服务做出来。”

单轨会议的氛围与众不同

这是我第一次参加单轨会议。所谓单轨，是指在任何一个时间点都只有一场演讲，参会者永远不需要纠结该去听哪一场，因为永远只有一个选择。

单轨的好处在于，所有人都看同样的演讲，所以你可以和任何人讨论任意一场演讲，对方很可能也看过。作为演讲者，能让 100% 的观众都看到你的演讲也很不错。

缺点是单轨活动缺少多轨会议自然产生的那种流动感。在多轨会议中，大多数人在每场演讲结束后都会换到另一个房间，从而结识新的人。而在 PyTexas，大多数人一整天都坐在同一张桌子旁，所以相互交流比我在其他会议上看到的要少。

花费

最终参会的开销比我预期的要多：

除了金钱成本，时间成本也很高。这是一个为期两天的会议，却让我前后耗费了大约五天时间。路上往返各花了差不多一天，回来后又花了一天来处理因外出而落下的日常琐事。除此之外，我还花了 20 到 30 个小时准备幻灯片并进行演练。

结论：继续参加，但要有策略

年初时，我定下目标要在 2019 年做三场会议演讲。PyTexas 是第二场，所以我觉得今年再参加一场就差不多了。

对我而言，收获在于结识新朋友、接触到原本不会了解的工具与方法，以及锻炼公开演讲的能力。其中最大的收获之一是了解到 Penflip，这个完全出乎意料的发现，未来可能会帮我省下大量时间和金钱，避免重蹈他们的覆辙。