@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 反而没有去做这个功能？

代码量有多少？建议不要直接在屎山上改，而是认真品鉴屎山的代码逻辑之后，用更好的方式重新写一遍。
有原始需求或者设计文档最好了。

血泪教训，特别是需要长期维护迭代的项目，早期图省事屎上雕花，后面会长痛。
除非真的赶时间，不如短痛一下重写。

你知道 redis 的某个版本的官方 Python SDK ，连接较旧版本的 redis 服务器，使用新版本才有的方法的时候，报的错是什么嘛？
SyntaxError 。某次我就踩了这个坑，发布到生产，用某个 redis 方法报语法错误，想破头都想不明白为什么测试环境没这个问题，最后发现是服务器版本不一致。一般人看到语法报错谁能想到是服务器版本不一致呢？

你说到底是这个开源的 Python SDK ，官方写的不好呢，还是说 redis server 写的不好呢？

当然要比烂还有更烂的代码，开不开源并不能代表代码质量好不好。
写的项目，有健壮性，容易维护，可读性好，性能好，稳定，那才是质量好。

@Linho1219 #61
物理的有意思的地方就在于，物理就是物理，他是不会变的。
区分高中、大学物理的原因在于教授对象平均水平不同，但是对于分析物理问题来说，就不应该用所谓初中、高中、大学物理来局限。

你提到了力矩，我大学物理没怎么学，高中物理倒是不错。这个题我的解题思路，其实是从重力势能出发的。
如果没有东西阻止重力势能的释放，那么重力势能释放了就是会变成动能，变成动能了，质心就是会位移。
有重力势能的质心有位移趋势，但是没有位移，那就必然说明，有支撑力或者摩擦力等力在阻止位移。

如果解题的时候用学习阶段来局限自己，那是考试考习惯了，其实是思维被局限了，并不是什么值得骄傲的事情呀！

我个人认为很多高中物理题是出的非常不好，很差的。
出题人总是会找一个理想场景去教授他想要教授的一个知识点/解题方法，但是很多时候，找了场景之后，加了太多限定条件，太多理想化的设定，导致学物理这件事情变成应付考试，而非真的去理解物理，感受物理了，这种教育从教授物理本身来说，是不对的，是失败的。

回到这个题，如果你还是用高中物理的知识体系去局限自己，那么假设我把题目稍微改一下，我把绳子与物块的连接点移动到非常靠右，甚至直接连到右上角的位置，然后再问你有没有摩擦力，这个时候还打算把物体视为质点去做受力分析，就会让人非常难受，因为你自己的直觉告诉你，如果墙很光滑，物块应该会旋转着往下滑才对。

所以才要用更先进的知识体系和方法论去分析问题，因为你会发现高中物理有些方法论是过时了的，不适用于大部分场景的。

学物理就是学物理，而不是学做题。
做题和考试是一种落后的、局限的练习和考察一个人对于问题的分析方法论，和解决方案提出能力的考察方式。

本来周五下午心情不错，看到 25 月的赔偿+分公司的橄榄枝，心情又不好了

@Linho1219 #54
https://i.imgur.com/1jNu4g3.png
https://i.imgur.com/B4E1bKP.png
不知道我这样画能明白吗

@Linho1219 #49
我又想了一下，绳子不可伸缩的话，我的第一个结论是错的。
或者这样，另一个思路，如果题目前提还维持一致，即墙壁粗糙，物块粗糙，绳子不可伸缩，重力方向与墙壁方向平行：
如果把墙壁和模块都突然变成光滑的，物块移动/转动，则说明原来应该有摩擦力，否则应该没有摩擦力。

题目没提到的，实际上可能是重要变量的情况：
·物块质心位置；
·绳子与物块连接点位置；
·绳子方向延长线与物体质心位置的关系；

所以换句话说，如果绳子与物块连接处不在完美的位置上，比如靠外，那么通过调整物块的姿态和位置使得物块质心可以下降的话，那么即说明这个题设如果去掉墙壁和物块摩擦力，物块就会发生位移/旋转。

只有物块质心、绳子连接点、绳子方向延长线与物体质心位置的关系在一个非常恰当的点，在光滑的场景下这个物块才不会旋转/位移。

我的脑子不用纸笔或者画图工具能思考到的深度就只有这么多了，脑子告诉我可以用绳长作为半径，绳子与墙壁连接处作为圆心，画一个圆弧；
然后绳子与物块连接点，再分别与物块左上角，左下角，右上角做圆形；
物块形心与物块左上角，左下角，右上角又做圆形；
移动/旋转物块，使物块四角至少有一个与墙接触，绳子拉直，且物块质心与原图示姿态有所下降，则说明物体仍有下降趋势，存在摩擦力。

你的题解里面我没看到有对物块质心、物块形心是否还有下降趋势的考虑的，因为物块是可以旋转的。

感觉题目没有足够的前提和假设。如果是高中物理题，应该要强调重力方向和绳子不可伸缩才能解题。

我有个思路，不知道对不对。

如果绳子完全不能伸缩，那这个场景，物块是稳定的情况下，应该是没有摩擦力才对，分力都是支撑力、重力和拉力。


如果这个绳子是有弹力/可伸缩的：
情况 1：
在绳子对物块拉力的重力方向的分力与物块重力刚好相等时，物块与墙壁不存在摩擦力。
情况 2：
绳子对物块拉力的重力方向分力与物块重力不相等，分为多种情况：
A：拉力分力比物块重力小，这种情况应该不会存在，因为这样绳子会伸长，物块会往下掉/物块以左下角为支点翘起来；
B：拉力分立比物块重力大，这种情况可能存在，物块在重力方向合力 = 墙壁对物块向上的摩擦力+物块重力+绳子在重力方向拉力；那么这时物块与墙壁有摩擦力。


或者换个思路，把绳子换成弹簧，增加或者减少绳子的拉力，看物块是否还能维持不动。还能不动那就是大部分情况有摩擦力，只有绳子长度和力刚好是某个情况的时候才能没有摩擦力。

没有 code review&没有完整测试用例做回归测试，个人理解主要问题在改你代码的人，次要责任在整个团队缺少 code review 环节&完善的回归测试，技术头头/组长没有制定相关制度&没有有效监督的问题。

个人感觉你别等领导问你了，你主动汇报一下情况，然后给点建议说抽时间做完善回归测试和 code review ，领导不采纳那是领导/时间预算问题了。