【译】鼓吹驱动开发

在twitter上看到阮一峰推荐的这篇文章,觉得确实囊括了团队技术选型阶段很多不好的方式,尝试着翻译了一下,建议还是看原文。原文的标题是Hype Driven Development,我个人觉得Hype在这个语境下翻译成鼓吹比较好,因为很多人确实是在微博上看到某些大牛说某某新技术非常好,就迫不及待的也向周围的同事宣传,并极力在公司里推广(当然这个推广要分情况,也有推广了确实提高了团队生产力的,关键在于是否考虑了团队实际情况)。

以下是译文

软件开发团队经常基于不准确的看法,社交媒体以及被大众认为是最火的技术而不是扎实的调研和任何对项目产生预期影响的认真思考来对项目的软件架构和技术栈做决定。

新技术— 新希望

你见过吗?一个正在选择最新最火技术的开发团队。其中的某人看了一篇微博上正趋火热的博客文章,然后我们大家也刚刚从一场热情讨论这个的技术会议上回来。不久,团队就开始使用这个崭新闪耀的技术(或者软件架构设计范式),但是,团队并没有走的更远(原本承诺的),并没有开发出一个更好的产品,反而陷入了新的麻烦里。他们停下脚步,变得消极,很难正常交付产品的工作版本。一些团队甚至在不停的修改bug而不是交付新特性。他们需要所谓的“再过几天”来解决所有的难题。

鼓吹驱动开发

鼓吹驱动开发(HDD)有许多特点,而且会以不同的方式影响你的项目。

  • 社交网站驱动开发— 当一个团队或者个人在技术/架构/设计相关方面是基于博客上的流行文章或者reddit, hackernews, blogs twitter, facebook, GitHub以及其它社交媒体上的最火的东西来做决定的。
  • 会议驱动开发— 好好看看那些从技术会议上回来的人们。他们好像被打了鸡血。这种情况就是一把双刃剑,在没有经过足够的调研之前就开始使用最新最火的库/框架/架构范式可能是一条不归路。
  • 嗓门驱动开发—这种情况就是一个家伙总是不停的在谈论最新的某新框架/库/技术,但是其实他根本在这方面毫无经验,最终团队决定了去使用这个玩意。
  • 模块/库/插件驱动开发—这个情况在Ruby On Rails社区特别突出,我偶尔能看到一个非常长的Gemfile(注:描述Gem依赖的文件,类似Java里的pom和Node里的package.json)以至于我认为比它更长的就是加载app所消耗的时间了。这个局面产生的原因是来自于一个理念,就是在rails里每个问题都应该由对应的gem来解决。有时候明明只需要我们自己写几行代码就能搞定,但是偏偏要通过添加各种库,插件,gem或者框架来解决问题。
  • 我同样会在这提到在鼓吹驱动开发者中盛行的行为—Stack Overflow驱动开发—当开发者们从Stackoverflow(或者网络上)复制粘贴方案而没有真正理解它们时。
HDD就是团队如何将毁灭带给他们自己的方式

鼓吹带来的问题就是它很容易带来不合适的决定。糟糕的架构决策和技术栈决策经常在几个月甚至几年后让团队掉入陷阱。在最坏的情况下,将不得不导致另外一个软件工程学里非常成问题的情况出现:大重写(原文:The Big Rewrite),这种情况几乎没有什么好的发展。

所有罪恶的根源似乎是社交媒体— 新理念在它们被广泛实地测试之前,甚至在人们能够理解它们的利弊之前就已经广泛的传播开了。

对技术鼓吹的剖析

大多数的技术鼓吹都有类似的结构,如下:
hype-structure

第一步:实际的问题和解决方案

一切都开始于某家公司的某个具体问题。公司内的某个团队认为解决这个问题已经超出了公司现有的技术栈,流程和架构的范畴,于是公司开发了一个新的框架,库或者范式将这个问题解决了。

第二步:公告,八卦流行和关键词

团队很兴奋地要向外面展示他们的工作成果,很快他们在博客上写文章并且在各种技术会议上做会谈。这个被解决的问题通常是很不平凡的,所以他们非常自豪的呈现出一个让人印象深刻的不平凡方案的结果,人们纷纷被这个新技术打了鸡血,唯一的问题是并不是每个被打鸡血的人能够完全理解问题的实际情况和解决方案的所有细节,毕竟这是一个有着不平凡解决方案的不平凡的问题。通过不止一次tweet,chit-chat甚至博客去解释说明,加上使用社交媒体,博客帖子和会议上的快速演讲等通信手段让实际的信息逐渐在网络上失真。

第三步:狂热开始了

形形色色的鼓吹驱动开发者们读博客帖子,参加技术会议。很快全世界的团队都开始使用这项新技术。由于失真的信息 — 他们中的一些人草率地决定去使用这个框架,即使实际上不会真正解决他们的实际问题,然而团队又确实期望这个新技术能对他们有所帮助。
mania-starts

第四步:失望

随着进入项目开发的冲刺阶段,这项技术并没有像人们期望的那样改善了团队的开发质量,反而带来了大量的额外工作。有非常多的代码重写工作和额外的学习成本在等待着团队成员。团队降低了开发速度,项目管理也变得令人厌烦,人们感到受骗了。

第五步:觉醒!

最后,团队做回顾总结,终于意识到什么才是新技术带来的折衷代价,为了什么目的它才是更有意义的。他们变得更理智了。。。直到下次技术鼓吹出现。

技术鼓吹的案例

让我们来看看一些技术鼓吹案例的前后经历。

案例 1: React.js

第一步: Facebook发现一个问题— 像Facebook自己那样,高级的单页面应用会有非常多的状态变化事件以至于很难跟踪发生了什么,很难保持应用状态一致。

第二步: Facebook通过流行词促进了新的范式:函数式(functional),虚拟DOM(virtual DOM),组件(components)。

第三步: 狂热:Facebook已经创造了未来的前端框架!从现在开始用react重写一切吧!

第四步: 大量的工作需要去做,但是不能马上有回报。

第五步: React对于有着非常多实时通知的高级单页面应用非常有用,但是不一定能简化应用程序。

案例 2: DHH说的TDD已死

第一步: David Heinemeier Hansson (DHH, Ruby on Rails 框架的创建者)意识到使用Rails很难做TDD,因为这个框架没有很好支持OOP的架构,所以他做了个务实的选择 — 不提前写测试用例。

第二步: 随着DHH的博客和技术会议上的会谈,技术鼓吹开始了,鼓吹关键词:TDD已死(TDD is DEAD)。

第三步: 让我们跳过测试!我们的导师是这样说的。我们完全不写测试用例。现在至少我们不用假装了。我们终于诚实面对了。

第四步: 慢着!怎么比以前起作用的部分更少了。我们的代码全是bug。

第五步: “TDD不是什么死了还是依然健在,TDD需要从以下方面进行权衡,包括API变动的风险,从业人员技能和现有设计” —Kent Beck。

案例 3: 微服务

第一步: 大型单一应用扩展困难,将其拆分成子服务是很有意义的。在网络请求模型中扩展更简单,同时也能更轻松的跨越多个团队进行扩展。

第二步: 鼓吹关键词:可扩展性(scalability),松耦合(loose coupling),整体性(monolith)。

第三步: 让我们把一切都重写成服务!我们有一个“意大利面条式代码”是因为我们有一个大一统的架构!我们需要用微服务的方式来重写一切!。

第四步: Shit!现在开发应用的方式很慢,而且难以部署,我们花了很多时间在多个系统间跟踪bug。

第五步: 微服务需要团队成员拥有相当水平的devops技能,而且正确的投入能够作为扩展系统和团队的一个方式。 (注:原文是Microservices require a lot of devops skills in the team and with right investment might pay off as a way to scale the system and team. 这里我感觉翻译的不好,请告诉我更好的解释),在你遇到严重的扩展问题之前,这将是个过度投入,微服务是提炼出的而不是直接写出的,你必须要在认识上达到这个高度才能去使用微服务

案例 4: NoSQL

第一步: 传统的SQL数据库在高负载和非结构化数据问题方面存在问题,全世界的团队都开始开发新一代的数据库。

第二步: 鼓吹关键词:可扩展性(Scalability),大数据(BigData),高性能(High Performance)。

第三步: 我们的数据库太慢了而且不够大!我们需要NoSQL!。

第四步: 我们需要表连接查询吗?那是不行的。简单的SQL操作变得越来越有挑战性,开发变得缓慢而且我们的核心问题并没有解决。(注:看到这我想起我很久以前在武汉参与的一个电商云平台,明明事务很重要,当时就是听公司一个架构师在IBM做社区系统的经验鼓吹用MongoDB,导致后续连续事务操作开发繁琐无比,后来我就离职不干了)

第五步: NoSQL是解决非常具体问题的工具(特别海量的数据,非结构化数据或者特高负载)。SQL如果能巧妙的用好实际上也是一个伟大的工具,能够很好处理高负载和海量数据。即使在2016年,使用NoSQL的案例也是十分少见的。

案例 5: Elixir 和 Phoenix(或者把你喜欢的一对lang/框架放在这)

第一步: 像ROR这样的框架不能很好的胜任高性能应用,分布式应用和websockets。

第二步: 鼓吹关键词:可扩展性(Scalability),高性能(High Performance),分布式(Distributed),容错性(Fault-tolerant)。

第三步: 天啊,我们的应用好慢,而且我们的chat无法扩展!

第四步: Wow,学习函数式编程和分布方法不是那么容易的,现在进度很慢。

**第五步:**Elixir 和 phoenix是伟大的框架,但是需要付出极大的努力去学习。如果你需要一个特别高性能的的应用,你必须经历一个长周期后才能获取回报。

列表继续:

在这个繁杂的计算机工程的范畴里,很多领域技术鼓吹都是常见的。在JavaScript世界里几乎每天都有新的框架诞生。Node.js(关键词:事件驱动编程(event programming)),reactive programming,Meteor.js(关键词:共享状态(shared state)),front-end MVC,React.js。还有什么由你命名。在软件工程中出现了新的架构:Domain Driven Development,Hexagon,DCI。什么是你喜欢的技术鼓吹调调?

好的做法

既然我们不能依赖网络上的说法和其他人的意见,那么如果做出聪明的决策?下面有几个好的做法:

在你做出决定之前要进行测试和调研:
  • Spikes—不要从博客里了解你的技术,而是从经验中来。在做出决定之前,花1到2天用新技术构建新功能的原型。让团队来分析利弊。你也许需要拿一组互相竞争的技术方案,让团队的不同成员使用不同的技术方案来构建原型。
  • Hackathon是建立团队对不同技术进行权衡意识的好方法,花1到2天时间为团队去攻击所有那些正冉冉升起而且足够有有活力的技术方案。这将使得团队能自己做出更明智的决定,能基于自己的经验采纳别人的决定。
何时行动?
  • 原则上投入后的回报应该是巨大的。大多数技术是为了解决特定问题而生的。你有那样的问题吗?这是个大问题吗?这个方案会节省很多时间吗?新技术的使用会回报学习曲线成本和重写成本吗?如果我们一开始进度比以前缓慢到2倍?或者4倍?是否值得呢?
  • 优秀的团队才能被允许更多 — 一些团队就是比其他团队更快交付产值。他们更容易对所做的事感到无聊,这些团队可以更频繁地引入新技术。这不是不去使用Spikes和Hackathon的理由。另一方面,如果团队在交付时遇到麻烦 —请谨慎处理。
雇用正确的人才
  • 强大的技术背景是挚友— 那些知道不同的范式,理解编程理论(比如算法,并发),有良好的工程师文化背景的人更倾向少鼓吹。
  • 经验—技术鼓吹现象对年轻的开发者来说出现的更为强烈。数年来那些已经见识过很多技术方案并跳入陷阱多次的人趋向于在技术选型方面获取更为均衡的看法。
    hype-is-strong-with-this-one

原文链接:
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22#.gvgz2rxqw

Show Comments