面向痛苦编程 (译文)

2015-05-06 18:04

Nathan Marz 是 Twitter 的分布式流处理框架 Storm 的主要作者,他的新书 Big Data: Principles and best practices of scalable realtime data systems 今天正式发售了,我半个月前就下了订单,满心期盼。先前在浏览他的博客时看到一篇有趣的文章,发表于2012年,现中文翻译于此,和大家分享。


面向痛苦编程

作者:Nathan Marz

译者:潘天 (puncsky)

前些天,有人问了我个有趣的问题:“在创业公司工作的时候,还能够有勇气去写 Storm,你是怎样做到的?” 我知道,在外界看来,创业公司做如此大规模的项目,是相当冒险的行为。而在我自己看来,其实,写 Storm 一点儿风险都没有:它很有挑战性,但并没有风险。

我遵从了一种能够极大地规避风险的开发方式,来应对像 Storm 这种大型项目,并将其命名为 “面向痛苦编程” 。简单来说,面向痛苦编程是这样的:不去做那些不重要的项目,除非,缺少它真的让你感到痛苦难耐。这一准则放之四海而皆准,大到架构上的决策,小到每天写的代码。面向痛苦编程保证你总是在做重要的事情,在尝试大的投入前先从小处精通问题的本质,因此而能够极大地规避风险。

面向痛苦编程有三句箴言:“先做成,再做美,后做快。” (First make it possible. Then make it beautiful. Then make it fast.)

先做成

当你进入某个你不熟悉的问题领域 (problem domain) 时,不要立马写一个 “通用的” 或者 “可拓展” 的解。你都不太了解,如何预见未来会有哪些需求?你会把不必通用的变通用,浪费了时间,增加了复杂性。

更好的做法是仅仅 “三下五除二干出来再说” (hack things out) ,直面解决手头的问题。这样,你就能够做成你需要做成的事儿,避免浪费时间。

Storm 的 “先做成” 阶段是一年的快速开发,用队列和工作节点做一个流试处理处理系统。我们学到了如何用 “ack” 协议保证数据处理,我们学到了如何用集群的队列和工作节点规模化实时计算,我们学到了有时候要用不同的方式分割 (partition) 消息流:有时候随机地、有时候 hash/mod 地,确保同样的东西总是流到同样的工作节点上。

当时我们还甚至不知道我们处在 “先做成” 的阶段,只是专注于做产品。尽管队列和工作节点们形成的系统在后来很快让我们痛得不行,但是当时,规模化这个系统很乏味,我们也并不需要容错机制。很明显,队列和工作节点形成的范式并不是一层正确的抽象,因为我们大多数的代码与路由 (routing messages) 和序列化有关,并非我们真正关心的业务逻辑。

同时,开发产品让我们发现了 “实时计算” 的新用例。我们写了一个功能,计算 Twitter 上某一个 URL 的 受众量 (Reach),所谓受众量,就是能够接触到 Twitter 上的某个 URL 的去除重复后的人数。这一计算很困难,一次计算就需要上百次的数据库访问、和上千万的去重操作。要处理这些绝对路径的 URL,我们最初的单机实现要跑一分多钟,显然,我们需要某种分布式系统来并行处理,加速计算。

启发 Storm 的一个关键就在于,我们意识到了 “受众量问题” 和 “流处理问题” 可以被归化成简单的抽象。

再做美

当你三下五除二干出来再说 (hacking things out) 的时候,这一问题领域的 “地图” 也逐渐明晰起来。随着时间的推移,你逐渐习得这一领域越来越多的用例,深入了解这些系统的微妙与复杂之处。这些深入的了解能够启发 “美丽” 的技术,来替代现有的系统,减轻你的痛苦,让过去的不可能做到的新系统、新功能变成可能。

做“美”的关键在于,搞清楚能够解决已知具体问题的最简抽象集。不要预测那些实际上你并未遇到的具体用例,否则结果就会做得太过了 (overengineering)。经验法则是,要想投入更多,对问题领域的理解需要更深刻,用例需要更多样。否则,就有发生第二系统效应的风险。

在“做美”阶段,你动用设计与抽象的技能,把问题区间提炼成简单的、可组合在一起的抽象们。提炼美好的抽象就似统计学所谓的回归一般:图上一堆点 (用例) ,找条最简单的曲线 (抽象) 契合这些点。

用例越多,找契合点的曲线也就越方便。如果点不够,得到的曲线要么做得太过,要么做得不够好,最终过度工程或者浪费时间。

做美有很大一块是去了解问题区间的性能与资源特征 (understanding the performance and resource characteristics of the problem space),设计优美的解要利用那些属于前一阶段“做成”时学到的微妙与复杂。

就 Storm 而言,我把实时处理提炼成了一堆小的抽象:流 (streams),出水口 (spouts),水栓 (bolts),和拓扑结构 (topologies)。我发明了新的算法,消除中间消息的代理,同时又能够保证数据得到了处理,整个系统中最复杂最令人痛苦的部分因此而被除去。流处理和受众量,两个看上去迥异的问题,如此优雅地归化到了 Storm,这强烈地预示着,我做的东西,了不得。

我继而进一步地为 Storm 寻找更多的用例,验证我的设计。我和其他工程师深入讨论,学习他们处理实时问题的独到之处。我并没有只去问我认识的人,我还发了 Twitter 说我正在做一款新的实时系统,想要知道其他人的用例,随后有很多有趣的讨论,让我对问题领域有了更深的认识,并验证了我的设计思路。

后做快

一旦得到了优美的设计,就能安全地花时间做性能分析 (profiling) 和优化了。过早优化浪费时间,因为你仍然有可能重新做设计。

“做快”并不是指系统高层级的性能特征。这些特征本应该在“做成”阶段被理解到,在“做美”阶段被设计好。“做快”是指微观上的优化,让代码更紧凑,更有效率地利用资源。所以说,在“做美”阶段,你会关心诸如渐进复杂度的问题;在“做快”阶段,你会关心诸如复杂度中那些常量的问题。

反复雕琢

面向痛苦编程是持续的过程。构建美丽的系统赋予你新的能力,让你在问题区间里更新更深的领域有能力“做成”。学到的新的知识又反馈到原有的技术中,用以微调或者补充原有的抽象,这样就能够搞定更多的用例。

Storm 就像这样迭代了好多次。一开始使用 Storm 的时候,我们发现了,单一的组件需要有能力放出多个独立的流。我们发现了,Storm 批处理元组 (process batches of tuples) 作为具体的单元,需要增加一种特殊的“直接流 (direct stream) ”。最近,我又开发了“事务性拓扑 (transactional topologies)” ,在 Storm 至少处理一次的基础上,对几乎任意情况的实时处理需求,达成恰好通知一次的语义。

当然了,在自己不了解的领域三下五除二干出来再说,然后持续性地迭代,会导致一些渣代码。而面向痛苦编程最重要的特性便是大无畏地专注于重构。这正是规避“偶发复杂度 (accidental complexity)” (译者注:将概念上的构思施行于电脑上所遭遇到的困难。) 破坏项目的核心所在。

结论

用例在面向痛苦编程中至关重要,用黄金来形容它们的价值也不为过。而习得用例的唯一方法,就是写代码积累经验。

绝大多数的程序员都会经历这样的进化过程。一开始挣扎地让东西跑起来,代码乱得毫无章法,渣代码和拷贝粘贴的代码一塌糊涂。后来,你会发现结构化编程的好处,尽可能多地共享代码逻辑。然后,你学到了如何抽象,用封装的思想看系统。再后来,你着迷于通用化你的代码,让一切的一切可以拓展到未来的程序中。

面向痛苦编程拒绝相信人们能够有效地预测未知的需求,它承认,在不了解问题领域的情况下通用化代码,终将导致复杂与浪费。设计一定要,也总是要,驱动于活生生的用例。

EOF

© 2010-2018 Tian
Built with ❤️ in San Francisco