1. <em id="2qvri"><tr id="2qvri"></tr></em>
      1. 首页»程序人生»我们是否应当克制对新技术的追求?

        我们是否应当克制对新技术的追求?

        来源:流光飞舞 发布时间:2019-02-25 阅读次数:

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

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

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

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

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

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

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

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

        TIOBE Programming Index

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

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

          尽管起了这样一个题目,但通读全文后你会发现,作者本人其实是很?#19981;?TypeScript 的,并?#20197;?#29983;产环?#25345;写?#35268;模应用了 TypeScript。作者对项目结果进行了评估,最终得出结论:

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

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

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

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

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

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

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

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

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

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

        最好将Docker视为一?#25351;?#32423;优化方?#28014;?#27809;错,它很酷且功能相当强大,但其同时?#19981;?#22686;加?#20302;?#22797;?#26377;裕?#19988;只有专业的?#20302;?#31649;理员才能够理解如何在生产中安全使用Docker并将其部署在关键性任务?#20302;持?#20869;。

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

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

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

          Docker in Production: A History of Failure

         写在后面

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

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

        无聊的好处(限制水平?#32454;擼?#22312;于,这些东西的功能相对更容易理解。而更重要的是,我们能够更轻松地了解其?#25910;?#27169;式。……但对于闪闪发光的新技术而言,其中的未知因素要多得多,这一点非常重要。

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

        QQ群:WEB开发者官方群(515171538),验证消息:10000
        微信群:?#26377;?#32534;微信 849023636 邀请您加入,验证消息:10000
        提示:更多精彩内容关注微信公众号:全栈开发者?#34892;模╢sder-com)
        网友评论(共0条评论) 正在载入评论......
        理智评论文明上网,拒绝恶意谩骂 发表评论 / 共0条评论
        登录会员?#34892;?/span>
        江苏快3投注技巧