前言

对创业公司来说，活下去是最重要的任务。

作为一个过来人，能体会到一点：在创业早期，由于多种因素的限制，大部分的决定和假设都是错误的。

任何新产品都具有不确定性，没有一个产品团队可以完全预测用户的行为和反应，
很多创业团队倾向在项目开始之前编写计划书，但其实这恰恰是对问题最缺乏了解的时候。

公司真正需要的是一套能够应对不确定性的流程，从产品、设计到工程一步一步试验，从而对客户的需求达成共识。

小步快跑,快速迭代

我接下来从一个开发的角度来简单谈谈，对这个标题的理解与实践。

先上一个简单的场景，开发者2位，一周内上线上线一个裂变活动。

因为人数少，开发任务重，理所当然的选择了 vue/spa(生态好) + node(生态好) + mongodb 这样的技术栈

这样能够尽可能的培养(yazha)开发者做全栈

拆任务：

• 一个偏重前端，编写自适应页面，接入微信sdk，编写nodejs交互api
• 一个偏重后端和运维，微信回调，编写nodejs基础架构和设计collection

最终凭借2人强大的技术能力和加班，完成并上线了。

后续也有一些需求改动，也凭借 mongodb 强大的 document handle 住了。

本人认为这套技术栈上手成本低，可扩展性强，尤其是全栈开发，在小项目快速迭代上有很大的优势。

也减少了前后端沟通的成本，即使可能会出现，代码写的烂，维护非常麻烦等等后续问题。

但是技术这一块往往不是起决定性作用的，即使代码写的像屎一样，又如何？

达成商业模式的闭环，做到盈亏平衡或拿到融资才是关键。

技术栈

跑偏了，回到正题。

这也是我之前讲到的那种技术栈的一个实践，即 frontend + nodejs + db

核心就是 nodejs , 前端本身只是表现形式，用什么技术只要达成目的就行。

在这套技术栈里，我大概先罗列一些问题:

• frontend ，部署上 cdn ,或者 ssr 搞搞动静分离都是非常简单的事情。
• nodejs + db 部署，现在往往是以 k8s docker 这种部署在云厂商那里的云服务器上。

docker 拉 db 那些镜像本身也是没有问题的，不买云厂商的db，只是很多的配套要自个做罢了。

小程序原型

先上一个小程序的Qrcode , 个人作品，能力有限

这个小程序在开发上，使用了 serverless 部署的 nodejs 和 db

代码结构分为三块:

1. serverless framework 的 Github Client
2. cloudbase 的微信云开发
3. uni-app 写的小程序本体

靠着 serverless 方便的运维， 3天左右做的一阶段的原型。

这时候我们改造原先的栈，在充分认识到这方面的优缺点之后，都很简单。

自己做新的产品原型尝试也能快速成型。

附上之前写的几篇文章 , 里面有这方面详细的介绍。

用Serverless给SaaS赋能

抛砖引玉：一种改善微信云开发 , 开发者体验的思路

腾讯云的Serverless:微信云开发与Cloudbase与SCF