Open zhaobinglong opened 3 years ago
这个小程序断断续续做了半年,严格意义上讲,这是我全栈开发的第二个项目,倾注了很多私人的感情。 有时候看着自己做的产品一点点出现,会有一种在养育一个孩子的感觉。因为是自己亲手养大的,所以知道这个孩子有哪些优点和缺点,也会经常想还有没有什么办法可以让这个孩子更优秀一点
独立开发的时候,最大的挑战不是用了什么了不得的技术,而是如何一个人,在有限的时间内,快速实现同时应对需求频繁的变更。
开发的时候,不可避免的会看到同一个模块出现在两个页面中,有时候偷懒,直接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还可以自动重启
当产品做完后,更大的困难才刚刚出现。如何才能活下去,它需要合理的商业行为和良性的用户增量。破圈的商业属性是有的,它有厦门岛内大部分的运动商户资源,提供很优惠的折扣价格。但是用户增量还是成为了最大短板,能让用户自发传播的产品凤毛麟角,大部分的应用,没有独一无二的产品优势,没有背靠大树,用户增量将成为迈不过去的坑。 我把自己当作用户,还是找不到可以让它自发传播的优势。这将是一个需要长期思考的命题