目前好的app会将数据存储在云上，给我们生活带来很多便利，我们可以方便的多屏之间获取到数据，也不用担心app及数据在本地删除后丢失的问题。但很多基于云平台的优秀软件到了国内就会出现一些使用上的问题。
比如Day One是一款跨平台笔记工具，得过苹果设计奖，也得到不少人推荐，功能确实很简洁实用。白天在路上用Day One写了一些文字，回来后发现uploading一直卡住，不知道是否跟文章中某些词语相关。打开iPhone VPN后，终于上传成功，但在电脑上还是半天下载不回来。忙了一些其他事情之后，发现终于同步完成了。
Day One底层可以选择用iCloud，Dropbox等云平台存储。这些云服务在国内访问速度及稳定性方面会存在一些问题。Day One可能出于功能简洁的考虑，将同步设计成后台进行。当同步出现问题时，界面上通常看不到相关提示，系统自动在后台重试同步。界面上也找不到任何同步按钮及菜单，也没有状态信息显示何时会进行同步，因此在同步失败时候，用户只能一筹莫展了。
在国外，由于云平台在基础网络链路及带宽方面都具有优势，因此同步阶段不会出现这么多曲折的情况。上面的问题更多是国内特殊的网络环境造成，软件开发商也无辜的被躺着中枪了，这是app存在的一类问题。
但并不是说国内的app就可以处身事外了，国内也有自身奇特的网络问题，比如一些厂商的DNS不定期的被劫持指向一些奇怪的IP。但开发商即使了解到这个反馈，未必有有效的手段短时间解决，这也是app存在的一类问题。
做互联网分布式系统的通常也有这样一种情况，在主从同步等场景下，数据只能保证最终一致性；互联网业务通常不会使用transaction来保证数据提交一致性，因此可能会存在半状态的数据，用户如果碰到这种情况并且会存在困惑，但开发商通常会采用事后修复的办法，从CAP理论的角度不会首先考虑引入事务来彻底解决，这又是一类问题。
上述问题是否能有效的解决？是否值得花大的精力解决？从“用户第一”的角度，所有用户的问题确实需要第一时间第一优先级解决，特别在影响用户范围足够的情况下。但上述这些问题都是小众群体及场景出现，而且都是在使用标准化方式的情况下出现了异常。
从架构师的角度，我是极力赞成使用通用化技术而反对自建轮子，比如不赞成用自己维护的UDP代替TCP，不赞成使用非主流或自己开发的数据库、框架、工具包；不赞成通讯上使用自定义的协议来代替XMPP，或者为了防止DNS劫持而去搭建自己的DNS方案。可以预见，这些自建方案的决策在一定程度上打开了一个潘多拉盒子，社区通用技术体系经过5-10年或更长时间的演进，经过较多问题的修改与避免。比如上面的TCP/HTTP RESET/URL关键词错误属于一个问题的话，TCP/HTTP协议已经很好的解决了前100个你看不到的问题。自建的体系从0开始搭建系统，可能需要将大量时间放在重复业界已经完成的功能上。
从工程师体验来说不太倾向于对各种特殊小众的环境都做一个适配方案。如果有机会能做这样一个比较，在“工程师体验第一（类似facebook的Hacker文化)”与“用户第一”做一个优先选择的话，究竟谁的成效很更好一些？老板们通常会倾向后者，类似有阿里的“客户第一，员工第二”文化；一些声称工程师文化主导的公司可能会声称选择前者，而且某些持这种理念的人也认为工程师主导产品改进的环境会激励工程师的主动参与及改进精神，而导致成效更好。另外一方面文化层面的东西很难直接比较优劣。
感谢新买到的低因伯爵红茶，让我写完这些文字后接着睡觉不会失眠。
