sillydaddy

这是天性改不了的：不忍铁锈着，磨剑不敢歇。

我通过“嵌入式 奇技淫巧 sillydaddy” 搜索到了 v 友面试遇到的一个题目给楼主看能不能做出来：

“请用一个 C 语言表达式判断某个数是否为 2 的 N 次幂 ”

今天又去查了下 10 倍定律，发现跟 OP 描述的含义不同。正确描述应该类似 3 个 16 定律：
16 次做同一件事，每次比前一次少花 16%的时间，那么第 16 次做时只需要花费最初 1/16 的时间。

上面的表述才是 10 倍定律的真正含义：想比原来效率高 10 倍，至少要花 10 倍的努力。这 10 倍的努力可以是通过重复做 10 次每次都有新的理解，也可以通过第一次就耗费大量的额外的 10 倍精力去把事情做透彻而不仅仅是做完而已。

我不认同你的观点。第二次实现跟第一次相同的功能，如果不是通过拷贝第一次的代码的话，并不会快多少。我写过自己并不熟悉的 python 爬虫、javascript 前端，配置过前端的编译链 gulp ，现在让我从头写，我还是会像第一次一样抓狂。所以你的 10x 理论只是臆想。

写的太乱。给你看一个竞品：
/t/985173

这个描述感觉很熟悉。搜一下 Image to vector 呢，或者“像素矢量化”，“图片矢量化”。

绩效应该有一个固定的基准，只要比这个基准高就可以。工资高基准就高一些，工资低就低一点。比如参考市场上的平均水平。
强制摊派低绩效就是胡搞，内卷没有止境。

如果你仔细观察那么多设计模式，会发现它们基本上都是在讲一件事：接口的抽象、分层、去耦合， 就像 #26 楼 @NoOneNoBody 说的。把这点仔细研究研究，就豁然开朗了。

举几个例子，

「观察者模式」： 某个对象变动了，通知其他对象（或者说其他对象观察某个对象的变动）。 这种“一变动就通知”的机制，主要用于底层对象向上层对象发送通知，对于这些通知，无论上层对象是处理还是不处理，无论上层具体怎样处理，都跟底层对象没有关系了。所以观察者模式，其实是将底层对象的向上通知这种（接口）行为统一抽象出来了，而且去掉了底层与上层的耦合。
「访问者模式」：将被访问的数据结构的遍历抽象出来了，上层要访问某个比较固定的数据结构的时候，不用每个访问者把遍历这个数据结构的代码都重复写一遍，只需要写出来对该数据结构如何具体操作，遍历这个数据结构的过程已经被“访问者模式”抽象和剥离出来了。像 C++ stl 的迭代器也可以算是非常典型的访问者模式，只需要 iterator++就可以，不用关心底层是 vector 还是 list 。
「工厂模式」：这个就更直接了，传给工厂一个不同的参数，生成一个与之对应的实例，并且这些实例都实现了一个相同的接口。具体生产哪个类的实例不需要关心，唯一需要关心的就是，传入一个不同的参数，得到同一个接口的不同实现，经过这种抽象后，工厂模式对外呈现出一种极为简洁的形式：不同参数->接口的不同实现。


所以学习的时候，只要仔细留心接口是怎样抽象的，接口抽象出来后，达到了什么目的和效果，就可以了，不用特意记各种设计模式，死记也记不住。

@meeop 前面提到的周转资金，可以从另一个角度考虑：
如果一个商家，每天卖出 100 件商品，商品总成本 10000 元，第 2 天可以收到付款。这个商家的库存里面，总是保留用于第 2 天卖的，与第一天卖的 100 件一模一样的商品。也就是说这个卖家只需要投入 20000 元，就可以维持它的生意不断，它库存与销售比是 2：1 。
如果使用押金模式，那么它需要 10000*10+10000=110000 元才能维持，也就是资金利用率只有原来的 1/5 左右。
如果扩大商家的库存销售比，比如扩大到 10:1 ，资金利用率也只有 1/2 。
所以这种高押金模式，对于商家/工厂来说，资金利用率是很低的。如果它的资金中有 50%是贷款，贷款利率是 4%，原本它的 6%的利润率就足够，如果它的资金利用率只有一半，那么它的利润率就要提升一大截才行。