创业公司技术选型的一些想法（二）

前几天，我厂前端大牛做了一个前端技术的分享，引起了厂内员工关于前端轮子的激烈讨论。在我看来，大家都有点泛泛而谈，没有针对具体的业务场景，比如是重展示还是重交易，比如运营系统多表单、查询条件丰富、需要大量图表展示，针对这类需求该如何取舍。我们在技术选型时，在类似的框架中做比较，需要看到它们本质上有什么不同，是在哪个本质问题上做了哪些 trade-off 导致了它们在设计实现和理念上分道扬镳，以及这些理念和设计是否更适合公司的业务和团队的现状。

最近我们也在规划后端的一些服务。虽然最近几年一直在做服务治理方面的工作，但我是特别不愿意一上来就大谈微服务，spring cloud(我个人对spring全家桶不算特别熟，但貌似java同学都非常热衷)。我们学了好多语言，好多设计模式，好多框架组件，不是为了一上来就找钉子把它们都用上，而是在了解各种编程范式之后，在合理的场景，用最小表达力来保持系统的尽可能简单，用尽可能简单的程序和架构来解决尽可能复杂的问题。KISS的重要性大家都懂，但保持简单还是常常没有摆在很重要的位置。只要应用程序还在使用，就会有很多的工程师加入，过于复杂的系统会让工作失去乐趣，让人变得更加保守。简单的系统可以让新的工程师从入职的第一周起就可以对项目有所贡献。从另外一个角度讲，这其实也是在节约成本 ：）事实上程序员的能力很大程度也体现在控制复杂度上。

说回服务治理，每增加一个组件，系统架构的复杂度就会增加一分。当然并不是说我们做技术选型的时候就要保持克制，而是需要严谨，需要确认确实是最佳实践，而不要只是带入之前的经验。能用云服务的我倾向于就不要自己搭。对创业公司来说，时间和人力才是最大的成本。保持简单，很重要的一点，就是把控制逻辑和业务逻辑分离，把从库的依赖转变成对服务的依赖，让服务治理等控制逻辑不要倾入到具体的业务逻辑。其实这跟微服务、Cloud Native的理念也是一致的。即使一定要依赖库，也要尽量做到对业务逻辑透明。

程序的本质就是控制逻辑+业务逻辑。控制逻辑和业务逻辑并不相干，比如你是分布式还是单体，是同步还是异步，是并行还是串性，而业务逻辑就是实实在在的业务逻辑。程序的复杂度是业务逻辑复杂度和控制逻辑复杂度的叠加。业务逻辑的复杂度通常是很难降低的，如果一个业务本身就非常复杂，通常也很难通过拆成各司其职的微服务来降低复杂度。所以如果你不想你的程序因为业务逻辑和控制逻辑交织，变的异常复杂，好的选择是分离控制逻辑和业务逻辑，或者是在业务逻辑里通过money patch, interceptor, middleware等方式屏蔽控制逻辑。现在非常火爆的service mesh其实就是这么干的，把服务发现服务治理这类控制逻辑独立了出来，就相当于给每个程序员配置了一个鼓励师，你只需要安心的写代码，报销啊，对外沟通等乱七八糟的事情她都帮你干了~ 想想还有点小期待呢 ^^

上篇午休时间匆匆忙忙写的，好多错别字，有的句子都没写完，这篇(也是午休时间)写到这又发现写的太随意不太好继续了，看来这个系列可以写好多篇。：）