BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

The Rise and Fall of Software Recipes作者访谈

| 作者 Shane Hastie 关注 11 他的粉丝 ,译者 王强 关注 0 他的粉丝 发布于 2017年5月3日. 估计阅读时间: 15 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

关键点

  • 相比起取得成功而言,软件工程主要的目标是避免失败
  • 软件项目都是独一无二的,应用套路式的方法会很危险,开发流程必须为项目进行调整
  • 多数情况下短迭代没什么问题,但有时它会严重影响生产力
  • 测试是至关重要的,但是我们必须搞清楚怎样做测试以及测试些什么
  • 任何来自高层、教练、书本、方法论的规则都应接受全面考察,否则就不能应用到实际当中

Darius Blasband是The Rise and Fall of Software Recipes的作者。在书中他挑战了软件工程的传统观念,抨击了行业中流行的开发套路(recipe)与标准化方法,并对现状表达了不满。他自称代码狂人(codeaholic),认为开发者应该仔细推敲特定的上下文对象(specific context),并尽可能使用领域特定语言。

这里是本书的两个试读章节:序言套路

InfoQ:请问你为何撰写本书?要指出什么问题?

Darius Blasband:我经常花费很多时间在路上颠簸,用几小时甚至几天时间坐火车飞机,住宾馆,穿越多个时区进行长途旅行。结果跑了那么远经常只是为了开个一小时不到的商务会议,简直是浪费光阴。然后我就开始在路上写笔记,积少成多,最后就有了这本书。

但这并不只是用来打发无聊时间的产物。

我想在书中指出的问题是软件工程中缺乏历史视角的现象。人们把新技术、新方法或新的编程语言当成万能的魔法石,却忽视了过去四十年间有数以百计类似的出色发明曾涌现和消亡。

就拿敏捷运动来说吧。敏捷被认为是软件领域所有相关问题的终极解决方案。但如果它自夸的这套说辞真的可信,21世纪之前就没人写过任何优秀的软件应用了。

显然(而且是幸好)事实并非如此。

稍稍回顾下历史就能发现,敏捷所推崇的许多方法已经存在许久了。抛开时髦的术语和狂热的追随者不谈,敏捷对现代软件开发行业几乎就没什么贡献。

另一方面,缺乏大局观的一个重要表现是,大多数软件项目首要考虑的是开发周期,人们会用尽最先进的技术和技能来控制项目耗时。

很多任务关键型软件系统需要运转二十年甚至更久。它们必须跨越多个技术变革周期,目睹曾经强大的供应商逐渐消亡,具备来之不易的专业技能的关键工程师也会成批退休,诸如此类。

如果从大局考虑,对于重要的软件系统而言,为控制开发周期而忽视系统长期运行的需求(虽然后者没那么吸引人)显然是对资源的极大错配。

InfoQ:为什么你会是写这样一本书的最佳人选?

Darius Blaband:我真的是最佳人选吗?我看不见得。

但如果非要我回答这个问题,我要说:

  • 因为别人都不写
  • 因为在工业软件开发行业有30年以上经验的人大都已经离开纯技术领域很久了。而技术细节比一般的管理理论所认为的重要得多
  • 因为我不搭理任何人的问题(除了我太太,我们的交流自在不言中),所以我可以质疑现状,抨击现在的陈词滥调,而不用担心这会影响我的私人生活
  • 因为我足够幸运,多年来参与过诸多差异明显的项目。这些项目有大有小,有为小商店开发的,也有为跨国公司开发的,有的用于普通的行政用途,也有独一无二的尖端项目

InfoQ:什么是“软件套路”,它们的本质问题是什么?

Darius Blasband:我所说的套路指的是约束开发者开发方式的东西,包括所有的方法论、所有的软件开发流程定义、所有分解任务的优先规则等。这些套路与具体的应用、技术环境和性能约束等因素都无关。

瀑布流方法论就是套路。

敏捷运动声称它推崇的东西并不算方法论,但他们还是坚持使用短迭代、持续测试这些东西。这是非常规范化的,在我眼中这当然也是一种套路。

简单来说,我不喜欢软件套路。

因为软件有很多形式,环境约束可以大相径庭,项目规模也是如此。软件的关键程度、与外界的交流界面、对时间和预算的敏感性等等,这些因素都会千差万别。

简而言之,各个软件项目之间有着明显的不同。用一套预先写好的规则应用到所有场景中就会忽略这些差异,并假设这些区别相比项目之间的共通点是无关紧要的。但这种假设未经充分的实践验证是不能随意下定论的。

不夸张地说,几乎没人正式对上述假设做过验证,就算有过,结果也是不确定的。

InfoQ:你的结论是否意味着团队不应该遵循任何流程或方法?那么他们应该怎么做呢?

Darius Blasband:关于软件开发行业,我并不倡导无约束的状态(虽说这种状态不像很多人想象的那么可怕)。我们可以规划项目,也可以定义任务。简单说,很多情况下我们可以预先制定一套流程。

但这套流程必须为项目本身进行适配,不应该照抄一体通用的规则册子:

  • 多数情况下短迭代是可行的,但有时它会变得效率非常低下。每周堆一截梯子看起来也是在取得进展,但如果目标是登上月球时就是另一回事了。
  • 测试是至关重要的,但我们必须知道怎样去测试以及测试些什么:
    组件,系统,性能,功能,稳定性,鲁棒性,等等;
    有些人是为测试而测试,测不到正确的点上,结果产生不了什么实际价值。

总之,我们可以为当下的项目制定一套对应的流程,流程中所有的决策都应该根据现实情况进行合理的评估。不要武断地做任何事情。任何来自高层、教练、书本、方法论的规则都应接受全面考察,否则就不能应用到实际当中。

在解决任何问题时,如果给出方案的理由最终归结到“因为敏捷宣言是这么说的”,你就该知道麻烦大了。

InfoQ:代码狂人是什么意思?它和code hacker、fix hacker有什么区别?

Darius Blasband:hacker专注于尽快找到解决方案,他们了解书里书外的所有技巧,知道怎么走捷径来实现目标。hacker几乎只看重执行力。“它奏效了”就是他们的格言。

代码狂人的动机是完全不同的。

他们意识到代码是一次写就,多次读取的。他们不会为了尽快赶工而牺牲代码的质量。在代码狂人眼中,一份软件的真正价值体现在它的可维护性、可读性与易于修改的程度上。

由此,代码需要优雅,需要有描述清晰的用途,需要遵循规范。因为这些会让代码更易预测,更容易管理,也更方便理解。

让软件正常运行,配备所需的功能并实现足够的性能的确重要,但这并不是终结,而只是漫长道路的起步。真正的功夫在于让代码可管理、可读、优雅并井井有条,这才是最难做到的部分。

InfoQ:你声称“相比起取得成功而言,软件工程主要的目标是避免失败”——为什么这么说,它对我们开发软件有什么启迪?

Darius Blasband:关于“为什么”这一点,这个观点来源于行业本身的复杂性。当设备有如此之多的活动组件时,往往就会出现组件损坏的情况。

对于整个行业来说,我们强调这一点有多种含义:

  • 我们使用冗余来减轻故障的影响
  • 我们投入大量精力进行测试,说明我们对开发团队的交付质量缺乏信心,而这种怀疑往往是理直气壮的
  • 如果可以,我们会简化解决方案,缩小适用范围,进而有效减少活动组件的数量
  • 我们使用分批交付策略,这样在最坏情况下,就算项目跳票超支,也起码能展示并交付一些有价值的成果
  • 听起来不可思议,我们甚至要做到教育用户必须要容忍某些故障的程度(如果一家车行提醒你他卖的车一年总会有几次打不着火,但就算打不着也没关系,你可以下车,锁门,然后再开门进车试着再发动一次,如此往复。他还说这种事儿一年出个两回不是什么大事儿,用不着抱怨——你会买他的车吗?)

InfoQ:你推崇领域特定语言(DSL),那么DSL有什么用,实践中面临哪些机遇和挑战?

Darius Blasband:公平来讲,对不同的人而言,DSL概念可以呈现出非常多的形态。很多人关注它到底是什么(是不是已有语言的扩展,或者它的不同概念之间的交集是怎样的)。

我个人对DSL的理解更看重它是怎样应用的:DSL是由一小组人管理或定义的语言,小组可以根据自身的特定需求来调整他们的DSL。

某种程度上,受众的规模是一个主观因素:小组要成为DSL的受众,最小的规模是多大?

另一方面,可变性是更主观的衡量指标。

DSL策略可以让DSL用难以度量的参数进行调整,由此使项目在范式的复杂程度、DSL的预定义能力和使用DSL撰写的用户代码中的组件之间取得平衡。

它是分治的终极形式。

我的意思是,我对DSL非常着迷。我擅长语言和编译器。对我来说,写DSL是最轻松的事情。

即便有的工程师缺乏丰富的编程语言技能,但严谨的DSL项目对语言基础架构知识(词义、语法和语义分析)的要求相比其他任务却小得多:这些任务包括将它与其他基础设施对接,提供基本范式区块,支持用户,等等。

问题在于,忽视语言的基础架构,转而扩展一种已有的语言,结果将DSL仅仅用作一个库,这种设计思路是很低级的。

如上所述,仅用DSL操作句法就无法让DSL变得更具弹性,更有表现力了。

重要的不仅是句法。DSL也是一种能以较低成本较容易地轻松获得成果的途径。

InfoQ:你在书中提到了一些debug的技巧,那么有哪些关键点呢?

Darius Blasband:如果只把debug看作是从系统中挑出bug的流程,那么它的性价比就很低了。聪明人会在debug阶段细心地研究为什么实际行为与期望会出现差异,这种差异是怎样产生的。

debug不仅消耗很多资源,还会让人抓狂。我们经常会奇怪这些bug当初是怎么钻进系统里去的。

不过其实我们没必要纠结。debug并不仅是一个流程,它也可以是一种可交付的内容。它能提升软件的价值,软件从debug中得到的可以不仅是修正缺陷。

提升价值的最简单方法是引入一种规则,在给出bug的解决方案之前先在测试用例中重现它们。这样一来,bug一旦再出现就能被测试套件侦测到。除了去除bug以外,期望的行为被可执行的测试用例正式记录下来,这也是对软件的改进。

不过软件debug并没有通用的最优手段。每一位开发者都有自己偏好的debug工具或流程。

有些人会对复杂的调试器无所不用其极。

我个人更像是个科技恐惧者,也比较懒,不喜欢研究越来越复杂的debug工具。我就是烦它们。

我用的是简单得多的技巧。倒不至于原始到把代码打出来慢慢研究,不过也够简单的了。

在软件出现bug的地方,我会添加断言(几乎所有现代编程语言都支持)来检查代表系统应有行为的情况。通过增加越来越多的断言,我会逐渐缩小bug的出现范围(就是进入之前一切正常,离开时就出错了的部分),最后我就能锁定源头并解决bug。

这套方法的美妙之处在于代码中的断言会保留下来。

有了这些断言,相同或类似问题再现时可以被迅速侦测,而且它们会正式成为系统的一项资产,包含了开发者的知识,并为未来的代码维护人员留下了参考。

这些断言远比简单的注释可靠,长久以来代码升级时没人会去维护注释内容。断言会渐渐偏离自己实际的行为,它们可执行,也可用来测试。

InfoQ:对本书的读者你有什么话想说吗?用一句话总结一下。

Darius Blasband:以史为鉴。

硬件在不断升级:存储、带宽和计算资源如今丰富得像免费一样,新的编程语言也不断涌现。但最重要的原则几乎没有改变:我们,作为软件开发者,并不比我们的前辈们聪明得多(或愚蠢得多)。我们与古人一样充满智慧,却也没比他们进化到哪儿去。

整个行业用了超过三十年时间寻找万能的魔法石,寻找一种让开发流程井井有条的手段,一种方法论,一种任务的分解规范以使开发者可靠而确切地产出所需的成果。总而言之,行业期待的就是一种软件开发套路。

一次又一次,人们都失败了。

经过三十年时间,我们该意识到这种努力永远不会成功了。因为它被一种未曾进化的元素卡住了:就是我们人类。

在我看来,这种企图就像是寻找独角兽。人们陷入一种谬论,觉得没人见过独角兽不代表它不存在。

但是有些东西真的是不存在的。

接受现实吧。

关于作者

Darius Blasband有法语布鲁塞尔自由大学(比利时ULB)的硕士和PhD学位。他专注于老旧代码的翻新,研究编译器对老旧语言的兼容手段。Darius是Raincode的创始人兼CEO,也是该公司的主设计师和核心技术制定者。他是学术和工业圈中著名的演说家。

 

查看英文原文:Q&A on The Rise and Fall of Software Recipes


感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

三十年不够 by wang sun

不懈探索三千年再下结论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT