破圈运动小程序复盘

[zhaobinglong]

[zhaobinglong]

这个小程序断断续续做了半年，严格意义上讲，这是我全栈开发的第二个项目，倾注了很多私人的感情。 有时候看着自己做的产品一点点出现，会有一种在养育一个孩子的感觉。因为是自己亲手养大的，所以知道这个孩子有哪些优点和缺点，也会经常想还有没有什么办法可以让这个孩子更优秀一点

[zhaobinglong]

独立开发的时候，最大的挑战不是用了什么了不得的技术，而是如何一个人，在有限的时间内，快速实现同时应对需求频繁的变更。

一个东西出现两次就组件化

开发的时候，不可避免的会看到同一个模块出现在两个页面中，有时候偷懒，直接copy代码。过了一段时间，又出现在了第三个页面，这时候因为没有组件化，就继续偷懒，冗余代码就这样越滚越多。如果一开始的时候就花点时间组件化，后续就不会出现这样的问题。开始的时候看似多花了一点时间，但其实纵观整个生命周期，节省了大量时间

能不写死的地方就不要写死

没有什么东西是不会变的。一个成熟的开发者，能做的就是以不变应万变。如何做到不改变代码，同时产品和运营又可以自己动手。 在破圈小程序中，所以固定位置的静态图片资源，比如开屏、banner、会员卡、会员卡介绍、活动背景图等，都有一个自己的类型名称，后台可以编辑任意一个位置的图片资源，运营随时手动更改，不再需要通过开发者。无形中节省大量沟通时间。

两个通用接口

小型项目的接口，粗略的分为两类，写接口和读接口。在不涉及多表的时候，单个表大部分都是更改某个字段的值，或者读取指定记录，所以我写了两个通用接口。一个通用更新接口，传入table名和key、value，update table set key = value，应对单表更新，一个通用查询接口，传入table名和limit_key、limit_value，select table where limit_key = limit_value, 应对普通的查询需求。

自动部署

没有自动部署机制的时候，每次push代码，都要自己登陆服务器然后pull，重复且没有任何技术价值。有很多办法可以解决这个困境，对于挂靠在github上的项目，github action是最佳选择。在开发分支上开发完毕后，推送到deploy分支，多人协作可以指定deploy分支的merge权限，在action中监听deploy分支的push事件，在action中执行run build，最后自动登录云服务，拉取代码。如果是nodejs的项目，pm2还可以自动重启

[zhaobinglong]

反思

当产品做完后，更大的困难才刚刚出现。如何才能活下去，它需要合理的商业行为和良性的用户增量。破圈的商业属性是有的，它有厦门岛内大部分的运动商户资源，提供很优惠的折扣价格。但是用户增量还是成为了最大短板，能让用户自发传播的产品凤毛麟角，大部分的应用，没有独一无二的产品优势，没有背靠大树，用户增量将成为迈不过去的坑。 我把自己当作用户，还是找不到可以让它自发传播的优势。这将是一个需要长期思考的命题