@woodfizky #31 打错了，清新->心情

还有就是隐藏门把手确实设计上很讨嫌，肯定有更好的方案在降低风阻的同时，交互上也能对用户友好的。
并且作为消费者我明确的希望车企在同一款车型上给消费者选择空间，可以自行选择隐藏把手和传统机械把手。

SU7 我记得看某些测试的话，正常碰撞事故发生后，车自己会尝试解锁。但是如果判断事故发生-解锁门的这个功能也在事故中失效，那就失效了。

正常情况下不管油车还是电车，只要自己没解锁，那不管是机械把手还是电动把手还是隐藏把手，都是不好开的，更何况碰撞之后就算解锁，也可能因为车辆变形导致车门开不了。

还有些评论说希望设计一个紧急时刻能从外部解锁车门并打开的功能，我能理解你的清新，但是我只能说，如果你是车主，那你也得做好车因为有这个设计而被轻易盗走的心理准备。

善用聊天记录合并转发、善用消息收藏（收藏还能打标签）、善用消息引用。

以上技能，可以组合使用，学会了你就没必要拉那么多两个人的群。找消息不累吗？

以前还体会不深，看了几次医生之后就知道千万要避免医生不声不响给你开中成药，开药一定要主动说不开中药。

一般药钱，中成药能占到六成甚至更多。
特别是有一次给我开了 300 多中成药，我拿到手才发现是 6 瓶擦拭洗剂，用了几个月才用掉一瓶，根本不需要 6 瓶那么多。

https://i.imgur.com/D6UIgrw.png

直接用的微软拼音，我是老老实实把拼音都打全了打字（有时候会偷懒省韵母）。
之前玩过一会死亡打字员这类打字游戏，可能有点帮助。

打字速度，每个人都不同，每个人用不同的打字方法熟练度也不同，很难量化评价。
一般人用各种打字方法都不会说特别特别快了。
你去看那些打字比赛或者破记录的，有参考意义吗？那些方法一般人不一定能学会啊！要求太高了。

自己打的舒服就好了。

名声大的人发言才能有人看到。

小红书刷到很多例几年前就在吐槽西贝的了，没流量。
普通人，就算在评价平台评个差评，不用媒体进行大规模扩散，也基本不会怎么样。

另外确实是西贝老板自己作的，哪怕不回应都能继续用贵价卖预制菜。

一直反感相亲的原因就是目的性太强了，很容易让人跳过恋爱阶段直奔结婚，变成搭伙过日子，特别容易培养成不对等的婚姻关系。
其实从前几句话就发现问题了：你赶着结婚不是因为遇到了对的人，而是因为父母催你。


这样的关系，没有长期和对象相处，筛查不可调和的矛盾/原则上不能接受的对方的缺点，就算结了，基本上也是不幸福的婚姻。何必呢？
遇不到对的人还不如单着。

题外话：V 站热度最高的帖要不就是这类，要不就是推广抽奖的。。。
才 4 个多小时两百多楼。

不要把相关性和因果性搞混。

@cmdOptionKana #15
不是音不音译的问题，而是日语发明了一套用片假名作为一种另类的拼音去读英文的方法。
日本人虽然看片假名不一定能知道是什么意思，但是一般能够读出来，虽然和英文原音不一定一致，但是每个人用片假名读出来，读音也差不多。

中国没有这套比较统一的音译标准或者将汉语作为英文拼音的标准。
如果读英文标准还可以，交流的人群英文听说水平都可以的情况下，是比较让人舒服的。
但是一旦周围人英文听说水平不怎么样，那很容易出现一个词在几个不同人的嘴里出来几个完全不同的读音。


其实这个锅还得英文背（当然也有个别人学不好英文听说的原因），同样的拼写方式，几个词可能读法音标却完全不同。英文也是被古英文、法语、日耳曼语等语言花式灌注的，本身就存在这个问题，导致在没有词典和上下文的情况下无法根据拼写本身获取标准读音。（当然中文也有类似问题，比如多音字）


那么这一套片假名作为拼音去读英文的好处说了，坏处呢？
https://i.imgur.com/EfkTceM.png
坏处就是只标准了读音，但是丢失了词句本身的信息。
就类似你用汉语拼音打了一屏幕字去交流的那种感觉。
你见过那种中文输入法坏了或者没装，打一串拼音的窘迫场景吧？
拼音是不太可能读错啊，但是书面交流为什么还要打一串拼音呢？

#11
@cmdOptionKana 漏 @了，@一下

不太算是一回事。

OP 提到的マージ，在日语里是有专门的词可以对应的
https://i.imgur.com/mCJoFgp.png


代入到中文语境，你同事跟你讨论用 git 合并代码，但是讨论到 merge 的场景，不用合并，也不读 merge 英文，而是读"墨之"。

脑补了一下已经开始难受了。

坐电车也可以很舒服的，司机开的好就行。
坐油车也可以很难受的，司机一脚地板油，一脚急刹，跟赶着投胎一样穿插变道加减速，那真是跟什么车没太大关系。。。

只能说电车便宜，降低了人买车开车的门槛，司机人群数量增加了，开车开的不好的自然就多了。

还有一种可能就是有些便宜的油车，不地板油根本感觉不到推背感。。

设置->帮助与反馈

点开之后上面的 title 是: kf.qq.com
气笑了。

你不骂，我来帮你骂，这就是傻逼产品。


我觉得很多程序员其实都是在帮不称职的产品做了一部分事情的，因为很多产品的能力都很差，不知道怎么设计交互、怎么设计流程和程序逻辑。

区别在于有些产品知道自己能力差，你帮他做了本应该他做的部分，他会知道你帮了他；而有些产品不知道，甚至还反过来指责你。

面对这种傻逼产品麻烦你严格要求他，需求文档、UI 设计文档、程序逻辑设计文档等，都要他负责或者牵头输出。
这些文档没有达到你的接受标准，甚至没有文档的情况，不要开始干活！有问题就向上反馈！

开发和测试的利益完全看公司怎么管理和设计奖惩制度的。

测试独立出来成为一个职能的目的，就是用不同于开发人员的视角（尽可能的贴近用户）来对程序功能做测试。
本质上是为了尽可能避免项目进入到投产阶段之后才发现问题，轻则导致返工，重则造成损失。

按我的理解，正常情况下，测试帮你把 bug 测出来了，是好事情。
如果是程序逻辑上的问题，那你确实要感谢他；
如果是产品设计上的问题，那你们应该一起找产品，讨论设计是不是真的不合理，不合理的话怎么修改设计；

除非你们公司属于那种被测出来 bug 就要扣绩效的，那我建议你跟管理层反馈一下这个制度的不合理，或者干脆换一家公司。

warning 被设计出来就是有用的，不是每个人都能避免写代码的时候犯低级错误的，保留并且认真的留意 IDE 的这些提示是一个减少潜在错误的很有效的手段。
当然前提是 IDE 的各种 warning 机制设计的比较合理。

我个人写 Python ，是要用 Pycharm 确保整个文件都监测不到最低级的问题的。
有些地方类型注解不对/用了保护变量等不规范但是没办法的写法，也不会直接关掉 IDE 的警告，而是直接用 IDE 的注释，关闭当前行/方法/类的告警。
这是我保证编码质量的一个有效手段，所以当我接手别的同事的代码，然后发现一堆包括但不限于 IDE 告警、不规范写法、垃圾设计等等的情况时，那都是非常难受的，需要花费大量时间精力去品鉴每段代码到底有没有潜在问题。。

除非我不用长期维护这些项目，短期内可以考虑捏着鼻子上，要我长期维护的话，不给我时间重构/优化的话那真的是会非常难受了。

@wnanbei #31
那换个思路，在异常捕获里再判断版本，如果发现是版本不对，不直接抛出 SyntaxError 也可以啊

@wnanbei
关键官方自己写的 SDK 完全可以在连接 redis 服务器之后获取 redis 服务器版本。
如果尝试在旧服务器上执行新版本的方法，那完全可以在执行之前就抛出类似 NotImplementedError 或者 NotSupportedError 。
连官方文档都能详细到某个方法甚至是某个方法的某个参数在哪个 redis 版本引入的，为什么官方 Python SDK 反而没有去做这个功能？