如何看待架构之道

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

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

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

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

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

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

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

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

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

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

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

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

架构不是银弹。

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

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

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

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

好比，

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

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

小结

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