谈谈不同思路下造就的不同产品与公司形态

王福强

2020-05-05

因为某总二次创业积极地要求帮助，所以，就给了一些公司内部信息化的建议和方案，顺道又重新梳理了一下这个生态和历史发展的路径演化，这里晒出来让大家一起批评一下，看有没有更深的探讨， here we go～

多方法还是一个方法搞定？

如果是程序员，你们有没有疑惑过，同样一个问题，让不同的人去写代码解决的时候，写出来的代码是不一样的，当然，这里的不一样不是说对比每一行上的差异，而是说程序结构上就不一样，有的人会这样干：

class XYZ{
    ...
    def methodA(...): T = {...}

    def methodB(...): T = {...}

    def methodC(...): T =  {...}
    ...
}

有的人的则会这么干：

class XYZ{
    // you can use pattern match of course, but never mind here.
    def process(...): T = {
        if(conditionA) {
            ...
        }else if(conditionB) {
            ...
        }else{
            ...
        }
    }
}

为什么会这个样子？！哪种更好？

RESTful还是GraphQL？

当进入分布式系统甚至微服务时代，大部分的远程调用是通过HTTP完成的，少数是基于长链接的RPC，但不管怎么样，大部分架构规划上都是一个Endpoint对应一个API或者说功能，也就是俗称但REST/ful，是不是很熟悉？

随着Facebook从一家社交起价的小破公司发展为今天的巨头，他家也自己造出了自己用的技术轮子GraphQL，与REST/ful模式做个对比，你有咩有感觉很有一种是曾相识的感觉呢？咋跟多方法和单一方法的对比有点儿类似呢？

哪种更好？

More Code还是NoCode？

一个需求来了，你是要每次都协调技术人员写代码来开发，还是自己鼠标拖拖拽拽就搞定了？这是两种做事方式，或者说两种生态环境。

早年淘宝估计也是写代码赶需求干的厌烦了，所以搞了个TMS，毕竟天天让人撵着赶需求不爽啊，我写个工具给你吧，下次你只要上去拖拖拽拽敲点儿文案进去，点击个按钮就发网上去了，yeah，轻松加愉快～

所以当年福强老师也是照着画葫芦，让前端团队搞了个H5版的TMS功能复刻版（叫BIU），这样，宝贵的前端同学就不用天天扑到那些没啥含金量当还需求频繁的海报上了。

时至今日， Airtable亦或黑帕云更是沿着通用需求和产品的思路来到我们的面前， NoCode？ Maybe， as long as it’s simple enough.

工具公司还是产品公司？

我们也知道，当需求外部化给第三方公司去做的时候，第三方公司往往为了提高效率，会采用代码生成脚手架之类的工具来提高开发速度，针对纷杂的开发需求，重复高效才是王道啊，毕竟成本低，因为原本就没有多少钱赚。所以， n多公司，n多工具，n多技术，这个生态还是挺大的，甚至于也造就了很多上市企业，比如上海的，比如深圳的，比如clickhouse这种技术研究很深入的，但是却不是服务自己公司的…

但既然NoCode这种概念已经提出来并流行起来了，那么，也有很多公司在沿着通用产品但思路在走，也就造就了不同的产品公司，比如Airtable，比如各种aPaaS公司，比如“NoCode” ^_-