前言
对创业公司来说，__活下去__是最重要的任务。
作为一个过来人，能体会到一点：在创业早期，由于多种因素的限制，大部分的决定和假设都是__错误__的。
任何新产品都具有不确定性，没有一个产品团队可以完全预测用户的行为和反应，
很多创业团队倾向在项目开始之前编写计划书，但其实这恰恰是对问题最缺乏了解的时候。
公司真正需要的是一套能够应对不确定性的流程，从产品、设计到工程一步一步试验，从而对客户的需求达成共识。
小步快跑,快速迭代
我接下来从一个开发的角度来简单谈谈，对这个标题的理解与实践。
先上一个简单的场景，开发者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
代码结构分为三块:
- serverless framework 的 Github Client
- cloudbase 的微信云开发
- uni-app 写的小程序本体
靠着 serverless 方便的运维， 3天左右做的一阶段的原型。
这时候我们改造原先的栈，在充分认识到这方面的优缺点之后，都很简单。
自己做新的产品原型尝试也能快速成型。
附上之前写的几篇文章 , 里面有这方面详细的介绍。
强力驱动