java学习笔记

摘要：几个朋友都在问，如何学习 Java的问题，“我已经学习了J2SE，怎么样才能转向J2EE?”，“我看完了Thinking in Java， 可以学习J2EE了么?”。于是就有了写这篇文章的想法，希望能帮助初学者少走一些弯路。也算是对自己几年来学习Java的一个总结吧。　查看全文

摘要：希望来过得都去看看，为java营造一个好的环境而努力:Java 编码惯例　查看全文

摘要：这是一首值得在安静的时间,用安静的呼吸,用纯洁的心灵去倾听的歌。　查看全文

出版社：机械工业出版社
原出版社： SAMS
我所见过的最好最经典的软件测试入门书，有一个别名叫“软件测试的本质”。书中没有讨论太多的软件测试理论，只包含了一部分常用的、基本的知识。从什么是软件测试、为什么要作软件测试开始，逐步引入基本的和高级的测试技术和方法，然后开始把读者引入实际工作中，讲述了一般的测试过程中要经历哪些阶段，要作哪些具体的工作，如何开展测试工作，如何找到缺陷并提交缺陷。甚至还包括了对测试人员的职业指导。建议所有的测试人员都读一读。

《软件测试》
作者：[美]Paul C.Jorgensen
译者：韩柯 杜旭涛
出版社：机械工业出版社
原出版社： CRC
另一本同名的经典测试书籍。如果说上面那本的目的是快速的将你引入测试的殿堂，或者说作为一本“快速职业培训”的话，这本则是更深入的介绍了软件测试的基本知识和方法。其中重点介绍了黑盒测试（功能性测试）、白盒测试（结构性测试）的技术和方法，以及如何开展集成测试和系统测试工作。另外，书中还包含了对于面向对象测试的内容。这本书可以作为夯实测试基础的教材，建议阅读。

《Automated Software Testing--Introduction,Management and Performance》
作者：[美]Elfriede Dustin等著
出版社：清华大学出版社
这本书虽然在国内也有中文版，我一开始看的也是中文版，不过限于中文版的质量，这里还是推荐有能力的朋友看影印版吧。
虽然书名中大主题是“自动化软件测试”，但是这本书中介绍的更多的并不是自动化测试的具体实现，而是侧重于测试过程和测试管理方面的内容，这也是因为自动化软件测试工作的开展必须依赖于一个完善的测试过程吧。
从某个角度来看，上述的三本书从测试技术、方法和测试过程几个方面都进行了详细的论述，可以作为逐步深入的“测试学习路线图”，先看第一本入门，然后通过第二本强化对测试方法和技术的理解，然后通过第三本来更深入、全面的理解测试过程。其实书不在多，如果但作为基础学习，找到基本合适的，然后反复的阅读、研究、实践，就应该足够了。

《软件测试自动化》
作者：Daniel J.Mosley, Bruce A.Posey/著
译者：邓波 黄丽娟 曹青春等/译
出版社：机械工业出版社
可以把这本书当做第一本书的延续——不过我指的是作用和风格，作者当然不是同一个人了——你可以把它理解为“软件测试自动化”方面的经典入门书。作者从实际工作的角度对自动化测试进行了详细的论述，包括应该何时开始自动化、测试自动化同软件开发过程中其他工作的关系，以及测试自动化工作开展的过程。还介绍了“自动化测试框架”。不过这本书最吸引我的，还并不是它将我轻松的引入了自动化测试的世界，它还在每个章节的后面提供了很多链接和文档资料，大都可以在网上搜索到和打开。配合这些资料的学习，更深一步的理解了自动化测试的本质。
建议准备学习自动化测试和已经开始尝试自动化测试的朋友阅读多几遍。

《有效软件测试》
作者：[美]Elfriede Dustin/著
译者：新语/译
出版社：清华大学出版社
虽然这本书国内也出了影印版，但是个人感觉中文版的质量还是不错的，从中也可以看出译者有着很深的软件工程实践功底。作为一本实践经验性的著作，书中涵盖了从测试过程到测试管理，从测试方法到测试技术，以及自动化测试方面的内容，所以要求读者应当具有相当的软件测试实际工作经验，否则只有理论知识恐怕也很难理解其中的一些做法，“知其然”却无法“知其所以然”。建议先看过上面介绍的四本书（或者至少前三本）并有了一些实际测试的经验以后，再来阅读这本书效果会好一些。你会在阅读的过程中发现，原来很多测试工作开展时遇到的难题可以这样解决，原来测试工作可以通过这样来提高效率……
虽然这本书的内容并没有特别的依赖于某些测试工具，不过看的出作者和译者的工作大都是基于RUP的，所以如果读者有这方面的了解和实践经验，阅读起来效果会更好一些。

一、软件测试概述 软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。 软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。 测试人员在软件开发过程中的任务： 1、寻找Bug； 2、避免软件开发过程中的缺陷； 3、衡量软件的品质； 4、关注用户的需求。 总的目标是：确保软件的质量。 二、常用的软件测试方法 1. 黑盒测试 黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。 黑盒测试的优点有： 1）比较简单，不需要了解程序内部的代码及实现； 2）与软件的内部实现无关； 3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题； 4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能； 5）在做软件自动化测试时较为方便。 黑盒测试的缺点有： 1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%； 2）自动化测试的复用性较低。 2. 白盒测试 白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下例程序代码： HRESULT Play( char* pszFileName ) { if ( NULL == pszFileName ) return; if ( STATE_OPENED == currentState ) { PlayTheFile(); } return; } 读了代码之后可以知道，先要检查一个字符串是否为空，然后再根据播放器当前的状态来执行相应的动作。可以这样设计一些测试用例：比如字符串（文件）为空的话会出现什么情况；如果此时播放器的状态是文件刚打开，会是什么情况；如果文件已经在播放，再调用这个函数会是什么情况。也就是说，根据播放器内部状态的不同，可以设计很多不同的测试用例。这些是在纯粹做黑盒测试时不一定能做到的事情。 白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。 白盒测试的缺点有： 1）程序运行会有很多不同的路径，不可能测试所有的运行路径； 2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求； 3）系统庞大时，测试开销会非常大。 3. 基于风险的测试 基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。 基于风险测试的两个决定因素就是：该功能出问题对用户的影响有多大，出问题的概率有多大。其它一些影响因素还有复杂性、可用性、依赖性、可修改性等。测试人员主要根据事情的轻重缓急来决定测试工作的重点。 4. 基于模型的测试 模型实际上就是用语言把一个系统的行为描述出来，定义出它可能的各种状态，以及它们之间的转换关系，即状态转换图。模型是系统的抽象。基于模型的测试是利用模型来生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统，过程如下图所示。 三、软件测试的类型 常见的软件测试类型有： BVT (Build Verification Test) BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如无大的问题，就可以进行相应的功能测试。BVT优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。 Scenario Tests（基于用户实际应用场景的测试） 在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。 Smoke Test 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。 此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等。 四、微软的软件测试工作 1. 基本情况 测试在微软公司是一项非常重要的工作，微软公司在此方面的投入是非常巨大的。微软对测试的重视表现在工程开发队伍的人员构成上，微软的项目经理、软件开发人员和测试人员的比例基本是1：3：3或1：4：4，可以看出开发人员与测试人员的比例是1：1。对于测试的重视还表现在最后产品要发布的时候，此产品的所有相关部门都必须签字，而测试人员则具有绝对的否决权。 测试人员中分成两种职位，Software Development Engineer in Test（测试组的软件开发工程师）实际上还是属于开发人员，他们具备编写代码的能力和开发工具软件的经验，侧重于开发自动化测试工具和测试脚本，实现测试的自动化。Software Test Engineer（软件测试工程师）具体负责测试软件产品，主要完成一些手工测试以及安装配置测试。 2. 测试计划 测试计划是测试人员管理测试项目，在软件中寻找Bug的一种有效的工具。测试计划主要有两个作用，一是评判团队的测试覆盖率以及效率，让测试工作很有条理的逐步展开。二是有利于与项目经理、开发人员进行沟通。有了测试计划之后，他们就能够知道你是如何开展测试工作的，他们也会从中提出很多有益的意见，确保测试工作顺利进行。总之，有了测试计划可以更好的完成测试工作，确保用户的满意度。 测试人员在编写测试计划之前，应获得以下文档： 1）程序经理编写的产品功能说明书或产品开发计划； 2）程序经理或开发人员提供的开发进度表。 根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括以下内容： 1）测试目标和发布条件： a. 给出清晰的测试目标描述； b. 定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特定版本。 2）待测产品范围： a. 软件主要特性/功能说明，即待测软件主要特性的列表； b. 特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并列举每个测试范围内要重点考虑的关键功能。 3）测试方法描述： a. 定义测试软件产品时使用的测试方法； b. 描述每一种特定的测试方法可以覆盖哪些测试范围。 4）测试进度表： a. 定义测试里程碑； b. 定义当前里程碑的详细测试进度。 5）测试资源和相关的程序经理/开发工程师： a. 定义参与测试的人员； b. 描述每位测试人员的职责范围； c. 给出与测试有关的程序经理/开发工程师的相关信息。 6）配置范围和测试工具： a. 给出测试时使用的所有计算机平台列表； b. 描述测试覆盖了哪些硬件设备； c. 测试时使用的主要测试工具。 此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产品或某个团队。比如此项测试依赖性WindowsCE这个操作系统，而这个系统要明年2月份才能做好，那么此项测试就可能只有在明年5月份才能完成，这样就存在着依赖关系。如果那个团队的开发计划往后推，则此项测试也会被推迟。 3. 测试用例开发 一个好的测试用例就是有一个合理的概率来找到Bug，不要冗余，要有针对性，一个测试只针对一件事情。特别是功能测试的时候，如果一个测试是测了两项功能，那么如果测试结果失败的话，就不知道到底是哪项功能出了问题。 测试用例开发中主要使用的技术有等价类划分，边界值的分析，Error Guessing Testing。 等价类划分是根据输入输出条件，以及自身的一些特性分成两个或更多个子集，来减少所需要测试的用例个数，并且能用很少的测试用例来覆盖很多的情况，减少测试用例的冗余度。在等价类划分中，最基本的划分是一个为合法的类，一个为不合法的类。 边界值的分析是利用了一个规律，即程序最容易发生错误的地方就是在边界值的附近，它取决于变量的类型，以及变量的取值范围。一般对于有n个变量时，会有6n+1个测试用例，取值分别是min-1, min, min+1, normal, max-1, max,max+1的组合。边界值的分析的缺点，是对逻辑变量和布尔型变量不起作用，还有可能会忽略掉某些输入的组合。 Error Guessing Testing完全靠的是经验，所设计的测试用例就是常说的猜测。感觉到软件在某个地方可能出错，就去设计相应的测试用例，这主要是靠实际工作中所积累的经验和知识。其优点是速度快，只要想得到，就能很快设计出测试用例。缺点就是没有系统性，无法知道覆盖率会有多少，很可能会遗漏一些测试领域。 实际上在微软是采用一些专门的软件或工具负责测试用例的管理，有一些测试信息可以被记录下来，比如测试用例的简单描述，在哪些平台执行，是手工测试还是自动测试，运行的频率是每天运行一次，还是每周运行一次。此外还有清晰的测试通过或失败的标准，以及详细记录测试的每个步骤。 4. Bug跟踪过程 在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段： 1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。 2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。 3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。 4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。 5. Bug的不同处理方式 在某些情况下，Bug已处理并不意味着Bug已经被修正。开发工程师可以推迟Bug的修正时间，也可以在分析之后告知测试工程师这实际上不是一个真正的Bug。也就是说，某特定的Bug经开发工程师处理之后，该Bug可能包括以下几种状态。 已修正：开发工程师已经修正了相应的程序代码，该Bug不会出现了。 可推迟：该Bug的重要程度较低，不会影响当前应提交版本的主要功能，可安排在下一版本中再行处理。 设计问题：该Bug与程序实现无关，其所表现出来的行为完全符合设计要求，对此应提交给程序经理处理。 无需修正：该Bug的重要程度非常低，根本不会影响程序的功能，项目组没有必要在这些Bug上浪费时间。 五、成为优秀测试工程师的要求 要成为一名优秀的测试工程师，首先对计算机的基本知识要有很好的了解，精通一门或多门的编程语言，具备一定的程序调试技能，掌握测试工具的开发和使用技术。同时要比较细心，会按照任务的轻重缓急来安排自己的工作，要有很好的沟通能力。此外，还要善于用非常规的方式思考问题，尽可能多的参加软件测试项目，在实践中学习技能，积累经验，不断分析和总结软件开发过程中可能出错的环节。这样，一名优秀的测试工程师就从软件测试的实践中脱颖而出了。 结束语：微软的软件开发经验积淀深厚，微软工程师们的授课生动溢彩，其中有些内容是结合编程代码所作的详细讲解，较难用介绍性文字加以概括提炼，加之笔者受能力和精力所限，只能撷取部分精华内容整理成文以飨读者，因此难免是挂一漏万，甚至会有失误之处，敬请对本系列文章的关注者谅解及指正。最后对微软老师们的辛勤付出再表由衷谢意！

1.1 脚本录制规范：
基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。
1.1.1 录制脚本要分开：
脚本太大，不仅不利于以后的维护，并且会导致WinRunner的不可预测的错误产生（具体可以参考WinRunner 的Readme文档）。录制时，可以根据测试用例的流程，拆分为几个小流程，对每个小流程分别录制成不同的脚本。
1.1.2 gui文件要合并：
首先，要在系统参数中，设置gui的录制模式为“Global GUI Map File
录制过程中，WinRunner会自动产生gui文件，一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护，脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的，每个小流程录制时都会产生一个gui临时文件，因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意，开始新的录制前，一定要先手工加载测试用例的公用gui文件。
如果划分的子流程超过20个，则按每20个子流程录制一个gui文件的方式。Gui文件太大，会影响WinRunner的回放效率。
1.1.3 批调用回放验证：
为了提高脚本的正确性，每录制完成一个子流程后，都要恢复数据库，其他初始环境进行回放，以近早发现脚本错误。
单个测试用例脚本录制完成后，要专门写一个主脚本，进行各子脚本的主次调用处理，然后恢复数据库和其他初始环境进行回放，以验证整个脚本是否可以正确回放。
1.1.4 可移植回放验证：
由于WinRunner 工具的限制，在本机回放成功后，如果把脚本移植到其他机器上，往往无法成功。这其中既有自己编写的脚本问题，又有WinRunner录制自动生成的脚本问题。
自己编写脚本问题：往往是编写的可移植性较差，如加载gui文件时用的是绝对地址，如gui_load(“c:\\aa\\aa.gui”)，这样的脚本换到其他机器必然出错。
WinRunner录制自动生成的脚本问题： WinRunner的录制脚本往往和机器的环境有关，如果换了其他机器环境，往往回放不成功，这就需要手工修改脚本。
因此，可移植性回放是非常必要的。
1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。
1.1.6 录入中文数据时统一使用简体。
1.1.7 数据表列名称规定
录入数据驱动的脚本时，数据表列名称统一采用英文，使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释，使用PB数据窗口中列对象的中文标签，这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动脚本中For循环的第一个表达式改为table_Row = 2。
1.1.8 脚本成功回放判定规定
一个子测试录制完成后，一定要及时回放测试，直到测试报告显示测试结果为OK，且子测试明细报告中没有红色的出错提示。如果是回放主测试，回放成功的标准是：主测试的结果报告显示为OK，同时所有子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。
1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定，以保证脚本所描述的业务过程按业务逻辑在时间上有序。
因为脚本回放与脚本录制时的系统日期时间不一致，会导致与系统时间关系密切的测试脚本回放时失败。
为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。

1.2 测试脚本存放规范：
各子测试脚本必须放到同一目录下，即环境目录下的Script目录下。这样便于批调用时引用。
1.3 Gui文件的存放：
Gui 文件，必须和测试脚本放到同一目录下，即环境目录下的Script目录下。
1.4 WinRunner使用规范：
（1） 必须写上清楚的注释：编写测试脚本，要进行详细的标注，每测试一小段，就要写一段备注，以便于将来修改，格式可以参考如下：
   功能描述：描述脚本的功能
   前置条件：该脚本在满足什么条件下才可以被执行
   步骤描述：描述脚本录制的动作
   检查点描述：描述作了对什么的检查，检查条件。
   录入人：录制人
   录入时间：
   备注：
（2） gui文件的加载保存：
每次开始测试用例的录制脚本前，如果该测试用例已经存在gui文件，一定要手工打开gui文件，再开始录制。如果不想手工打开，可以写段自动加载gui的脚本，每次录制前运行一下该脚本。录入脚本后，要注意保存GUI文件，如果测试用例已经存在gui文件，一定要把临时的gui文件合并到该用例的公用gui文件中，然后保存。
（3） 如果机器数据较慢，或者网络较慢、或者数据库运行较慢，需要把等待打开窗口的时间设长。或者在脚本中插入同步点来处理。
（4） WinRunner不支持Fomular One，目前不可以用wr测试Fomular One
使用WinRunner录制时不可以切换不同输入法录制，仅可以用一种输入法。
（5） WinRunner 对shift 键无法纪录，需要特殊处理 ，可以加入如下处理
obj_type "dw_1.fslipbugno","<kShift_L>-";（告诉WinRunner按下Shift键）
中间是选择行的脚本
obj_type ("dw_1.FBugNo","<kShift_L>+";（告诉WinRunner释放Shift键）
（6） 保证录制的脚本干净性：
在录制过程中，不可避免的要进行其他动作，如打开邮件、打开非录制程序等，这些动作也会被WinRunner录制下来，这些动作会严重影响测试脚本的回放（除非作这些动作前停止录制）。
因此，为了保证脚本的干净，在WinRunner的参数中进行如下设置：设置Recode 的“Selected Applications” 为要录制的程序。
（7） 录制脚本时，不允许同时打开两个运行程序（指进行wr测试的程序）
（8） 变量的声明：WinRunner有auto \public \static \extern 四个类型的变量作用域声明，其中public为默认的类型。由于public 是全局的，只要在一个脚本中声明了，在任何其他脚本都可以引用，这就带来一个问题，如果其他的脚本修改了这个public 变量的值，将会引发问题。因此变量声明时必须明确的加上类型（auto \public \static \extern），public 的一般不要使用，推荐使用static \auto 。
2. 异常处理规范：
在录制或者编写测试脚本时，必须进行异常的错误处理。以提高程序的错误检查能力。
2.1 函数异常检测：
对于一些常用函数，必须进行函数执行异常的处理。至少进行如下函数的异常检测：et_window、win_activate、menu_select_item、ddt_open。
发现异常后，要终止程序的执行，并发邮件通知相关人员。
2.2 返回值规范：
模块、函数的返回值约定如下，0 表示成功 ，其他失败。
对于一些函数的返回值，需要进行判断处理：
（1） 每一个call语句都应该检查它的返回值是否为0, 如果不为0则报错退出。
所有GUI检查点、数据库检查点都应做返回值检查。如果不为0则报错退出。

摘要：软件测试所需要理解的基本常识。　查看全文

摘要：About SQL　查看全文

摘要：我的记忆里面从来就没爷爷、奶奶、外公、外婆的影子，呵呵，很想知道他们什么样子，很想知道他们在我不知所措的时候会告诉我些什么。。。　查看全文

摘要：第七章。。。　查看全文

摘要：以前看得，随便做的笔记，基本知识点！~　查看全文

摘要：Blue Foundation----As i moved on: Come and dance, come !~　查看全文

摘要：期望职位：软件开发工程师，软件测试工程师，实习生！　查看全文

摘要：N老的一个关于数据库连接池的实例，编译测试通过，这是一个初学的好例子！~　查看全文

摘要：在使用开发基于数据库的WEB程序时,传统模式下的开发可能导致内存泄露，系统开销相当大等问题，如果采用一个全局的Connection对象，则会导致连接的不稳定，因此，人们想到了预先建立一些连接放置于内存对象中以备使用的方法，即连接池技术。　查看全文

摘要：本文介绍如何使用 Microsoft SQL Server 2000 JDBC 驱动程序连接到 SQL Server 2000。　查看全文

终于考完了。

学生期间的最后一个寒假，珍惜！~

找工作，+U+U！

作者：林庆忠，1990年毕业于昆明工学院计算机软件专业，后又于1999年毕业在南京大学 完成软件工程专业硕士的学习，现供职于CNPC旗下的一个行业软件研发中心，因为在网上看了许多有经验的各路软件开发人员写的好帖，一时手痒兴起，也凑一篇壮壮声势。

 

假设你是一名软件专业毕业的本科学子，如何在工作中修炼成为一名有较高职业水准的程序员呢，本文试图总结作者从事15年软件开发工作的感想，希望对有志成为职业程序员的人有所帮助，并借此机会感谢原昆明工学院计算机系的和智玲老师和张怀宁老师，特别感谢我的硕士导师，南京大学计算机系的博导郑国梁教授。

注：本帖言辞尖刻，乃作者脾气秉性使然，如果你看着有气，就请多多见谅，放下别看了。

 

程序就是一系列按步骤进行的操作序列，它有好多种级别，比如最低级的微程序、次低级的汇编程序、高级的各种编程语言程序、最高级的脚本语言程序，也许我列的不对，但没关系，我要说的是不管是那个级别的程序，其本质都是操作的逻辑序列。大多数系统和应用程序都是建立在高级编程语言上的，比如C、C++、C＃、FORTRAN、BISIC、JAVA等等，就让我们只关注这一级的编程能力吧。因此如果一个程序员的逻辑能力不高，他永远都不能成为一名具有合格职业水准的程序员，我们在下面的讨论有关编程能力的方方面面，最终都是为了最大程度地提高和实现一名程序员的逻辑能力。

 

一、掌握基础知识：十六年寒窗的持续积累

从7岁读小学起，经过16年的学习，你从软件专业本科毕业后，必须完成以下几门专业课程的学习：计算机组成、操作系统原理、汇编语言、数据结构、编译原理、数据库原理、软件工程、结构性设计语言(PASCAL、C)、面向对象设计语言(C＋＋、C＃)、计算机网络等，你最好还懂一些算法分析、分布式系统、计算机图形学、形式逻辑、人工智能原理、软件设计模式、软件构架/框架等研究生的课程，16年来，你积累的除了知识，更重要的是形成最适合自己的学习方法和工作方法。这些是你具备程序员职业水准的基础能力，不要受什么计算机软件怪杰之类传奇的影响，那不过是小概率事件，而且这些怪杰们就算没有读过软件本科和研究生，也往往自学了大多数专业课程，很可能比在校学习的学生对这些课程的精髓部分理解的更好，还有他们的工作方法和思维方式是特别而高效的，但普遍性差，可以借鉴，不宜模仿。好，所以现在你只需要问问自己，那些课程和知识都学会并掌握了吗？如果是，那就准备好进行实践了。

 

二、在实践中提高：成为一名高水平的Coder

好了，你毕业了，在校功课都不错，也找了一个专业对口的工作，你想大展鸿图了，可是别急，你的翅膀还不够硬，不信我们说来看看。

通常，你在工作中都会用到某一种单位/公司固定的操作系统和编程语言开发环境，比如Windows、UNIX、LINUX等操作系统，又比如用VC、VB、PB、Delph、JAVA、Motif/XWindow、QT、OpenGL、OpenInventor等编程语言和开发环境，我们在后面把它们合称为开发环境。就在校学习的有关开发环境的知识而言，大概你距工作需要的差距是不小的，当某个操作系统和编程语言环境成为你的饭碗时，就不应也不能用通过课程/认证考试之类的眼光和要求来评价你的能力，即使你能考100分。你需要深入地学习该操作系统和编程语言环境的各类开发手册的所有内容，你会说大多数你都用不上，其实你既对又不对，对的是单从使用的角度而言，你确实用不上开发手册的大多数内容，比如庞大的VC开发类库和复杂的开发环境，你在实际工作中能用到的不到总数的1/10或1/5，不对的地方在于，你用到的部分不是孤立存在的，它们是整个体系中的一部分，只有对整个体系有了一个较完整的了解，才能得心应手、随心所欲地用好你用到的部分，你才算初步具备在这种开发环境下进行Coding的职业水准(还远不够程序员的职业水准呢)，而这只是刚开始。如何才能真正掌握一种开发环境的全面的知识呢，最原始的办法就是读开发指南/教程、参考手册，一般来讲，学习开发指南/教程时，你如果是一个认真的人，都会完成5/10~7/10左右内容的学习和练习，如果你想成为职业选手，就应该完成9/10以上内容的学习和练习。参考手册不同，大多数所谓的“程序员”们只是用到了才翻翻，这差的太远了，你应该象读开发指南/教程一样，每个环节都要读，比如VC，参考手册中的每个类，类的每个函数，都要读上几遍，它们往往是一小伙一小伙地纠缠在一起使用的，开始时读得你毫无头绪、心烦意乱，不要紧，还有一手呢，如果你开发环境安装的全面，它们往往都有开发商做的demo例子可看，你就进入另一个境界了，开始时你关注demo中的具体技术，后来你发现这些demo的程序写的都还算不错，结构简单但合理，如果你真的用心，就一定能发现一些个别的demo是极品，它所展现的程序逻辑结构是你设计不出来的，你现在有点更关心它的程序设计构架，甚于对你原始目的(某种相关的技术/技巧)的关注，这时的你，开始了从一名Coder向一名Programmer的转变，你会忍不住要看看开发商提供的源程序，比如.h和.cpp，通常你会找到include路径下所有的.h程序，你才知道，哇！好多好多东东在参考手册中都没提到，你要学的太多了，没时间顾及其它的业余爱好了，现在知道为什么程序员是年轻人的职业了吧，你要有足够多的时间才行，即使你的智商有160。如果你走到这一步，在你工作的团队中，已经是经常有人向你请教技术问题，经常有人请求你帮忙debug，你已是公认的“高手”了，别得意，因为你仍然是个Coder，为什么这么说呢，你想想，你已深入了解了这个开发环境中的各种技能，知道一名Coder如何用好这些东西，可是你能设计的出提供给Coder们用的东西吗？唔……，你想了想，可能还不太行。对了，就是这样，你还是一名小我境界的程序员呢，本质是个Coder，当然已是一名高水平的Coder了，然而你需要进一步登堂入室才能成为一名真正的程序员。

让我们继续吧，通常你都是从精通一种编程环境开始的，假设你已经较为精通在Windows下用VC开发软件了，这时在技术和技巧方面你将面临一小一大两个挑战，第一个小挑战是如果公司/单位改换了开发环境，比如用LINUX下的QT交互语言工具进行开发，你不过是把前面掌握VC的过程再来一遍，由于在主观上经历了VC工具的学习过程，在客观上各种开发环境都有太多相似的方面，这回你掌握的应该较快。要小心，在这时第一次诱惑之门打开了，因为你感觉良好，看！这回这么快，我就这么好地掌握了新的开发环境，你开始关注其它暂时还用不到的同类环境，比如VB、Delph、JAVA，如饥似渴地掌握各种开发工具，证明自己的学习能力和价值，但你忘了一点，你仍然是个Coder，只不过是一个在好多开发环境下都能编程的Coder，就像你生活在中国，因而精通了汉语，工作需要你又掌握了英语，然后你就来了劲，把俄语、日语、阿拉伯语、拉丁语，等等等等，都学习个遍，我只能说，有点BT。你忘了自己是个职业人，同一类的东西工作中用得到才需学习，太多太多的Coder们喜欢在一起比较和炫耀自己会掌握了几种开发工具，不信你看看招聘时的求职书就知道了，sigh！他们中绝大多数人永远都只能停留在这个层次上，心浮气躁，一生都再也当不成真正的程序员了。总结一下，其实你在这时需要的是对自己掌握新开发环境的能力的自信，而不是一遍遍地重复来证明自己。第二个大挑战就是你明白了只掌握VC是不够的，你发现自己有点浅薄，有很多东东你会用但你不太懂，很多方面支持VC编程的知识你都没掌握，比如操作系统的源码、网络协议知识、Windows 的注册表、进程和线程的基础知识、硬件驱动方面的知识、ActiveX、Windows 庞大的 API，又是一个等等等等，这些基础知识的学习和掌握可是要花费大量时间的，你再一次深切地感到时间太不够用了，因为这时的你大概有许多俗务缠身了，所以有点沮丧，还不用提IT业每天不知有多少新东西在发布，KAO，永远都跟不上，越拉越远了。哎！别气馁，振作一点，你还是忘记了自己是个职业人，既然好多东东在工作中你永远都没机会用，那么干嘛要学呢？用什么才学什么，最多预测到马上要用什么，先一步学什么好了，要知道没有人是真正的、无所不精的全科大夫，除非你是神，但如果你还在耐着性子看这篇文章，你肯定是个人嘛。

OK，一般工作后三五年，你经历了上述过程，经受了诱惑和考验，终于明白了一个道理：你要的是强劲的学习知识的能力，是对某种软件知识/技能的有深度的精通，一种摸到它的根的深度，而不是已掌握的技能的种类和数量。这时无论谁用他掌握了多少种你不会的技能来吓唬你都没用，你对他的层次只有蔑视。通过几年的学习和工作，要记住最重要的一点，永远最重要：对自己学习IT知识能力的自信，一个程序员一生都要不停地进行高强度的学习，用心问问自己，有没有这个自信？别用虚荣心来骗自己哦，如果没有的话，那就不必花费你宝贵的时间向下看了，作者在此感谢你有耐心看到这里，现在建议你关闭这篇文章，趁着年轻，当机立断转行吧！

三、注重逻辑：成为一名职业程序员

好，再前进一点点，你就要成为一名职业程序员了，让我们继续来完成这个任务吧！我们在前一节提到过，“你发现一些个别的demo是极品，它所展现的程序逻辑结构是你设计不出来的，你现在有点更关心它的程序设计构架，甚于对你原始目的(某种相关的技术/技巧)的关注”，其实你是在关注这个demo程序作者的思维逻辑，所有程序的本质就是逻辑。技术你已经较好地掌握了，但只有完成逻辑能力的提高，你才能成为一名职业程序员。打一个比方吧，你会十八般武艺，刀枪棍棒都很精通，但就是力气不够，所以永远都上不了战场，这个力气对程序员而言就是逻辑能力(其本质是一个人的数学修养，注意，不是数学知识)。逻辑能力也是逐步提高的，开始时你一定是用直观的逻辑能力来编程的，怎么想就怎么编，不对就再改，在改进中提高自己的逻辑能力，从直观逻辑能力提高到抽象逻辑能力，这是很正常的。提前说一句吧，到达逻辑能力的至高境界，其表现是用数学语言来描述问题和问题的解决办法，高度抽象！好，说回来吧，你要提高逻辑能力，最快的办法就是读别人写的结构优秀的程序。优秀的代码是百读不厌的(这句话是我抄来的)，暂时放放对其中某种技术和技巧的关注吧，你要推导和学习的是这些好程序的逻辑结构，它们是被精心设计出来的。你可以先捂住这个demo程序，自己设计一个功能相同的程序结构，然后比较一下demo的程序结构，如果差距较大，那你就不应简单地改进一下，而是要把demo作者设计的过程在心里复原一遍，做到这一点也许有点困难，但这种事干的多了，你就会越干越快，越来越得心应手，你的逻辑能力飞速提升，你能看得上的逻辑结构优秀的程序开始不多了，下一步就是练习。从工作中开始吧，如果你有空闲，你需要做至少两类练习，一类是算法练习，所有的经典算法都是经典的逻辑，题目有的是，像个好学生一样吧，每年的国内国际编程竞赛都有逻辑要求非常高的题，你可以只选一两道难题来做做。当你可以把复杂的单递归程序(只有A调A)变成非递归程序时，已经不错了，如果你能看得懂双递归程序(A调A、A调B、B调A、B调B都有)，我为你鼓掌！你不必往下看了，我有点不好意思啦――班门弄斧，你快滚蛋吧！另一类是把以前和当前你工作中你不满意的程序推倒重新设计一遍，这非常重要，省时省力，因为你熟悉需求，技术上也没问题，目的就是改进程序的逻辑结构，很划算哦，唯一要克服的就是：你对推翻以前工作中那点小小成就的心理障碍，如果你真想优秀，说句粗话：这点心理障碍算个屁，一遍遍反复地推倒已有的成果只能使自己快速进步，放手干吧，没什么好可惜的，马恩早就在《共.产.党宣言》里说过了：在这个过程中，你失去的只有锁链(禁锢你思想的锁链)。

让我们来总结一下，经过自我否定后，再生的你尽管对过去的“业绩”还有一些眷恋，但已是一个初步具备职业水准的程序员了，掌握了相应的技术和技巧，具备了较高的抽象逻辑思维能力，最主要的特征是：能自觉地自我否定，不断地追求更高水平的逻辑能力。

在这个过程中，如果你能注意以下一些小的方面，你前进的步伐也许会快一些。

l         从编译原理的角度来理解你工作中使用的高级语言，如果你做到这一点，至少有两个好处，第一个好处是避免一大堆低水平重复出现的编译错误。一名优秀的Coder平均在一个工作日中应该完成200行以上的源码，其编译错误应该控制在5个以下，要知道这200行源码不是一次完成的，所以大多数情况下你都要追求一次编译通过，而一名职业水准的程序员，应该进一步做到即使用purify这类的工具来检查源码，也不会存在严重的内存泄露。第二个好处是可以提高源码的可读性和效率。规范地编写你的代码使你自己的逻辑清晰，因为你明白多加几个括号和空行、多换行对齐、多注释，编译器是会自动识别的，不影响程序执行的效率，反过来，控制好递归调用和循环内的if语句才是提高程序效率的关键，要全力避免递归，但要深刻理解递归，能通过自己建立堆栈来把递归程序转换成非递归程序，要求还是较高的哦！

l         避免思维陷阱，只要你是人就一定有自己的思维惯性，这一定又会表现在你的程序逻辑中，有时你就是从这个惯性中跳不出来(谁都有这个时候)，但要心里有数才行，所以你需要帮助，如果你有几个水平相若或更高的职业伙伴，太好了，当遇到花30分钟还打不下的bug时，就别浪费时间了，找他们吧，最要紧的是能思路清晰明确地表述你的问题，通常你自己在这个过程中或者伙伴中就有人把问题解决了，又快又好。另外，有几个可以良性竞争的职业伙伴是人生的一件幸事，1+1>2，大家各有所长，你最好做到及时公开你的成果，技不压身嘛，IT发展的这么快，你再优秀，那点东东也没有什么值得隐藏的，所以你可以技术或水平不够高，但千万不可以让真正具有职业水准的选手鄙视你的职业品质和行为。

l         有自己debug的特点，下面的说法作者不敢太肯定，只是经验之谈。即使在VC这种高度完善的开放环境下，你仍然应该要求自己仅凭打印语句就能debug。这也有两点好处，第一个好处是，遇到bug你会认真想问题所在，而不是用debug工具一步步简单地追踪卡在哪儿了，你定位bug范围的方式是从大到小、从粗到精，这是一种自顶向下的思维方式，而用工具追踪，容易形成自底向上的思维方式，这不算好，你应该先看到森林，再看到树木。我反复提及：程序就是逻辑过程，大多数程序从main函数开始，是由数据结构和功能子程序组成的一个树形结构的逻辑过程(要认清即使是面向对象的程序语言也是一样的)，它的执行过程是深度优先的，但你定位bug应该是广度优先的，好好想想这一点，嗯？第二个好处是强迫你思考并记住而不是用工具看到调用过程，你大脑的抽象逻辑思维能力和胳膊上肌肉的力量一样，都是练出来的，如果你的bug是程序结构上的逻辑错误引起的，这一点就非常重要了，顺便说一句，最难打的bug就是程序逻辑结构错误导致的bug。你要是真正明明白白地认识到这儿了，那我就没什么东西可以告诉你了。总之，程序员的职业水准：生产效率和程序质量，主要是取决于源码中bug的数量和debug的速度，而不是取决于编写源码的速度。给你一个我自己定义的考查一个职业程序员的指标：一个合格水准的职业程序员，编程的时间如果算一份的话，其累计debug的时间不能超过一份，真正职业高手累计debug的时间应该控制在0.5份以下，如何？你关上门悄悄问问自己，你花费在编程和debug上的时间比例是多少？如果你把程序员作为自己一生的职业，那么就永远都要牢记一点：追求做一个0 bug的优秀程序员！这是任何一个想成为职业程序员的人的理想，请相信：坚忍不拔地追求实现这个理想将让你出类拔萃！

l         做好程序的单元测试，这是另一项考查你是否是一名具有合格职业水准的程序员的一个必要指标。其实在你拿到需求的时候就要准备单元测试用例了，并且这些用例将直接影响你的详细设计(有关软件设计本来是该放在第四节讲的)。我们还是打比方吧，当你拿到一个需求时，除了分析它静态的功能外，还应明确它动态的操作/执行过程，把这个动态过程明确地用流程图画出来，比如分为A～Z的26步，其中A又可以进一步分解为A1～A5的5步，直到不能再分解为止。又比如说A3步不可分解了，那么你应该把A3步的正常操作和所有五花八门的异常操作都列出来，确保正常的操作肯定正确，异常的操作起码程序不退出才行。这样你就要写好多好多的测试用例，说句老实话，我也从来不写！但我一般会列一个提纲，比如A3步有正常的操作a、b、c、d、e共5项，异常的操作有f、g、h、i、j、k、l、m、n共9项，你在进行单元测试时都应该跑一遍，这样的程序都还不敢说质量如何好，但起码可以说较稳定吧！如果要想在进行单元测试时干得快、效率高，那么在进行详细设计时，你就应该把A3步中对所有正常操作和异常操作的判断都设计好，在编程实现A3步时，使得程序的结构合理高效，对不对？所以，如果你在工作中是割裂地看待软件工程中从需求、分析、设计、编程、测试等各个环节，恐怕水平很有限喔！但如果你在分析需求时就能看到测试的问题，并改进设计和实现，为此做好相应的准备工作，嘿嘿，整个软件开发过程你的效率会高很多，通常你在一个开发团队中就会高度自信的，你已越过当一名偏颇、露骨的高手的境界，成为一个平静的高手，这可是The best in the best！，用周星星的话说：是高手之高高手，因为别人看不出你高在哪儿，没见你有什么高招或特拚命干，但反正你就是干得又快又好、又省力。关于进行单元测试还有很多复杂的方法，在此本文只提到了最基本的一点，目的是让你在工作上考虑周全、安排有序，其它的自己琢磨吧，没有人能替你吃饱饭！

l         如果你是用C＋＋编程，我再简单谈谈有关内层释放的一个小技巧，就是对所有你编写的类，在构造和析构函数中加打印语句，统计每个类在运行程序时构造和析构的地方，如果是配对的，那么起码没有对象类一级的内层在程序运行结束时没有释放，然后你就可以把打印语句删掉了，招数虽土，但管用！

l         还有其它一些好习惯，在这里我随笔写一些，你要是有不同看法也请一笑过之吧。编程时应该对齐缩进，一个缩进用一个tab键，一般是4个空格，严格遵守开发团队的编程规范也是非常重要的。一个子程序不应超过30行(不算空行)，其内多重循环不应超过3层，否则都应该分裂成两个子程序，个别算法程序可以长一些，但也不宜超过200行。通常一个类的所有成员函数总和不宜超过1500行，多了就应该考虑分解成两个类(这个工作最好在设计时就完成)。每完成一小段程序，比如15～30行，就立即编译运行，不要假装高手，先敲它一大堆程序，再编译运行，妄想一次成功，体验一种假爽的、虚荣的快感，或炫耀给别人看，这么做只能证明自己是一个不折不扣的傻瓜，装酷而已。因为只要有一次不成功，你就会花费大量的时间来调程序，别人的进度在这时就远远地超过你了，平常心是道，还是修炼真功夫吧！孙子兵法里关于这一点有明确的阐述，我就不引用了，但建议你真的不要这么干，除非你确实就是这样总是一次就成功的天才，那你还看这篇文章干什么呢？我又不是写给你们这些天才们看的。再就是有学会买好书、读好书，关于计算机和软件方面的书太多了，时间有限，比如有一个叫侯捷的家伙，几乎写的每本书都不错，张国峰的C＋＋编程也不错，这只是我的个人意见啊，好书多着呢，列出来比这篇文章长好多倍，我就不多说了。还有一招，要是你运气好，能搞到一些著名软件系统的源码，好好读读吧，在此我只能告诉你，Linux操作系统的一些源码不错，是开放的，你可以合法地搞到，其它的不要说是我建议你侵犯知识版权啊！

四、天生神力：成为系统分析员

本来就论述如何成为一名职业程序员而言，本文已基本完成任务了，但《菜根谭》有言：竭世机枢，似一滴投于巨壑，穷诸玄辩，若一毫置于太虚。既已乘兴到此，何妨多置一毫于太虚呢，作者不才，干脆尽兴写算了。

你要是运气好，直接进入了一个严格规范生产的软件企业就业，刚开始就应该是按别人做好的软件设计来实现编程，你可以有机会直接学习软件设计，当你积累的足够多了，能够对其中的一些设计提出好的改进建议，而且干得又快又好，就会渐渐地展露头角，我相信你终有一天成为一名软件设计人员(注意，不是软件产品设计人员)，步入系统分析员的行列，但这还需其它的一些条件和自我修炼。如果你在一个不规范的软件企业工作，那也不错，你很可能直接就有机会进行软件设计，然后开发、测试，甚至还不得不自己定义需求，把软件开发过程的各个环节走一个遍，当然这样对你的要求更高，而且你也不容易得到及时有益的指点，在正态分布的情况下，你应该是成长的很慢。但不管就业的单位如何，如果你决心要成为顶尖软件职业选手，通常什么客观困难都阻挡不了你，然而你个人的因素可能会阻止你的前进。下面提出的观点纯属一己之见，伤人自尊之处作者在此提前道歉，并建议你除非对本文有强烈的兴趣，否则就请直接看第五节或放下别看了。丑话已说在前头了，在各种软件开发组织的发展过程中的事实也证明，只有少数程序员能成为系统分析员，我想这一点不是我杜撰的吧，因此你要是在看接下来的部分时感到气愤难当，那也实在没着，纯属活该，因为作者只是在说明自己的观点而已，你最多可以呲之以鼻，表示一下你的轻蔑好了，但没有任何理由可以骂人！

作者自己没有到微软面试过，但身处软件行业，关于微软的许多东东当然还是有耳闻的，据说微软招聘一名程序员要过五个已经成为微软程序员的面试关，而且是一票否决制，又据说大多数面试题并非编程，而是一些有关逻辑和智力的题，作者私下也做过许多流传的微软面试题，并对此做法深以为然。程序的本质就是逻辑，所以几十年前就有人提出编程是一门艺术，而艺术是要靠天份的，这一点少有人反对。一个人的逻辑能力可以不断提高，但其能到达的终极逻辑能力的层次必定为其天生智力所限制，这一点就让人不易接受了。好笑啊！人们可以公开承认自己没有某种或全部的艺术天份，但要说自己逻辑天份不够，换句话说承认自己笨、IQ不够高，往往是要怒发冲冠的，其实这又有什么区别呢？话都说到这儿了，再次建议你如果不够自信，就跳过这一节吧，直接看第五节，好吗？

好了，把话题说回来，你已经成为一门合格的职业程序员了，如果要想成为从事软件系统设计的职业系统分析员，第一件事就是悄悄找一个标准智商测试的网站或其它渠道，严格认真的测一测自己的智商，如果IQ低于130 (正常智商是110)，就请别费劲了，打消掉成为系统分析员的念头吧！好！好！先请你冷静一下，好好想想，其实微软面试时就是在测你的智商和逻辑数学素质呢，这就是本节的标题为“天生神力”的原因，因为设计就是从无到有地进行创造，无论是软件还是其它行业都一样，可以有借鉴的，没有现成的，设计就是创造！如果你IQ在130以上，又决心要当一名职业软件系统分析员，其实你不过是要准备好吃更大的苦而已，有什么好虚荣的呢？

修炼还是从基本功开始的，过程和成为一名职业程序员差不多。必须使用设计工具这一点是不用多说的。在工作中，你基本上遇到的是两类方式的设计，一个是结构化设计，另一个是面向对象设计，就个人经验而言，面向对象的设计更好。如果你工作中不得不采用结构化的设计，你必须熟练地掌握数据流图和控制流图的分析和设计，一般来讲，如果你把一个软件中用到的数据模型设计好了，针对功能化的流程，不难设计出数据流图，但下一步设计控制流图才是挑战，如果你按照需求走不通设计好的控制流图，那么你或别人在按照这个设计编程实现时，必定也走不通，没有奇迹会发生，还是在设计阶段严格要求吧，又有一点需要牢记：返工是最慢的。当你在进行控制流图的设计时，也不要妄想得到需求人员提供给你明确的指点，通常他们要是能够把需求的功能和操作次序写完整的话，你应该就感恩戴德了，从需求中整理出功能、操作的拓扑次序和条件是你作为系统分析员的职责。看看，要是没有一点图论的基础和拓扑学的入门知识，你是当不好一个职业系统分析员的，即使你天赋不错，必要的数学和逻辑素质仍然不可或缺。也不用气馁，永远没有最好的设计，只有更好的设计，反复地进行设计迭代，勇于推翻旧的设计，你将快速进步。如果你在工作中是采用面向对象进行设计的，那就更有利了，有关面向对象设计的书太多了，不用作者在此多费口舌，建议精读一本经典的书，比如北大邵维忠等编译的《面向对象的分析》，有些方法和技巧可能过时，但其逻辑的基本原理是非常正确的，其本质是，你在逻辑上是如何认识这个世界的，你就是如何设计软件体系结构的，然后读读其它书，触类旁通，自己创造机会多实践，成功自然会到来的，总之，不管是结构化设计还是面向对象设计，评价一下自己的软件系统设计方案吧，有好多指标呢，比如是否均匀和平衡？局部独立性强不强？有没有歧异的结构？有没有层次太多或太少？有没有某个层次太大、太广？是不是逻辑结构先复杂了再化简的？还是只会设计简单的，复杂不起来(这一点是笨哦，如果出现多次，请你不要意气用事，转行吧)？最重要的一点，是否容易理解、实现和改进？你自己会得出评价的。如果有机会看到别人的设计，一定不要错过学习的机会，自己推导一遍，认真比较比较，获益会较多。

走到这一步，你就应该关注设计模式了，首先还是学习，这方面的好书有的是，但一般在工作中用到的设计模式较为单一，应该多尝试一下其它的设计模式。其次必须要明白设计模式不是设计思路，也不能代替设计思路，比方你要从A到B修一条路，设计模式只是让你选择，是修水泥的还是柏油的？是高架路还是普通的，但线路必须你自己定，而线路就是设计思路，模式对思路是有影响，但不能代替，所以如果你的智商高达250，我相信你直接用汇编语言也能写出面向对象的程序来。第三在此有一个陷阱，很多系统分析员生搬硬套设计模式，全然不懂如何融会贯通，在你的一项具体工作中，往往是以一种设计模式为主，其它模式为辅的，思维不拘泥于形式才是关键，而且也为你到达更高的软件设计的境界做好准备。

唉！都不知该怎么向下写好了，因为已达到作者水平的极限了，我胡乱说一点，你凑合看吧。软件设计最终的层次是：以无法为有法、以无限为有限，这句话是李小龙说的，不是我说的。再拾人牙慧一把，类比一个故事吧，金大侠在《倚天屠龙记》里讲到张无忌初学太极，学会的标志是把刚学的招数全忘了，记住的是太极的道理和精神，和李小龙有些相似喔，软件设计也一样，忘记所有的设计模式，随心所欲进行设计才是至高境界，所以你能到达多高的软件设计的境界最终将取决于你的哲学素质，这一点实在是不好写啊，你自己领悟吧！作者只有祝福了！

五、职业人的终极目标：全面修炼，成为Leader

这一节更不好写，涉及到太多其它非技术方面的因素，特别是个人人生观和世界观的修炼，如果本帖的点击率超过作者私下期望的一个数值，那我就争取尽力厚着脸皮再补上吧。我只说一句，虽然大家都知道软件开发是一个团队性的工作，但追求参与一个大型软件系统的成功开发，是一名软件人员的本能，就像拿破仑说的不想当元帅的士兵不是好士兵，所以不追求实现大系统的软件人员，也不是一个好的职业软件人员，但你只有成为Leader，领导一个优秀的软件开发团队，才有机会实现这个终极职业目标，对不对？

好吧，不管你现在的感受如何，我都谢谢你能读到这里！我不习惯假歉虚，就不说什么作者水平有限，本文抛砖引玉，欢迎大家批评斧正之类的客套话了，虽然作者水平确实有限。所以我认为你尽管有权砸砖，但实在没必要搞回帖、或回骂、或顶之类的玩意儿，我只是尽兴写一点多年从事软件开发工作的体验，因此接下来我就高挂免战牌，不回复任何回帖了。再次谢谢你能有耐心读到这里！希望本文对你有所裨益，祝你成功！再见！

虽然大概一两年前我还在夸夸其谈桌面应用程序是将来的潮流，大学生们现在还是偶尔向我请教职业发展的问题。所以我把我的建议写下来。以供学生们阅读，嘲笑，忽略。

大多数锐气十足的学生从来不向前辈征求意见。在计算机科学领域，这样做是正确的。因为前辈们很可能说些“在2010年前，市场对于那些只会敲击键盘的代码工人的需求将会超过一亿（因此前景是乐观的）”，或者诸如“Lisp语言现在真的很热门”。

我和那些前辈也差不多，当我给别人建议时，实际上我不知道自己在说些什么。我是如此的落后于时尚，以至于连AIM也搞不明白，而不得不使用 email（恐龙时代的产品，在那个时代，音乐是刻在扁扁的的圆圆的盒子上，噢，那种盒子叫cd）。（译者按：我认为祖儿这里在说反话，后文很多地方作者都在说反话，读者尽量理解这种美国式幽默吧。）

所以你最好不要理睬我将要说的，你应该立刻去制作某种在线交友软件。

然而，

如果你喜欢编程，那就感谢上帝吧:你属于幸运的少数人，这些人喜欢工作，他们的工作可以保证他们能过上舒适的生活。大多数人没有这么幸运。对大多数人来说，工作是不愉快的，忍受工作的目的攒钱，是为了在年满65岁退休后能过上自己想过的生活。如果他们想过的生活不需要灵活的膝盖，明亮的眼镜，轻盈的脚步的话。

现在让我回到主题，我将提供一些建议。

好了，不罗嗦了，下面就是Joel给计算机系学生们七条免费的建议:

毕业前学会写作
毕业前学会C语言
毕业前学习微观经济学（microeconomics）
不要因为某些非计算机课程枯燥无趣就敬而远之
学习有大量编程实践的课程
不要担心工作都跑到印度去了
好好做夏季毕业实习
让我逐条解释这些建议。但解释之前我要说明一下，如果因为这些建议是Joel的建议你就打算无条件地接受，以至于连我的理由都想跳过，那么你就太单纯，太容易被别人骗了。如果你是那种单纯的人，我还要给你第八条建议，找心理医生咨询一下如何培养自信（self-esteem）。

毕业前学会写作

如果Linus Torvalds不懂如何布道的话，Linux会成功吗？ 正象每一个黑客，Linus精通写作，他知道如何准确地在email和邮件讨论组中使用书面英语表达自己的思想，所以他能够从全世界召集大量志愿者为Linux工作。

你听说过最近风靡全世界的极限编程（Extreme Programming）吗？ 即使你不懂什么是极限编程，你至少听说过这个词。为什么？因为宣传极限编程的人都是天才的作者和演说家。

就看看你身边的那些小型的软件开发组织吧，最有权力和影响力的人是那些可以用自信，准确，舒适的英语交流的人。好吧，我承认这些人也许言过其实，但是你无可奈何。

一个合格的程序员和一个伟大的程序员的区别不在于知道多少种编程语言，不在于他们是喜欢Python或者Java，而是在于他们是否擅长表达。他们能够说服，所以他们获得权力。他们能够写清楚明白的评论和接口文档，所以他们使得别人不用重写，而可以重用他们的代码，否则他们的代码就是毫无用处的。他们也能够写出清晰的用户手册，于是最终用户可以理解他们的代码是做什么用的，明白了他们的工作的价值。sourceforge埋葬着许多精美的代码，这些已死的代码无人使用，因为代码的作者很少写（或者根本不写）用户手册。

我不会雇佣一个不懂写作的程序员。如果你擅长写，你就很容易找到工作，紧接着你就会被要求写技术规格文档，这意味着你已经被管理层注意到了。

大学里有一些课程，要求你做很多的写作练习，不要犹豫，赶快参加这些课程。不要错过任何要求你每周或者每天练习写作的课程。

给自己建立一个网络日志（weblog）。在上面写的越多，你会写地越容易。写地越容易，你就写地越多，这是一个正向地循环激励。

毕业前学会C语言
我可没有说是C++。虽然现在用C的工作不多，但是掌握各种编程语言的程序员事实上用C来交流（lingua franca）；更重要的是，C比某些“现代”语言更接近机器语言。我不管现在大学里在教什么流行的垃圾语言（trendy junk），你至少得花一个学期接近机器。否则，你不可能使用高级语言写出高效的代码。这意味这你不会有机会写编译器或者操作系统，也许这是更好的编程工作；别人不会相信你能够为大项目设计架构。无论你知道多少高级的控制结构，知道如何进行错误处理，如果你不能解释为什么while （*s++ = *t++）;的意思是进行字符串拷贝（而且对你而言这是世界上最自然，最易懂的代码），那么你就是在对编程一窍不通的状态下编程（programming based on superstition）。打个比方，就好比一个医生不懂基本的解剖学就给你开处方，如果你问这个医生为什么开这种药而不是那种药，他会说因为医药销售代表说这种药有用。

毕业前学习微观经济学（microeconomics）

我个人对经济学的一些理解：在经济学刚诞生的时候，它只是局限于有限的领域，在这些领域中人们发展和发现了很多有用的理论和很有趣的事实，这些理论和事实是从逻辑上是可以证明的。然后， 经济学开始走下坡路了。 “有限的领域”就是微观经济学，它对于商业可以进行有意义的指导。然后，事情就开始变糟了（以下部分你可以跳过），你接下来碰到的是讨论诸如失业率和银行利率之间关系之类东东的宏观经济学，很多时候宏观经济学讨论的理论都是无法证明正确或者错误的。接下来事态更加恶化了，经济学中的一些领域开始和物理学搭界，嗯，学习物理经济学也许你帮你在华尔街找到好工作。言归正传，无论如何请学习微观经济学，因为你需要知道什么是“供给和需求”，什么是竞争优势，什么是净现值（NPVs，Net Present Value，指项目经济寿命期内现金流入总和与现金流出总和之差额），什么是折扣和边际效用（discounting and marginal utility），如果你真想了解商业是如何运作的话。

为什么计算机系的学生要学习经济学？因为理解商业基本规律的程序员对商业界来说是宝贵的程序员。我记得无数个程序员使我非常沮丧，因为他们在代码中坚持某些疯狂的设计，这些设计从技术上来说，完美；从资本主义的角度来看，发疯。如果你是一个理解商业的程序员，商业会给你回报。这就是你要学习经济学的原因。

不要因为某些非计算机课程枯燥无趣就敬而远之

首先，你需要让你的学分平均分（GPA）看起来漂亮点。

不要低估学分平均分的威力。很多雇主和人事经理（包括我）阅读简历时首先看成绩，为什么？因为这代表了大部分的教授在很长的时期内对你的学业的一个平均的看法。托福成绩（美国的托福大致相对于我国的高考中的语文考试）？哈，几个小时的测验而已。当然学分不一定说明了一切，如果你修的是很难的课程，学分就有可能低一点。即使你的学分平均分很高，我还是要看各科分数是否一致。如果你应聘的是软件工程师职位，我为什么要关心你在大学里学的欧洲历史课程分数的高低呢？毕竟，历史很枯燥。那么要是你要编程的部分也是很枯燥的，你是不是要放弃了？事实上，有时候编程是枯燥的，如果你不能忍受编程中的枯燥部分的话，你就不能完成整个工作，雇主不愿意雇佣你这样的员工。

我在大学里修过一门叫做“文化人类学”的课程，因为那时候我也搞不懂我到底要学什么，听起来这么课程可能还蛮有意思的。

出乎我的意料。我不得不阅读大量讲述巴西热带雨林中的印第安人如何如何的书，让人真昏昏欲睡。听老师讲解也好不到哪去，我发觉看教室外的草如何长更有趣点。土著人如何烤蕃薯藤和我有什么关系？我为什么要去讨论如何烤蕃薯藤？但是期中考试马上就要到了，我暗暗下定决心，如果我能跨越“文化人类学”这个障碍，以后也许没有什么能难倒我了。我决心得A并且得到了A。以后当我不得不坐在林肯中心，连看18个小时的瓦格纳的《尼伯龙根的指环》时，我终于明白我为什么要学习“文化人类学”了，相比之下，我也能忍受这种歌剧了。

学习有大量编程实践的课程

我还记得决定不去读研究生的那一刻。

就是在学习《动态逻辑》（Dynamic Logic）这门课的时候，我记得是耶鲁的Lenore Zuck（一个天才的教师）教的。

修这门课的时候，我已经不再是雄心勃勃了。我可不指望在这么课程中得个A，我梦想的是混个及格。逻辑本质上是很简单的：如果结论正确，前提必须正确。例如，如果“所有读书好的人都能找到工作”并且“张三的读书好”，那么“张三能够找到好工作”。就这么简单。

但是我要学的是动态逻辑， 动态逻辑和一般逻辑差不多，但是要考虑时间因素。例如，“在你开灯之后，你可以看见你的鞋子”加上“过去灯被打开了”意味着“你现在可以看到你的鞋子”

动态逻辑学对于象Zuck教授这样的天才理论家来说非常诱人，因为这门学科的知识也许可以用来证明计算机程序是否正确。我记得在第一堂课上，为了证明“如果你有一盏关着的灯”并且“你按了一下开关”，那么“现在灯亮了”，Zuck教授就使用了两黑板加上边上的墙壁。

证明过程难以置信的复杂。我觉得如此复杂的证明过程很可能会有小错误，但是我没办法证明证明过程本身是正确的。事实上，写在黑板上的证明跳过了很多中间步骤，许多步的证明使用了演绎法，使用了归纳法，以及一些研究生才懂的证明方法。

作为课后作业，我们需要证明以下命题：如果灯过去是关着的，并且现在它是开着的，请证明有人按了开关

我真的试着证明它了。

我花了许多小时，试图证明这个命题。

在无数个小时的努力后，我发觉Zuck博士的原始的证明有一个逻辑上的错误，也许这个错误是我的笔记抄错了，我不知道。于是我终于认识到，如果为了证明一个简单的问题需要花三个小时写下几黑板的证明步骤，再考虑到这个漫长的证明过程中可能会引入种种错误，那么这种机制是不可能用来证明任何有趣的东西的。

对动态逻辑学家来说，有用是无关紧要的。

于是我退出了那门课程，发誓永远不会去读计算机系的研究生。

这个故事的主题是，计算机科学和软件开发不一样。如果你非常非常幸运，你的学校会开软件开发的课程。然而，他们也可能不开这样的课程，因为名牌大学认为教授实用技巧的事情应该留给那些二三流的技术学院或者某些释放犯人再安置计划。你可以在任何地方学习编程，我们是耶鲁大学，我们培养未来的世界领导人。你付给耶鲁16万美元的学费就是为了学习如何写循环语句吗？你把耶鲁当成什么地方了？Java速成班吗？哼。

问题在于，我们没有一个专业的学校教授软件开发。所以如果你想成为一个程序员，你可以进计算机系读书（当然计算机科学也值得学习），但是你学的不是软件开发。

如果走运的话，你可以在计算机系发掘出很多有大量编程实践的课程，就象你能在历史系找到很多提供写作水平的课程一样。这些课程绝对值得学习。如果你喜欢编程，不要为你不能上教授诸如lambda算子或者线性代数的课程沮丧，在那里你连摸一下计算机的机会都没有。找找看有没有名字中带有“实习（Practicum）”字样的课程，不要在乎Practicum是个拉丁语。有用的（无奈状）课程就是需要在课程名中塞一些拉丁语，才能从那些装模作样（Liberal Artsy Fartsy）管理层的眼前蒙混过关。

不要担心工作都跑到印度去了

啊哈，如果你人在印度，你就无所谓了。愿你享受外包带来的工作机会并顺祝身体健康。

但是我听说现在愿意读计算机系的学生越来越少了。据说原因之一是工作机会都跑到印度去了。我认为这种观点是大错特错。首先，根据眼前的商业时尚选择事业是非常愚蠢的。其次，即使工作真的都跑到印度和中国去了，编程对于其他有趣的工作来说都是极好的训练，例如业务流程工程（business process engineering）。第三，无论是在美国还是印度，好程序员仍然是非常短缺的，请相信我。当然，现在有许多所谓搞IT的人吵吵嚷嚷地说就业形势不好，工作太难找。但是事实如何？恕我直言，好程序员找工作还是很容易。第四，你还有更好的主意吗？历史系的毕业生找工作更容易吗？去法学院如何？据我所知，99％的律师恨他们的工作，每分钟都恨。而且律师一周工作90小时。正象我以前说过的，如果你喜欢计算机，那么感谢上帝，你将属于全世界人中的极少数的幸运儿，这些幸运儿热爱他们的工作，而且工作也可以提供体面的收入。

实际上，我也不认为报考计算机系的人越来越少有多大的意义。相对于internet泡沫时期大家都疯狂的往计算机系挤，现在的人数回落只是回归正常水平而已。在泡沫时期，我们这个行业涌入了许多对计算机毫无兴趣的南郭先生，他们梦想的是拿着高的吓人的薪水加诱人的期权，然后年轻退休。谢天谢地，现在这些人都跑了。

好好做夏季毕业实习

明智的招聘者知道热爱编程的人初中就为当地的牙医写数据库程序，高中就在计算机夏令营教课，为校报规划网站，在某个软件公司做实习。他们找的就是这样的人。

如果你喜欢编程，你最容易犯的最大的错误就是“有活就接”。我知道，其他专业的学生假期打工可顾不了这些条条框框。但是你不一样，你拥有一种特殊技能，不要浪费它。当你毕业时，你的简历上应该已经罗列一堆的编程工作实习。让其他人去“为大家提供租车服务”（Tom Welling是个例外，他业余时间去演超人）。

最后，为了让你的生活更容易一点，也为了说明我这篇文章是能够自圆其说的，我将给我自己的公司的做做广告。我的公司Fog Creek软件公司，可以为大学生提供软件开发方面的实习机会。在我们公司，你可以学习“编码，开发，商业”。去年在我们公司实习的Ben就是这么说的，可不是因为我给他什么好处他才这么说。二月一号截至，抓紧机会吧。

如果你听了我的建议，你就会太早地卖掉Microsoft公司的股票，拒绝Google提供的职位，原因是因为你已经拥有自己的公司了。到时候可别后悔，更别怪我，呵呵。

1. 你们的项目组使用源代码管理工具了么？

应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

 2. 你们的项目组使用缺陷管理系统了么？

应该用。ClearQuest太复杂，我的推荐是BugZilla。

3. 你们的测试组还在用Word写测试用例么？

不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

4. 你们的项目组有没有建立一个门户网站？

要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么？

应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。

6. 你们的程序员工作在安静的环境里么？

需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。

7. 你们的员工每个人都有一部电话么？需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。

8. 你们每个人都知道出了问题应该找谁么？

应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

 9. 你遇到过有人说“我以为…”么？

要消灭“我以为”。Never assume anything。

10. 你们的项目组中所有的人都坐在一起么？

需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。

11. 你们的进度表是否反映最新开发进展情况？

应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

 12. 你们的工作量是先由每个人自己估算的么？

应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。

13. 你们的开发人员从项目一开始就加班么？

不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？

不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

15. 值得再多花一些时间，从95%做到100%好值得，非常值得。

尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

16. 登记新缺陷时，是否写清了重现步骤？

要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。

17. 写新代码前会把已知缺陷解决么？要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。

18. 你们对缺陷的轻重缓急有事先的约定么？

必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

 19. 你们对意见不一的缺陷有三国会议么？必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么？

Bug应该由Opener关闭。Dev不能私自关闭Bug。

21. 你们的程序员厌恶修改老的代码么？

厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

22. 你们项目组有Team Morale Activity么？

每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。

23. 你们项目组有自己的Logo么？

要有自己的Logo。至少应该有自己的Codename。

24. 你们的员工有印有公司Logo的T-Shirt么？

要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

 25. 总经理至少每月参加次项目组会议要的。

要让team member觉得高层关注这个项目。

26. 你们是给每个Dev开一个分支么？

反对。Branch的管理以及Merge的工作量太大，而且容易出错。

27. 有人长期不Check-In代码么？

不可以。对大部分项目来说，最多两三天就应该Check-In。

28. 在Check-In代码时都填写注释了么？

要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

 29. 有没有设定每天Check-In的最后期限？

要的，要明确Check-In Deadline。否则会Build Break。

30. 你们能把所有源码一下子编译成安装文件吗？

要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。

31. 你们的项目组做每日编译么？

当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？

要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

 33. 设计越简单越好越简单越好。

设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么？

要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。

36. 你们的项目组每个人都写Daily Report么？

要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

 37. 你们的项目经理会发出Weekly Report么？

要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

 38. 你们项目组是否至少每周全体开会一次？

要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

39. 你们项目组的会议、讨论都有记录么？

会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

 40. 其他部门知道你们项目组在干什么么？

要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通

Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group

如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。

43. 每个人都知道哪里可以找到全部的文档么？

应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。

44. 你做决定、做变化时，告诉大家原因了么？

要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。

45. Stay agile and expect change 要这样。

需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员？

要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

 48. 你是先写Test Case然后再测试的么？

应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例？

不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？

要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

 51. 你们是否随便抓一些人来做易用性测试？

要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么？

别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？

不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么？

虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

 55. 你们项目组中有人能说出产品的当前整体质量情况么？

要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。

56. 你们有单元测试么？

单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么？

大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

 58. 你们的程序中所有的函数都有输入检查么？

不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

 59. 产品有统一的错误处理机制和报错界面么？

要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么？

要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。

61. 你们的每个人都了解项目的商业意义么？

要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

 62. 产品各部分的界面和操作习惯一致么？

要这样。要让用户觉得整个程序好像是一个人写出来的那样。

 63. 有可以作为宣传亮点的Cool Feature么？

要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

64. 尽可能缩短产品的启动时间要这样。

软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

 65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

 66. 你们根据详细产品功能说明书做开发么？

要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

67. 开始开发和测试之前每个人都仔细审阅功能设计么？

要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么？要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

 69. Dev工作的划分是单纯纵向或横向的么？

不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。

70. 你们的程序员写程序设计说明文档么？

要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

 71. 你在招人面试时让他写一段程序么？

要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。

72. 你们有没有技术交流讲座？

要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？

要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10