只是这几年好了吧。我刚买 M905 和 M705 那段时间，微动一直坏。好在保修够长，坏一个罗技给我换一个，换到后来某次突然就不坏了，之后就再没坏过。

十五六年前建过一个 QQ 群，聊技术以外的话题就踢，氛围就还挺好。现在 Telegram 上也有类似这样的群。

看来只有我没读懂标题

我可能更愿意买 E7

闹钟

竞争力在于你花在思考上的时间的日积月累。

这个问题的根本，是磨损程度不一样的两侧轮胎的抓地力极限不一样，容易失控。再加上不同品牌、型号，花纹不一至，进一步放大差异。

而这个极限，除了开车的激烈程度以外，跟路面状况也有很大关系。比如湿地、雪地，抓地力的极限就会很小，即使小心开也更容易达到极限。

而单侧轮胎先到达极限，车辆会旋转起来；两侧轮同时到达极限则会稳定一些。

剩下的怎么选择，就看你愿意赌概率还是愿意保险一些。跟买保险差不多吧，有些人倾向于省钱，有些人倾向于保险。

@unregister 我倒是没情绪，摆事实罢了。

搞笑，现在小屁孩的脾气都挺大。你只要告诉他“我看好你哦，业余多打打游戏看看动画片”就好了。

剩下的让社会教育就好了，市场不跟你讲情绪。

不就是开发速度快的同时 bug 少么？

那就留着这个方法，在这个方法之上再封装一层，不同的状态用不同的名字。

比如：

```
def 吃饭
selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList(状态=1)
end

def 睡觉
selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList(状态=2)
end

def 打豆豆
selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList(状态=3)
end
```

吃饭、睡觉、打豆豆很容易就能看明白了，这样就不用再纠结 `selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList` 这个方法的名字，不是问题。

要总结一个干了很多事情的方法，得用业务意义上的名词，而不是直接描述底层细节。
吃饭不要写成“哺乳动物通过蛋白质摄取能量”

@Navee 看了半天你对全责有异议啊，否则就不会认为 A 需要承担事故责任。

@jones2000 所以你们就说重写好了，别扯什么重构嘛。干的是重写的事，整天吓唬人说不要重构，搞得这么好的技能都没几个人掌握。

你让项目更容易维护我不反对啊，去掉冗余代码我不反对啊，能达到这个目的就可以了没错啊，我也不反对啊。讨论了半天你有没有发现你跟我说的完全是两件事啊？用你程序员严谨的逻辑想一想。

@jones2000 所以说你们说的重构不是重构。请回顾一下重构的定义，以及重构名录里那些细碎的步骤。要是真的重构过代码，根本不会说出这些名言。所以说大家说的所谓的“重构”，其实都是在重写。

目前有三个版本：Java 版、Ruby 版、JavaScript 版。吃力就吃力呗，这书属于认真啃过一遍收益满满的。

可惜无论是工作中还是网络上，一旦谈起“重构”，95% 以上的人给我的感觉是这书只翻了前面几页，然后看了一下“提炼函数”、“内联函数”、“提炼变量”，大概就把书扔一边了。

然后他们一旦谈起重构，就是“很费时间”、“没时间重构”、“会把代码改出 bug”、“能运行的代码就不要动”，我就觉得很搞笑。

无论他们在谈“重构”还是“重写”，谈的其实都是“重写”。

直接拉黑