当前，软件开发者在设计和实现系统时总是面临很多选择。我们时常被过多的选择轰炸并习惯于应付像NoSQL、云、REST、Map-Reduce等流行词。然而，负责设计系统的开发者很容易被诱导而采用没有明显优点的新技术，反而忽视了那些看起来不够现代和时髦的简单方案。看来KISS原则(Keep it simple,stupid!)虽然常被提起，但在支持企业级方案时却往往被忽略。这是为什么呢？
原因可能有很多，下面我总结了几条，我想能覆盖大部分情况。作为职业开发者，我强烈认为，我们有责任为雇主提供最好的、长期的解决方案，当我们的个人喜好与此目标冲突时，我们应该控制自己。软件开发仍旧不同于医药或工程领域，但我想我们确实需要学习这些领域中的工作所带有的专业精神、责任和义务。
原因1-厌倦重复
开发者经常重复的解决同类问题。不是所有人都能一直从事新工作，就算有机会，也很可能还是老环境下的；类似的问题常常已经被全球的软件开发者解决过成千上万次了。
即使之前我们能熟练的解决某一问题，我们还是想尝试新的事物，这并不奇怪。我们是天生的难题解决者，而且有时仅仅是想尝试下新的难题。我确信很多有几年经验的人都看到过这样的现象，采用不同技术的新实现将原功能系统替换掉，而此举除了满足新开发者的个人喜好之外实际上没有什么明确的原因。
我们应该如何处理呢？我们该如何控制自己对新事物的渴求？比起尝试最新的NoSQL平台来，关系数据库真让人烦躁。谁在意是不是我们未能有效利用它呢？哦，我想我们还是有几项可选的。比如，采取主动，找到可能受益于新技术的平台构建方式。为什么不利用业余时间做一些试验性项目来满足自己对新技术的渴望呢？毕竟我们的工作是交付高质量软件，而非取悦自我。
这里要说明一下，我并不是要劝阻任何人使用新技术，只是建议一定要了解技术的优点，并确认这是否是你的最佳选择；如果说离了这个新技术干不成事，那就尽情去用吧！
原因2-简历加料
这可能是使开发者选昏招的最悲哀的原因，主要会影响决策过程不良的团队。这个原因也是很常见的。
目前，软件开发中的合同和职位经常变动——开发者一两年跳个槽很正常。忌讳跳槽的时代早就过去了。正因如此，开发者通过不断的跳槽向上爬。对平均水平或者不够熟练的开发者而言，通过跳槽获得提升比在一家公司等晋升要容易的多。
因此，开发者希望采用新技术并获得一些经验，以此为自己的简历增加闪光点。至于新技术对平台到底有多大用处，重要性倒在其次。通常，真正用到多少并不重要——找新工作的时候没有人能假装他们没有夸大自己的技能。所以，平台在从小变大的过程中，往往因为各种原因而死掉，比如使用了未经测试的技术，或者使用了内部人士都没有真正理解的技术。随着开发人员跳到更有前景的地方，公司剩下的就只有因使用了太多技术而无人维护的系统了。
我想大多数开发者不会这么做。当面对要做出错误选择的开发者时，有反对意见的人要努力阻止他们。
原因3-同伴压力
同伴压力可能是最难抵制的原因了。我们都愿意相信，我们是独立的、可以做出明智的决策的个体，但我们都是人，即使最敏感的人也是社会性的动物，也想有一个开心融洽的团体。
当面对新的或者时髦的技术时，很多人都有点害怕去抵制实现那些看起来并未必多好的想法。我们要尽量压制这种感觉。如果在你所处的环境中，讨论和争论是重要的（就像人们所期待的那样），你要随意的说出你的担忧，即使你不完全熟悉最新的和最好的技术。别忘了虽然软件技术变化不定但基本原理几乎保持不变。要是有些东西看起来不合理，那就说出来。即使你是初级开发者，也应该自由的加入你的看法——有经验不代表就正确。此外，在决策过程中你也可以获得一些洞察力。
原因4-缺乏理解
技术选择可能是在开发者不了解平台如何工作，甚至他们都不想去了解的情况下做出的。
比如，你因为没有高性能关系数据库经验，而又担心实现的东西不具有可伸缩性，所以倾向于选择NoSQL路线。虽然往往这种担心是没有任何理由的。如果你错误的使用了工具，当然它就起不到好的作用。不要在缺乏理解或认识的情况下就轻率的采取行动。如果事实上采用关系数据库的方案可以很好的实现系统，并且你的平台已经在使用这种方案，那么仅仅因为你对当前方案不熟悉而引入新的依赖是愚蠢的。
为了避免这样的问题，你需要多加阅读和学习！如果你在做技术选择，请检查你的假设是否成立。就讨论中的工具与有经验的开发者沟通，并详细咨询工具的优缺点。学习可用工具的更多信息并不是浪费，你的行动很有可能在未来得到益处。
原因#5-误解或者解决不存在的问题
这点与前一点有些联系，但这个问题非常重要，值得单独讨论。
当开发者定位新技术时，通常都会因为该技术可以做X和Y，还能对抗Z而选择它。但实际上，大部分情况下X，Y和Z根本就不是问题。例如，如果我们有一个只读的数据集需要缓存到集群中的多个节点上，有人可能选择一个支持分布式数据集且每个节点上元素都不同的缓存技术。但是，如果数据集很小且我们不修改数据集，那分布式缓存有必要吗？我们将为不存在的问题而引入了速度慢、可靠性差且复杂度高的新技术。
为了预防这一点，开发者需要确保自始至终都理解问题域，也需要反复核对假设以确保其正确性。有时我们假设的事情可能并非事实，所以反复核对非常重要，从而避免覆盖假设情况的诱惑。非必要的情况下不要增加功能。增加功能也是要耗费力气的，而我们把在后期做修改的代价看的过高了，却没有意识到我们现在投入相同的努力仅仅是为了避免在以后付出同样工作进行修改的机会，其实这种机会往往很少出现。
我们应该做什么？
当选择技术时，怎么做才是正确的呢？首先，你需要回顾下面几点，尽量形成团队决策。投入越多，越不容易漏掉那些可能让你改变决策的信息。
- 复查需求——确认一致性、容错、性能等需求点。
- 评估一下现有的东西能否满足需求，如果能，那它基本上就是最佳选择。
- 调查其他技术如何满足需求，并考虑额外依赖和潜在失效点带来的成本（没有免费的午餐，新技术可能都有较大的维护成本）。
- 征求团队中的专家意见——支持你真正理解的。
- 考察任何其他的关注点，比如价格、时间表等。
- 团队讨论并列出赞成和反对的理由。
这只是一些指导原则，你可以采用任何你喜欢的方式，关键还是仔细和理性的做出决策。
希望不要有人把本文的意思误解为新技术是可怕的或者说要避免新技术。其实我已经在实际中使用过NoSQL技术。我相信它能很好的满足既有需求，并且我之前曾经用它来解决过具体问题。有时我想我们是纠缠于新技术里有趣的地方而忘记了我们的最终目标。记住你的目标，尽可能做出最好的、长期的选择。