怎样识别正品程序员

好，最后一篇灌水。以后绝不灌水了。
扯谁比谁厉害都没意义，第一是因为山外有山，第二是因为术业有专攻。水货和正品的区别不是水平而是态度。我认可的态度第一是打破沙锅问到底，第二是有自己的想法，第三是有常识。
云风那个乐观悲观锁是个好的反面栗子，可以看看他的态度有多毛糙。
碰到性能问题，第一步是简化场景，第二步是量化分析。简化场景可以帮你更容易发现热点，也更容易搭起测试环境，而不是靠线上程序的反应来查找热点。量化分析是性能问题的唯一解决方法，除此之外其它方法都是瞎蒙。
云风两件事都没干。他猜了下问题是lock的方式引起的，然后没有任何测试数据依据就把cas改成了spinlock，最后根据线上程序的反应，说问题得到了解决。我不知道他怎么能说服自己安心睡觉。
这个问题正确的解决方法如下。首先是把程序执行逻辑拆开成可以单独profile的单元，根据profiling的结果找到热点。然后把有问题的部分单独提出到测试环境，用模拟的压力测试重现问题。这是一个递归的过程，直到热点的范围能精确到源代码某一两行，甚至到某一两条指令上。------这就叫常识。要在只有很少symptom的情况下，知道该做什么以及怎么做。
然后开始考虑这一两条指令为什么会引起性能问题。通常profiler的数据都会给出明确提示，这个性能问题其实是branch miss或者d$ miss或者i$ miss。但也有时候看不出明显的原因，那你就得多想一点，是不是deadlock/livelock，是不是甚至可能不是performance而是correctness的一个表现方式，如果是的话，有什么测试可以证明这个想法。通常这时候你不需要跟任何人讨论，因为跟其他人思想同步的过程纯属浪费时间。-----这就叫有自己的想法。任何能用搜索引擎找到正确答案的问题都不是问题，但有些问题是在哪也找不到答案的，只有靠自己想。
有了自己的想法，接下来就是要获得验证。这里必须搬出量化分析。换个姿势再来一次，看看各种miss是否有稳定的减少，时间是否有稳定的降低，具体降低了百分之几。更优的解法必须通过这个过程来获得。但有些问题注定是无解的，因为性能问题最终都要回归到trade-off上，而且需要trade out的部分甚至可能是correctness。
你回过头再看看云风是怎么“解决”问题的。不知道根据什么，匆匆得出个结论说“多核心无助于提高队列的性能”，然后依据此结论推出spinlock比cas更高效。这种既没有上下文，又没有数据支持，又笼统的结论，连说服自己都难。
还有个没提到的态度，是打破沙锅问到底。你们可以翻翻我之前几篇日记，其中之一提到了一个想法，就是有没有可能在软件里借鉴bus的设计来做分布式系统。到目前为止没有结果。归其原因是我对bus了解的还太少了。bus protocol只是暴露出来的冰山一角，bus的atomicy也是一个虚拟的概念。实际当中，cache controller的state-machine有几个transient的状态，每条transaction的原子性也不是仅仅靠arbiter来解决的。不搞清楚这些内在的设计就不知道实现bus的黑魔法到底是怎么回事。很有可能最后还是个dead end，但我必须把bus的设计搞清楚，另外directory-based的系统也同样要搞清楚。
干码农这行就是得有这样的动力，要分析性能吗？那必须知道从register到LLC到memory bus的全部细节，要知道pipeline上所有hazard的全部细节，要知道store/load buffer是怎么干扰program order的，要知道out-of-order哪些情况下是不可避免的、哪些情况下是邪恶的。
要知道TCP状态是怎么跳转的吗？那么不仅要读几乎所有的TCP rfc，还要把Linux/BSD的stack翻一遍--因为implementation和rfc是相互参照相互倾轧的。这不是你网上搜一个TCP FSM图就能明白的。
口口声声talk is cheap, show me the code的人，Linus的话搬过来也压不死人。代码只是记录思想的工具，而且绝大部分代码都是废话。看书比写代码重要的多的多。
最后说一下我认同的正品程序员。银神我很佩服，冰河我很钦佩，知乎/微博上的温兆伦也不错。