标签：饮食 配置文件 人物 php框架 roi oid 产品经理 承担 速度慢
前面从开发效率比较了 Laravel 和 Spring Boot两个框架，见：Laravel 和 Spring Boot 两个框架比较创业篇（一：开发效率） ，这一篇打算比较一下人工成本。
本文说的人工成本是狭义的技术支出成本。当然人工成本不单纯是开发人员的人工成本，同时包含了团队协作管理、架构设计、运维等方面的人工（团队）成本。
本文从以下几个维度分析：
相信这个是大家比较关注的维度，很好理解，就是要根据需求撸一套产品出来，无论是后端、前端、APP还是小程序、中台，都要士兵冲锋前阵，也就是靠程序员实现出来，所以这个是刚需。
相信很多猿都会认为自己是全栈工程师，后端OK、前端也OK、APP也能撸，微信小程序也没问题，这样的人还是不少的，但是大部分是停留在框架或者类库的使用上，称为 “github工程师”，必然会有自己比较精的一个端。
例如前端的Single Page Application，一般现代的猿对JavaScript语言都会了解，如果对Vue技术熟悉，配合Vue Route、Element UI、Vuex 就能撸出一个像模像样的SPA，如果对 React 语法和单向数据流思维熟悉，Dvajs + Ant Design也能撸出一个绚丽的中台系统。
对于Android开发，熟悉 Java 语法，了解 Android 四大组件，不需要对Android Framework 内核、NDK 有深入的理解，只要有大牛工具库的加持，例如Retrofit、EventBus、GreenDao、，也能撸出一个看起来还不错原生Android APP。何况还有Flutter！
现代框架的高度封装特性使生产力获得提高，同时容易让开发人员对底层原理失去探索需求，这种失去不但体现在开发人员本身，同样也体现在软件企业在人才筛选上为了降低成本而对技术要求做出让步。
大厂考底层原理和算法、初创看项目经验，这似乎成为了一种行业规律。
不扯远了，回到找猿的话题。
J2EE 非常庞大复杂，知识点数量不亚于一本字典，Spring Boot 配置方式从传统的xml定义向Java类注入转变，现在很多J2EE 猿仍然是起手一个裹脚布似的xml配置文件，一看洋洋洒洒上千行，看起来牛逼，其实只是刚把项目运行起来而已，九九八十一关才过了一关。也正是因为传统J2EE的这个特点，Java 给人一种开发速度慢、成本高的印象。
Java Web 体系就像饮食业
J2EE饭店内，只见顾客光着膀子走进饭店，和工作人员说道：我要红色的衬衣，扣子要六角形的，鞋子要皮鞋黑色的，吃饭的筷子要长度16cm，木头做的，吃饭的椅子要四只脚的，垫子厚度1cm，6号桌子...，一个小时后一切定制完毕，可以吃饭了。
Spring Boot饭店内人不多，迎宾在声嘶力竭的呼喊：“南来得北往的老少爷们，快来看看瞧瞧啦”，一个顾客走过来，迎宾马上把他迎进大厅领到空桌坐下，服务员拿出菜单，问道：“您要吃点什么呢？”。顾客露出惊讶的表情：“我还没有定制我的衣服、筷子、椅子呢？”。服务员道：“我们都准备好了，每个顾客都一样，16cm的筷子，四只脚的椅子，1cm垫子，不需要定制呢，您可以直接点菜用餐”。顾客停了一会说道：“垫子我要1.5cm的，其他的就这样吧”，服务员：“好嘞”。顾客点了一个驴肉火烧，15分钟后吃饱了满足的离开了店里，喃喃说着：“以后再也不去J2EE饭店了，还是这里方便。”
因此我们要找的不是Java猿，也不是J2EE猿，而是Spring Boot猿。
价格方面
貌似成本不低。
价格方面
啥？技术管理是啥？CTO吗？小项目还折腾啥CTO？
其实不然，当开始一个项目的时候，产出的软件不可能只是一个端，至少需要后端和前端，或者APP端、小程序端。
技术管理的作用是协调各个端的交互和接口规范，还有项目开发里程碑和任务安排 （注意不包含架构，在初创快速实现的强烈需求下，架构先不考虑）。我们不可能让专职后端来制定APP端的里程碑，同样也不能够让专职APP客户端来定后端的里程碑。必然会有一个技术比较全面的枢纽人物，我认为这是项目快速推进的基础，同样也可以负责测试和code review。尽管这和产品经理有点类似，对于产品规划较全面的初创来说，是可以合二为一的。出于成本考虑，我们需要低成本招到这样的人来统揽项目技术全局。
后端在产品体系中属于重合度最高的端，需要和每个端产生交互，最低成本的方式是将技术管理这部分成本附加到后端，说人话：“找一个符合前面所述开发要求的全栈后端来承担技术管理工作”。
个人总结（按照通用水平，大神级别的不在讨论范围内）：
最后再多嘴说一句初创的软件系统架构问题：我接触过很多初创，而且还把软件系统架构看的很重，这是一个严重的误区。正如网友们说的，Laravel 存在性能问题，为了做大之后流量大了服务不挂掉，嚷嚷着要上微服务。
产品上线了没？产品都还没上线，要啥高并发，要啥高性能，要啥微服务。
初创项目一般流量不大，也不是计算密集型服务，性能瓶颈不会是在PHP框架本身，没有必要纠结是 C/C++和JVM谁执行速度快，PHP比C慢了多少个数量级，这些毫无意义。当你有了这个性能需求的时候，如果公司还没那个资金去高薪找人才，那商业模式真的是没谁了！
还有微服务，一个街边小摊嚷嚷着要按照阿里巴巴的运营模式来搞，其实这样没啥问题，自己选的路，冷暖自知吧。微服务天生就是分布式，分布式本身就是一个非常大的系统，不是初创适合玩的。就像跨国运营战略适合阿里这种体量的公司，因为业务复杂度已经到达了某种程度，经过评估是对公司短、中、长期发展都是有利的。街边小摊套用这种模式，只会被复杂度困住手脚，当然当您的小吃迈出国门，走向世界，手底下几千人，战略模式自然就有了。当软件复杂度和项目业务量到达一定程度，有了服务拆分和分布式需求，微服务自然就有了，初创要做的可能是关注扩展性，并不是微服务。
小流量前提下谈高并发和架构就是耍流氓！您要的可能不是架构，而是扩展性！
Laravel 和 Spring Boot 两个框架比较创业篇（二：人工成本）
标签：饮食 配置文件 人物 php框架 roi oid 产品经理 承担 速度慢
原文地址：https://www.cnblogs.com/ymstars/p/10508175.html
