在用 charge 2，表带脱胶是通病。

说真的我倒是挺喜欢“没有恋爱的感觉”这种状态

另外刚看了帖子，据说 t490s 续航比 x1 carbon 多几小时。前者 20，后者 15。

谢谢各位。虽然说看重便携，但重量稍微有些差距倒是不介意的。我更好奇现在这些 x 系列和 t 系列的体积是不是相差不大。

@jacketma 本来考虑过 480S，不过据说屏幕比较差

忍者必须死？

依壁雕凿的城市？

不看

把“烂”的程度控制住也是很重要的。

@whileFalse “当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”，其实这个问题我敢说是基本上就是“预先设计”本身引起的。

或者这么说，如果你的代码一直是完成且仅完成当前的业务需求，那么结果就是你的代码完全贴合业务需求，那么这个时候如果新的需求无法实现，只能说明这个需求本身是错的，你自己会很容易发现这一点。这时候你把问题抛回给提需求的人，他都能够很明白这其中的逻辑冲突。

软件开发中的复杂性我是分为两个部分来看的，一部分是业务逻辑的复杂性，另一部分是代码结构的复杂性，如果完全消除了代码结构的复杂性，那么软件整体的复杂性就跟业务逻辑本身的复杂性趋向于一致。这种情况下，如果新需求无法实现，就只会有一个原因：新业务与旧业务冲突，而不是技术上的问题。反过来，如果业务逻辑确实没有冲突，那么只能说明代码本身对未来的预测与当前业务不符，就是“预先设计”引起的问题。所以我还是拒绝任何程度的预先设计。

另一方面，当“你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”的时候，如果因为进度或者其它客观原因，暂时没办法花时间和精力去修复，这时候“绕过这个底层问题”也是讲方法的，而不能因为底层已经烂了，上层就随便应付了事。

@whileFalse 我想表达的意思是招式不重要，重要的是解决问题，用最简单的办法解决问题，同时不引入新的问题就行，解决完一系列问题，你说的“设计模式的嵌套”已经自己出来了。

我觉得我们这个圈子里，太多太多人喜欢套用自己先前用过的、或者其它“大公司”分享过的方法 /模式，也就是所谓的“招式”。我更倾向于对每个系统重新做设计。而且我所谓的“设计”并不是扮先知，预言未来的需求和可能遇到的问题。我所谓的“设计”，是在满足且仅满足当前需求的前提下，用最简单的代码来实现需求。对“未来可能”的需求和问题作 0 考虑——就是根本不考虑。未来的东西本来就是不确定的，万一（回顾一下吧，其实是多数时候）你预言错了呢？之前对未来做出的复杂设计就变得一文不值，同时还会是累赘，是负产出。而仅实现当前需求的代码，是最简单也最容易改变的。

设计不是“预知未来”，精良的设计能让改动的成本降到最低，但不可能让你在面对需求的变化时无需改动设计。必须积极地改动设计——在每一次需要改动的时候，不要把这些必须改动的设计积累起来。“拥抱变化”说的是这个。

还是对于“招式”，有件事我们需要明白：方法是用来解决问题的，如果问题不存在，那方法本身根本无意义。

补充一个相关链接 https://www.zhihu.com/question/306481351/answer/562237980

我不知道我是不是废话比较多，其实蛮希望能有朋友能讨论这些东西。谢谢你花时间看完。

@bmos :D 不客气。我之前也是一直对自己的代码不满意。现在虽然也并不是非常满意，但起码方向是清晰的，不像之前那么没底气，写什么系统都 hold 得住，知道自己该如何继续改进。最重要是别放弃这份追求。加油。

抓到了根本，招式都是结果。

@bmos 我觉得完成功能之后，消除重复是首要目标。当你竭尽全力的去寻找消除重复代码的方法的时候，会发现许多面向对象的特性正好可以拿来消除重复；然后会发现设计模式原来是这么回事；会去寻找在当前这个场景下，消除重复最合适的重构手法。所有的面向对象的特性、设计模式和重构手法的应用，全都是最合适的。

但如果一上来就去找设计模式之类的东西，反而会没了方向，学了方法不知道该在哪用。

其实，在“消除重复”之前，还有更根本的东西：“消除重复”的动机是什么？是降低代码结构的复杂性。

前面一直有人在提《代码大全》，《代码大全》里面很重要的一句话大概是这样的（原话不太记得了）“软件开发中的首要目标就是降低复杂性”。而复杂性来源于哪里？一、重复代码；二、糟糕的命名。

我觉得建议看源码的最扯淡，我不知道为什么这种说法能一直流行到现在，我也很好奇这些人在说出这些建议的时候是不是真的清楚自己在说啥。

首先，开源代码本身就良莠不齐，请问如何分辨哪些是优秀的？使用的人多就是优秀的？我觉得很多时候恰恰相反。MooTools 这样优秀的开源库就很少人知道，同时期最流行的却是 jQuery。MooTools 在小众的圈子里一直到存活到 CoffeeScript、TypeScript、ES6、ES7 出现之后，开发人员觉得 MooTools 完成使命，可以退休了，官方才宣布停止维护。

其次，优秀的源代码你看过一遍基本上只会有一种感觉：这代码本来就应该是这么写，理所当然的，看过之后根本不会留下什么印象。而让你留下深刻印象的往往是些炫技的代码，这样的代码又只会把人往坑里带。