设计

1.新功能部分开放，或者用户部分开放。

比如新功能就只在高手区开放测试，普通场继续用稳定的版本。（普通场用户多，高手场为了尝鲜）

2､还有就是更新，有时候会出现，下载最新版本的有这个新功能，但是旧的安装软件提示已经是最新的版本，但是就是没有那个功能。

只有重新安装最新的包才有。

2018-09-05

xcode设计还不错，它把build的文件夹放在工程目录外，这样我想备份工程的时候，直接把工程打个压缩包就好了，比较小。

而Android Studio会把build目录里的也打包进去，内存好大。

不过xcode 工程里面有git，也蛮大的，我打包一个工程，代码1M不到，git就有14M。

可能xcode是基于，把git打包好，下次，在别人的电脑也可以直接登git上传代码？？？只是猜想。

2021-08-13

最好的结果返回是: 结果码+说明。   结果码是类型，说明是具体失败原因，可以带入参。

{
    "code": 10000,
    "text": "成功"
}

2021-09-10

一些关键参数，如果缺失，要么就全部拒绝，要么缺少部分不更新。（不过第一种更靠谱些，不会给别人错觉，把失败原因告诉别人，别人好修改。第二种方法就容易产生错觉，我更新成功了呀，实际上有些部分没更新）。

失败的例子：以前专辑是有图片的，更新的时候，图片不存在，这个居然更新生效了，图片变成不存在了。。。。

2021-10-08

代码中多用图片的相对地址，一个是方便图片迁移，二个是如果ipv4切ipv6也方便。

2022-08-15

按名称查，最好能实现，一个是按模糊查，一个是按精确查。有时候，名称就是一个单字，比如 “爱” ，如果用模糊查，就查出很多不相关的资源。

2022-09-07

数据库主键自增长适合单体服务。自定义主键（并随时间变动）适合分布式集群，这样他们在本地生成的ID不会和其它子节点重复。

2023-01-31

通过心跳（指定间隔的http请求）记录用户的状态，（是否登录，前端会员状态，视频是否可播。）。高级点，可以操作用户退出登录或者apk升级，或者debug日志上报。（当然了，需要前端预先设计好逻辑。）

2023-05-10

今天遇到了一个很有趣的事，有一个用户，他用了别的软件（不知道是不是c写的），然后他升级了数据库，发现数据列表的排序变了，很烦了。

原因很简单：估计是之前软件是用了默认排序，默认排序可能在不同的数据库版本中不同。就造成了现在的乱序。（引出第一个原则：所有的列序都要手动排序，不能用系统默认的排序）。

扩散思维（一个好软件，在不考虑商业利益的情况下）。可能改变的东西，其它最好写入配置，这样你交付给一个不懂代码或者说本来就没有源码的客户时，至少，它能通过配置，做一些定制化的修改。

【个人开发的时候，为了偷懒，有时候就在代码里写死配置，开发效率高，不过后期维户不方便。总以为要改就改代码，不是挺快的嘛，没考虑到客户不懂代码或者说没有源码的情况，即使懂，也肯定是改配置方便 ，不用重新编译。】

2023-11-22

好的系统就应该尽可能复用资源。比如A系统有媒资信息，B系统需要用到媒资信息，就从A系统拿到基本信息，其它扩展信息再由B录入。

最典型的就是图片系统

如果图片想复用，图片字段就不能只填地址path,而是一个图片id, 图片id再关联到图片地址，图片大小，图片比例。然后能给图片打标签。这样能快速搜索到，并能复用。