这里给一个典型的 Legacy BIOS POST 过程中做的事情，很有代表性但不一定所有的 BIOS Vendor 都是一样的。

多少年来，人们普遍有一种看法，认为软件工程应该和其它种类的工程一样：仔细的设计，精确的规划，然后进行开发 —— 严格按照设计说明书。就像修建一座桥梁，不是吗？这种开发方式的问题在于：软件，它是“软”的。它可以无限的延展。任何需要的时候你都可以大幅度的修改你的软件，人们也都是这么干的。

相信每个人都见识过Windows那令人忧郁的蓝屏吧。有时因为它，很多天的工作毁于一旦，在这个时候，你是否会在心中大骂那帮不细心的程序员呢？程序员不是上帝，他们也会犯错误。对于商业软件来说，在上市之前会进行大量的测试，即使有程序错误溜过去了，大多也可以通过打补丁来修复。但是对于某些软件来说，情况就麻烦得多。

扫雷作为策略游戏，需要游戏者精确的判断。现在扫雷高级的官方最快纪录是33.95秒，中级则是由一个波兰玩家保持的8.5秒。而初级纪录是1秒，世界上很多人达到了这一点。在1秒的时间里完成初级扫雷，据测算概率在0.00058％至0.00119％之间（属于运气题），最可能的方法是直接点击四个角的方块。而本文所作的事情，则是将雷与雷之间的规律给你揪出来，并且深入思考其中的内涵。让你以后面对扫雷时，缩短与记录的差距，战无不胜！

这不能帮助我们管理团队。你只需要让一个人做主，其他人遵守。内疚带来平等——“我们不能让我们的伙伴独自去做困难的事情，我们得帮帮忙”。遵守的人越多，那些抛下同伴的人压力就会越大，直到整个团队半夜里聚在一起喝可乐，吃披萨。但他们如何容纳一个同样的人进入他们的世界，因为在这里也有一个因特立独行而著名的程序员。当我们还是学生时，我们乐于把所有事情都推给某个人处理，然后在校内做我们想要做的事；但当我们走上工作岗位时，一切都要靠我们自己。真让人困惑。

　　有趣的是，有时候这些大量的努力甚至并没有得到正常合理的追踪记录，好像它反而让项目看起来很糟糕一样。所以他们“作假帐”，正如客户只关心每个人每周工作40小时（或者他们拿的是40个小时的工资），也许还会关心项目在目前的进度，但他们从不在意小组每个成员花费在项目上的另外40个小时。好吧，或许他们会在“第二套假账”中追踪记录的团队成员的真正努力。虽然会计会因为此类造假而锒铛入狱，但在IT业内，没有人会反对这种造假的要求。

1. 负数求反时，不要轻易转换类型。
2. 有乘除法时，应先做乘法。否则会产生较大的误差。

业余不一定不专业，爱因斯坦当年写相对论的时候，正式工作是专利局的小职员。严格来说，相对论是他的业余爱好。

以前有个同事，业余爱好是研究植物。拿植物的根茎叶，还有花果皮，切成片，碾成粉，榨出汁儿。泡在水里，油里，酒里。用来喝，用来闻。

去他家拜访，会看见很多很多广口瓶。指着一个瓶子说，油里面泡的是树皮碾成的粉。又拿出大开本的彩色植物学图册，翻到一页，指着照片说，这树皮是从印度尼西亚偷运来的。之所以说偷运，是因为海关检查出来，一律没收，理由据说是这种植物会对美国本土的一些植物造成破坏，类似于中国的花椒会对加州的橘科植物造成破坏一样。

21) SMP

Pattern Name and Classification: Symmetric multiprocessing
Intent: 合理分配计算资源
Also Known As: cluster(parallel) model
Motivation (Forces):

SMP/AMP主要关注在多核环境中核的分配。multiple processor是和single processor相对应。
而symmetric和asymmetric相对应。不管symmetric还是asymmetric，它们都面临相同的问题:
在多核下编程。从字面意义来讲，symmetric就是说所有的core做的事情是一样的，这并不是说在
任何时刻，每个核的状态都是一样的，而是说，每个core完成的功能是相同的，不存在差别。而
asymmetric与之相反，每个core完成的功能是不同的。当然在实际使用时，应该是两种模式混合
使用，也就是说，可能从整体来看，系统是AMP，而从某个局部来看，系统是SMP。
使用SMP还是AMP，与系统所面临的任务相关。比如在一个包处理过程中，可能包含以下步骤
a) dequeue，把包从网卡的buffer里面取出来，并放到系统buffer里面。
b) parse，parse这个包，取出感兴趣的信息。
c) classify，包分类。
d) process，处理包。
e) enqueue, 把包放到发送队列。

测试中有可信度并不是和代码覆盖率有关，而是相信团队成员，他们会为重要的事物增加测试。如果你做了更改或者破坏（break）测试，你就需要认真考虑你的更改，而不是仅仅移出错误测试。我们要做的是能提高代码和测试可信度，而非仅仅解决一个新问题。
　　这些年我了解到，测试是开发过程中至关重要的一部分。每次代码修改后，都应该进行测试。用于提高测试可信度的每一秒钟，就是你每次运行测试都会成功的时候。在软件开发上，取得最大效率的唯一方式不是不写测试，而是相信你的测试。
　　你是一位开发人员吗？你为你的应用程序写测试吗？你每次提交都在提高测试中的可信度吗？每次提交都需要提高可信度，否则你就是增加了一个有问题的代码，最后终将导致你重写整个程序。

当然，我实际上根本没有回答Jeremy的问题——如何调试不是我写的代码？

这取决于我的目的。如果我只是因为一个bug，而深挖一段具体的代码，我会在调试器中逐步跟踪所有代码，写下我“走过”的调用分支，记录下哪些方法是特定数据结构的“生产者”，哪些方法是“消费者”；我也会仔细盯着输出窗口，查看出现的有用信息；还要打开异常捕捉器，因为异常通常是问题所在。设置断点；我会记录所有和我上面建议相反的地方，因为这些东西很可能误导了我。

如果我想在理解一段代码后修改它，我通常是从代码头部开始，或者先查找公共方法。我要知道类是如何实现的，它是如何扩展的，它的作用，它是如何嵌入整个代码中的？我会尽力理解这些东西后，才去了解这些特定部分（代码）是如何实现的。这耗时虽更长些，但如果你准备改动复杂代码，你应当那样做。

从系统层次去优化系统往往有比较明显的效果。但是，在优化之前，我们先要问一问，能否通过扩展系统来达到提高性能的目的，比如:

Scale up: 用更强的硬件替代当前的硬件
Scale out: 用更多的部件来增强系统的性能
使用更强的硬件当然和优化没有半点关系，但是如果这是一个可以接受的方案，为什么不用这个简单易行的方案哪？替换硬件的风险要比改架构，改代码的风险小多了，何乐而不为？

工具解决哪些问题？

1）帮助建立基线。没有基线，就没办法做性能优化。性能优化是个迭代的过程，指望一次搞定是不现实的。

2）帮助定位问题。这里有两个含义：一是性能问题出现在什么地方，是由哪一段代码引起的；二是性能问题的原因，cache miss，TLB miss还是其他。

3）帮助验证优化方案。优化的结果应该能在工具里面体现出来，而不是靠蒙。

5. 对考核绩效管理要本着“救人”而非“杀人”的宗旨出发。

绩效考核是任何企业公司都是必须的，绩效考核的好处不言而喻，个人认为绩效考核要本着发现员工的不足，提升员工的各方面水平而进行。好的表扬，差的批评。而批评惩罚的目的我们是要明确大家的不足，给大家改进、改正和提高的机会，而不是通过考核进行淘汰和开除，因为任何考核都很难做到绝对公平，过分的强调考核结果和考核淘汰会让员工没有安全感，如果员工只针对考核项进行工作，就会没有大局观，没有整体意识，对实际工作不利。当然对于较恶劣的员工，考核制度也是一个很好处理手段。

这11本外还有很多书虽然票数不是那么多，但大家估计都耳熟能详，比如《Effective C++》(中文版《Effective C++：改善程序与设计的55个具体做法》)，《Clean Code》(中文版《代码整洁之道》)，《Effective Java》(中文版《Effective Java中文版(第2版)》等 。

记得有位先哲曾说过：

一种编程语言的重要性并不在于语言本身，而是在于这种语言来体现出来的编程思维模式。所以说，并不是你用到的书才去读，读书是一种习惯。

我发生过几次这个问题，都是以前用了vs2008SP1写的程序，现在用没有SP1的vs2008编译引起的。解决它的根本方法当然就是装SP1，但是这个SP1装起来需要1个钟头，很麻烦，而且装上要耗掉1G多硬盘空间。
我的程序是对话框程序，和那些高端的controlbar根本没什么关系，我猜大概改源代码也可以。后来我尝试了一下，直接在stdafx.h中改了一处，把#include 注掉，后面加了一行
#define CWinAppEx CWinApp：