如何看待小程序云开发把程序员的准入门槛降低？那怎样衡量一个程序员的价值？ 第1页

嗯哼？

朋友我读书多侬不要想着诓我啊。

我还也特意去搜了下相关新闻，建议对这个事情不了解的知友们先康康这篇新闻。

云开发又不是“神仙妙药”，还能打通普通人“任督二脉”瞬间成仙？

所以这个还是先问个问题“是不是成立”嘛。

要说起来，还是的先聊聊所谓“程序员准入门槛”。

计算机是什么？

一个能做逻辑计算的机器。

程序是什么？

现实世界事物的一种数学逻辑表达。

程序员是什么？

用某种规则（代码）教计算机做事（写程序）的人。

所以才能掌握这样的技术，跨过门槛呢？

一般来说，

我们都说先学一门编程语言吧。要不Python开始？

然而这里我们已经假设：

这个小伙子至少有基础的数学基础（加减乘除？），

知道一点逻辑判断（与或非？），

同时能看懂英语（不要和我“咬”中文编程。）

还是让我们直接开始学习一些简单的代码，

做个 a = b+c，a = a+1，

循环1 +2 +3 ++++100之类的。

这个时候我们会发现，

这些东西好像都没什么难度，

那么问题来了，说好的门槛在哪呢？

先说答案：“门槛”在理解需求和整合技术实现。

理解需求，也就是要做什么。

整合技术实现，也就是要怎么做。

回到我们讨论的问题上面“小程序云开发”。

他们自家简介：“为企业和开发者提供一站式后端云服务，无需管理基础架构，一次开发多端运行，腾讯云和微信联合出品。”

可能有些朋友看起来还是一头雾水，

这里再说一下传统Or日常的所谓程序需要什么。

我们以一个闲置物品交易的XX小程序为例。

用户在手机上可以操作

-> 微信小程序、支付宝小程序、APP

用户信息和闲置物品信息的保存

-> 需要一个存储的地方（数据库），需要看到彼此的信息，所以存储得放到公共服务器（云服务器、云数据库）

用户需要交易打款收钱

• 接入某宝支付、某信支付、银联支付、XX支付

做一个这样的产品，照着现在一般公司的分工如下：

一个产品经理（可能直接是老板，还兼职UI、UX）

一个前端工程师（反正用户看得到的东西都归他）

一个后端工程师（反正用户看不到的东西都归他）

清晰明了的分工！！！

完美的项目规划！！！

今天产品上线！！！

明天公司上市！！！

想象很完美，现实很残酷。

前端小哥可能只会写前端，不会写APP；

后端小哥可能只会写业务代码，不熟悉服务器运维；

产品老哥只会用纸画图，输出不了PRD。

“就缺一个程序员？”这种难题都解决了，现在怎么遇到的问题更多了？

有了需求，也会有解决方案的。早几年React Native跨平台框架出来了只写JS的前端小哥也能写APP了。再后面点X信小程序也发布了，APP都不写了，

直接写一套小程序在X信、X宝、X度里面跑，一处编写处处运行的“美好世界”真的来的。（有坑，下回填）

解决了前端的需求，怎么着也该看看后端小哥“头凸”怎么办吧？。后端小哥一个人写代码，还得搞搞服务器，再来搭个数据库什么的，同时搞日志收集异常追踪。。。

是不是听起来就头大了？不是说好程序员只是写写代码而已吗？后来云厂商起来之后，服务器、数据库、日志服务、存储服务之类都成了基础组件，越来越不太需要程序员介入过多。

给钱，拿去用，有问题怼厂家就完事了。

然而工程代码，还是离不开程序员小哥，至于服务器负载情况、数据库存储问题、流量峰值之类的一些问题，依旧还是压在我们可爱的后端小哥身上。

那么“教练”大哥，能不能给力一点啊！！！

AWS CTO说完全没有问题。

最早大概是14年 亚马逊AWS 就推出了AWS Lambda平台。

AWS Lambda一句话：函数既服务。

AWS Lambda 的设计理念（引用）

AWS CTO Werner Vogels 2014年在技术主题演讲上简要叙述了 Lambda 设计思路的由来。

Vogels 首先抛出一个问题：什么是云计算的根本（primitives）？

答案：云计算是一个执行环境。

Vogels 再抛出第二个问题：什么是应用的根本？

答案：函数（functions，即业务逻辑的载体）+ 数据（data，即跟业务相关的输入与输出），以及这两者之间的交互——即事件（events。常见的事件如增加、变更、删除等）。

换言之，对于一个应用来说，除了 functions、data、events 这三个东西是根本之外，其他无论什么代码和框架，无非都是胶水或者 UI 罢了。既然如此，理想的情况是用最少的时间写胶水，将做多的时间投入到应用的核心当中。

总结来说，这一套方案就是：

服务器？您别管了。我们平台搞掂。

需要其他的资源（数据库？网关？）直接接我们的云平台，

您老安安心心写自己的应用逻辑代码就好。

再后面，Azure、腾讯云都慢慢做起来了，

慢慢都提供了自家类AWS Lambda 的Serverless产品，

在我用过的几家产品来说基本都大同小异了。

不过题目提到的小程序云开发前阵子接触了一下，

倒也还算是有点意思可以聊聊的。

先“捞”一份“腾讯云开发”简介：

云开发提供完整的原生云端支持，弱化后端和运维概念，无需搭建服务器，使用平台提供的 API 进行核心业务开发，即可实现快速上线和迭代。

乍一看感觉没什么神奇的东西嘛，

不过一细看倒是发现腾讯云这“缝合怪”组合拳还真打得不错，

整体解决方案做得有点给力。

他们家六大产品：

云数据库、云存储、云函数、

静态网站托管、云托管、扩展应用

云函数对标AWS Lambda和阿里云函数服务就不用多说了，

云存储算是整合了S3或者OSS对象存储的内容，凑和OK，

静态站点托管算是在S3、OSS上面做的扩展，不需要详说。

下面的就有点意思了。

云数据库

• CloudBase 提供的核心功能之一，提供基础读写、聚合搜索、数据库事务、实时推送等功能。
• 一种文档型数据库，数据库中的每条记录都是一个类似 JSON 格式的对象
• 可以在用户端（如 Web 网页、小程序、Flutter）内调用，也可以在服务端（如服务器、云函数）内调用。通过用户端调用时，需要先进行云开发的登录鉴权，然后以用户的身份进行数据库的读写操作。

看起来像不像一个魔改定制版MongoDB？ClickHouse？Elastic Search？

分布式、扩容、搜索、事务、推送同步什么都支持了，

服务端鉴权这个没什么神奇，多租户什么的都是正常操作，

客户端鉴权（Web和小程序都能用）这个就有点“不讲武德”了，

看下来除了可能迁移性不太好，其他的都OK。

云托管倒不是什么大新闻。

云开发（Tencent CloudBase，TCB）提供的新一代云原生应用引擎（App Engine 2.0），支持托管用任意语言和框架编写的容器化应用。和云开发其他产品（云函数、云数据库、云存储、云调用、云接入、静态网站托管等）一起为用户提供云原生一体化开发环境和工具平台，为开发者提供高可用、自动弹性扩缩的后端云服务，可用于云端一体化开发多种端应用（小程序、公众号、Web 应用、微服务应用、Flutter 客户端等），避免了应用开发过程中繁琐的服务器搭建及运维，使开发者可以专注于业务逻辑的实现，开发门槛更低，效率更高。

标准的Docker容器嘛，

看起来其实就是k8s之类的容器编排平台的二次封装，

看起来算半个买点，毕竟腾讯云自家的K8S平台也很好用。

扩展应用就是个打包产品

云开发团队为开发者提供的一站式云端服务，旨在降低开发者使用云服务的门槛，助力开发者快速开发应用。

说人话: 在云开发平台使用Redis、MySQL、WordPress XX应用的能力，

打

包

卖….

看完一圈回来之后，

程序员小哥的工作是不是就越来越少了。

云厂商搞掂了基础服务，解决了大半的运维问题，

AWS搞了Serverless，解决了多写代码的毛病，

腾讯云开发还做个“缝合怪”，进一步提供了更多的便捷。

那么，是不是可以进入：

“无后端模式”？？？

照着我司首席前端带刀工程师的原话来说，

“推行无后端模式势在必行，大家要用于尝试！”，

我看着他手上拿着的削苹果的水果刀笑而不语，

他看着我手上拿着板砖机械键盘处事不惊。

再想起来之前从别的朋友看到一个说法挺有道理：

谁负责业务建模/实现功能建模，谁就是后端。

谁负责页面呈现/用户交互，谁就是前端。

平心而论，所谓的“无后端”在今时今日，大部分场景是把利用前端小哥的能力来写后端，用云平台的能力来支撑运维和解决存储问题，应该算是前端赋能或者说是打破边界，并没什么本质上的 “革命”。

讲到这里我们发现，

云厂商、云平台、云框架直接降低好像并不是程序员门槛，

它降低了做一个产品的技术难度，也能更加合理控制了项目演进的试错成本，

省钱省事，也让项目有机会起步得更快。

又说回来，有了能抄的东西，也有了更完善的解决方案，

间接来说程序员的门槛算是低了一点了，

至少我写个小程序用个云平台也能说自己是个“全栈”工程师了嘛。（笑哭+狗头…

这么一来我自己也在思考，一个云开发时代的程序员价值在哪呢？

思索了一下，感觉还是有些地方可以聊聊。

下面这些观点都是想分享一下的：

1. 基于经验和自己计算机知识体系，给出一个项目当前的合理实施方案 (换手机壳同步换手机主题？)
2. 用自身技术广度和技术深度构建“壁垒”
3. 合理规划当前实现方案以适应未来发展（多快好省+拥抱变化）
4. 协调资源共同推进项目发展（人、团队管理、钱？）
5. 复杂的世界里面，划出计算机能做什么不能做什么的边界能力

最后，

恭喜您成为了一个“架构师”，

希望头发和脑子都还好。