今天最大的感触是：与其自己花时间用已经知道的方法实现功能，不如寻找最佳实践，然后套用。

通过自己造蹩脚的轮子，确实也能解决实际问题，但总是容易遗漏要考虑的点，后续的开发、维护，也是问题多多。

反观寻找最佳实践，虽说前期要花较多时间深入理解相关知识点，但这几乎是一次性投入，之后会有源源不断的好处。

顶住短期的压力，寻找最佳实践，是长期来看的最佳选择。

之前家里的电饭煲坏了，我觉得扔了可惜，就拆开看，其中电路板坏了。于是，我在淘宝花 28 元买了电路板。可惜装上后，还是不干活。如果是专业人士看，应该是很简单的故障，应该能修好的。可惜，我并不是专业人士，也并不打算花很多时间来修。

并且，这个电饭煲已经用了多年，淘宝上全新的也不足 300 元。如果满世界找售后维修点，先跑一趟送修、再跑一趟取回来，甚是不划算。

无奈，从经济角度来讲，扔掉是最划算的。虽然从环保角度上，我很不愿意如此。

于是，我买了新的。可是，即便已经买了新的，旧的还是在家里放了好几天，我才真的把旧的扔掉。

对于一个坏掉的、已经完全被取代的电饭煲尚且如此，对于其他的存量，我怕是更没有勇气和能力扔掉吧。这时候，存量已经不是优势，而是包袱了。

你，有什么存量？

今天基本完成了手机与手机之间的数据同步，技术上主要是 Core Data > CloudKit > Core Data 及反向流程。

虽说已经基本实现功能了，但感觉很多环节都是使用野路子，依靠对技术仅有的理解，堆出解决方案。但，最佳实践是什么呢？这是我很好奇、也是让我很痛苦的地方。接下来，准备再花点时间了解下 Core Data、CloudKit 的技术，并参考网上的资源，看如何优化现在实现的方案。优化后，可以方便地应用于 Klib 等其它产品中。

另外还有一个关联的问题：数据如何互相驱动？现在的数据存在 3 个地方：Core Data、CloudKit、内存中，要精确实现这三者的一致性，且实现一处修改、推送修改至其他处，很是麻烦，其中有很多逻辑要处理。如何简化呢？比如，是否能去掉内存中的镜像，并不会大量增加 IO 请求、并保持界面的快速响应？

回看日记，已经连续花了一周处理这个事情，时间确实长了点，效率也下降了。明天放空一段时间，看状态再继续。

多端同步的复杂度，真的让人怀疑人生啊。

网络异步请求 + Core Data + CloudKit + iOS 与 macOS 又平台 + 冲突合并 + UI 响应…所有这些因素相乘所组合出来的复杂度，让我怀疑我是否适合做程序员…

Anyway，今天还是有进展的，搞定了把 Core Data 上传至 CloudKit，并能处理服务器端有变更时的情况。明天搞定从 CloudKit 下载数据、并组装为 Core Data，实现的效果就是：在一台手机上做的修改，能同步至另一台手机。

这两天在看 CloudKit + Core Data 配合的方式，本来是照着 这篇教程 学习。本来，是想整体学习、整体迁移至自己的产品中。无奈，他的实现方式确实复杂。再加之，编程思路、惯用法不一样，看起来好累。

最后，还是放弃了，准备自己一点点从零开始搭建。当然，也是会参考教程中的一些思路。遇到问题、解决问题，这是自己比较习惯、适应的开发方式。

今天完成了部分数据结构，明天铺上传、下载相关的代码，争取本周末把这个部分好好搞定，包含测试用例和单元测试。