toc
译自：Pick your poison
作为一个程序员，年龄渐长经验更足，当你听到有人在讨论某个“银弹”的时候，你知道有人在推销一个夸大的东西(snake oil)。程序开发更多是一种妥协的艺术。
当我读到技术和架构之间比较，读到所呈现的论据和所处的上下文以及所涉及的热点时候，大多都缺少上下文的陈述。当一个初级程序员认为到MVVM是合适的方案，却只是根据作者有着众多的粉丝。当你越选用一些流行、普世的方案，你就越不会真正去审视它。作为读者，你想当然的认为，MVVM适合一个陌生人，也会同样适合你。
个人过往的经验会影响我们的思维和行为。如果我们有过MVC的糟糕经验，一旦听到别人推荐MVC的时候，你会认为他是个傻蛋。我们前行，我们走过苦难，我们自然会想要避免过去的失败。
就像之前所说的，上下文才是根本的。你可能被一个从没有用过MVC的人影响，认为是架构本身的错误，而不是人的问题。你会认为，那个家伙还是不错的，况且代码在他之前就已经很乱了。
但我们评估一个工具的时候，我们应该问，这真的合适我和我的团队吗？ 技术是一个很重要的因素。比如说，你不应该依赖一个维护不佳技术。你也应该避免选用一个社区中不成熟的方案。但是，技术却不是唯一需要考虑的东西，尽管初期工程师可能会这么认为。有些时候人才是最本质的东西。团队会用这个技术吗？ ReactiveSwift以及其他的 FRP* 库可能此类问题的代表。一个初级开发人员多久才能理解这些代码？ 诸如此类的问题会决定一个团队最终的选择。
当然，极端来说，哪怕是有很多的非议和谴责，如果团队能够按时交付有质量的软件，它就是正确的方案。
Twitter，以及其他地方通常讨论“因为Y而使用X”，或者“Z是个垃圾，因为我用的很糟糕”。当我们为下一个app选架构，或者为公司引入一个工具的时候，我们恰恰就是要剔除掉这些主观的东西。
