deepin 搞的 wine 版的 tim 和 qq，体验基本上和 win 版一致了，偶尔有丢失焦点的问题，不过这个问题也是 linux 比较常见的问题。

水平一致，优先招妹子，总体而言应该比男生好找工作。

@wizardforcel 不要总是用反问句，这样会显的你攻击性很强。

@HangoX
@incompatible

这类问题不可能完全解决，总归会有漏掉的地方，如果是一次性开发完就不在更新的产品，自然是把所有出问题的地方都解决了即可。

但是在大型的不断集成新功能的产品，app 有了十几个版本，每个版本的接口都会一直运行，老版本的接口在当时的需求设计下是没有问题的，但是后续需求变动，导致老版的接口出现异常，然后 app 就会出现闪退的情况。还有团队里面会有快速的需求迭代，以及临时的 bug 修复提交代码到线上，这些都有可能造成异常问题。

代码 review 解决的还是一个有序的问题，但实际情况下不会有时间给每个接口做足够的检查，有 review 的时间还不如让开发自己写接口测试。大型项目里面还存在大量接口转发的问题，例如我的功能里面部分页面已经有其他人现成的接口写好了，我不过是调用对方生成好的数据返回给客户端，这种情况下，天知道对方的代码有没有类型错误的问题，最简单的方案就是直接全部转成 string 来解决。

最终大家偏向全部 string 方案的原因还是类型错误的这个问题太低级了，但是又很难杜绝，但是出现的闪退问题却又是测试里面被认定为最严重类型的问题，多搞几次这类错误，团队里面谁都扛不住压力，大家只能放弃理论最优方案，转而使用比较 dirty 的方案。

第二种是理论最优，但实际上跑过大型的复杂的系统之后，整个团队会倾向于第一种写法（ bool 采用 0 和 1 表示）。

具体原因是客户端数据类型错误的时候会导致应用直接闪退，虽然明确类型是最优解决方案，但是客户端无法确定服务器端会不会返回错误的类型，到时候客户端就闪了，对于 boss 而言，出现闪退这种严重的问题，竟然只是因为类型错误导致的，团队里面都很难承担这种压力，最终开发在实际应用中会尽量将除 id 之外的字段全部转成 string 来解决类型错误的问题。

用 DDE 吧，除了有点小 bug 之后几乎完美了。

@Telegram ruby 的语言有些小众，但社区创造力十足，轮子要多少有多少。。。

@ioth 部门领导没有责任带领整个部门的水平上升吗？

现在劳动法完全偏向员工，为何这么怂。。。

@zhaolion 这就是现实世界，一荣俱荣，一损俱损。所以大家工作的时候最好不能想着独善其身，多努力点总是好的。

区别对待是正常的，不让参加年会是明面上的区别对待，年终奖少是暗地里的区别对待。

如果年终奖不被区别对待，那我宁愿不参加年会。

@biggerbug 因为灵敏总是和嗅觉搭配到一起的，听觉这个词平时用的比较少，一般都说自己耳朵或者听力比较好，所以看到觉和灵敏，就自动脑补了嗅觉灵敏...

@EvanG 第一眼看成了我嗅觉比较灵敏，想着你这技能好高超，可以闻到领导的皮鞋

@exiahan wine 可以支持运行腾讯的那一堆软件，不过 wine 的版本没有腾讯的自动升级，每次升级都是 deepin 官方重新打包的，然后更新。

@exiahan 我知道 wine 不是模拟器啊，你是想表达啥？

这就体现出 linux 的好处了，在 deepin 下面用的 wine 的 tim，功能和 Windows 版本一模一样，但是完全不担心这些问题。