⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://yuhao.space/blog/2019/02/should-we-restraint-from-seeking-new-tech 「流光飞舞」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

毋庸讳言,程序开发是一个快速发展的行业,尤其是最近几年,从Web/移动到云、容器、DevOps、大数据、大前端、VR、区块链、人工智能,我们似乎有永远学不完的新技术;同样明显的是,程序员这个开发群体也极其热衷于追求各种更新、更酷、更强大、更优雅的技术。很难全面地评价这究竟是好事还是坏事,似乎我们已经把这当成一种不言自明的事实。

但最近,我听到了一些特别的声音,虽然它们来自不同技术背景的开发者,立场和观点也不尽相同;但这些内容似乎指向同一个结论,即:一些被认为是“老旧”的技术实际上是被低估了;而另外一些为众多开发者所追捧的新技术,它们未必真正达到如预期的那种生产力提升,并且,使用“老旧”的技术实际上可以达到同样的效果。无论如何,这些确实来自真正的一线开发者的实际经验总结。我希望你能够听一听他们的声音。

在我的职业生涯中,没有一种技能比 SQL 更有用!

作者是一个以 Postgresql 为主要产品的云服务提供商负责人。他的核心观点如下:

在我的职业生涯中,我学到了很多技能,但没有一种技能比 SQL 更有用。SQL 在我看来是最有价值的技能,

  1. 它对于不同的职业角色和学科来说都是有价值的;
  2. 一旦学会了就不需要重新再学;
  3. 它让你看起来像个超级英雄。一旦你掌握了它,而其他人不懂,你就显得特别强大。

我的意见:部分同意作者的说法。在这些年中,我观察到的一个有趣的趋势是:各种 NoSQL 技术开始时都标榜自己和传统 RDBMS 的不同,但随着产品的发展,他们最终还是发现自己需要 SQL (或类似的东西)。不过,我认为 SQL 也有自己的问题,那就是作为数十年前发布的技术,它没有包含关于如何分布式执行的内容,而这是从 Google 的早期论文到现在的各种数据平台一直在致力解决的。此外,目前似乎有一种令人讨厌的趋势,即随便哪个公司都声称自己在应用大数据。我相信很多小公司的数据问题是可以在 SQL 的层面得到解决的。

关于作者的观点,有一个有趣的佐证,那就是 TIOBE 的编程语言趋势报告。

TIOBE Programming Index

从图中我们可以看到,在排名前 20 的语言各自都有不同程度的起起落落,唯有 SQL 从 2004年以后就保持了惊人的稳定,几乎没有任何浮动。为什么 SQL 能保持如此稳定的分数,TIOBE 并没有太多公开的细节可供参考,但这确实在一定程度上证明了作者的结论。从长期来看,SQL 或许应当被看作一个回报率不算突出、但非常稳定和值得信赖的投资。在投身学习纷繁复杂的各种数据技术之前,或许你应该首先了解一下这个已经存在了 50 年之久的名字:SQL。

为什么说 TypeScript 不适合大型项目?

尽管起了这样一个题目,但通读全文后你会发现,作者本人其实是很喜欢 TypeScript 的,并且在生产环境中大规模应用了 TypeScript。作者对项目结果进行了评估,最终得出结论:

我对 TypeScript 的好处、成本和不足都有了更深入的了解。我想说的是,它并不像我所希望的那么成功。除非它有很大改进,否则我不会在另一个大型项目中使用 TypeScript。

换句话说,TypeScript 并非没有价值,只是没有之前预期那么高的价值,加上引入 TypeScript 所带来的成本,使得作者认为在 TypeScript 上面的投资不太值得。

我的观点:个人比较感兴趣的是作者对项目进行评估的方法。从文中来看,作者通过开发工具、API 文档、重构、培训、招聘等方面对引入 TypeScript 的效果进行了评分。这个方法应该说是有一定参考意义的,同时,对于各个指标的分析作者也进行了详细的说明,值得一看。作者还提到了一个很有价值的观点(也可能是有争议的):TypeScript 所推重的类型安全对减少 bug 实际上没有想象的那么大,而比较传统的技术,包括单元测试和 Code View,能更全面地覆盖问题。类型安全似乎也没有多大差别。再次引用原文:

TypeScript 的支持者经常谈论类型安全的好处,但很少有证据表明类型安全会对 bug 密度产生重大影响。这个很重要,因为代码评审和 TDD 会带来很大的差异(仅在 TDD 方面就有 40% 到 80% 的差异)。将 TDD 与设计评审、规范评审和代码评审结合起来,可以看到 bug 密度降低了 90% 以上。其中的一些流程(尤其是 TDD)除了能够捕获到 TypeScript 可以捕获的 bug 之外,还能捕获到很多 TypeScript 无法捕获的 bug。

我猜测作者的结论可能会让很多 TypeScript 的拥护者有点受伤。不过我个人明确地对作者的这一观点表示赞同,即:比起各种新技术带来的改进,单元测试和代码复审理应在开发工程中发挥更大的作用。

Docker:一场令人追悔莫及的豪赌

本文的主要观点是,把所有赌注压在 Docker 上面是危险而不合理的。作者所推崇的是另一条道路:将程序部署为所谓的大型二进制文件或 uberjar(最适合这种模式的语言包括 Java、Golang 和 Clojure 等),从而在最大程度上避免依赖造成的问题。在这种场景下,不用 Docker 而使用传统的运维技术,包括 Chef、Puppet 和 Ansible, 同样能有序地管理服务器,而且避免了 Docker 带来的问题。同时,作者认为 K8S 带来的编排仍然是有积极意义的,但作者也提出了这样的疑问,即编排一定要基于容器吗?换句话说,一定要基于 Docker 吗?

原文很长,涉及的内容也相当多,可能需要反复阅读才能理解(我自己是读到第三遍才比较有把握说读懂了原文)。另外,该文是对作者前一篇文章《Why would anyone choose Docker over fat binaries?》的集中回应,因此先阅读上一篇文章有助于更好的理解文章的背景。

说实话,在读到本文之前,虽然我也知道 Docker 存在一些缺陷,但并未从系统角度去理解这些缺陷意味着什么。而本文很好的开阔了我的视角,在这个意义上,即便我并不同意作者的一些最终观点,但我仍然认为作者看待问题的角度是值得了解的。

作者提出的以下意见可以视为忠告:

最好将Docker视为一种高级优化方案。没错,它很酷且功能相当强大,但其同时也会增加系统复杂性,且只有专业的系统管理员才能够理解如何在生产中安全使用Docker并将其部署在关键性任务系统之内。

就目前来看,您需要掌握更多系统专业知识才能使用Docker。事实上,几乎所有Docker相关文章都只展示过分简单的用例,而忽略了在多主机生产系统上使用Docker所带来的复杂性挑战。这无疑给人们留下了Docker的实际生产应用非常简单易行这一极为错误的印象。

在计算机编程领域,流传着这样一句至理名言:“不成熟的优化是万恶之源”。然而,今年以来我们的大部分客户都坚持“我们必须从起步阶段就全部实现Docker化。”因此不同于传统最初最佳实践要求的建立一套工作系统、将其投入生产、最后考量Docker能否带来比较优势的作法,客户们开始盲目推动Docker的标准化开发与部署。

此外,本文还引用了另一位开发者的文章,该开发者由于在生产环境中引用 Docker 遇到了许多重大问题, 因而对 Docker 的批评更加激烈,以至于建议不要在任何严肃的场合部署 Docker。虽然观点可能有过激的嫌疑,但毕竟也是来源于一线的生产实践,并且提到了 Docker 文件系统和接口演变的一些内幕,还是颇为值得一看的。

Docker in Production: A History of Failure

写在后面

新技术肯定有新的价值,这一点毫无疑问,我也无意否定开发者求新求变的理想和追求。但在追逐新技术的同时,请不要忘了我们的“老”技术,不管你用或不用,它们就在那里。

最后,我还是想引用 《Docker:一场令人追悔莫及的豪赌》一文对旧技术的评价,因为这段文字深得我心:

无聊的好处(限制水平较高)在于,这些东西的功能相对更容易理解。而更重要的是,我们能够更轻松地了解其故障模式。……但对于闪闪发光的新技术而言,其中的未知因素要多得多,这一点非常重要。

换句话来说,已经存在了十年的软件更易于理解,而且未知因素更少。未知因素越少,运营开销越低,这绝不是坏事。

文章目录
  1. 1. 在我的职业生涯中,没有一种技能比 SQL 更有用!
  2. 2. 为什么说 TypeScript 不适合大型项目?
  3. 3. Docker:一场令人追悔莫及的豪赌
  4. 4. 写在后面