算是一些要对自己说，让自己记住的话和人生经验吧。如果碰巧能启发到其他人，那就太好了。

每个时刻都应该知道自己该干什么，并有效执行

恰逢前阵子TI6护国神翼夺冠，看到知乎上有人回答，在dota界极少有整场都知道自己该干什么并贯彻执行的。而神翼是5个人都很清楚要干什么。就像大酒神伍声视频里总是强调，打dota路人就是要每时每刻想着单位时间里收益最大的动作是什么。在为梦想拼搏的时候，也是如此。生活可以过得写意一些，但至少工作时间里，需要做到这一点。曾经有人说我目的性太强。但正是这样，才让我走到今日。恰恰相反，我不是目的性太强，而是还不够强，因为我觉得自己还没有达到这种境界。

每次只干一件事

专注非常有好处，这可能分人。就我自己而言，即使面对multi-tasking的情形，事情也是要一件一件来处理，把所有东西都打开对我自身效率的提升毫无用处。我想如何处理multi-tasking，CPU调度方式已经给了我们答案。Round-robin scheduling + priority。

生活节奏不能乱

该睡觉就睡觉，该吃饭就吃饭，该干活干活，该看书看书，该玩就玩。再也不像学生时代那样可以随便乱来了。因为如果工作了还保持这样，很可能一辈子就是这样了。Life is not a sprint, it is a marathon。仰望星空的同时，更重要的是脚踏实地，过好每一天。你仰望的星空，也许在你实力增长以后，就不再是你要的星空了。但脚踏实地带来的提升，会永远保留着。这一点上很佩服一些女孩子XD。

努力一定会有提高

这一点其实以前大学搞竞赛的时候就已经深刻体会到了。第二年打world finals和第一年打的时候比完全是处于两个境界。犹记得第一年训练结果忽好忽还，后来我甚至对训练的效果产生了质疑。我还对搞学长说：『训练根本就没有什么用，该会的知识都已经会了，那都是智商题，临场想得出来就想得出来，想不出来就想不出来，就这样了。』后来一年练多了以后才明白那种忽好忽坏，其实就是菜。理解还不够深刻，手还不够熟练。当思维熟练到一定程度的时候，解法和灵感就自然来了。

所谓的创新，也不过是把相似的东西联系结合起来罢了。人的联想能力是有限的，所以当我们面对很难的问题的时候，如果你的记忆里储备的相关内容不够多，是不可能把他们联系结合起来的。除了要提升自己知识储备的量以外，对学习到的内容加深理解也是很重要的。所谓加深理解，就是提取事物的本质特征。因为最终你能联想到相关的东西，一定是因为一些共同的本质特征。如果你事先提取好这些特征放在脑子里(做法就是平常对遇到的事物多思考)，那么联想起来就容易很多了。人类的思考模式有点像广度优先搜索，遇到问题，先找最相关的一堆东西，不能解决再找次相关的一堆东西。这里简单想一下就会知道这个『相关事物的量』相对于从问题到要找的东西的距离是指数级的。所以你平常不思考做好索引，搜索起来肯定就慢得要死了…还很可能超出你能搜的能力极限，反映到实际就是，你搞不定这个问题了。

分析了这么多，就是要印证这个标题：努力一定会有提高的。能到什么程度不知道，但一定可以比原来强。

适当展示自己

这一项的目的不是为了show off，而是为了调节他人对自己的期望。有些牛人确实很低调，那是因为他们不再需要周围人改变对他的期望来实现自己的价值。我觉得之前在依图那边听来的一句话非常正确，大意是：一个人的成长是由他做的事情决定的。

如果你做的东西都是打杂，那成长的速度是很慢的。

而对于我们刚出来社会工作的new graduate来说，在大公司被boss拿去打杂是十有八九的。要去做重要的有难度的事情，就必须要秀你自己的能力。万事开头难，当你抓住机会表现了一两次以后，别人对你的期望就会得到改变。这时候拿到了一些有意思的活就不要再表现得那么强势了，不然最后不能meet老板的期望就适得其反了。

强者的谦虚才是真的谦虚。当在别人的期望里还是个弱者的时候，再谦虚就没人会注意了。记得大酒神打dota1 solo大赛的时候杀完对面的鸡打的那一句：对不起，这场比赛我要赢。人都是需要机会来证明自己的。当你被推到那个舞台之后，自然而然就会变强了。

不过呢，这一点在比较小的创业公司就没有这个问题，反正事情都干不完，you can you up…

就像@Lpuck跟我说的：你玩宠物小精灵的时候，一个怪也就是一开始厉害一点，后面你一直用，他升级飞快，就很厉害了。展示自己，做的就是让自己“看起来厉害一点”。

坚持自己的想法

别人的意见要看，但是不要随便就接纳。犹记得刚进来的时候，随便一个提交都好多comments。然后当时比较naive，觉得他们说得有一点道理的都照着改。结果一会儿你把这次的经验用到下一个提交上面的时候，又有一个另外的人来说，你这里不应该这样…然后我就意识到其实这群比我senior的人之间其实都不能统一意见。在那之后，如果不是我想过非常有道理的意见，基本都坚持自己的想法。

每个人都有不同的想法，所以外界的意见是不可能保持自洽的，能自洽的只有你自己的体系。但是当外界对某件事形成一个统一的想法的时候，就要特别注意思考其原因。虽然这种意见不一定对，但即使是错的，也值得积累下来的。这样在你带领别人的那一天，就能快速理解别人的动机并指正。

看《Effective Java》看到的，主要讲对Java equals的override。C++对==的重载也是一样的。下文就用Java举例子了，因为是OOP的通用问题，所以很容易类比到C++。

问题描述：

class A {
    int x;

    public A(int x) {
        this.x = x;
    }

    @Override
    boolean equals(Object o) {
        if (o instanceof A) {
            return x == (A)(o).x;
        } else {
            return false;
        }
    }
}

class B extends A {
    int y;

    public B(int x, int y) {
        super(x);
        this.y = y;
    }
}

以上代码中B如果想Override equals使得y也能加入判断，应该怎么做？

也许最直接的答案是

    @Override
    boolean equals(Object o) {
        if (o instanceof B) {
            return x == (B)(o).x && y == (B)(o).y;
        } else {
            return false;
        }
    }

然而equals需要的是一种等价关系，需要满足三个条件：

自反性。即x.equals(x)为真。
对称性。即x.equals(y) == y.equals(x)
传递性。即x.equals(y) && y.equals(z)，则x.equals(z)

上面这个做法明显对称性会崩盘。
A a = new A(0);
A b = new B(0, 0);
a.equals(b); //true
b.equals(a); //false

那如果加入对父类的特判呢？对称性是没问题的，但是传递性会崩。
A a = new B(0, 0);
A b = new A(0);
A c = new B(0, 1);
a.equals(b); //true
b.equals(c); //true
a.equals(c); //false

实际结论是B根本没有办法重载一个合理的equals。

证明：因为不能更改A类的equals，因此A的实例equals B的实例的时候一定会只判x然后返回true。那么根据对称性，B类的实例equals对应A类的实例的时候，也一定要返回true。所以如果想要在B的equals中判断y，上面传递性的问题一定会出现。至此对称性和传递性不可能同时满足，所以不可能存在科学的重载方法。
这个从本质来讲，父类和子类的相等是一种偏序关系，然而equals要的是等价关系，所以被父类强行equals为true以后，就怎么也救不回来了。
那么我们放松一下条件，允许修改父类呢？

从上面的教训可以知道如果子类和父类之间可以相等的话，一定会GG。那只能做成不相等了。

于是直接getClass判吧，直接看new的时候是什么的类，不同就直接判不等。那么假如A多了一个方法。
    private static final Set <a> luckyA = new HashSet<>()
    static {
        luckyA.add(new A(5));
        luckyA.add(new A(10));
    }

    public boolean isLucky(A a) {
        return luckyA.contains(a);
    }

这个isLucky写得再正常不过了，然而如果我们那么做，那这个isLucky对于所有子类就失效了。这违背了OOP的Liskov substitution principle。

Wiki上的定义：Subtype Requirement: Let  be a property provable about objects x of type T. Then  should be true for objects y of type S where S is a subtype of T.
你也许会想，不加这个isLucky不就没有违反了吗？是的，但是只要A中有依赖A的equals的方法，就会违反这个规则。
然而你觉得因为子类的一个equals问题，给父类定下不能依赖自己的equals实现任何功能的规矩，合理吗？
综上所述，父类与子类equals可以为true是不行的；然而一律为false又会break OOP的原则。于是我们可以推导出即使允许同时修改父类和子类的equals，也没有任何合理的写法。这也是《Effective Java》给出的结论。
形式化描述一下这个结论：
如果父类是可实例化的(非abstract，非interface)，子类如果添加了新的域想override equals把这个域放进去，没有任何一种override的方法是合理的。
那么该怎么做呢？答案：不要用继承，用组合。然后加一个fallback的方法。
class B {
    A a;
    int y;

    public asA() {
        return a;
    }
}