这些最基本的职业技能通常决定了一个程序员的级别，能否用好这些技能，直接关系到了程序员的职业生涯。很多程序新手也是因为缺少、达不到或是不熟悉在这些基本技能，所以，他们需要有老手带，需要努力补齐这些技能。而高级程序员应该非常熟悉这些基本技能，而且有能力胜任并带领其他经验不足的程序员。

下面这些基本职业技术可以用来做为对一个程序员的评估，很明显，下面的这些技能都可以用来做面试。虽然，还有很多非技术的因素，但对于评估一个程序员的技术能力来说，其应该是足够的了。

下面是程序员所应该具备的基本职业技能：

当然，还有很多的基本技术也是非常重要的，比如，与人的沟通能力，语言的表达能力，写作能力，团队协作能力，适应变化的能力，时间管理能力，多任务处理能力，自我学习能力，故障处理能力，等等，等等，这里只是列举了和技术相关的能力，这些是程序最最最基本的能力，只要是程序员就必需要有的能力。

本文转自：http://coolshell.cn/articles/428.html

查看main函数的汇编代码(编译器：gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) )

   这种情况是类显示提供含默认值的构造函数。
   查看汇编实现如下：

   上面的汇编代码就不在添加注释了，因为两种操作产生的汇编代码是一样的，都是先调用operator new分配内存，然后调用构造函数。
   上面的情况在VS2010下验证是一样的情况，有兴趣的朋友可以自己去看，这里就不再贴出VS2010下的汇编代码了。
   通过上面的分析，对于new A和 new A() 的区别，我们可以得出下面的结论：
      1、类体含有显示适合地默认构造函数时，new A和new A()的作用一致，都是首先调用operator new分配内存，然后调用默认构造函数初始化对象。
     2、类体无显示构造函数时，new A()首先调用operator new来为对象分配内存，然后使用空值初始化对象成员变量，而new A仅仅是调用operator new分配内存，对象的成员变量是无意义的随机值！  （peakflys注：对于基本数据类型，如int等 适用此条）
   注意到，现在很多书籍对new操作符的说明都存在纰漏，例如《STL源码剖析》中2.2.2节中有以下的描述：

事实证明，new Foo的操作是否有构造函数的调用是不确定的，具体要看Foo类体里是否有显示构造函数的出现。

/*****************************************华丽分割线**************************************
补充：刚才发现，在C++Primer第四版5.11节中，已经有了对于new A()的说明：

   We indicate that we want to value-initialize the newly allocated object by following the type nameby a pair of empty parentheses. The empty parentheses signal that we want initialization but arenot supplying a specific initial value. In the case of class types (such as string) that define their own constructors, requesting value-initialization is of no consequence: The object is initialized by running the default constructor whether we leave it apparently uninitialized orask for value-initialization. In the case of built-in types or types that do not define any constructors, the difference is significant：

     int *pi = new int;         // pi points to an uninitialized int 

     int *pi = new int();       // pi points to an int value-initialized to 0 

In the first case, the int is uninitialized; in the second case, the int is initialized to zero.
   这里给出的解释和上面自己分析的new A()的行为是一致的。

/***************************************再次华丽分割线************************************
鉴于上面的结论是通过GCC和VS2010得出的，而且有朋友也提出同样的质疑，为了确定这种结果是否是编译器相关的，刚才特意查看了一下C++的标准化文档。
摘自：ISO/IEC 14882:2003(E) 5.3.4 - 15
— If the new-initializer is omitted:
      — If T is a (possibly cv-qualified) non-POD class type (or array thereof), the object is default-initialized(8.5). If T is a const-qualified type, the underlying class type shall have a user-declared default constructor.
      — Otherwise, the object created has indeterminate value. If T is a const-qualified type, or a (possibly cv-qualified) POD class type (or array thereof) containing (directly or indirectly) a member of const-qualified type, the program is ill-formed;
— If the new-initializer is of the form (), the item is value-initialized (8.5);

所以可以确定，这种情况完全是编译器无关的(当然那些不完全按照标准实现的编译器除外)。
但是通过上面标准化文档的描述，我们可以看出文中对new A在无显示构造函数时的总结并不是特别准确，鉴于很多公司都有这道面试题(撇去这些题目的实际考察意义不说)，我们有必要再补充一下： 对于new A: 这样的语句，再调用完operator new分配内存之后，如果A类体内含有POD类型，则POD类型的成员变量处于未定义状态，如果含有非POD类型则调用该类型的默认构造函数。而 new A()在这些情况下都会初始化。
   PS：估计很多公司的“正确答案“ 也不一定正确吧。

本文转自：http://www.cppblog.com/peakflys/archive/2013/04/08/199208.html

l         僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。

l         脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

l         牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

l         粘滞性（Viscosity）：做正确的事情比做错误的事情要困难。

l         不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。

l         不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。

l         晦涩性（Opacity）：很难阅读、理解。没有很好的表现出意图。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净以及富有表现力。

1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

　　 规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交 付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。用户故事是一种表示需求的 轻量级技术，它没有

固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板：“作为【用户的类型】，我希 望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口头交流。

2。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

　　敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。
  
3。经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

　 　迭代是受实践框限制的，意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越 紧密，对产品质量就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中 都会增加一些功能，增加的每个功能都是经过编码、测试，达到了可发布的质量标准的。
　　另外敏捷开发项目中对开发阶段没有什么重要的分割，没有先期的需求阶段，然后是分析阶段，架构设计阶段，编码测试阶段等，在项目真正开始后，每次迭代中都会同时进

行所有的上述阶段工作。
 
4。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

　　软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁 

的交互，这样就可以在早期及时的发现并解决问题。
 
5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

　　业务和技术是引起不确定的二个主要方面，人是第三个方面。而业务和技术又必须由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团

队的目标一致，我们就需要鼓舞起每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。

6。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

　　在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以

大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
 
7、可工作的软件是首要进度度量标准。

　 　一般的工作都比较容易衡量任务进展，比如让你去搬运1吨的石头，我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说，在软件没有编 码、测试完

成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工 作了，对用户来说已经可

以应用了。

8。敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

　 　很多人都认为软件开发中加班是很正常的，不加班反而不正常，我对此有点不理解，这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发，开发速度不会 随着迭代的任务不同而不同，不欣赏所谓的拼一拼也能完成的态度，开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了，因为完成一个项目 后会接踵而来下一个项目，而只要还是拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说，那我们就一直加班，也是“持续的开发速 度”啊，这时可要注意了，持续加班智

慧导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。
 
9。不断地关注优秀的技能和好的设计会增强敏捷能力。

　　敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发－原则、模式与实践》一书中介绍了很多设计，感兴趣的可以去仔细看看。
 
10。简单----使未完成的工作最大化的艺术----是根本的。

　 　我们不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而把注意力放在如何通 过最简单的方法完成现在需要解决的问题。这时有人会说，我已经预计到了肯定存在哪些需求扩展点，我们在一开始是否需要考虑呢？这时团队需要根据自己的理解 去决定是否考虑，如果深信在明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。
 
11。最好的构架、需求和设计出自与自组织的团队。

        敏捷中有很多种实践，大家都知道，迭代式开发是主要的实践方法，而自组织团队也是主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。一群人是一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也并不视彼此为一体。项目一开始，我们就会组建“团队”，但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为，团队的形成必须经历几个时期。在 经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人 都知道上午九点来上班，都会主动询问别人是否需要帮助，也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高 效的工作团队。在这样团队中，成员之间相互理解，工作效率非常高。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指 导更像是一个目标，一个致力于开发出更好的软件的目标。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出 承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。

　　虽然敏捷开发小组是以小组为整体 来工作的，但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者（Product Owner）。产品所有者的主要职责包括：确认小组所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具有价值的功能，以及作出决定 使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队（developer），这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等，有时产品所有者也可以被看作是

开发人员。还有一个重要角色就是项目经理（project manager）。敏捷开发的项目经理会更多的关注领导而不是管理。在某些项目中，项目经理可能同时也是开发人员，少数时候也会担任产品所有者。
　　 
12。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

　　由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。　敏捷不是基于预定义的工作方式，而是基于经验性的方式，对以上这些变化，小组通过不断的反省调整来保持团队的敏捷性。

l         单一职责原则（The Single Responsibility Principle，简称SRP）：就一个类而言，应该仅有一个引起它变化的原因。在SRP中，我们把职责定义为“变化的原因（）”。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。事实上，我们将要论述的其余原则都会以这样或那样的方式回到这个问题上。

l         开放封闭原则（The Open-Close Principle，简称OCP）：软件实体（类、模块、函数等等）应该是可以扩展的，但是不可以修改的。遵循开放封闭原则设计出的模块具有两个主要的特征。它们是：（1）、对于扩展是开放的。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。换句话说，我们可以改变模块的功能。（2）、对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者Java的.jar文件，都无需改动。

l         Liskov替换原则（The Liskov Substitution Principle，简称LSP）：子类型必须能够替换掉它们的基类型。OCP原则是OOD中很多说法的核心。LSP是使OCP成为可能的主要原则之一。正式子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。

l         依赖倒置原则（The Dependency Inversion Principle，简称DIP）：（1）、高层模块不应该依赖于底层模块。二者都应该依赖于抽象。（2）、抽象不应该依赖于细节。细节应该依赖于抽象。使用传统的过程化设计所创建出来的依赖关系结构，策略是依赖于细节的。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口。事实上，这种依赖关系正式好的面向对象设计的标志所在。

l         接口隔离原则（The Interface Segregation Interface，简称ISP）：不应该强迫客户依赖它们不用的方法。如果强迫客户程序依赖于那些它们不适用的方法，那么这些客户程序就面临着由于这些未使用方法的改变所带来的变更。这就无意中导致了所有客户程序之间的耦合。我们希望尽可能地避免这种耦合，因此我们希望分离接口。

测试驱动开发

极限编程（eXtreme Programming，简称XP）是敏捷方法中最著名的一个。它由一系列简单却相互依赖的时间组成。这些实践结合在一起形成了一个胜于部分结合的整体。其中一个非常重要的，当前也受到格外重视的实践就是TDD（测试驱动的开发方法）。

在测试驱动的开发方法中，编写所有的代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试，由于它要测试的功能还不在，所以它会运行失败。然后编写代码使测试通过。

编写测试用例和代码之间的更迭速度是很快的，基本上几分钟左右。测试用例和代码共同演化，其中测试用例循序渐进地对代码的编写进行指导。作为结果，一个非常完整的测试用例集和代码一起发展起来。

测试粗略的可以分为单元测试和验收测试。单元测试是用来验证系统中个别机制的白盒测试。

单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工作的正确性。所以，单元测试是必要的，但是不够充分。

验收测试是用来验证系统满足客户需求的黑盒测试。验收测试由不了解系统内部机制的人编写。验收测试是程序，因此是可运行的。通常通过使用专门为应用程序的客户创建的脚本语言来编写验收测试。正如单元测试作为可编译、运行的有关系统内部结构的文档那样，验收测试是有关系统特性的可编译、执行的文档。

编写代码前就编写单元测试会带来四个很明显的好处：

1、首先编写测试使得程序中的每一项功能都有测试来验证它的操作的正确性。这就可以给以后的开发提供支援，使我们可以更自由地对程序进行更改，因为测试可以告诉我们程序仍然具有正确的行为。

2、首先编写测试迫使我们必须从程序调用者的有利视角去观察我们将要编写的程序。这样，我们就会在关注程序的功能的同时，直接关注它的接口，我们也就可以设计出便于调用的软件。

3、首先编写测试迫使我们把程序设计为可测试的。为了把程序设计为易于调用和可测试的，程序必须和它周边环境解耦。这样首先编写测试迫使我们解除软件中的耦合。面向对象设计的原则在进行这种解除耦合方面具有巨大的帮助作用。

4、首先编写测试的另一个重要效果是，测试可以作为一种无价的文档形式。测试就像一套范例，它帮助其他程序员了解如何使用代码。这份文档是可编译、可运行的。它保持最新。它不会撒谎。

首先编写验收测试的行为对于系统的架构方面具有深远的影响。为了使系统具有可测试性，就必须要在很高的系统架构层面对系统进行解耦合。正如单元测试可以促使你在小的方面可以做出优良的设计决策一样，验收测试可以促使你在大的方面做出优良的系统架构决策。

 软件大师、C++之父Bjarne Stroustrup曾经说过：设计和编程都是人的活动。忘记了这一点，将会失去一切。敏捷软件开发方法正是认识到软件开发的这一本质特征而提出的革新性开发方法。使用敏捷开发方法会给我们带来巨大的好处。当然要完全做到也是很困难的。这不仅需要对敏捷的深刻理解，更需要敏捷团队成员的共同努力。

我们常常会通过观摩杰作体会并学习艺术的精髓，而可扩展性也应该遵循同样的路线！

在这篇文章中，我将列出数款为大家所耳熟能详的可扩展性架构。通常情况下，架构师们完全可以借鉴已知的可扩展架构模式，进而创造出新的可扩展架构。

1. LB (负载平衡器) + 无共享单位 - 该模型中包含一系列单元，各单元彼此间不共享任何内容，且一致指向一个将输入文讯按一定条件发往单元处的负载平衡器（这构成一个循 环，以负载等情况为基础）。每个单元可以是一个单独的节点或是紧密耦合的节点所构成的集群。用户可以使用DNS循环、硬件负载平衡器或者软件负载平衡器达 成负载平衡效果。创建一套负载均衡的层次结构，并在其中结合前面提到的各种负载平衡器也是可行的。在由Michael Stonebraker撰写的《 无共享体系架构实例 》一文中，专门讨论了此类架构。
    
2. LB + 无状态节点 + 可扩展存储 - 传统的 三层式Web架构 使用的就是这种模型。该模型包括数个与可扩展存储交互的无状态节点以及一个分布于节点间负载中的负载平衡器。在这一模型中，存储通常作为限制因素存在，但NoSQL存储则可以利用这套模型创建出具备相当可扩展性的系统。
    
3. 点对点架构 (分布式Hash列表 (简称DHT)以及内容寻址网络(简称CAN)) -这套模型提供了一些传统的 可扩展算法，这些算法的各个方面几乎全部按对数进行了等比例增加。举例来说，像Chord、Pastry（特指免费版）以及CAN都属于此类。而以 Cassandra为代表的、基于P2P架构的几款NoSQL系统也是其中的成员。《 展望P2P系统中的数据 》一文就深入探讨了这类模型的各种细节。
    
4. 分布式队列 – 这种模型以将队列实施（即先进先出交付机制）作为网络服务处理为基础。该模型通过JMS队列而广泛得到采用。一般会遵循这种做法的有任务队列以及通过保持队列分级体系实现扩展性的任务队列版本，后者在负载无法及时处理时，任务会由低级层面向高级层面传递。
    
5. 发布/订阅模式 - 一般用于通过网络向彼此发布订阅讯息。《 发布与订阅的多面性 》这一经典论文中详细的介绍这一模型，该模型方面最典型的例子即 NaradaBroker与 EventJava 。
    
6. 小道消息与自然灵感式模型 - 这种模型源自日常生活中小道消息的传播途径，也就是每个节点将随机选择后续节点以交 换信息。正如现实生活中的实际反馈，这种八卦型算法在信息传播方面出奇地迅速。该模型的另一大分支则是受到生物学影响的启发式算法。自然世界中存在着大量 协调及扩展方面极为卓越的固有算法。举例来说，蚂蚁、人类以及蜜蜂等等，都能够以最简洁的交流方式协调好扩展性方面的需要。模型中的算法正是借鉴了这些实 际存在的现象。在论文《 从流行病的蔓延到分布式计算 》中对这种模型有着详尽的叙述。
    
7. 地图缩小/数据流 - 这一概念首先由谷歌公司提出，地图缩小为工作的描述及执行提供了一套可扩展的模式。虽然内容 简单，但它仍然成为联机分析处理方面的首要处理模式。数据流则是一种更先进的方式，用来表达执行信息；而像Dryad及Pig这样的项目为数据流的执行提 供了可扩展的框架。论文《 地图缩小：大型集群上的简化数据处理 》中设置了专门的主题，详细讨论这一内容。Apache的Hadoop就是这种模型的代表性产品。
    
8. 责任树形图 - 这种模型打破了递归问题的束缚，将整个流程以树状形式加以处理；每个父节点将工作下放至子节点。这种模型扩展性强，并已经被应用于数款可扩展性架构当中。
    
9. 流处理 - 这种模型被用于处理源源不断的数据流及数据。这种处理方式通过网络中的处理节点获得支持（例如Aurora、Twitter Strom以及Apache S4等）。
    
10. 可扩展存储 – 该模型的应用范围从数据库、NoSQL存储、服务注册到文件系统都有体现。 链接中的这篇文章 以可扩展性为切入点对其进行了深入讨论。

综上所述，可扩展性的实现只有三种方式，即：分布、缓存及异步处理。前文所提到的各种架构事实上都是把这三种方式进行不同组合并加以实施。而另一方 面，不利于可扩展性的因素，除了糟糕的编码本身，全局性协调也起到了重要的影响。简单来说，任何一种全局性协调都会限制系统的可扩展性。本文中所提到的各 种架构也只是在做好了本地性协调，而非全局性协调。

然而，将它们有机地结合起来以创建一套极具可扩展性的架构可不像说起来那么容易，除非我们能找到一种全新的扩展模式。不过经验告诉我们，比起搞一套全新的架构，采用为我们所熟知且更易驾驭的可扩展性解决方案永远是更好的选择。

搜索质量评估是搜索技术研究的基础性工作，也是核心工作之一。评价（Metrics）在搜索技术研发中扮演着重要角色，以至于任何一种新方法与他们的评价方式是融为一体的。

Cranfield评价体系

A Cranfield-like approach这个名称来源于英国Cranfield University，因为在二十世纪五十年代该大学首先提出了这样一套评价系统：由查询样例集、正确答案集、评测指标构成的完整评测方案，并从此确立了“评价”在信息检索研究中的核心地位。

Cranfield评价体系由三个环节组成：

1. 抽取代表性的查询词，组成一个规模适当的集合
2. 针对查询样例集合，从检索系统的语料库中寻找对应的结果，进行标注（通常人工进行）
3. 将查询词和带有标注信息的语料库输入检索系统，对系统反馈的检索结果，使用预定义好的评价计算公式，用数值化的方法来评价检索系统结果和标注的理想结果的接近程度

查询词集合的选取

Cranfield评价系统在各大搜索引擎公司内有广泛的应用。具体应用时，首先需要解决的问题是构造一个测试用查询词集合。

按照Andrei Broder（曾在AltaVista/IBM/Yahoo任职）的研究，查询词可分为3类：寻址类查询（Navigational）、信息类查询(Informational)、事务类查询(Transactional)。对应的比例分别为

Navigational ： 12.3%  Informational ： 62.0%  Transactional ： 25.7% 

为了使得评估符合线上实际情况，通常查询词集合也会按比例进行选取。通常从线上用户的Query Log文件中自动抽取。

另外查询集合的构造时，除了上述查询类型外，还可以考虑Query的频次，对热门query（高频查询）、长尾query（中低频）分别占特定的比例。

另外，在抽取Query时，往往Query的长短也是一个待考虑的因素。因为短query（单term的查询）和长Query（多Term的查询）排序算法往往会有一些不同。

构成查询集合后，使用这些查询词，在不同系统（例如对比百度和Google）或不同技术间（新旧两套Ranking算法的环境）进行搜索，并对结果进行评分，以决定优劣。

附图：对同一Query：“社会保险法”，各大搜索引擎的结果示意图。下面具体谈谈评分的方法。

Precision-recall（准确率-召回率方法）

计算方法

信息检索领域最广为人知的评价指标为Precision-Recall（准确率-召回率）方法。该方法从提出至今已经历半个世纪，至今在很多搜索引擎公司的效果评估中使用。

顾名思义，这个方法由准确率和召回率这两个相互关联的统计量构成：召回率（Recall）衡量一个查询搜索到所有相关文档的能力，而准确率（Precision）衡量搜索系统排除不相关文档的能力。（通俗的解释一下：准确率就是算一算你查询得到的结果中有多少是靠谱的；而召回率表示所有靠谱的结果中，有多少被你给找回来了）。这两项是评价搜索效果的最基础指标，其具体的计算方法如下。

Precision-recall方法假定对一个给定的查询，对应一个被检索的文档集合和一个不相关的文档集合。这里相关性被假设为二元的，用数学形式化方法来描述，则是：

A表示相关文档集合

A表示不相关集合

B表示被检索到的文档集合

B表示未被检索到的文档集合

则单次查询的准确率和召回率可以用下述公式来表达：

（运算符∩ 表示两个集合的交集。|x|符号表示集合x中的元素数量）

从上面的定义不难看出，召回率和准确率的取值范围均在[0,1]之间。那么不难想象，如果这个系统找回的相关越多，那么召回率越高，如果相关结果全部都给召回了，那么recall此时就等于1.0。

Precision-Recall曲线

召回率和准确率分别反映了检索系统的两个最重要的侧面，而这两个侧面又相互制约。因为大规模数据集合中，如果期望检索到更多相关的文档，必然需要“放宽”检索标准，因此会导致一些不相关结果混进来，从而使准确率受到影响。类似的，期望提高准确率，将不相关文档尽量去除时，务必要执行更“严格”的检索策略，这样也会使一些相关的文档被排除在外，使召回率下降。

所以为了更清晰的描述两者间的关系，通常我们将Precison-Recall用曲线的方式绘制出来，可以简称为P-R diagram。常见的形式如下图所示。（通常曲线是一个逐步向下的走势，即随着Recall的提高，Precision逐步降低）

P-R的其它形态

一些特定搜索应用，会更关注搜索结果中错误的结果。例如，搜索引擎的反作弊系统（Anti-Spam System）会更关注检索结果中混入了多少条作弊结果。学术界把这些错误结果称作假阳性（False Positive）结果，对这些应用，通常选择用虚报率（Fallout）来统计：

Fallout和Presion本质是完全相同的。只是分别从正反两方面来计算。实际上是P-R的一个变种。

再回到上图，Presion-Recall是一个曲线，用来比较两个方法的效果往往不够直观，能不能对两者进行综合，直接反映到一个数值上呢？为此IR学术界提出了F值度量（F -Measure）的方法。F-Measure通过Presion和Recall的调和平均数来计算，公式为：

其中参数λε(0,1)调节系统对Precision和Recall的平衡程度。（通常取λ=0.5，此时 ）

这里使用调和平均数而不是通常的几何平均或算术平均，原因是调和平均数强调较小数值的重要性，能敏感的反映小数字的变化，因此更适合用来反映检索效果。

使用F Measure的好处是只需要一个单一的数字就可以总结系统的检索效果，便于比较不同搜索系统的整体效果。

P@N方法

点击因素

传统的Precision-Recall并不完全适用对搜索引擎的评估，原因是搜索引擎用户的点击方式有其特殊性，包括：

A 60-65%的查询点击了名列搜索结果前10条的网页；  B 20-25%的人会考虑点击名列11到20的网页；  C 仅有3-4%的会点击名列搜索结果中列第21到第30名的网页 

也就是说，绝大部分用户是不愿意翻页去看搜索引擎给出的后面的结果。

而即使在搜索结果的首页（通常列出的是前10条结果），用户的点击行为也很有意思，我们通过下面的Google点击热图（Heat Map）来观察（这个热图在二维搜索结果页上通过光谱来形象的表达不同位置用户的点击热度。颜色约靠近红色表示点击强度越高）：

从图中可以看出，搜索结果的前3条吸引了大量的点击，属于热度最高的部分。也就是说，对搜苏引擎来说，最前的几条结果是最关键的，决定了用户的满意程度。

康乃尔大学的研究人员通过eye tracking实验获得了更为精确的Google搜索结果的用户行为分析图。从这张图中可以看出，第一条结果获得了56.38%的搜索流量，第二条和第三条结果的排名依次降低，但远低于排名第一的结果。前三条结果的点击比例大约为11:3:2 。而前三条结果的总点击几乎分流了搜索流量的80%。

另外的一些有趣的结论是，点击量并不是按照顺序依次递减的。排名第七位获得的点击是最少的，原因可能在于用户在浏览过程中下拉页面到底部，这时候就只显示最后三位排名网站，第七名便容易被忽略。而首屏最后一个结果获得的注意力（2.55）是大于倒数第二位的(1.45)，原因是用户在翻页前，对最后一条结果印象相对较深。搜索结果页面第二页排名第一的网页（即总排名11位的结果）所获得的点击只有首页排名第十网站的40%，与首页的第一条结果相比，更是只有其1/60至1/100的点击量。

因此在量化评估搜索引擎的效果时，往往需要根据以上搜索用户的行为特点，进行针对性的设计。

P@N的计算方法

P@N本身是Precision@N的简称，指的是对特定的查询，考虑位置因素，检测前N条结果的准确率。例如对单次搜索的结果中前5篇，如果有4篇为相关文档，则P@5 = 4/5 = 0.8 。

测试通常会使用一个查询集合（按照前文所述方法构造），包含若干条不同的查询词，在实际使用P@N进行评估时，通常使用所有查询的P@N数据，计算算术平均值，用来评判该系统的整体搜索结果质量。

N的选取

对用户来说，通常只关注搜索结果最前若干条结果，因此通常搜索引擎的效果评估只关注前5、或者前3结果，所以我们常用的N取值为P@3或P@5等。

对一些特定类型的查询应用，如寻址类的查询（Navigational Search），由于目标结果极为明确，因此在评估时，会选择N=1（即使用P@1）。举个例子来说，搜索“新浪网”、或“新浪首页”，如果首条结果不是 新浪网（url：www.sina.com.cn），则直接判该次查询精度不满足需求，即P@1=0

MRR

上述的P@N方法，易于计算和理解。但细心的读者一定会发现问题，就是在前N结果中，排序第1位和第N位的结果，对准确率的影响是一样的。但实际情况是，搜索引擎的评价是和排序位置极为相关的。即排第一的结果错误，和第10位的结果错误，其严重程度有天壤之别。因此在评价系统中，需要引入位置这个因素。

MRR是平均排序倒数（Mean Reciprocal Rank）的简称，MRR方法主要用于寻址类检索（Navigational Search）或问答类检索（Question Answering），这些检索方法只需要一个相关文档，对召回率不敏感，而是更关注搜索引擎检索到的相关文档是否排在结果列表的前面。MRR方法首先计算每一个查询的第一个相关文档位置的倒数，然后将所有倒数值求平均。例如一个包含三个查询词的测试集，前5结果分别为：

查询一结果：1.AN 2.AR 3.AN 4.AN 5.AR  查询二结果：1.AN 2.AR 3.AR 4.AR 5.AN  查询三结果：1.AR 2.AN 3.AN 4.AN 5.AR  

其中AN表示不相关结果，AR表示相关结果。那么第一个查询的排序倒数（Reciprocal Rank）RR₁ = 1/2=0.5 ；第二个结果RR₂ = 1/2 = 0.5 ； 注意倒数的值不变，即使查询二获得的相关结果更多。同理，RR₃= 1/1 = 1。 对于这个测试集合，最终MRR=（RR₁+RR₂+RR₃）/ 3 = 0.67

然而对大部分检索应用来说，只有一条结果无法满足需求，对这种情况，需要更合适的方法来计算效果，其中最常用的是下述MAP方法。

MAP

MAP方法是Mean Average Precison，即平均准确率法的简称。其定义是求每个相关文档检索出后的准确率的平均值（即Average Precision）的算术平均值（Mean）。这里对准确率求了两次平均，因此称为Mean Average Precision。（注：没叫Average Average Precision一是因为难听，二是因为无法区分两次平均的意义）

MAP 是反映系统在全部相关文档上性能的单值指标。系统检索出来的相关文档越靠前(rank 越高)，MAP就应该越高。如果系统没有返回相关文档，则准确率默认为0。

例如：假设有两个主题：

主题1有4个相关网页，主题2有5个相关网页。

某系统对于主题1检索出4个相关网页，其rank分别为1, 2, 4, 7；

对于主题2检索出3个相关网页，其rank分别为1,3,5。

对于主题1，平均准确率MAP计算公式为：

(1/1+2/2+3/4+4/7)/4=0.83。 

对于主题2，平均准确率MAP计算公式为：

(1/1+2/3+3/5+0+0)/5=0.45。 

则MAP= (0.83+0.45)/2=0.64。”

DCG方法

DCG是英文Discounted cumulative gain的简称，中文可翻译为“折扣增益值”。DCG方法的基本思想是：

1. 每条结果的相关性分等级来衡量
2. 考虑结果所在的位置，位置越靠前的则重要程度越高
3. 等级高（即好结果）的结果位置越靠前则值应该越高，否则给予惩罚

我们首先来看第一条：相关性分级。这里比计算Precision时简单统计“准确”或“不准确”要更为精细。我们可以将结果细分为多个等级。比如常用的3级：Good（好）、Fair（一般）、Bad（差）。对应的分值rel为：Good:3 / Fair:2 / Bad:1 。一些更为细致的评估使用5级分类法：Very Good（明显好）、Good（好）、Fair（一般）、Bad（差）、Very Bad（明显差），可以将对应分值rel设置为：Very Good:2 / Good:1 / Fair:0 / Bad:-1 / Very Bad: -2

评判结果的标准可以根据具体的应用来确定，Very Good通常是指结果的主题完全相关，并且网页内容丰富、质量很高。而具体到每条

DCG的计算公式并不唯一，理论上只要求对数折扣因子的平滑性。我个人认为下面的DCG公式更合理，强调了相关性，第1、2条结果的折扣系数也更合理：

此时DCG前4个位置上结果的折扣因子（Discount factor）数值为：

取以2为底的log值也来自于经验公式，并不存在理论上的依据。实际上，Log的基数可以根据平滑的需求进行修改，当加大数值时（例如使用log₅ 代替log₂），折扣因子降低更为迅速，此时强调了前面结果的权重。

为了便于不同类型的query结果之间横向比较，以DCG为基础，一些评价系统还对DCG进行了归一，这些方法统称为nDCG（即 normalize DCG）。最常用的计算方法是通过除以每一个查询的理想值iDCG（ideal DCG）来进行归一，公式为：

求nDCG需要标定出理想情况的iDCG，实际操作的时候是异常困难的，因为每个人对“最好的结果”理解往往各不相同，从海量数据里选出最优结果是很困难的任务，但是比较两组结果哪个更好通常更容易，所以实践应用中，通常选择结果对比的方法进行评估。

怎样实现自动化的评估？

以上所介绍的搜索引擎量化评估指标，在Cranfield评估框架（Cranfield Evaluation Framework）中被广泛使用。业界知名的TREC（文本信息检索会议）就一直基于此类方法组织信息检索评测和技术交流。除了TREC外，一些针对不同应用设计的Cranfield评测论坛也在进行进行（如 NTCIR、IREX等）。

但Cranfield评估框架存在的问题是查询样例集合的标注上。利用手工标注答案的方式进行网络信息检索的评价是一个既耗费人力、又耗费时间的过程，只有少数大公司能够使用。并且由于搜索引擎算法改进、运营维护的需要，检索效果评价反馈的时间需要尽量缩短，因此自动化的评测方法对提高评估效率十分重要。最常用的自动评估方法是A/B testing系统。

A/B Testing

A/B Testing系统

A/B testing系统在用户搜索时，由系统来自动决定用户的分组号（Bucket id），通过自动抽取流量导入不同分支，使得相应分组的用户看到的是不同产品版本（或不同搜索引擎）提供的结果。用户在不同版本产品下的行为将被记录下来，这些行为数据通过数据分析形成一系列指标，而通过这些指标的比较，最后就形成了各版本之间孰优孰劣的结论。

在指标计算时，又可细分为两种方法，一种是基于专家评分的方法；一种是基于点击统计的方法。

专家评分的方法通常由搜索核心技术研发和产品人员来进行，根据预先设定的标准对A、B两套环境的结果给予评分，获取每个Query的结果对比，并根据nDCG等方法计算整体质量。

点击评分有更高的自动化程度，这里使用了一个假设：同样的排序位置，点击数量多的结果质量优于点击数量少的结果。（即A2表示A测试环境第2条结果，如果A2 > B2，则表示A2质量更好）。通俗的说，相信群众（因为群众的眼睛是雪亮的）。在这个假设前提下，我们可以将A/B环境前N条结果的点击率自动映射为评分，通过统计大量的Query点击结果，可以获得可靠的评分对比。

Interleaving Testing

另外2003年由Thorsten Joachims 等人提出的Interleaving testing方法也被广泛使用。该方法设计了一个元搜索引擎，用户输入查询词后，将查询词在几个著名搜索引擎中的查询结果随机混合反馈给用户，并收集随后用户的结果点击行为信息．根据用户不同的点击倾向性，就可以判断搜索引擎返回结果的优劣，

如下图所示，将算法A和B的结果交叉放置，并分流量进行测试，记录用户点击信息。根据点击分布来判断A和B环境的优劣。

Interleaving Testing评估方法

Joachims同时证明了Interleaving Testing评价方法与传统Cranfield评价方法的结果具有较高的相关性。由于记录用户选择检索结果的行为是一个不耗费人力的过程，因此可以便捷的实现自动化的搜索效果评估。

总结

没有评估就没有进步——对搜索效果的量化评测，目的是准确的找出现有搜索系统的不足（没有哪个搜索系统是完美的），进而一步一个脚印对算法、系统进行改进。本文为大家总结了常用的评价框架和评价指标。这些技术像一把把尺子，度量着搜索技术每一次前进的距离。

感谢张凯峰对 本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者 朋友交流。

我们截获函数执行最直接的目的就是为函数增添功能，修改返回值，或者为调试以及性能测试加入附加的代码，或者截获函数的输入输出作研究，破解使用。通过访 问源代码，我们可以轻而易举的使用重建（Rebuilding）操作系统或者应用程序的方法在它们中间插入新的功能或者做功能扩展。然而，在今天这个商业 化的开发世界里，以及在只有二进制代码发布的系统中，研究人员几乎没有机会可以得到源代码。本文主要讨论Detour在Windows二进制PE文件基础 上的API截获技术。对于Linux平台，作这件事情将会非常的简单，由于最初的操作系统设计者引入了LD_PRELOAD。如果你设置  LD_PRELOAD=mylib.so ，那么应用程序在载入 dll时，会先查看mylib.so的符号表，在relocation 的时候会优先 使用mylib.so 里的 symbol 。假如你在mylib.so里有个printf() ，那么这个printf就会替代libc的 printf。 而在mylib.so里的这个printf可以直接访问 libc.so里的printf函数指针来获得真正的 printf的入口地 址。 这样，所有的dll的API HOOK在loader加载dll的时候就已经完成，非常自然，和平台相关的部分全部交给loader去处理。
一、  Detour开发库：
  简介
Detours是一个在x86平台上截获任意Win32函数调用的工具库。中断代码可以在运行时动态加载。Detours使用一个无条件转移指令来替换目 标函数的最初几条指令，将控制流转移到一个用户提供的截获函数。而目标函数中的一些指令被保存在一个被称为“trampoline” （译注：英文意为蹦 床，杂技）的函数中，在这里我觉得翻译成目标函数的部分克隆/拷贝比较贴切。这些指令包括目标函数中被替换的代码以及一个重新跳转到目标函数的无条件分 支。而截获函数可以替换目标函数，或者通过执行“trampoline”函数的时候将目标函数作为子程序来调用的办法来扩展功能。
Detours是执行时被插入的。内存中的目标函数的代码不是在硬盘上被修改的，因而可以在一个很好的粒度上使得截获二进制函数的执行变得更容易。例如， 一个应用程序执行时加载的DLL中的函数过程可以被插入一段截获代码（detoured），与此同时，这个DLL还可以被其他应用程序按正常情况执行（译 注：也就是按照不被截获的方式执行，因为DLL二进制文件没有被修改，所以发生截获时不会影响其他进程空间加载这个DLL）。不同于DLL的重新链接或者 静态重定向，Detours库中使用的这种中断技术确保不会影响到应用程序中的方法或者系统代码对目标函数的定位。
如果其他人为了调试或者在内部使用其他系统检测手段而试图修改二进制代码，Detours将是一个可以普遍使用的开发包。据我所知，Detours是第一 个可以在任意平台上将未修改的目标代码作为一个可以通过“trampoline”调用的子程序来保留的开发包。而以前的系统在逻辑上预先将截获代码放到目 标代码中，而不是将原始的目标代码做为一个普通的子程序来调用。我们独特的“trampoline”设计对于扩展现有的软件的二进制代码是至关重要的。
出于使用基本的函数截获功能的目的，Detours同样提供了编辑任何DLL导入表的功能，达到向存在的二进制代码中添加任意数据节表的目的，向一个新进 程或者一个已经运行着的进程中注入一个DLL。一旦向一个进程注入了DLL，这个动态库就可以截获任何Win32函数，不论它是在应用程序中或者在系统库 中。
  基本原理
1．  WIN32进程的内存管理
众所周知，WINDOWS NT实现了虚拟存储器，每一WIN32进程拥有4GB的虚存空间， 关于WIN32进程的虚存结构及其操作的具体细节请参阅WIN32 API手册， 以下仅指出与Detours相关的几点：
(1) 进程要执行的指令也放在虚存空间中
(2) 可以使用QueryProtectEx函数把存放指令的页面的权限更改为可读可写可执行，再改写其内容，从而修改正在运行的程序
(3) 可以使用VirtualAllocEx从一个进程为另一正运行的进程分配虚存，再使用 QueryProtectEx函数把页面的权限更改为可读可写可执行，并把要执行的指令以二进制机器码的形式写入，从而为一个正在运行的进程注入任意的代码 。
2． 拦截WIN32 API的原理
Detours定义了三个概念：
    (1) Target函数：要拦截的函数，通常为Windows的API。
(2) Trampoline函数：Target函数的部分复制品。因为Detours将会改写Target函数，所以先把Target函数的前5个字节复制保存好，一方面仍然保存Target函数的过程调用语义，另一方面便于以后的恢复。
(3) Detour 函数：用来替代Target函数的函数。
Detours在Target函数的开头加入JMP Address_of_ Detour_ Function指令（共5个字节）把对Target函数 的调用引导到自己的Detour函数， 把Target函数的开头的5个字节加上JMP Address_of_ Target _ Function+ 5共10个字节作为Trampoline函数。请参考下面的图1和图2。
(图1：Detour函数的过程)
 
（图2： Detour函数的调用过程）
 
说明：
  目标函数：
目标函数的函数体（二进制）至少有5个字节以上。按照微软的说明文档Trampoline函数的函数体是拷贝前5个字节加一个无条件跳转指令的话（如果没 有特殊处理不可分割指令的话），那么前5个字节必须是完整指令，也就是不能第5个字节和第6个字节是一条不可分割的指令，否则会造成Trampoline 函数执行错误，一条完整的指令被硬性分割开来，造成程序崩溃。对于第5字节和第6个字节是不可分割指令需要调整拷贝到杂技函数(Trampoline)的 字节个数，这个值可以查看目标函数的汇编代码得到。此函数是目标函数的修改版本，不能在Detour函数中直接调用，需要通过对Trampoline函数 的调用来达到间接调用。
  Trampoline函数：
此函数默认分配了32个字节，函数的内容就是拷贝的目标函数的前5个字节，加上一个JMP Address_of_ Target _ Function+5指令,共10个字节。
此函数仅供您的Detour函数调用，执行完前5个字节的指令后再绝对跳转到目标函数的第6个字节继续执行原功能函数。
  Detour函数：
此函数是用户需要的截获API的一个模拟版本，调用方式，参数个数必须和目标函数相一致。如目标函数是__stdcall，则Detour函数声明也必须 是__stdcall,参数个数和类型也必须相同，否则会造成程序崩溃。此函数在程序调用目标函数的第一条指令的时候就会被调用（无条件跳转过来的），如 果在此函数中想继续调用目标函数，必须调用Trampoline函数（Trampoline函数在执行完目标函数的前5个字节的指令后会无条件跳转到目标 函数的5个字节后继续执行），不能再直接调用目标函数，否则将进入无穷递归（目标函数跳转到Detour函数，Detour函数又跳转到目标函数的递归， 因为目标函数在内存中的前5个字节已经被修改成绝对跳转）。通过对Trampoline函数的调用后可以获取目标函数的执行结果，此特性对分析目标函数非 常有用，而且可以将目标函数的输出结果进行修改后再传回给应用程序。
Detour提供了向运行中的应用程序注入Detour函数和在二进制文件基础上注入Detour函数两种方式。本章主要讨论第二种工作方式。通过 Detours提供的开发包可以在二进制EXE文件中添加一个名称为Detour的节表，如下图3所示，主要目的是实现PE加载器加载应用程序的时候会自 动加载您编写的Detours DLL，在Detours Dll中的DLLMain中完成对目标函数的Detour。
（图3）
 
二、  Detours提供的截获API的相关接口
Detours的提供的API 接口可以作为一个共享DLL给外部程序调用，也可以作为一个静态Lib链接到您的程序内部。
Trampoline函数可以动态或者静态的创建，如果目标函数本身是一个链接符号，使用静态的trampoline函数将非常简单。如果目标函数不能在链接时可见，那么可以使用动态trampoline函数。
  要使用静态的trampoline函数来截获目标函数，应用程序生成trampoline的时候必须使用
DETOUR_TRAMPOLINE宏。DETOUR_TRAMPOLINE有两个输入参数：trampoline的原型和目标函数的名字。
注意，对于正确的截获模型，包括目标函数，trampoline函数，以及截获函数都必须是完全一致的调用形式，包括参数格式和调用约定。当通过 trampoline函数调用目标函数的时候拷贝正确参数是截获函数的责任。由于目标函数仅仅是截获函数的一个可调用分支（截获函数可以调用 trampoline函数也可以不调用），这种责任几乎就是一种下意识的行为。
使用相同的调用约定可以确保寄存器中的值被正确的保存，并且保证调用堆栈在截获函数调用目标函数的时候能正确的建立和销毁。
可以使用DetourFunctionWithTrampoline函数来截获目标函数。这个函数有两个参数：trampoline函数以及截获函数的指针。因为目标函数已经被加到trampoline函数中，所有不需要在参数中特别指定。
  我们可以使用DetourFunction函数来创建一个动态的trampoline函数，它包括两个参数：一个指向目标函数的指针和一个截获函数的指针。DetourFunction分配一个新的trampoline函数并将适当的截获代码插入到目标函数中去。
当目标函数不是很容易使用的时候，DetourFindFunction函数可以找到那个函数，不管它是DLL中导出的函数，或者是可以通过二进制目标函数的调试符号找到。
DetourFindFunction接受两个参数：库的名字和函数的名字。如果DetourFindFunction函数找到了指定的函数，返回该函数 的指针，否则将返回一个NULL指针。DetourFindFunction会首先使用Win32函数LoadLibrary 和 GetProcAddress来定位函数，如果函数没有在DLL的导出表中找到，DetourFindFunction将使用ImageHlp库来搜索有 效的调试符号（译注：这里的调试符号是指Windows本身提供的调试符号，需要单独安装，具体信息请参考Windows的用户诊断支持信息）。 DetourFindFunction返回的函数指针可以用来传递给DetourFunction以生成一个动态的trampoline函数。
我们可以调用DetourRemoveTrampoline来去掉对一个目标函数的截获。
注意，因为Detours中的函数会修改应用程序的地址空间，请确保当加入截获函数或者去掉截获函数的时候没有其他线程在进程空间中执行，这是程序员的责任。一个简单的方法保证这个时候是单线程执行就是在加载Detours库的时候在DllMain中呼叫函数。
三、  使用Detours实现对API的截获的两种方法
建立一个MFC对话框工程，在对话框的OK按钮的单击事件中加入对MessageBoxA函数的调用，编译后的程序名称MessageBoxApp,效果如图。
 
(图4)
  静态方法
建立一个Dll工程，名称为ApiHook，这里以Visual C++6.0开发环境，以截获ASCII版本的MessageBoxA函数来说明。在Dll的工程加入：
DETOUR_TRAMPOLINE(int WINAPI Real_Messagebox(HWND hWnd ,
    LPCSTR lpText,
    LPCSTR lpCaption,
UINT uType), ::MessageBoxA);
生成一个静态的MessageBoxA的Trampoline函数，在Dll工程中加入目标函数的Detour函数：
int WINAPI MessageBox_Mine( HWND hWnd ,
    LPCSTR lpText,
    LPCSTR lpCaption,
    UINT uType)
{
  CString tmp= lpText;
  tmp+=” 被Detour截获”;
  return Real_Messagebox(hWnd,tmp,lpCaption,uType);
//  return ::MessageBoxA(hWnd,tmp,lpCaption,uType);  //Error
}
在Dll入口函数中的加载Dll事件中加入：
DetourFunctionWithTrampoline((PBYTE)Real_Messagebox, (PBYTE)MessageBox_Mine);
在Dll入口函数中的卸载Dll事件中加入：
DetourRemove((PBYTE)Real_Messagebox, (PBYTE)MessageBox_Mine);
  动态方法
建立一个Dll工程，名称为ApiHook，这里以Visual C++6.0开发环境，以截获ASCII版本的MessageBoxA函数来说明。在Dll的工程加入：
//声明MessageBoxA一样的函数原型
typedef int  (WINAPI * MessageBoxSys)( HWND hWnd ,
    LPCSTR lpText,
    LPCSTR lpCaption,
    UINT uType);
//目标函数指针
MessageBoxSys SystemMessageBox=NULL;
//Trampoline函数指针
MessageBoxSys Real_MessageBox=NULL;
在Dll工程中加入目标函数的Detour函数：
int WINAPI MessageBox_Mine( HWND hWnd ,
    LPCSTR lpText,
    LPCSTR lpCaption,
    UINT uType)
{
  CString tmp= lpText;
  tmp+=” 被Detour截获”;
  return Real_Messagebox(hWnd,tmp,lpCaption,uType);
//  return ::MessageBoxA(hWnd,tmp,lpCaption,uType);  //Error
}
在Dll入口函数中的加载Dll事件中加入：
  SystemMessageBox=(MessageBoxSys)DetourFindFunction("user32.dll","MessageBoxA");
  if(SystemMessageBox==NULL)
  {
    return FASLE;
  }
  Real_MessageBox=(MessageBoxSys)DetourFunction((PBYTE)SystemMessageBox, (PBYTE)MessageBox_Mine);
在Dll入口函数中的卸载Dll事件中加入：
DetourRemove((PBYTE)Real_Messagebox, (PBYTE)MessageBox_Mine);
  重写二进制可执行文件
使用Detours自带的SetDll.exe重写二进制可执行文件，可以在需要截获的程序中加入一个新的Detours的PE节表。对于本文就是新建一个批处理文件调用SetDll.exe。
@echo off
if not exist MessageBoxApp.exe (
echo 请将文件解压到MessageBoxApp.exe的安装目录, 然后执行补丁程序
) else (
setdll /d:ApiHook.dll MessageBoxApp.exe
)
Pause
调用后使用depends.exe（微软VC6.0开发包的工具之一）观察MessageBoxApp.exe前后变化， 可以看到Setdll已经重写MessageBoxApp.exe
成功，加入了对ApiHook.dll的依赖关系。
 
      （执行SetDll.exe前）                                                       (执行SetDll.exe后)
执行SetDll.exe重写后的MessageBoxApp.exe，点击确定后可以看到结果如下：
至此，MessageBoxApp.exe对MessageBoxA函数的调用已经被截获，弹出的对话框内容已经明显说明这一点。


本文转自：http://www.cnblogs.com/flying_bat/archive/2008/04/18/1159996.html

1、围绕数据编程与不是围绕UI编程

当我们拿到需求最先接触到的就是UI的设计，也许是美工画的，也许是设计草图。工程师在具体设计的时候容易受UI的影响，或者干脆从UI开始编程。

这是一个错误的编程习惯，无论UI如何展现与交互，最终都应该围绕数据编程。拿到需求后，应该先思考和推敲数据的设计与流转，UI不过就是数据的一种展现形式而已。

2、做好UI与逻辑的解耦

UI的编程会涉及到许多控件的操作，消息的处理，不知不觉，一个UI类的代码会越写越大，以至于一段时间以后，浏览和梳理都会变得不太方便。

在UI类里，除了与UI本身的操作有关的代码以外，任何逻辑代码都应该与此解耦，并根据具体情况进行封装调用。如果一个控件关联了太多数据操作，应该把这些操作封装到控件的继承类中，把一类代码进行集中管理和维护。

上述问题，在程序写作的初期还不太明显，随着代码逐渐膨胀，会越会越让人难以忍受。

3、数据单向依赖，单向更新

UI围绕的数据进行展现与更新，在这个过程中，所以对数据的操作应该进行封装，而不是散落在UI程序在各个角落，数据的更新、获取和UI传递消息时，应该单向操作，如果出现循环处理的情况，在以后维护调试的BUG的过程中会变得比较困难，导致维护效率下降。

本文来自CSDN博客，转载请标明出处：http://www.cppblog.com/humanchao

1、不愿意将就的人

程序设计工作是一项地地道道的脑力劳动，把工作做得很好和做的很差往往只在工作中的一个小小的细节，我发现我身边优秀的程序员都不太喜欢将就，始终把自己的计算机和自己的开发环境调整到最佳状态，原来带我的老员工甚至会自己写一些小工具，来提高工作效率。

2、不喜欢蛮干

脑力劳动与体力劳动不同，很多时候很难通过简单的量的积累达到目的，尤其是处理一些难题的时候。一味的强调蛮干，加班几乎天生与高手无缘。没有思路的时候，换个环境，也许答案就在明天上班的路上想起。

3、愿意思考、专注改进

程序员与其他劳动者相似，熟练了以后都会形成惯性思维，会不自觉的用自己习惯的方式解决问题，但问题的形式与本质总会变化，只有不断的改进才能使工作效率不断提高。而把脑力劳动变成体力劳动的现象在实际工作中比比皆是。

4、良好的基础和不断的学习

良好的基础与不断的学习是天生的一对孪生兄弟，因为基础好所以学的快，因为学得快，所以基本功好。良好学习习惯不是不停的简单追踪新技术，一方面是了解新技术，另一方面需要不断的弥补思维盲区，学习可以有很多种状态，有一种是闻一而知一，技也，有一种是闻一而知三，术也，有一种是闻一而知十，道也。

5、直接切入问题的能力

在解决一个问题的时候，有些人总是能够直接切入问题核心，而有些人总是喜欢关注边缘问题。直入主题是一种核心能力，需要思考，实践，改进，积累，提高，周而复使，螺旋上升。另外我觉得这与思维方式与知识面关系很大，多涉猎一些领域没有坏处。

***英语***：呵呵，对，还是英语，流利的听说读写。

本文来自CSDN博客，转载请标明出处：http://www.cppblog.com/humanchao

先给大家看一段据说是史上最强的程序：
e100 33 f6 bf 0 20 b5 10 f3 a5 8c c8 5 0 2 50 68 13 1 cb e 1f be a1 1 bf 0 1
e11b 6 57 b8 11 1 bb 21 13 89 7 4b 4b 48 79 f9 ad 86 e0 8b c8 bd ff ff e8 20
e134 0 3d 0 1 74 1a 7f 3 aa eb f3 2d ff 0 50 e8 f 0 5a f7 d8 8b d8 26 8a 1 aa
e14f 4a 75 f9 eb de cb 57 bb 21 13 8b c1 40 f7 27 f7 f5 8b fb ba 11 1 4f 4f 4a
e168 39 5 7f f9 52 8b c5 f7 25 f7 37 2b c8 95 f7 65 2 f7 37 95 2b e8 fe e fe
e181 10 79 6 c6 6 fe 10 7 46 d0 14 d1 d1 d1 e5 79 ec 5a b8 11 1 ff 7 4b 4b 48
e19b 3b d0 75 f7 5f c3 83 f7 83 a6 5d 59 82 cd b2 8 42 46 9 57 a9 c5 ca aa 1b
.............................................................................

这段程序是1997年世界程序设计大赛的一等奖作品的部分代码（完整的代码下载，把代码复制粘贴到cmd的debug命令中，回车看到效果）。这个程序运行后将是一个3D的且伴随着音乐的动画。震撼吧！
是不是从事软件开发的人员都希望成为这样的武林高手呢？然而真要是用这样的高手来设计、编写我们的产品代码，恐怕某一天，我们什么都不用干了，只能人手一本机器代码，一句一句进行翻译了；那么对于软件产品开发而言，如何写好代码呢？一流的软件产品的代码具备哪些特征呢？

一流代码的特征

1、稳定可靠（Robustness）
代码写出来以后，一定要能够运行得非常好，非常稳定可靠。在现今的IT行业，软件产品都是是24*7，即要保证系统一天24小时，一星期7天中都可以无间断的正常运行。比如我们百度的搜索引擎系统，比如我们的通信系统，等等。到了产品开发后期，大部分的成本都将投入到产品稳定性的提高。

2、可维护且简洁（Maintainable and Simple Code）
在写代码时，首先要考虑的是：写出来的代码不但要自己可以读懂，而且我们的同事、测试工程师都可能要修改这些代码，对其进行增减。如果代码很复杂，不容易读懂，如程序中的递归一大堆、程序不知何时或从何地跳出，则会使程序的可维护性和简洁性降低。所以必要的注释、统一的编程规范等都是非常重要的。

3、高效（Fast）
在软件行业中效率是非常重要的，比如搜索引擎。有些软件的搜索效率就不高，搜索过程特别缓慢，让人难以接受。当然这里面有一个带宽的问题，但是程序效率不高也是一个重要的原因。而实际上程序的效率提高，有时候很简单，并没有什么神秘之处，如使用数组索引时候，可以用指针方式而不使用数组下标；数组的空间定义应该定义为2的N次幂等等。

4、简短（Small）
这方面大家的感受可能不是很深，但是我的感受是很深的。配置过PSTN程控交换机、路由器、VoIP网关设备的人都知道，这些设备的软件都是从PC机通过网口或串口下载到这些设备的Flash上（类似PC机的BIOS）再通过设备上的CPU启动。如果程序写的很罗嗦，随着特性不断增加，程序规模将变大的巨大，Flash空间告急、内存告急、下载升级变的不可忍受，等等，带来的就是成本不断增加，利润不断下降。

5、共享性（Reusable）
如果做大型产品开发，程序的共享性也是非常重要的。我们产品有那么多开发人员，如果每一个人都自己定义字符串、链表等数据结构，那么开发效率就会降低，我们的产品恐怕到今天也不能出台。我所说的“共享”不是指将别人的代码复制到自己的代码中，而是指直接调用别人的代码，拿来即可用。这一方面可以减少代码的冗余性，另一方面可以增强代码的可维护性。如果别人的代码里有Bug，只需修改他的代码，而调用此代码的程序不用进行任何修改就可以达到同步。这同时要求我们在设计的时候，如何考虑系统的内聚和耦合的问题。

6、可测试性（Testable）
我们的产品开发里，除了软件开发人员，还有一部分工程师负责软件测试。软件测试人员会将开发代码拿来，一行一行地运行，看程序运行是否有错。如果软件开发人员的代码不可测试，那测试工程师就没有办法进行工作。因此可测试性在大型软件开发里是很重要的一点。可测试性有时候与可维护性是遥相呼应的，一个具有好的可测试性和可维护性的代码，测试人员可以根据开发提供的维护手册、debug信息手册等就可以判断出程序出错在哪个模块。

7、可移植性（Portable）
可移植性是指程序写出来以后，不仅在windows 2000里可以运行，在NT/9X下可以运行，而且在Linux甚至Macintosh等系统下都可以运行。所有这些特性都是一流代码所具备的特性。但是其中有些特性是会有冲突的。比如高效性，程序写的效率很高，就可能变得很复杂，牺牲的就是简洁。好的代码要在这些特性中取得平衡。

1、百家之长归我所有（Follow Basic Coding Style）
其实写代码的方式有很多，每个人都有自己的风格，但是众多的风格中总有一些共性的、基本的写代码的风格，如为程序写注释、代码对齐，等等。是不是编程规范？对就是编程规范。

2、取个好名字（Use Naming Conventions）
取个好的函数名、变量名，最好按照一定的规则起名。还是编程规范。

3、凌波微步，未必摔跤（Evil goto's?Maybe Not...）
这里我用“凌波微步”来形容goto语句。通常，goto语句使程序跳来跳去，不容易读，而且不能优化，但是在某种情况下，goto语句反而可以增强程序的可读性。Just go ahead，not go back。

4、先发制人，后发制于人（Practic Defensive Coding）
Defensive Coding指一些可能会出错的情况，如变量的初始化等，要考虑到出现错误情况下的处理策略。测试时要多运行几个线程。有些程序在一个线城下运行是正常的，但是在多个线程并行运行时就会出现问题；而有些程序在一个CPU下运行几个线程是正常的，但是在多个CPU下运行时就会出现问题，因为单CPU运行线程只是狭义的并行，多CPU一起运行程序，才是真正的并行运算。

5、见招拆招，滴水不漏（Handle The Error Cases：They Will Occur！）
这里的Error Case（错误情况），是指那些不易重视的错误。如果不对Error Case进行处理，程序在多数情况下不会出错，但是一旦出现异常，程序就会崩溃。 6、熟习剑法刀术，所向无敌（Learn Win32 API Seriously）
用“剑法刀术”来形容一些API是因为它们都是经过了很多优秀开发人员的不断开发、测试，其效率很高，而且简洁易懂，希望大家能掌握它，熟悉它，使用它。是不是象我们的ULIB。

7、双手互搏，无坚不摧（Test,but don't stop there）
这里的测试不是指别人来测试你的代码，而是指自己去测试。因为你是写代码的原作者，对代码的了解最深，别人不可能比你更了解，所以你自己在测试时，可以很好地去测试哪些边界条件，以及一些意向不到的情况。

8、活用断言（Use,don't abuse,assertions）
断言（assertion）是个很好的调试工具和方法，希望大家能多用断言，但是并不是所有的情况下都可以用到断言。有些情况使用断言反而不合适。

9、草木皆兵，不可大意（Avoid Assumptions）
是指在写代码时，要小心一些输入的情况，比如输入文件、TCP的sockets、函数的参数等等，不要认为使用我们的API的用户都知道什么是正确的、什么是错的，也就是说一定要考虑到对外接口的出错处理问题。

10、最高境界、无招胜有招（Stop writing so much code）
意思就是说尽量避免写太多的代码，写的越多，出错的机会也越多。最好能重用别人开放的接口函数或直接调用别人的api。

本文来自CSDN博客，转载请标明出处：http://www.cppblog.com/humanchao/archive/2010/08/05/122334.html

转自：http://yinkai210.blog.163.com/blog/static/287483452009050256466/

这些端口如果被其他程序占用就不能正常启动，比如有时启动时会提示WEB启动失败，其实就是80端口被占用了，而迅雷等下载软件恰恰就是占用了80端口，关掉就行了。但有时迅雷等都没有开也启动不了，那就是别的东西占用了，那怎么办呢？我来叫你查看端口并关掉的方法。
1.在开始--运行   里面输入cmd点回车，会出现运行窗口。
2.在提示符后输入netstat -ano回车，找到tcp 80端口对应的pid，比如1484.
3.ctrl+alt+del打开任务管理器，选进程，这里有很多正在运行的程序怎么找？别急点上面的   查看--选择列--在PID（进程标示符）前面打钩。好了，下面的进程前面都有了PID号码。这时上一步找到的PID就有用了，找到1484，比如PEER.EXE什么的，结束进程吧。这时再开服务器，看WEB可以启动了！

如上面的不清楚还有简明的：

假如我们需要确定谁占用了我们的80端口

1、Windows平台
在windows命令行窗口下执行：
C:\>netstat -aon|findstr "80"
TCP     127.0.0.1:80         0.0.0.0:0               LISTENING       2448
看到了吗，端口被进程号为2448的进程占用，继续执行下面命令：
C:\>tasklist|findstr "2448"
thread.exe                     2016 Console                 0     16,064 K
很清楚吧，thread占用了你的端口,Kill it
如果第二步查不到，那就开任务管理器，看哪个进程是2448，然后杀之即可。

如果需要查看其他端口。把 80 改掉即可

Linux查看端口使用状态、关闭端口方法
转自：http://blog.csdn.net/wudiyi815/article/details/7473097
前提：首先你必须知道，端口不是独立存在的，它是依附于进程的。某个进程开启，那么它对应的端口就开启了，进程关闭，则该端口也就关闭了。下次若某个进程再次开启，则相应的端口也再次开启。而不要纯粹的理解为关闭掉某个端口，不过可以禁用某个端口。

1. 可以通过"netstat -anp" 来查看哪些端口被打开。
（注：加参数'-n'会将应用程序转为端口显示，即数字格式的地址，如：nfs->2049, ftp->21，因此可以开启两个终端，一一对应一下程序所对应的端口号）
2. 然后可以通过"lsof -i:$PORT"查看应用该端口的程序（$PORT指对应的端口号）。或者你也可以查看文件/etc/services，从里面可以找出端口所对应的服务。
（注：有些端口通过netstat查不出来，更可靠的方法是"sudo nmap -sT -O localhost"）
3. 若要关闭某个端口，则可以：
1)通过iptables工具将该端口禁掉，如：
 "sudo iptables -A INPUT -p tcp --dport $PORT -j DROP"
 "sudo iptables -A OUTPUT -p tcp --dport $PORT -j DROP"    
2)或者关掉对应的应用程序，则端口就自然关闭了，如：
 "kill -9 PID" (PID：进程号)
  如：    通过"netstat -anp | grep ssh"
  有显示：    tcp 0 127.0.0.1:2121 0.0.0.0:* LISTEN 7546/ssh
  则：    "kill -9 7546"

（可通过"chkconfig"查看系统服务的开启状态）