架构技术选型哲学

好记忆不如烂笔头,能记下点东西,就记下点,有时间拿出来看看,也会发觉不一样的感受。

不谈具体技术,从更高层面看,技术选型应该怎么做?
写在前面
技术选型是一个很热门的话题,最近我看到自己的微信朋友圈有好几篇关于技术选型的文章,读者对这类主题的热情很高。在技术组织内部,技术人员经常会面临技术选型问题,有时候,技术选型还常常牵扯好几波干系人,相互之间还会产生争议,有的甚至还可能发展到派系斗争的地步。即便像我自己,已经有十几年研发和架构经验的老司机,不管是工作还是业余,有很大部分时间的思考都是深陷在 A 技术和 B 技术的利弊权衡之中,不能自拔。无论如何,技术选型说小了关乎项目和团队成败,说大了关乎企业业务的发展,不可小觑。


本文所表达的技术选型理念应该是与具体技术无关的,但是由于我个人的背景更偏向互联网后端的研发和架构,所以本文的视角更偏向后端技术的选型。


软件的本质复杂性
近年,云计算、微服务、容器和 DevOps 等新技术和理念层出不穷,技术人员对各种新技术的追捧热情也空前高涨,各种新技术微信讨论群也如雨后春笋般冒了出来。这是一个好现象,说明我们的开发人员多了,技术环境也日趋成熟,有点百花齐放的感觉。同时也让我有一点担忧,我担忧的是纯技术和工具论的抬头,也就是太过专注技术,认为技术可以搞定一切,反而忽略了软件研发的本质复杂性。回想当年,自己也曾是这样的技术狂热分子,EJB 刚出来的时候,我为 EJB 摇旗呐喊,Spring 出来的时候,我也曾一度是该技术的死忠,简单认为这些技术是银弹可以帮助解决所有的复杂性问题。


1986 年,人月神话的作者 Brooks 就提出,软件的本质复杂性(Essential Complexity)存在于复杂的业务领域中(用技术的话讲是业务领域建模复杂性),技术仅是辅助工具,它解决的问题是帮助将业务领域问题映射转换成软件实现,只解决次要复杂性(Accidental Complexity)。


作者同时指出,由于软件本质的复杂性,真正的银弹并不存在;也断言在十年内,没有任何一项技术或者方法可使软件工程的生产力提高一个数量级。30 年前作者提出的论断,今天依然闪烁智慧的光芒。人月神话已经出了 40 周年纪念版了,堪称软件工程的圣经,建议所有从事软工行业的朋友学习。除了业务和技术,我还想强调软件的本质复杂性同时隐含在企业的人、组织、流程和管理中,不容忽视。


架构师只有深刻理解软件的本质复杂性,才能站在解决实际业务问题的角度,更好的做出技术选型,否则易陷入唯技术工具论的陷阱。


使用成熟的技术
大部分公司都是商业组织,不是科研机构或者纯软件研发机构。商业组织使用技术是为了解决当下的业务问题,他们更应该使用成熟稳定的技术。


如下图,技术的使用有明显的生命周期,早期有创新者和早期使用者采用,我把这个阶段称为试水趟坑期,也就是说这个阶段技术不是很成熟稳定的,虽然尝新者可能占据一定的技术领先优势,但是他们常常需要以踩坑填坑作为代价;如果这项技术经过早期验证则会跨越鸿沟进入早期大众阶段,这个阶段技术会逐渐走向成熟,处于上升期,坑逐渐被填平,技术被大众所采纳;之后技术缓慢经过末期大众阶段,最终走向滞后期,一直到生命周期的结束退出历史舞台。


技术选型的一大智慧是不要盲目追求新技术,老老实实采用成熟稳定的技术,让那些喜欢追新的人去踩坑

阅读更多
换一批

没有更多推荐了,返回首页