笔者认为适合中小公司的方式：重规则、轻架构。
短期内提升整体研发水平上限比较难，而提高下限会容易很多且省钱。制定规则约束是一个成本较小，又有明显短中长期收益的方式。方式有：
- 制定代码规范
- 统一使用format工具
- 统一使用lint工具
- 规定公共模块使用规则
- 规定依赖包的版本约束
- 规定代码目录规范
- 统一使用相同的日志库、orm库等
- 统一使用相同的中间件
- 统一编写release log
- 统一开发流程，例如gitflow，最重要的是使用相同的分支管理规则
关于框架选择，根据所使用的语言，选择主流的框架即可，要在重型、轻型之间做选择。避免同时使用不同的框架，即使不使用框架，有了规则的约束，也不至于程序员的代码过于放飞自我。
不知道有多少人吃过架构过于复杂的苦，好的架构往往不是一次性设计出来的，而是迭代演化出来的。
一些功能/模块是选择开源组件还是自研？与业务绑定越深的越建议自研，比如登录认证、权限校验等；像网关、日志、监控等与业务绑定不深的选择开源组件，有的设计会在网关做一些统一的业务处理，此时最好选择支持灵活自研插件的网关。
整体架构不宜太过复杂，不要盲目迷信一些大型公司的“最佳实践”，可以参考，但别人的不一定适合自己。随着业务演进、产品迭代，架构和代码通常也需要随之进化调整。如果架构过于复杂、引入了过多的开源组件，很可能成为进化的阻碍。再者，小公司技术人员数量有限，并不一定能保证对使用的开源组件和工具做到熟练和深入了解，有很多是拿来即用，这都是潜在的暴雷点。要避免发生“我们使用的XXX开源组件不支持这个需求”的情况，这是本末倒置了，我们写代码本身的目的就是产出产品。
每个公司的业务不同，当然不能一概而论，根据自己的需要做抉择，参考指标有：
- 技术人员规模
- 并发能力
- 吞吐能力
- 高可用要求
- 安全性
- 部署要求