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