技术决策与权衡和解决问题有关

在过去十年中的某个时候，我们到达了拐点，分布式系统及其所有复杂性成为普遍的现实。

也许由于CPU时钟的速度没有加快而需要改变缩放比例的问题……也许是Google MapReduce和/或Amazon Dynamo的论文……或者也许是RedSox赢得了世界大赛。 这并不重要，因为我们现在生活在一个所有人都可以访问分布式计算的世界中。

通常，围绕分布式计算的技术论点并没有错，只是它们没有适当的上下文。 提出的解决方案应根据技术/语言的实施环境和权衡取舍，说明技术/语言如何解决问题。

如此之多就成了解决方案，解决方案，解决方案，而无需分离并深入研究问题，然后将问题与解决方案联系起来。 当您在上下文中解释解决方案（或技术警告）并解释解决方案的缺点（因此您接受上下文权衡时会遇到什么）时，解决方案（或技术警告）的效果最佳。

我们继续之前的一些快速示例

• 必要时保护锁，甚至优于无锁环境。 锁具有许多众所周知且有据可查的缺点。 它们也用在许多系统中，并具有有据可查的众所周知的好处。 因此，上下文是这里的关键。 很多时候，使用锁来解决特定问题是有意义的。 许多人可能遇到与您相同的问题，并且这通常是一个复杂的实现，因此他们可以从使用和/或不使用锁的情况下了解到您做错了什么，而在正确的情况下了解到了什么。

• 通过指出所有不利于一切的语言并说不使用它来翻录语言。 没有提供其他解决方案就不要谈论问题。 当然，在构建某种类型的特定应用程序时，该语言可能对您而言没有意义，但这并不意味着它具有零收益。

• 提倡您在使用技术时遇到问题，因此没有意识到自己可能做错了事，而是开始质疑该技术……例如向邮件列表发送电子邮件，说您对技术有“怀疑”也许你只是不明白。

仅仅因为这对您和您的域上下文没有意义，并且您不愿意接受权衡取舍，也不会使技术或语言变得糟糕或错误……也没有使它正确。

我喜欢就对比和重叠的技术进行深入的讨论和辩论。 当尚不清楚哪种方法适合特定用例时，我特别喜欢它。 如果两种（或更多）技术各自只能解决80％的问题并且以不同的方式解决问题，那就更好了。 这使您不必编写自己的软件。 这就是魔术发生的地方！

如果您不能谈论不利因素和权衡取舍，那么您只是一个无所事事的球迷。 这种行为实际上并没有使任何人受益。

上下文事项

阿马里洛·斯利姆（Amarillo Slim）最好说：“如果您不能在桌子的前半小时内看到吸盘，那您就是吸盘。”

因此，如果您要建立一个收集棒球卡的网站，则使用FileMaker Pro，MySQL，Oracle，MongoDB，Cassandra或HBase作为后端都没关系。 当您的整个Facebook和Twitter圈子决定一次全部登录时，只有您的朋友和家人会关心它是否掉线，丢失数据或无法处理负载……

现在，假设您正在建立一个网站（在我的头顶上）来注册个人（假设）。 现在，如果我建议在银行的AS400上用COBOL编写该系统，那么我认为可以公平地说，每个人都会认为我很疯狂，就像“乔，天空是蓝色的，请停止争论它不是”。 如果您可以找到愿意在AS400上运行的资源并以足够的资本投入来支持它来权衡这些问题，那么在AS400上运行的COBOL系统就可以了。

最终，人们解决了计算机问题，以及他们如何应用技术以及技术和语言本身。 如果您期望数以万计甚至数百万的人都试图一次注册（因为开放日很大），那么在那之后您的系统做什么，写什么内容，后端是什么都没关系它具有基于云或裸机的功能，因为如果他们甚至无法登录或注册，那么它就破产了。 问题和折衷最初是被理解的，所以争论技术/语言是对还是错是多余的。 失败的根本原因是对问题的理解不足。

可以说每种技术都有用处……因此，我们不要再浪费技术了，对我们的方法要多一点理解和集中精力。 归根结底，将技术（和语言）归类到适当的类别中，以区分它们可能会带来的好处和不利之处。 这既适用于欢呼技术/语言，也可以警告人们。 并且不要忘了学者和学者（在教学和研究/领域的进步方面）的解决方案。 您可能会在学校做一些有意义的事情，因为这是最好的学习方法，但实际上并不是您将在其他领域中使用的解决方案。

关注问题并管理可接受的权衡以解决这些问题

因此，经过“在技术上是否可行”之后，您必须决定权衡取舍，并客观地决定它如何影响您的环境。

如果您没有权衡取舍，那么您做错了什么。 总会有权衡取舍。

• 您的真正目标是什么？ 定义它们！ 明确要实现的目标，并专注于问题。 不要制造要解决的问题…。 Please Please Please，不要制造非域驱动的问题来解决。 而且，如果这样做，则不要将其作为解决方案进行宣传。

• 您可以承受多少停机时间？ 不要说零，因为这对任何人都不是现实。 对此进行量化和解释。 不要只是说零停机时间，而是每秒计算出由于宕机而损失的钱……或者，如果系统宕机了多长时间，您可能还会损失什么，并量化和传达其原因。 不仅将其应用于系统，还应将其应用于每个子系统以及可能应用于每个子系统中的每个组件。

• 丢失多少数据是可以接受的？ 如果答案是否定的，那么您愿意牺牲多少系统可用性？ 您可以实现数据零丢失，但又不能不牺牲可用性。 但是，如果可用性比您愿意丢失多少数据更为重要，则必须接受这种折衷方案。 有关更多信息，请查看Henry'Robinson的CAP困惑：“分区容忍度”问题的 博客文章 “分区容忍度是指通过选择删除其他系统属性中的一个来简单地制定应对策略。 这是CAP定理的真正教训–如果您的网络可能会丢弃消息，那么您将无法兼顾可用性和一致性，您必须选择一个”

• 用户的期望是什么？ 解释这是因为用户提供了系统可以做什么和不可以做什么的域和上下文。 真正的要求与好/幻想/华而不实/有什么要求？

• 您现有团队的组成是什么？ 潜在的新员工市场是什么？ 如果您尝试选择所有闪亮的“新奇的”技术和语言作为解决方案怎么办？ 如果您必须扩大团队规模，却又无法雇用任何知道该技能的人，而又没人愿意将其添加到简历中，会发生什么？ 它仍然闪闪发光吗？ 另一方面，您是否正在使用过时的技术，因此即使您现有的资源对过时的技术感到满意，您在招募不断支持它的人才方面是否也会遇到麻烦？

• 您有现有的代码和现有的业务吗？ 您是否需要维护新项目的代码和业务？ 你能扔掉什么？ 您需要等多久才能扔东西？

• 您是否正在解决自己真正遇到的问题或认为自己遇到的问题？

“程序员浪费大量时间来考虑或担心程序的非关键部分的速度，而在考虑调试和维护时，这些提高效率的尝试实际上会产生严重的负面影响。 我们应该忘记效率低下的问题，例如大约97％的时间：过早的优化是万恶之源。 然而，我们不应该放弃那关键的3％的机会。” –唐纳德·努斯

技术决策与权衡和解决问题有关

对我来说，我有自己的见解和解决问题的能力。 我并不总是着手研究自己喜欢的用例，有时可以肯定地说，我得到的用例实际上是完全而完全糟透的，需要我使用使我有点口吐的技术和语言。 但是，当这一切完成后，如果我仍然可以照镜子，对自己感到自豪，并为最终结果感到满意，并且在不付出太多代价的前提下超出了期望，那么解决方案==很棒。

因此，基于我的种种and激，想法和见解，我让您集中精力解决自己的问题，并根据您的工作状况和所接受的权衡取舍对它们进行解释。 感谢Camille Fournier ， Jay Kreps ， Alex Popescu和Steven Gravitz审阅了此博客文章，以使我保持诚实并把我拉下平台，并在此过程中帮助收集了一些垃圾。

参考： 技术决策与权衡和解决问题有关 ，我们的JCG合作伙伴 Joe Stein在All Things Hadoop博客上发表。

翻译自: https://www.javacodegeeks.com/2013/12/technology-decisions-are-about-trade-offs-and-solving-problems.html