系统工程地完成一个任务
系统工程地完成一个任务
任务背景
几个月前，我的发小guok找到我，请我一起完成一个任务，这个任务有很多部分组成：
- 一个可以人脸识别的app
- 一个微信小程序
- 一个为多端提供服务的api
- 一套数据库+文件存储的设计
这些组成部分有一些我非常熟悉，比如api和数据库，我每天的代码都围绕着他们； 也有我非常陌生的领域，比如app和小程序，我只和这些开发者进行过合作，并没有完成过这方面的代码。
完成过程
刚开始的时候，是我一个人完成这任务的所有组成部分，后来，guok找了外包公司，负责app部分的开发。 我开始思考如何让这个任务可以持续地进行，能够在我或者外包公司开发完成过后，后续的开发者可以顺利地接手迭代。
技术选型
app部分
- 我使用的是flutter，准备支持Android和iOS，后续外包公司使用了Java，仅对Android进行支持，这也满足了现在的需求
微信小程序
- 我采用了凹凸实验室的Taro框架
api部分
- 我使用的是Python的Django框架，没有使用Java的SpringBoot或者Golang的gin，是因为虽然我对两者都更加熟悉，但是我需要考虑云端数据呈现的问题，又会增加了一个组成部分的工作量
数据库+文件
- 我使用的是Mysql，我也没有使用其他中间件，对于定制软件的使用者，简洁够用即可
- 文件我通过api直接存储于实例上
代码的维护
我在码云上开辟了多个私有库，用于存放几个工程的代码
可持续地部署
在开启堆码之前，先进行了流程疏通
- app从打包，到传至云端，通过链接下载
- api代码拉去实例，systemd service启动与守护
- nginx对api、file等service_name的转发验证
于是当我还没有投入多少精力时，已经可以整个流程跑通，剩下的就是对业务逻辑的翻译，堆码
阶段性的验证与交付
即使是发小，他也是甲方，对于系统的期待总会超出实际的进度，尤其是在进度偶然达到或超出预期时。
所以要非常慎重地进行预期管理，否则就会进入一个恶性推导：
进度赶不上-> 信任感下降-> 进度预期就是赶不上-> 果不其然没赶上-> 信任感荡然无存
正向推导：
主动 沟通预期-> 评价预期的合理程度-> 约定交付预期-> 如约完成阶段性-> 靠谱
核心：
- 编码的硬实力
- 天赋
- 勤学苦练
- 推动外包公司（或者其他合作伙伴）的软实力
- 平等对待
- 多提问引导，少指导
- 注意节奏
这样做的好处
- 可以有效地规避不必要的服务不可用：
- 因为开发过程都是建立在稳定服务流程的基础上，所以服务抖动可以有效减少
- 可以减少很多沟通成本
- 和需求方及外包公司的沟通都是有节奏的进行，减少了不在节点上的无效沟通
- 任务如期完成
- 这是最重要的