多研究些架构,少谈些框架(4)-- 架构师是技术的使用者而不是信徒
大约 3 分钟
我承认我是标题党, 为什么要写这篇充满争议的文章?目前架构师这个职位特别火热,程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么?很多人把架构师和框架师等同起来,认为研究框架多的才是架构师 下面说的情况请勿对号入座。
- 盲目的追新: 技术人员的喜好往往是什么技术流行就追什么技术。现在的技术发展快,前后端不断涌现各种框架,我们恨不得把这些框架都用在自己的项目里才行,要不然怎么好意思和别人打招呼啊。 我亲身经历,有个技术人员一定要把原来单元测试框架的xml初始数据改为json,他的原话是”json看的更舒服”,但是改完后,我们的单元测试反而难落地了,原因是原来的单元测试框架有个工具是可以将表中的数据自动生成xml的,而改成json后,我们必须手写json数据了。 他的喜好不包括给大家更好用的工具。
- 按技术站队,以结果反推: 很多人把手段当成了目的,成为了框架的信徒。用了Java开发,你的设计就一定是面向对象的?用了Spring boot就是微服务了吗?这些荒唐的事情却在技术圈不断发生,技术人员甚至会按照语言、框架形成不同的圈子,各种技术圈互相鄙视,互相踩,真相此时无法越辩越明,反而把技术方向带歪了。
技术要和实际场景结合
架构师也要深入了解掌握技术,但是更多的是了解技术的优劣和使用场景,而不是简单的生搬硬套。以现在流行的微服务架构来说,Netflix使用RESTful接口作为通讯,我们是不是要把公司的用了n年的基于TCP的RPC换成RESTful接口,因为根据Netflix的实践,RESTful可以更好的解耦、更强的伸缩性等优点,还能支持多种语言开发,互通性好。但是我们需要对RESTful彻底的理解清楚:
- RESTful接口不简单是是http+json,Richardson成熟度模型中哪个层级更合适我们的内网API通讯,HATEOAS是否需要?
- RESTful的核心是资源,如何在微服务中抽象资源概念,如何将基于过程的RPC调用平滑的迁移到RESTful上?
- 多语言开发是快,但是后续维护如何找到稳定的Go、Scala、xxx语言程序员来源? 以上的问题应该是架构师在考虑引入新技术的时候的重点,其中对技术优劣和架构思路是核心