Code418

发下图吧，如果确实是商家有问题发瑕疵品，那就光明正大把商家名也爆出来，算是做好事了

以前用 MQTT 搞过，不过最终的感觉是其实 IM 用 MQTT 实现还是挺麻烦的，我不是专门作 IM 的，这部分也是菜，只能讲一些粗浅的地方。其实上面大家都讲的差不多了。

群或私聊本身有自己的 topic，但事实上在客户端进入聊天时再订阅就好，关键在用户需要一个随连线一起订阅的 notify 用的自己的 topic，连上 broker 就必定订阅这个，往这里面 notify 就好。反正你消息包定义定好了你想通知什么都可以。

重点在 notification 的设计上怎么作高效。可以实时发 notify，单纯做到这步的话实现很简单。但是一个群就得先捞完所有群员然后各自发的话，无论是 dispatch 或是实际的 I/O，人多群多的情况下就会非常吃重，这部分看实际业务状况跟想怎么去设计权重与优化。不过单纯用 MQTT 的机制做起来我觉得挺麻烦困难的，本身的使用场景其实就不是常规的 Chatting 。

尤其 IM 还要考虑到实际的离线消息，就更加复杂麻烦跟炸性能。反正我做到这边我就扔着等有时间再优化了，还没时间拆人家的 IM 抄袭（划掉）琢磨人家的设计跟优化……

@cshijiel 劳您视认性打了三个问号，我觉得这边得回应一下。

这边是故意用这个词跟可读性切割开来的。我原本提到这个词指的是用拼音，如果把词给看出来了，那代码本身可读性应该是跟你直接使用日语 /中文是一样的，尤其在这边提到的特殊业务场景下。

但是问题在于看拼音还得花力气先看出来在写的是什么呢？就这么个情况。当然可能用词不是很精确，我原本也其实就是讲点个人碰见过的情况跟感受。

举个极端点的例子，编辑器你高兴用什么字体，都不能说字体让代码的可读性变差吧？但是太花里胡哨的你自己都得花力气去看懂，当然也有典型的 0OiI 之类的问题存在。虽然不太精确，但我这视认性指的就类似这种情况。

@slyang5 就你在看代码呢？而且我说的罗马拼音混代码里头看着难受，你在这儿 high 个什么？参予过实际业务项目被虐过才知道烦。而且我的感受跟人家规范有几毛钱关系？

虽然中文变量名我是反对的。

这确实是个很大而且很烦的议题。编码五分钟，命名一小时……有时候找对应通用翻译不是非常容易，尤其很多领域跟业务场景，其实内地的习惯跟全世界都不一样，只能勉强对应上去，事实上表意反而很不精确。而且常常也会导致命名太长的问题，生生当 java 写（咳）

前面提到的用中文枚举感觉虽然还是很难受，但感觉大家商量下，在必要的地方用，感觉还是勉强可以接受的，应该也可以解决掉大部分问题。但是如果是作为普通变量名或是其他 token 的话感觉就真的太难受了，这个完全不能接受。

而且中文本身过度自由了，有 ide 自动完成实现得够好的情况还成，但团队如果有人用的开发工具这个不行的话，估计应该会非常难受。

环境问题还有很多，现在可能还好些，基本上应该问题不大，但我想起几年前吧，有很长一段时间（记得是 java vm 的问题还是怎么的），我用 idea 全家桶没法儿用输入法直接键入中 /日等语言，那会儿要我在代码中用中文那就是要我死。而且这还要求开发环境必须要能用中文，虽然应该很少人遇到这种情况…

混杂拼音的话主要是感觉视认性跟表意性也很差，而且真的看起来会非常不舒服，这个不知道怎么整。日语的话用罗马拼音在这个问题上感觉不会这么难受，可能一方面因为英语中引入日语词汇已经非常多了，观感上已经习惯了，加上日语本身的音节特别干净简单。但是真的用太多看起来还是会非常恶心，而且虽然没有中文那么严重，视认性也还是很烂的。

楼主还有提到数据库，库里的表或栏位或 key 直接使用中文从没做过，不确定可行性，但也感觉难以接受，而且吐出一堆 field 都是中文这个看了会傻眼的吧就。而且 non-ascii 额外还牵涉到编码的问题，整体的可用性可靠性鲁棒性可移植性各种性感觉都会有影响，说就直接 unicode 解决一切拯救世界这个，反正我这种老古董是很难直接就接受的。

反正这个问题真的困扰。为了规避这个问题，我反正常常在其实不需要的情况下强行拆出来结构甚至逻辑，使其完全脱离代码，别问，问就是可自定义，高扩展性，增加业务弹性…

嘛写了一些想法但也没有提出什么建设性的东西，总之我就当插个眼。

恢复了现在