概览

上周末，PyTexas 邀请我在他们于得克萨斯州奥斯汀举办的年度会议上发表演讲。

这是一次有趣的旅行，我也学到了很多东西。不过，从经济成本和时间成本来说，这次旅行都相当昂贵。我写下这些笔记，一部分是为了分享自己的收获，另一部分也是为了帮助我判断，参加会议所获得的收益是否值得付出这些成本。

最喜欢的演讲

Intentional Deployment: Best Practices for Feature Flag Management

演讲者：Optimizely 的 Caitlin Rubin（凯特琳·鲁宾）

Feature flags(功能开关)允许软件团队在运行时改变应用程序的行为，而不必推送一次全新的部署。对于较大的改动，你通常会希望进行 progressive rollout(渐进式发布)：先为 1% 的用户启用，然后是 5%，再到 25%，这样一来，如果改动导致生产环境崩溃，就可以限制损失。团队经常使用功能开关来实现这种缓慢发布。

功能开关存在公地悲剧问题。任何一个开发者都很容易为自己的新功能添加一个开关，但如果每个人都不断加入新的功能开关，应用程序就会积累大量不同的执行路径，最终变得难以推断程序的行为。此外，一旦团队在全局范围启用了某个功能，开发者就几乎没有动力去做那些脏活：移除分支逻辑并删除开关。

这场演讲简洁地解释了功能开关是什么、为什么会引发问题，并分享了防止这些问题的具体步骤。尤其是，我很喜欢 Caitlin 提出的“WIP limit”——工作进行中限制。如果团队将 WIP limit 设为 2，那么在任意时刻只能存在两个功能开关。这会促使开发者认真考虑何时使用功能开关，并确保在应用程序不再需要分支功能逻辑时移除这些开关。

我喜欢的其他方面：

• 幻灯片简洁干净，从不让大量文字压得观众喘不过气
• 每隔几秒就推进或更新一次幻灯片，让节奏保持流畅
• Caitlin 在台上显得很自在，说话清晰而平静
• 演讲中穿插了恰到好处的幽默

Free yourself from your ORM with mypy!

演讲者：uStudio 的 Thomas Stephens（托马斯·斯蒂芬斯）

我一直不太喜欢 object-relational mapping (ORM) frameworks(对象关系映射框架)。它们允许开发者在应用程序对象和数据存储之间传递数据，而不必手动实现大量 serialization and deserialization logic(序列化和反序列化逻辑)。Thomas 清楚地说出了我一直对 ORM 系统感到不满、却始终无法用语言表达的问题：它们会把你的对象模型绑定到 ORM 框架上。

我也见过 mypy，理解它的吸引力，但大约一年前我试用过它，当时很难让它在我的项目上运行（我的项目大多使用 Python 2.7），所以最后只能放弃。如果你还不了解它，它是 Python 的 static type checker(静态类型检查器)。它会读取代码中的 PEP 484 类型提示，并在你违反这些提示时提醒你。

这场演讲温和地介绍了 mypy，并强调了使用它的一项影响深远的好处：你可以相对轻松地自行实现数据序列化和反序列化，而不必过度依赖 ORM。Thomas 演示了如何高度依靠类型检查器来防止常见的序列化错误。

我喜欢的其他方面：

• 清楚地阐明了他试图解决的问题
• 简单的现场编程，易于跟上
• 代码优雅而清晰

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

演讲者：Netflix 的 Harrington Joseph（哈林顿·约瑟夫）

幻灯片

应用程序经常使用布尔值来跟踪对象的状态。由于 Harrington 就职于 Netflix，他使用了视频播放器作为例子，这很好地突出了其中的问题。视频可以处于播放、暂停或停止状态。天真的做法是用 is_playing 和 is_paused 这样的布尔值来跟踪状态。

以这种方式管理状态会给开发者带来沉重负担，因为他们现在必须做很多工作来推断状态。要推断出“停止”状态，就需要检查 is_playing == False and is_paused == False，这非常绕。它还要求开发者花费大量精力检查非法的状态转换。例如，已经停止的视频不能暂停，因此要强制执行这一限制，会让代码变得杂乱。

Harrington 演示了 pytransitions library 如何优雅地解决这个问题。你只需用一个简单的状态列表定义应用程序的状态转换，之后所有转换都由这个库来管理。你可以检查当前所处的状态，而库会对任何非法状态转换抛出异常；你不必编写代码手动检查。

我喜欢的其他方面：

• 漂亮的幻灯片
  • 深色主题效果很好
  • 全屏显示、带语法高亮的代码片段易于阅读
  • 状态机图示出色，容易理解
• 清晰的代码示例
  • 删去了与核心观点无关的代码，让所有内容都更容易理解

其他值得注意的收获

原来有针对 prose(文字内容) 的代码审查工具

这和 Python 毫无关系，却是我和另一位会议参会者交谈时偶然发现的一颗有价值的宝石。

我曾想过为未来的一个项目构建类似 Reviewable 的东西，不过对象不是代码，而是文字内容。我搜索过类似的工具，但找到的只有面向大型出版商的重量级工具（例如报纸使用的工具，针对有许多审批人的复杂工作流进行了优化）。我和 Caitlin Rubin 交谈时，她提到自己知道一个名为 Penflip 的类似工具。

我第一次尝试访问 Penflip 时，即使重试了很多次，仍然收到 502 网关错误。第二天，页面虽然加载出来了，但一切都极其缓慢，最终导致无法恢复的服务器错误。所以，它似乎已经不再是一个活跃的产品了。

不过，有一个产品名称至少给了我一个搜索其他产品的切入点。显然，市面上曾有一大堆“针对内容的代码审查”产品，但它们都失败了：

• 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（阿德里安·洛）的主题演讲《Python 团队之禅》。
• 个性化
  • 当演讲者本人也是故事的一部分时，我会觉得演讲更吸引人。你试图解决什么问题？遇到了哪些挑战？学到了什么？回答这些问题，比干巴巴地总结“你知道吗，工具 X 可以解决问题 Y”有趣得多。

是什么削弱了演讲效果

• 麦克风问题
  • 很遗憾，最常让我从演讲中抽离出来的事情之一，竟然是音频质量这种基础又无聊的问题。
  • 会议使用了Tony Robbins 式耳挂麦克风，许多演讲者都难以正确调整位置，所以声音经常时有时无。
  • 其他演讲者选择了手持麦克风，但又难以让麦克风足够靠近嘴巴，说话声音也不够大，导致麦克风无法有效收音。
• 幻灯片迟滞
  • 最好的演讲者会让幻灯片快速推进。他们至少每 30 秒推进一张幻灯片，或显示一个新的项目符号。当演讲者连续 60 秒甚至更久停留在同一张幻灯片上、什么都不改变时，我会产生一种“卡住了”的感觉。
• 照稿朗读
  • 参加现场会议的部分乐趣在于，作为参会者，你也是演讲的一部分。演讲者会回应你的能量，并相应调整演讲。当演讲者有很长一段时间逐字朗读稿件（更糟的是，整场演讲都是静态稿件）时，你就失去了现场演讲的乐趣。
• 动图
  • 我觉得它们很分散注意力，尤其是当它们在屏幕上循环播放超过几秒钟时。
  • 我经常觉得，那些廉价的笑话反而削弱了演讲者的观点。
• “这是一张旧幻灯片。”
  • 有几场演讲包含了一两年前的过时信息，因为它们是从之前的会议上重新使用的。演讲者会说幻灯片比较旧，以此为它辩解，但这总让我失望：演讲者似乎不够在意自己的演讲，事先都没有完整演练一遍，以便发现这些问题。

点评我自己的演讲

演讲者：Michael Lynch（迈克尔·林奇）（我本人）

幻灯片

• 做得好的地方

  • 准备充分：演讲前几周我完整演练了 5-8 遍，所以对材料感到很自在。
  • 幻灯片节奏：回看视频时，我觉得自己避免了幻灯片迟滞，演讲以不错的速度向前推进。
  • 我调侃 Java 的部分（见 16:15）引来了很好的笑声。

• 需要改进的地方

  • 放慢速度：我说得太快了。我忘记一直显示计时器，所以为了按时结束而陷入了一种匆忙慌乱的状态。我的排练大约需要 27 分钟，但在正式活动中，我讲得太快，半小时的时段只用了 22 分钟。
  • 多抬头：我花了太多时间低头看屏幕、阅读内容，而不是与观众互动。
  • “Magic numbers are fine in test code”（见 19:58）
    • 这句话需要更多论证。幸运的是，有人在问答环节问到了这个问题，所以我得以补充说明，但它本应成为正式演讲的一部分。

其他想法

作为演讲者参加会议，比作为普通来宾参加更有价值

在考虑是否参加更多会议时，我曾犹豫过是否应该以参会者而不是演讲者的身份参加一些会议。我觉得，以演讲者身份参加所获得的价值大约高出一个数量级。

人们更有兴趣和演讲者交谈。即使你还没有发表演讲，这一点也成立，因为大家会有一种“哦，那你一定擅长某件事”的感觉。而在你演讲之后，想认识你的人也很容易找到话题，因为他们至少知道一件你热衷的事情。

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

我本应该提出点请求

每位演讲者实际上都会在自己的演讲中获得一次免费的“行动号召”。对大多数演讲者来说，这通常是邀请听众应聘他们的公司或使用他们的产品。我不招聘，也正处于项目间歇期，所以当时没想到要提出行动号召。

演讲结束大约一小时后，我突然想到：“啊，我本应该请企业把他们的痛点告诉我！”我猜，许多 PyTexas 参会者的日常工作中都有某件事，会让他们想：“我讨厌做这个。为什么没有一个托管服务能替我们处理？”很多这类问题一直没有得到解决，因为产品构建者很难与存在未满足需求的小企业建立联系。PyTexas 也许是个很好的场合，让我直接说：“嘿，来和我聊聊，说不定我可以为你们构建这项服务。”

单轨制会议有着不同的氛围

这是我参加的第一个 single-track(单轨制) 会议。我的意思是，在任何时候都只有一个演讲正在进行，因此参会者永远不必决定参加哪场演讲，因为始终只有一个选择。

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

缺点是，单轨制活动没有多轨制会议自然形成的人员流动。在多轨制会议中，大多数人每场演讲结束后都会换到另一个房间，最终认识新的人。在 PyTexas，大多数人一整天都待在同一张桌子旁，所以比起我参加过的其他会议，大家之间的交流更少。

成本

最后，参加这次会议的花费超出了我的预期：

除了金钱成本之外，时间成本也很高。这是一个为期两天的会议，但它让我大约五天都精疲力竭。我往返途中各损失了大约一天，然后又花了大约一天时间处理离开期间错过的非工作杂事。除此之外，我还花了 20-30 个小时制作幻灯片和排练演讲。

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

年初时，我设定了一个目标，要在 2019 年参加三场会议并发表演讲。PyTexas 是第二场，所以我认为这一年再参加一场就很合适了。

对我来说，参加会议的好处包括认识新朋友，了解那些原本接触不到的工具和技术，以及练习公开演讲。最大的收获之一是了解了 Penflip，这完全出乎意料，但通过避免重蹈他们的覆辙，可能为我节省大量时间和金钱。