构思：略

设计：主要分为三部分，一个是前端的页面原型设计，一个是后端的数据库建模，还有一个不太典型的是数据的获取，即爬虫。

• 说起来也好笑，虽然工作中一直都是写前端，但是反而是关于界面的部分难到我了，工作中都是拿到设计稿，构思之后就可以开怼了。现在呢，最大的问题就是脱离了 UI 设计稿之后，无法直接对一个 App 的各个页面建立起直观的认识，即产品设计相关的知识不足。导致进度比较缓慢，好在这次有了一些经验，可能下一次就好多了。
• 最初时候，页面非常的简陋，不过随着后端业务逻辑的进行，以及对 App 整体功能的把控，各个功能也慢慢的丰富起来了。如果这个业务能够跑通的话，随着时间的流逝，肯定还会不断的新增功能，到时候估计还得考虑怎么让菜单项更合理的显示了，而不是像现在这样，把所有的功能都列出来，尽量填补 App 页面的空白。
• 爬虫相关的也额外耗费了一些时间，主要是对原本的数据进行清洗浪费了时间，但是我觉得更大的影响还是所谓的完美注意，经常爬取之后又重新处理了一些东西，可能调整很少，但是我还是选择了清除数据重新来过。这算是个人的一点强迫症，也算是一个确定吧，毕竟绝大多数的时候追求的的确是能用就好，而不是用时间去换取“完美”。

开发：开发主要是分成两块，前端、后端。

• 前端方面，虽然前期主要分发渠道是 App，但是中期可能还要有配套的小程序和 H5 页面，基于这方面的考虑，前端选择使用的是 uni-app。毕竟除了它，好像也没什么太好的渠道了。现在国外主流的跨端技术主要有 React Native，Flutter，但是它们都没有考虑小程序，毕竟小程序是国内特有的生态。而京东家的 Taro 主要是针对小程序的跨平台解决方案，又没有 App。所以矮子里面拔将军，最后选择了 uni-app。当然，除此之外还有很大的一点考量是——目前的应用主要是业务驱动类型的，对高性能和一些炫酷的特效并没有什么要求。如果你也在考虑跨端技术，最好还是要考虑到这些方面。

  • 题外话：不要过于相信 uni-app 官方自吹自擂的一些话，比如 uni-app 也可以使用 Weex 作为渲染引擎，这样就是原生渲染了，性能很好什么的。然后实际上这套方案有很多坑，比如在 Android 机型上，采用 Weex 渲染时，会有一个肉眼可见的从上到下渲染的过程，表现为就是论坛上很多提交反馈说 nvue 闪屏的问题。后期官方做了一些修补，比如部分 nvue 组件可以使用 render-whole 属性配置为整体渲染，然而效果依然不甚理想。
  • 软件工程领域没有银弹，跨端开发也同样是，特别是在掺杂上国内特有的小程序生态时，更令人头大。uni-app 这个方案肯定不能说是尽善尽美，说坑很多也不为过，但是好歹也是做出了东西了，给开发者带来了更多选择，也挺好的。
  • 做技术选型时，还是要结合自己的业务来分析，哪有这么多尽善尽美，完美无缺的东西呢。

• 后端方面，选型是 Nest.js(Fastify) + MongoDB + Redis。最开始选择这套东西主要是因为和前端技术栈重合度高，比较方便结合起来。后来在实践的过程中，发现 TypeScript 用来写业务挺舒服的，而且 Nest.js + Fastify 这套组合性能也相当不错，再加上 Nest.js 目前发展迅速，生态良好。后面应该也是主要用这套技术栈了。

部署，也是主要分成两部分，前端（App）部署和后端部署

• 前端 App 部署主要就是打包出来应用上架应用商店，应用商店这块比较复杂，因为现在各个商店几乎都不支持个人开发者上架了，并且平台规则不一样，这里恐怕没有办法一个一个去详细说。此外个人觉得还有很重要的一点就配置好在线更新相关的功能（基于 JS 方案的跨端技术一般都会支持热更新功能），不然上线后不能更新就搞笑了。你考虑完全使用应用商店提供的更新，那就无所谓了。
• 后端部署，其实我也蛮想各种服务都上云的，毕竟省心。然而太贵了，根本伤不起，阿里云光是那个 MongoDB 云服务就贵的离谱，当然，Amazon 的 MongoDB 服务其实也是这样。看了一遍后我就放弃了，最后还是在 VPS 上配置起服务环境的，毕竟某 VPS 从前年黑五购买过之后就基本限制，CPU 平均下来估计都没跑过 5%。整体方案大概是 Let’s Encrypt(SSL 证书) + Nginx + PM2 + Node.js + MongoDB + Redis，同时为了避免在服务器上使用 node_modules，Nest.js 的后端服务是经过 ncc ​打包的，这样丢到 VPS 上的最终产物大概 10MB 左右，轻量多了。

总体的整个过程大概是这样，其中还有很多的细节可以继续深入探讨，不过每个细节都描述清楚，就得写的很长很长很长了。这篇就当作一个整体流程概述吧。