如何看待架构之道

如何看待架构之道

九月 07, 2021 本文共计: 835 字 预计阅读时长: 2分钟

如何看待架构之道?这个题目看起来肯能有些大,有些宽泛,但是我却思考了很久,可能我说的不对,但是确实是我自己的一些想法,当然立场也仅代表我个人。

有接触过创业公司的”现状”:

  • 各种外包同学写不同风格的代码,大驼峰小驼峰帕斯卡等等,单论命名就够头疼了,且不说写的人怎么看,但是维护的人来说,”我到底维护一套风格还是维护两套风格?”
  • 自己为了方便,把封装的npm包发布在npm.org上,我第一次看到这个操作的时候,着实有些震惊的!
    • 你走了其他同学怎么办?
    • 如果需要二次开发怎么办?
  • git代码管理用阿里云管理
    • 不是说不好,只是有些太矬,是真的矬

也有接触过比较好的公司,各种设施都很完善:

  • 组件库
  • 私有gitlab平台
  • 构建工具
  • npm仓库
  • jekins
  • sentry

就我现在接触的到完善的东西来看,我对于架构的理解是:

一个公司的架构需要适应自己的业务与现状。

第一句话我想表达的意思呢,就是,每个公司都有自己的架构思想在里面:

好比,之前公司的组件库是完全不编译给业务侧用的,目的是考虑用到各种系统环境变量,但是实际真实是不需要的。

但是我现在完全用不到这个思想,rollup + esbuild就完事了。【生产上的实践也是比较好的】,既加快了业务侧代码的构建速度,也加快了打包的编译速度。目前组件库打包速度100ms - 2s内。

再好比,每个人的编码风格不一样,我们去碰一碰,碰出一个大家都认同的规范出来,一起落地。

这就比较合理的解释了上面的概括,适应现状。

架构不是银弹。

再回到我上面举例的创业公司的现状来看,创业公司,为了拿到融资,自然是先出成绩再出架构,所以我理解那些五花八门的写法与用法。

但是这些东西迟早是技术负债,还是要看负责人怎么去想去看待了。

所以架构不是银弹,没有架构一样可以做事,有架构又怎么样呢?没有业务推动,凭空架构,就是费钱。

架构一定是来源于业务的推动的,如果经历了不同的业务压力,业务负担才会考虑去做架构。

好比,

  • 业务侧使用umi/requesthttp请求,但是umi人家支持的标准的http请求方案,所以为了更好的兼容现有服务端的错误代码兼容,就需要去二次处理axios

  • 不同团队的应用需要做集成处理,那么这个时候,就需要架构去做兼容,可以用iframe,也可以用微前端,我觉得乾坤做的就比较好。

小结

至少目前的我觉得,花费50%-60%的时间去做做业务,看一下业务到底需要怎么去改善,在考虑做全局的架构,会比较好。