你们好，我是飘渺。前端
前几天跟一个团队技术负责人聊天，他说他们有个小的项目都是直接使用的SpringCloud。java
我问他为何，你这不是为了技术而设计吗？小项目用个单体架构不是很方便吗？程序员
他说我就是想用一下SpringCloud，熟悉一下。数据库
我问他，那你在使用SpringCloud过程当中有没有遇到一些问题，好比数据库怎么拆分？事务问题如何解决呢？怎么作的CICD？编程
他又说咱们不拆，就一个库。只不过在应用层规定了服务与服务之间只能经过接口调用，至于分布式事务嘛，暂时还没考虑。服务器
。。。。。。微信
都说兴趣是最好的老师，热衷新技术自己也是没错的，可是这样很容易形成一个问题就是在作项目的时候为了技术而架构，简单问题复杂化。架构
那软件工程师到底应该如何应对新技术呢？（固然这里提到的SpringCloud并不算什么新技术了）咱们看看 Karl Hughes 是怎么说的！框架
原文地址：http://t.hk.uy/8yS编程语言
2015 年，我带领一支工程团队为大学生构建了一个 Web 应用程序。因为录取工做已于 5 月结束，所以咱们只有 3 个月的时间为每一年 8 月的流量暴涨作好准备。
第一年咱们只有几千个用户，因此没有人担忧扩展问题。咱们使用了 Angular 前端和 MySQL 数据库，在 PHP 中构建了这款应用。
第一年结束时，咱们的应用程序架构
当咱们准备在第二年将用户规模增长到三倍时，咱们开始怀疑现有的应用程序可否良好地扩展。我开始学习全部最新的工具，聘请了一位经验丰富的 DevOps 工程师，而后制定了一项负载测试计划。
通过两个半月的混乱，研究了 Docker、Azure Service Mesh 和其余一些最新工具后，咱们意识到没法遇上 8 月的截止日期。咱们退后一步，从新考虑了所面对的问题。我开始向一些导师寻求建议，记得那天，其中一位叫我出去，对我说：
“你不须要那么多复杂的工具！”他告诉我。“在系统上再扔一台服务器就好了。”
为何新技术如此吸引人？
像许多工程师同样，我会抓住机会利用全部最酷的新工具。通过几个月的无谓尝试，我终于意识到解决方案原本很简单，而且咱们手头已经有了所需的工具。咱们水平扩展了 API，垂直扩展了数据库，这花了大约两周时间。
第二年开始时，咱们的应用程序架构
过后看来这显然是正确的选择，可是为何一开始它就不那么明显呢？为何甚至很有经验的软件工程师也会像飞蛾扑火通常被闪亮的新技术所吸引？
新技术承诺解决老问题
管理大量服务器很是困难，一直以来都是一个难题。当咱们迁移到云后，这个问题终于变简单了，如今 Kubernetes 承诺可让这件事情变得更轻松。与全部“烦人的旧东西”相比，新技术有望更快、更高效或更灵活地解决问题。若是你只看那些宣传资料，你可能会认为它们甚至没有任何代价可言。
咱们会由于用上了“最新和最棒的技术”而受到关注
我在 2015 年读到的全部文章都在说 Docker 将会有多伟大。他们坚持认为它将在短短几年内取代 VPS。早期采用的公司所以获得了不少正面的报道。我也想要这种关注。
求职者涌向新技术
不幸的是，由 Hacker News 推进的炒做周期使工程师认为他们必须采用最新技术才能跟上时代。对于新手开发人员来讲尤为如此。你想不到最近有多少培训班毕业生问我是否在使用新出的 X 或 Y 框架。甚至有人试着劝我将咱们的整个关系数据库转移到区块链上。
咱们也想变得很酷
“深刻其中并对全部事物作现代化改进是颇有趣的事情——固然，你能够在此过程当中学到不少东西（也许会以牺牲业务为代价）。”——David LeBlanc
我对丰富简历内容没什么兴趣，但我记得那时候我会想：“这将成为一次会议演讲上的精彩故事。”我如今可不敢这么说，由于在 2015 年的早期创业阶段尝试部署 Docker，结果以失败了结的经历，多是我迄今为止最大的管理败绩。
过早采用新技术的风险
几年前，我发现技术炒做周期是这么一回事：
“炒做周期中，市场先是对某种很棒的新事物有一段时期的夸大宣传，鼓励人们采用——直到技术逐渐真的普及开来，人们才发现新事物并无广告中所描述的那么神奇。而后这种新事物便会失宠，乃至被彻底丢弃或遗忘，直到它的成功所需的知识基础成型为止。”——Dick Dowdell
技术炒做周期
许多工程师在新技术诞生伊始的高峰期（也就是关注和讨论最多的时期）错误地采用了它们。问题在于，不成熟的技术会有全新和未知的故障机制，而现有的解决方案并不会如此。
软件工程团队须要浪费大量时间寻找不那么明显的错误、查找文档里没有的边缘案例并重写代码来适应新技术。这就是六年前咱们尝试采用 Docker 时发生的事情。咱们没有足够的资源来遍历全部没有文档支持的特性和选项，并且 API 会随着版本升级而不断变化。
就算这些问题并无令你困扰，但早期采用者仍会承担技术开发公司倒闭的风险。我记得有几个朋友很早就用上了 RethinkDB，但到了开发它的公司于 2016 年关闭时他们大失所望。尽管它后来做为一个社区维护项目又回来了，但让你的应用程序数据库陷入困境历来都不是什么好事情。
技术采用技巧
既然如此，若是新技术增长了太多没必要要的风险，为何咱们都没有停留在 1990 年代的 Java 版本上呢？咱们如何才能避免落后太多，以致于连升级途径都找不到呢？当咱们开始一个新项目时，咱们不该该使用最新的技术工具吗？
针对这些有趣的问题，答案都是“取决于具体状况”。
我已经开始为在软件工程团队中采用新技术的策略制定一些经验法则。请随意使用这些内容，也能够根据你的组织状况作出调整或创建本身的规则集。
给人们时间进行实验
我坚信能够给员工一些时间来在工做中学习新事物。这为他们提供了一种创造力的源泉，使他们保持领先，并能让你尝试一些业务永远不会优先考虑的事情。若是一位工程师使用他的学习时间来证实咱们的应用程序中可使用某些新技术工具，那么我会认真考虑此事。
“在将新技术用于产品以前，须要对新技术进行验证……你必须作出结果。若是不这样作，就是把产品推向了死亡之路。”——Andrew Orsich
保持一个默认技术栈
微服务的罪行之一是，它们鼓励公司使用不一样的编程语言来构建应用程序的不一样部分。虽然经验丰富的工程师可能会喜欢每周更换语言，但这会增长认知负担，并让新开发人员难以接受。当程序员选择的语言不同时，团队还会出现一些技术孤岛。选择一个技术栈做为默认选项，仅在真正须要时才作扩展。
保持核心的可靠性
当你选择尝试新技术时，请先考虑将赌注限制在不过重要的功能上。当你基于 SQL 构建平台时，很难采用某种新的、先进的数据库，可是在临时营销站点上尝试新的 UI 库并不难。一旦在非关键任务中验证了这项新技术后，你就能够决定在整个核心应用程序中采用它。
在整个应用程序中采用新技术的风险级别
记住业务目标
与我合做过的最优秀的那些工程师始终会牢记“为何”这一要点。他们在业务价值较低的应用程序部分中节约资源，而会花几周时间来完善核心数据模型。做为经理或团队负责人，你必须随时问本身为何企业须要这种技术。若是某种新工具进入市场，你就必须判断它会增长多少业务价值以及采用的成本。
结论
新技术并不坏。我喜欢尝试使用新的框架和编程语言，可是做为领导者，你必须在好奇心和业务目标之间取得平衡。人们很容易陷入未经验证的新工具的泡沫中，所以，你应该制定标准来帮助你决定应该什么时候尝试新的工具。
最后，我是飘渺Jam，一名写代码的架构师，作架构的程序员，期待你的关注。我们下期见！
关注即送10个G的教学视频哟！！！
本文分享自微信公众号 - JAVA日知录（javadaily）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。