您团队中的某人有一个令人兴奋的建议，一种新技术要介绍。 但这是个好主意吗？
通常，眼前的利益要比眼前的风险或长期的事情容易得多。 本文着眼于在软件开发和运行中实施新技术时要提出的问题和预防措施。
首先，认识到不同的技术带来不同的风险。 问问自己-可能发生的最坏情况是什么？ 什么痛苦是不可避免的？ 还问-可能发生的最好情况是什么？ 最后，我如何才能以最小的危险实现这一目标？
风险概况中最大的区别因素是这个新想法在技术堆栈中的位置：
- 一个人使用的程序是低风险的。
- 测试工具对于探索是相当安全的。
- 生产中运行的任何内容（包括监视和日志记录）都存在更多风险……
- 或将代码投入生产的任何内容（配置，构建，部署）。
- 一种新的编程语言带来了特殊的负担。
- 移动数据的组件需要勤勉的支持。
- 最后，要当心将信任授予新的生产数据记录系统。
该频谱如下所示。
还不怕吗？ 让我们详细考虑这个风险范围内的四个要点。
风险极低：本地开发人员实用程序
开发是自动化的，快速的开发人员可以自动化开发。 风险最低的技术由我们在我们自己的机器上运行。 我可以加快的任何重复性任务都会增加一天的时间，而成本却很少。
这是一个极端的例子：命令行别名。 我每天输入一百次“ git status”，因此我将shell配置为“ alias gs ='git status'”。 这是一个很小的优化。 它只影响我：团队中没有其他人，没有客户。
当我进行良好的优化时，它可以遍布整个团队。 那是可能发生的最好的事情。 整个团队在余生中都可以提高工作效率。
可能发生的最坏情况是什么？ 我使用另一台计算机，不记得如何询问哪些文件具有本地更改-似乎不太可能。
实际上，情况有些糟：在某些Linuxy VM上，我在每个命令提示符下键入“ gs”的反射使我进入名为“ ghostscript”的程序，这完全不是我想要的，然后我必须记住如何退出它，然后我都对沮丧的ghostscript感到沮丧，分心和诅咒。 足够的时间后，我编辑该机器的外壳配置以添加别名。
现在我的指纹在上面了； 牺牲了统一性，并且整个公司的命令提示符都难以预测。 即使是这种微小的工具也会产生一些后果。
您是否应该禁止开发人员创建别名或安装他们个人认为有用的程序？ 没有！ 仅当您喜欢喜欢重复而不是自动化的开发人员时。 如果一个人避免自动化，他们会成为一个好的自动化者吗？
在对技术说“不”之前，请考虑对保留的影响。 什么样的开发商会留下来？ 我曾经在一家公司工作，安装文本编辑器的正确过程包括填写表格并等待一个月的批准。 我没有在那里工作很长时间。
低风险类别
- 仅影响选择使用它的人
- 如果我们停止使用它，那我们就是以前的样子
优点：团队中的其他人学习了他们不知道的工具，整个团队的生产率提高了。
缺点：切换环境很困难，因此很难配对。
必然成本：只需设置。
激励措施：开发人员感到有权自动化。
中度风险1：部署基础架构
有什么比自动化我的工作更好？ 为整个团队自动化任务。 这有什么风险？ 如果此工具失效，我的整个团队将被淘汰。
开发的结果不是代码：它是生产中的工作软件。 两者之间有很大的鸿沟。 DevOps将其与自动化联系在一起。 基础结构工具生成可执行文件，运行测试，将新版本推入生产环境，并进行监视以确保它们可以正常工作。
这些是最近的创新热点。 持续的改进在这里有很大的影响-在这里没有取得进步的任何公司都会落后并失去竞争优势。 但是费用是多少？
新技术可能很小：只要提交代码，GitHub Webhooks就可以触发CI构建。 或强制执行代码格式的质量检查提交挂钩。
可能更大：用于日志聚合的Splunk或用于声明式配置的Ansible。 甚至可能是Docker-整个系统都值得担心。 您编写的那个小bash脚本也很重要！ 任何可用于每个构建/测试/部署的内容都是您团队核心工作的一部分。
可能发生的最坏情况是什么？ 它中断了，您无法部署。 那很糟。 如果它与某些紧急生产错误同时发生，则非常糟糕。
当部署过程由于其他原因中断时，每个新工具都是我们必须检查的项目。 人们必须了解关于代码如何进入生产的另一件事。 通过频繁运行部署来减轻这种风险，因此不会有潜在的意外。
什么是必然的苦工？ 当我们启动时，还需要设置一件事。 现代建筑的趋势包括更多，更小的项目，因此更频繁地启动。 我们要么将其添加到我们的项目设置自动化中，要么每次执行并对其进行故障排除。
关键是：公司中的某些人必须了解此工具。 必须有人知道它是如何工作的，适合的位置以及为什么在这里。
如果您要介绍这项创新，那个人就是您。 为了降低风险，它不能只停留在您身上。 您的队友有兴趣了解吗？ 该文档的质量如何，以便他们可以从您之外的其他来源了解它？ 该bash脚本的可读性如何？
我们的每个工具都需要所有权。 对于我使用的工具，我拥有它，没问题。 对于每个人都使用的工具，答案是“谁拥有这个工具？” 不太明显，更重要。
生产过程中的任何程序都需要维护和保养； 如果其代码不变，那么周围世界将发生变化。 工具已升级。 环境在变化，业务约束也在变化。 责任不随执行而终止：当程序不再运行时，责任终止。
如果这听起来很痛苦，别忘了问，可能发生的最好情况是什么？ 部署自动化远比节省时间大。 它改变了激励措施，使变革更安全，更具吸引力。 这样做的影响远远超出了团队范围：整个企业有权进行试验并加快行动速度。
共享了影响最大的开发工具，但是共享它们会引发所有权问题。 如果您已经有了DevOps的心态，那么DevOps团队可以为您提供帮助。 他们可以通过提供基础结构并对这些共享工具负责来提高所有其他开发人员的生产力。 他们研究收益并承担风险。 他们出售使用它们的开发团队。
Twitter，Netflix，Lyft和许多其他公司都这样做。 对于不太注重软件的公司，个人开发人员的主动性会有所作为。
中度风险类别
- 部署自动化
- 被许多开发人员使用
- 在验证或部署路径中
优点：变更的风险降低了，痛苦也减轻了。
缺点：发生故障，生产部署受阻。
不可避免的成本：持续的所有权和维护
激励措施：开发人员有权改善整个部门。
中度风险2：编程语言
编程语言最近遍地开花。 添加微服务架构，语言的变化变得实用。 将新语言带入您的生产环境意味着什么？
编程语言不能单独工作。 我们使用编程系统进行开发，而语言是其中的一部分。 新语言带来了新语法……新构建工具，新依赖管理，新库，新包装，新测试框架和新内部DSL。
这些可能是引入该语言的原因。 例如，ScalaTest非常适合测试Java代码。 Python的Pandas库具有快速的数字处理功能。 Go使创建二进制文件变得容易。
可能发生的最坏情况是什么？ 生产中没人能理解的代码。 如果最初的发烧友离开，其他人将需要学习该语言或全部重写。
仔细隔离可以使实验代码可替换，从而降低风险。 例如，理查德·费尔德曼（Richard Feldman）通过选择具有清晰界面的业务逻辑在NoRedInk引入了Elm 。 这样就留下了应急计划（“用JavaScript再次编写”），并且在Elm实施上花费的时间有限。
当您向公司介绍一种新语言时，您正在从事另一项全职工作。 您将成为本地专家，即疑难解答者。 所有问题都是您的问题，直到团队中的其他成员都适应为止。 而且，如果您不Swift加快它们的速度，那是不负责任的。
正如Camille Fournier指出的那样，一些公司使用多语言微服务来避免团队之间的交流。 “当他们这样做时，他们就是在分崩离析。” 如果他们也没有在人与人之间复制这种知识，那么一个人退出，必不可少的知识就会丢失。
不可避免的痛苦是什么？ 集成语言系统。 必须构建，测试和打包新代码以进行部署。 如何对其进行监控？ 调试了吗？ 许多因素都会影响这种痛苦。
如果要将Scala引入Java环境，则两种JVM语言在编译后都可以相同地工作。 将Ruby添加到Java环境更加困难。 如果您的部署管道是基于容器的，那将减轻痛苦。 如果基础结构是特定于语言的，那将会很痛苦。 在NoRedInk，将Elm构建到Rails生态系统中需要做很多工作。
考虑一下围绕一种语言的工具开发得如何，以及其他人是否已将这种语言集成到像您一样的堆栈中并进行了文档记录。
这是另一个明确的难题：将读取已编写的代码。
对跨语言边界的数据流进行故障排除时，来回切换会产生成本。 即使我知道所涉及的所有语言，在Bash脚本，Scala，Ruby，cloud-init，AWS云形成之间来回移动时，也伤了我的脑筋。每一个技术堆栈都为调试带来了认知上的开销。 只有当复杂性降低的程度大于将我的大脑切换到该工具所需的开销时，“适合该工作的工具”才值得。
Avdi Grimm曾经故意在每个过程的每个步骤中使用所有最适合的实用程序（awk，sed，make，perl），并且发现在它们之间进行切换的负担大大掩盖了每个步骤的最大简洁性。 “正确工具”的极端性可能与“唯一工具”的极端性一样痛苦。
如果确实在堆栈中添加了一种全新的语言，则可以使用其所有优势。 最好的情况是什么？ 您可以从语言中学到更多知识，而不仅仅是语法。 您可以访问其社区。
考虑一下招聘的动机-知道他们可以使用Clojure或F＃或Elm，什么样的人想要在这里工作？ 像NoRedInk这样的小型创业公司吸引了想要在Elm工作的热心开发人员。 当然，世界上Scala开发人员少于Java开发人员。 但是，这些群体之间也存在人才差异。 您想吸引哪些开发商？
中度风险类别
- 程式语言
- 一种新的代码编写方式
- 生产系统多样化
专业版：获得新功能并使用新思路获得新的开发人员社区。
缺点：生产中没人能理解的代码。
不可避免的成本：部署自动化，学习整个工具和库系统。
激励措施：保留并吸引渴望学习的人。
严重风险：数据库
如果我们将代码投入生产并在以后感到遗憾，则可以重写该代码。 启动新的，停止旧的。
这很痛苦，但是除了首先编写这种方式之外，没有其他工作要做。 替换数据库并非如此。 有状态的记录系统是一个认真的承诺。
一旦数据库开始投入生产，它就会拥有您的数据。 您无法启动新的，停止旧的并且无法像以前一样继续进行所有操作。 您必须进行迁移。 您必须从旧数据库中提取所有数据，将其插入新数据库中，然后获取在此过程中插入到旧数据库中的所有数据，然后将其放入新数据库中。
从一个数据库过渡到另一个数据库绝非易事。
在过去的团队中，我们想实现一个更适合的数据库，但是编写新代码需要时间，而我们所有的时间都花在了一个负担繁重，过时，配置不充分的ElasticSearch部署上（不打算作为记录系统） ！我们的坏！）。 我们无法消除它； 我们需要这些数据。 我们无法解决它； 负载太大了。
可能发生的最坏情况是什么？ 您丢失数据。 请实现某种形式的复制。 备份，还原，迁移自动化-数据库也是整个系统的一部分。 所有这些都应在生产数据输入之前就位并进行测试。
什么是不可避免的小痛苦？ 您将学习所有存储和查询的怪癖。 请将此隔离在服务后面； 微服务最重要的部分就是这种隔离。
然后是维护：随着负载的增加和存储的扩展，进行监视，升级，重新配置。 不要被快速进入世界的故事所迷惑。 最初的“嘿，我可以存储数据！” 与生产负载增加的平稳运行的数据库有很大不同。
所有这些都很困难，并且对业务至关重要。 托管数据的任何技术（即使是短暂的队列中的技术）都需要背后的团队。
最好的情况是什么？ 精心选择的数据存储可实现其他情况下无法发生的查询。 总是问：“现在我们有了这个，我们还能做什么？” 图查询现在可能很快。 也许曾经是批处理过程的现在可以是实时的。 也许现在我们可以为客户动态更新一些有见地的可视化。
严重风险类别
- 数据库
- 值得信赖，可以保持基本状态
优点：不可能回答的问题变得容易。
缺点：数据丢失或无法访问，业务停止。
不可避免的成本：学习每个配置选项，查询，自动迁移以及备份和还原的怪癖。
激励措施：仔细考虑每种存储的权衡
业务情况。
结论
对于每个团队，每个环境和每种可能的技术，权衡都是不同的。 有意识地做出此选择。 研究技术 ， 规划自己的需求 ，并当心。
如果您不愿意添加到堆栈中，那么团队继续学习新技术和思维方式仍然至关重要。
考虑将此功能与功能开发隔离。 一家公司每天拨出第一个小时来对某些新技术进行暴民编程。 一个小时的专注工作可能会散发出很多光芒，同时又会提出有用的想法。 其他公司也有星期五在黑客入侵一个选定的项目。 内部工具可能是探索高风险技术的低风险方式。
当您确实接受堆栈中的技术时，请确保它具有所有者。 通过配对，文档和交流传播知识。 明确责任，并留出时间进行维护，升级和重新评估。 当今，正确的技术在某些时候将是错误的技术。
您想要的开发人员将希望提高业务效率。 给他们自由和信息来选择正确的工具，不是为了他们今天的工作，而是为了公司将来的工作。 考虑最好，最坏和不可避免的情况。 当您看到兴奋时，请始终感激不已。
翻译自: https://www.javacodegeeks.com/2015/11/growing-your-tech-stack-when-to-say-no.html