ZHEN

日本的IT表面上看起来是前端难用，其实前端只是暴露给用户的一个界面。很多UIUX其实是因为日企后端的数据结构、接口设计，以及不同系统之间的数据兼容性的问题。 我觉得收货地址和邮编是个很好的例子。 附图是淘宝收货地址的截图，从前端开发的角度看，这没什么技术含量。定位可以调用系统的位置信息，地址搜索可以利用高德地图的API，选择之后，可以通过Geocoding或者Reverse Geocoding获取位置信息。 但在这里，系统可以把用户输入的地址拆分成不同的数据对象，不必从头到尾都把地址当作一串字符串处理。 比如一个用户填写「湖北省武汉市江岸区台北街道OO路OO小区XXX室」，对服务器后端而言，这里面至少包含行政区划、道路或建筑物、楼栋、房间，以及可能关联的地理坐标。 这些信息可以在数据库中分开储存，比如行政区划可以关联稳定的区域编码，建筑物可以关联POI ID等等。 但如果地址只以自由字符串的形式保存，那后端系统在做地址判断的时侯，就可能必须要重新解析字符串。 而如果数据在录入阶段已经完成了必要的结构化处理，下游系统就可以直接用这些数据。 物流系统不需要依赖完整地址字符串判断行政区，也更容易处理不同写法指向同一地点的问题。 这里涉及一个数据库设计的基本原则：人类阅读所需要的显示文本，不应该成为机器识别对象的唯一依据。 而日本的地址数据，就存在这方面的问题。 日本的地址体系首先在行政上就极其臃肿复杂。再加上旧字体、全角半角、异体字等等，同一个地址可能存在多种写法。 这就涉及Normalization和Entity Resolution。由于日本常年没有统一维护一套master data，导致不同机构分别各自维护地址数据，因此导致了大量同一地址不同写法以及数据难以关联。 这说明日本的统一地址数据很可能还在建设中。 日本还有个问题就是Data Interoperability。 对于已有大量历史数据的系统来说，前端改造可能只需要加几个组件，但数据结构的改造要涉及历史数据迁移、接口兼容等等。 而且新旧系统还必须在一段时间内并行运行等等问题，这对不愿改变、没有人愿意担责任的日企来说是非常难以接受的。 日本的IT系统的最大问题就是总是喜欢把其实可以用很小成本实现的结构化、标准化和可引用的重复信息，留给用户不断重复填写和确认。 在已有成熟地图 API、邮编数据库和地址标准化工具的情况下，为什么部分业务流程仍然需要用户承担大量本可由系统处理的工作？ 我觉得这是日本的UX最差的地方，一个IT系统应该要把现实世界的信息转化成可靠、可自己复用、可自行交换的数据，并且尽量避免让用户反复完成机器本该完成的工作。 而日本的前端暴露出来的全都是这样的问题，根源就是日企的后端数据严重落后。