温室小花.技术.博客 --纯粹的unix技术博客 » 技术感悟

如何认识软件项目估算

admin — Wed, 23 Dec 2009 03:25:56 +0000

虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行……因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》
1、估算前的规划
当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
1．1、规划的第一步：确定软件范围
确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势，等等。

获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：
在供电站总部每天结束前要审核下属节点操作员（30~40个）的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号（MODEM）用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据（一旦审核完毕的数据，就进行归档）总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。
通过上面的描述，我们通过提炼和简化，得到软件的一下功能：
◆ 节点数据录入、查询、上传
◆ 总部数据汇总、查询、反馈
◆ 总部与节点的互联
◆ 总部数据库存储
◆ 节点数据的本地存储
在本例中，软件的性能是潜在的。客户虽然没有明确提出，但是由于数据本身的重要性，要求系统在数据上传、反馈、存储过程中安全可靠。客户要求使用MODEM进行拨号连接，那么鉴于MODEM连接过程中可能会出现，由于拨号断开而道导致的数据丢失，在节点本地存放一份数据副本是有必要的。由于系统要求每天上传数据，总部数据库应当是7X24小时不间断服务的，再加上目前总部只有该系统运行接受数据任务，各节点数据量并不大，那么在建议用户选择服务器时，应当考虑性能稳定可靠，但并不一定要购买大容量磁盘阵列和高性能双CPU主机。由于每天上传数据接近下班时间，那么总部汇总数据应当是自动进行的，一旦分析发现重大问题，可以通过与外部网络的设置，向值班人员发送手机讯息、E-MAIL或其他警示。由于不同人员对于上报数据的权限不同，对于系统用户实行分级管理。不同级别的用户，具有对数据的不同管理权力，从而保证在软件使用过程中不发生混乱。
那么现在一个较为清晰的软件模型已经构造完毕，接下来我们需要进入计划的第二步：确定工作所需资源。
1．2、规划的第二步：确定工作所需资源
软件工作所需资源包括：工作环境（软硬件环境、办公室环境）、可复用软件资源（构件、中间件）、人力资源（包括不同各种角色的人员：分析师、设计师、测试师、程序员、项目经理……）。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比例最小的，最下面的是组成比例最大的部分。
■ 人力资源
一个项目到底需要多少种职务的人员构成、多少数量的人员总量，再能成为最有创造力的团队呢？这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。

■ 可复用软件资源
这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。根据不同的应用、时间、来源，可复用软件资源被分为以下几种：
可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。
具有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险相对较小。
具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这类构件进行所需的修改会有相当程度的风险。
新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构件。
在采用构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂亮的构件的应用，可能会带来潜在出错的风险或者必须经过复杂修改或者效率低下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满足项目的需要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使用的构件。
■ 环境资源
“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。
站在人件的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工，产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。
到此为止，估算前的项目计划已经完成，我们已经形成一个工程开发框架。这是一个有界限的框架，虽然还不够精确，但足以进行估算的工作。
4．3、IBM模型估算法
该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。
4．4、COCOMO估算法
Boehm在其经典著作“软件工程经济学”(software engineering conomics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，COnstructive COst MOdel)，它代表了软件估算的一个综合经验模型。
COCOMO 模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序)；(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。
4．5、软件方程式估算法
软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。
4．6、WBS估算法
这是一种基于WBS（工作任务分解）的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：
对项目需求作出一个完整的限定。
制定完成任务所必需的逻辑步骤。
编制WBS表。
项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。
5、估算的戒律
记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确?? ——亚里斯多德
对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们不是用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。
不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。更何况估算的太精确，反而会失去灵活机动的空间。

不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。

不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。
客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。

客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。
不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现客户的需求。但我们要实现的是合理的目标，况且不能为了完成目标而去堆积数字，这样岂不是因果倒置了。
不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。现在风险就会带来潜在的成本，如：突然一位程序员离职，导致工作进度路落后。我们不可能估算到任何一种可能发生的情况，但有责任把可能出现的一些关键环节列出来。
2、估算的对象
目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。
估算主要包括以下几个重要内容：
◆ 规模估算
软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。
◆ 工作量估算
这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。
◆ 进度估算
进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。
◆ 成本估算
包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。
3、估算的策略
在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。
3．1、自顶向下的策略
这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。
当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。
3．2、自底向上的策略
与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。最后将估算加起来就是项目的估算值。
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。
4、估算的方法
显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。
估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。
4．1、FP功能点估算法
功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等；技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。
4．2、LOC估算法
这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码（LOC）作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：
PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。
类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长。
系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS（系统分解结构），它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。

想不到俺给一个很简单的技术问题弄得很郁闷！

admin — Sat, 01 Aug 2009 08:01:33 +0000

俺的几个小站，数据要迁移，也就是从一台服务器迁移到另外一台服务器。都是centos5.2的。由于选用php的版本不当，走了很多弯路，浪费许多时间。俺的几个小站从上月27日开始就无法正常访问。因为新迁移的环境是lighttpd1.4.22 与php5.3.0 与mysql5，起初，俺以为是迁移时，不小心破坏网站文件与网站数据库，因为俺是直接直接关掉网络应用，直接tar 打包，再移到新环境解压的。解压后。打开网站无法访问。出现一片??乱码。俺检查了数据库与文件，发觉没问题。那就上网查了查。怀疑是新环境的数据库字符集问题,就参照网上的资料作修改，也不行。那俺怀疑可能是lighttpd编译安装不对。又再次编译安装一次lighttpd。发现又不行。那俺怀疑是不是环境的字符集不对啊。就先后装了supesite7.discuz6,uc1.0 的utf版本，发觉可以安装，最后再试试安装discuz6,uc的gbk版本都可以，那环境应没有问题。。但就是恢复俺的网站数据时，访问时，总是发现乱码。那俺再尝试安装supesite6时，发现还是乱码。俺随手用editplus 打开supesite的安装文件，发现提示说没有安装zendopitizer 。那基本判断是环境没有安装zendopitizer所致。那俺就尝试安装zendopitizer。但无论如何安装都无法在phpinfo.php看到zendopitizer3.3.3的信息。俺看了看php.ini 发现php.ini后面都已加上zendopitizer的信息。但就是无法在phpinfo.php看到zednoptizer的信息。也就是网站继续乱码。。。俺白天忙生计，晚上才有时间搞迁移。。。从上个月的27日一直到今天，都仍然无法解决这乱码的问题。俺就犯愁。最后，俺忽然有一个想法，会不会是php版本的事情。因为，俺在安装php5.3.0就遇到一两个奇怪问题。第一，就是php5.3.0下面没有php.ini-dist文件，第二，就是在运行phpinfo.php总提示date参数不对。总将timezone设为Asia/Chongqing .最后，要修改php.ini的开发版本的timezone设置。phpinfo.php所显示的date参数才正常。最后，俺再下载一个php5.2.10时，再跑一装php的安装设置流程。再运行lighttpd ,再打开phpinfo.php 发现zendoptimizer 3.3.3信息可以看到，再打开俺的小站。发现终于正常访问！

俺真的想不到，最终的问题是出在php的版本过高问题，就是这个版本过高。累俺花了五个晚上时间去搞迁移与恢复！而且，俺的php5.3.0是俺访问www.php.net时，并在中国的verycd network像像下载的！

虽然。俺平时不多说粗口，但是针对这个问题。累俺浪费这么多时间。俺真的禁不住说一句：操！是谁放出php.5.3.0这个版本的！

读懂程序代码，使心法皆为我所用

admin — Mon, 15 Jun 2009 04:25:19 +0000

程序代码是别人写的，只有原作者才真的了解程序代码的用途及涵义。许多程序员心里都有一种不自觉的恐惧感，深怕被迫去碰触其它人所写的程序代码。但是，与其抗拒接收别人的程序代码，不如彻底了解相关的语言和惯例，当成是培养自我实力的基石。

对大多数的程序员来说，撰写程序代码或许是令人开心的一件事情，但我相信，有更多人视阅读他人所写成的程序代码为畏途。许多人宁可自己重新写过一遍程序代码，也不愿意接收别人的程序代码，进而修正错误、维护它们、甚至加强功能。

这其中的关键究竟在何处呢？若是一语道破，其实也很简单，程序代码是别人写的，只有原作者才真的了解程序代码的用途及涵义。许多程序员心里都有一种不自觉的恐惧感，深怕被迫去碰触其它人所写的程序代码。这是来自于人类内心深处对于陌生事物的原始恐惧。

读懂别人写的程序代码，让你收获满满

不过，基于许多现实的原因，程序员时常受迫要去接收别人的程序代码。例如，同事离职了，必须接手他遗留下来的工作；也有可能你是刚进部门的菜鸟，而同事经验值够了、升级了，风水轮流转，一代菜鸟换菜鸟。甚至，你的公司所承接的项目，必须接手或是整合客户前一个厂商所遗留下来的系统，你们手上只有那套系统的原始码（运气好时，还有数量不等的文件）。

诸如此类的故事，其实时常在程序员身边或身上持续上演着。许多程序员都将接手他人的程序代码，当做一件悲惨的事情。每个人都不想接手别人所撰写的程序代码，因为不想花时间去探索，宁可将生产力花在产生新的程序代码，而不是耗费在了解这些程序代码上。

很遗憾的是，上述的情况对程序员来说很难避免。我们总是必须碰触到其它人所写成的程序代码，甚至必须了解它、加以修改。对于这项需求，在现今开放源代码的风气如此盛行的今日，正如之前的《程序设计2.0》文中所提到的，你可以透过开放源代码学习到新的技术、学习到高手的架构设计，大幅提高学习的效率及效果。你甚至可以直接从开放源代码项目中抽取、提炼出自己所需的程序代码，站在巨人的肩膀上，直接由彼端获得所需的生产力。从这个观点来看，读懂别人所写的程序代码，就不再只是从负面观点的“被迫接收”，而是极具正面价值的“汲取养份”。

先了解系统架构与行为模式，再细读

倘若撰写程序代码是程序员的重要技能之一，那么读懂别人的程序代码、接着加以修改，也势必是另一个重要的技能。

如果你不能熟悉这项工作，不仅在遇到你所不愿面对的局面时，无法解决眼前接手他人程序代码的难题，更重要的是，当你看着眼前现成的程序代码，却不知如何从中撷取自己所需，导致最后只能入宝山空手回，望之兴叹。

阅读他人的程序代码，大致上可以分为三种程度：一、了解，二、修改、扩充，三、抽取、提炼。

了解别人的程序代码是最基础的工作，倘若不能了解自己要处理的程序代码，就甭论修改或扩充，更不可能去芜存菁，从中萃取出自己所需，回收再利用别人所撰写的程序代码。

虽说是“阅读”，但程序代码并不像文章或小说一样，通过这种做法，便能够获得一定程度的了解。阅读文章或小说时，几乎都是循序地阅读，你只消翻开第一页，一行行阅读下去即可。但是，有许多程序员在试着阅读其它人的程序代码时，却往往有不知从何读起的困难。

或许找到系统的第一页（也就是程序代码执行的启始点）并不难，但是复杂度高的系统，有时十分庞大，有时千头万绪。

从程序代码的起始点开始读起，一来要循序读完所有的程序代码旷日费时，二来通过这种方式来了解系统，很难在脑中构建出系统的面貌，进而了解到系统真正的行为。所以，阅读程序代码的重点，不在于读完每一行程序代码，而是在于有效率地通过探索及阅读，从而了解系统的架构及行为模式。以便在你需要了解任何片段的细节实作时，能够很快在脑上对应到具体的程序代码位置，直到那一刻，才是细读的时机。

熟悉沟通语言与惯例用语

不论如何，有些基本的准备，是阅读他人程序代码时必须要有的。

首先，你最好得了解程序代码写成的程序语言。想要读懂法文写成的小说，总不能连法文都不懂吧。有些情况则很特殊。我们虽然不懂该程序代码撰写所用的语言，但是因为现代语言的高阶化，而且流行的程序语言多半都是血统相近，所以即使不那么熟悉，有时也可勉力为之。

除了认识所用语言之外，再来就是要先确认程序代码所用的命名惯例（naming convention）。了解命名惯例很重要，不同的程序员或开发团队，差异可能很大。

这命名惯例涵盖的范围通常包括了变量的名称、函式的名称、类别（如果是对象导向的话）的名称、代码档案、甚至是项目建构目录的名称。倘若使用了像设计模式之类的方法，这些名称更有一些具体的表述方式。

命名惯例有点像是程序员在程序语言之上，另行建构的一组沟通行话。程序员会通过共同约束、遵守的命名惯例，来表达一些较高阶的概念。例如，有名的匈牙利式命名法，便将变量名称以属性、型别、说明合并在一起描述。对程序员来说，这种方式能够提供更丰富的信息，以了解该变量的作用及性质。

对程序代码阅读来说，熟悉这个做法之所以重要，是因为当你了解整个系统所采用的惯例时，你便能试着以他们所共同操用的语汇来进行理解。倘若，不能了解其所用的惯例，那么这些额外提供的信息，就无法为你所用。像以设计模式写成的程序代码，同样处处充满着模式的名称，诸如：Factory、 Facade、Proxy等等。以这些名称指涉的类别，也直接通过名称，表达了它们自身的作用。对于懂得这命名惯例的读者来说，不需要深入探索，也能很快捕捉到这些类别的意义。

当你拿到一套必须阅读的程序代码时，最好先取得命名惯例的说明文件。然而，并不是每套程序代码都附有此类的说明文件。另一个方式，就是自己到程序代码中，大略浏览一遍，有经验的程序员可以轻易发掘出该系统所用的命名惯例。

常见的命名方式不脱那几类，这时候经验就很重要，倘若你知道的惯例越多，就越能轻易识别他人所用的惯例。如果运气很糟，程序代码所用的惯例是前所未见的，那么你也得花点时间归纳，凭自己的力量找出这程序代码命名上的规则。

掌握程序代码撰写者的心态与习惯

大多数的程序代码，基本上都依循一致的命名惯例。不过运气更差的时候，一套系统中可能会充斥着多套命名惯例。这有可能是因为开发团队由多组人马所构成，每组人马都有不同的文化，而在项目开发管理又没有管控得宜所造成。最糟的情况，程序代码完全没有明显的惯例可言，这时候阅读的难度就更高了。

想要阅读程序代码，得先试着体会程序代码作者的“心”。想要这么做，就得多了解对方所使用的语言，以及惯常运用的语汇。在下一回中，我们将继续探讨阅读程序代码的相关议题。

101条伟大的计算机编程名言

admin — Tue, 26 May 2009 02:40:08 +0000

“人们总是害怕改变。电被发明出来的时候他们害怕电，是不是?他们害怕煤，害怕蒸汽机车。无知无所不在，并导致恐惧。但随着时间推移，人们终究会接受最新的科技。”
　　正如比尔盖茨曾经警告过一样，计算机已经真正成为我们的最新科技，几乎遍布我们日常生活的每一方面。所以，我们这个时代的某些最伟大的头脑开始思索起计算机和软件对于人类的重要性来了。以下就是101条有关计算机的伟大名言。

　　计算机

　　1、“计算机没什么用。他们只会告诉你答案。”

　　(巴勃罗·毕加索，画家)

　　2、“计算机就跟比基尼一样，省去了人们许多的胡思乱想。”

　　(萨姆·尤因，作家)

　　3、“他们拥有计算机，他们也还可能拥有其他的大规模杀伤性武器。”

　　(珍内特·雷诺，美国前女司法部长)

　　4、“跟计算机工作酷就酷在这里，它们不会生气，能记住所有东西，还有，它们不会喝光你的啤酒。”

　　(保罗·利里，吉他手)

　　5、“如果汽车能赶上计算机的发展周期的话，一辆今天的劳斯莱斯仅值100美元，每加仑要跑100万英里，每年还得爆炸一次，把里面的人杀个精光。”

　　(Robert X. Cringely，技术作家)

　　计算机智能

　　6、“计算机总是越来越智能的。科学家告诉我们说不久它们就能跟我们对话了。(这里的“它们”，我指的是“计算机”。我怀疑科学家永远都不能跟我们对话。)”

　　(Dave Barry，幽默作家)

　　7、“我最近注意到，在共同文化中，那种对计算机变得智能化并最终掌控世界的妄想恐惧症几乎彻底消失了。据我所知，这跟MS-DOS的发布基本是同步的。”

　　(Larry DeLuca)

　　8、“计算机会不会思考这个问题就像问潜水艇会不会游泳一样。”

　　(Edsger W. Dijkstra，图灵奖获得者)

　　9、“活了一百年却只能记住30M字节是荒谬的。你知道，这比一张压缩盘还要少。人类境况正在变得日趋退化。”

　　(Marvin Minsky，人工智能研究的奠基人)

　　信任

　　10、“这座城市的中央计算机告诉你的?R2D2，你不该相信一台陌生的计算机!”

　　(C3PO，星球大战中的翻译机器人)

　　11、“不要信赖那些大到不能扔出窗外的计算机”

　　(斯蒂夫·沃兹尼亚克，苹果联合创始人)

　　*译者：游戏《文明4》中的科技引言，实际上沃兹尼亚克自己也不记得自己是否确切讲过这样的话。

　　硬件

　　12、“硬件:计算机系统中可被踢的部分。”

　　(Jeff Pesis)

　　软件

　　13、“今天大部分的软件都很像上百万块砖堆叠在一起组成的埃及金字塔，缺乏结构完整性，只能靠强力和成千上万的奴隶完成。”

　　(阿伦·凯，图灵奖获得者，面向对象创始人)

　　14、“我终于明白‘向上兼容性’是怎么回事了。这是指我们得保留所有原有错误。”

　　(Dennie van Tassel)

　　操作系统

　　15、“有两样重要产品出自伯克利：LSD和BSD*。我们不相信这是个巧合。”

　　(Jeremy S. Anderson)

　　*译者：LSD是一种药力至强的迷幻剂，BSD-BSD(Berkeley Software Distribution，伯克利软件套件)是Unix的衍生系统

　　16、“2038年1月19日，凌晨3点14分07秒”

　　(UNIX中的世界末日*–1970年1月1号之后的2^32秒)

　　*译者：word跟world发音类似，UNIX用有符号整形数(WORD)表示时间，所以最多只能计时2^31秒，原文的2^32应为错误。

　　17、“每个操作系统都差不多… 我们都一样的烂。”

　　(微软的高级副总裁布莱恩·瓦伦蒂尼这样描述操作系统的安全状况，2003)

　　18、“微软出了个新版本，Windows XP,据大家说是‘有史以来最稳定的Windows’，对我而言, 这就好像是在说芦笋是‘有史以来发音最清脆的蔬菜一样’ “

　　(Dave Barry)

　　互联网

　　19、“互联网?那个东西还在吗?”

　　(Homer Simpson)

　　20、“网络就像是个母夜叉。我每转到一处都会看见小个的按钮命令我提交*。”

　　(Nytwind)

　　*译者注：Submit：提交，另一层意思是要求屈服

　　21、“想想看吧，已经有一百万只猴子坐在一百万台打字机旁，可Usenet就是不像莎士比亚。”

　　(Blair Houghton)

　　软件产业

　　22、“计算机软件产业最为惊人的成就，是其持续不断地放弃硬件产业的惊人成果和稳定性。”

　　(Henry Petroski)

　　23、“真正的创新经常来自于那些贴近市场、但无力拥有市场的的小型初创公司。”

　　(Timm Martin)

　　24、“人们常说，伟大的科学学科就像是站在其它巨人肩膀上的巨人。人们也说过，软件产业正如站在其他侏儒脚上的侏儒。”

　　(Alan Cooper，交互设计之父)

　　25、“这无关比特、字节和协议，而关乎利润和损益。”

　　(郭士纳，IBM前CEO)

　　26、“我们是微软。反抗是徒劳的。你会被同化的。”

　　(保险杠贴纸)

　　软件演示

　　27、“不管演示在彩排的时候有多好，一旦在观众面前展示时，演示不出错的几率与观众人数成反比，与投入的金钱总额成正比。”

　　(Mark Gibbs)

　　软件专利

　　28、“专利大多数都是垃圾。浪费时间去阅读这些专利是愚蠢的。只有专利持有人才会这么干，还得强迫自己才会看。”

　　(Linus Torvalds，LINUX创始人)

　　复杂性

　　29、“控制复杂性是计算机编程的本质。”

　　(Brian Kernigan)

　　30、“复杂性杀死一切。它把程序员的生活给搞砸了，它令产品难以规划、创建和测试，带来了安全挑战，并导致最终用户和管理员沮丧不已。”

　　(Ray Ozzie)

　　31、“进行软件设计有两种方式。一种是让它尽量简单，明显没有不足。另一种是弄得尽量复杂，没有明显缺陷。”

　　(C.A.R. Hoare)

　　32、“好的软件的作用是让复杂的东西看起来简单。”

　　(Grady Booch，UML创始人之一)

　　易用性

　　33、“不管那些计算机书籍如何宣称，只需记住，你并非‘傀儡’。真正的傀儡是那些无法设计出易于使用的硬件和软件的那些人，尽管他们是技术专家，因为这是普通消费者赖以生活的东西。”

　　(Walter Mossberg，科技专栏记者)

　　34、“软件供应商在努力尝试让他们的软件更‘易于操作’… 迄今为止，他们最好的办法就是翻出所有的老手册，然后在封面盖上‘易于操作’这几个字。”

　　(比尔·盖茨)

　　35、“有个老套的故事说有人希望他的计算机能像他的电话机一样好用。他的愿望实现了，因为我已经不知道该如何使用自己的电话了。”

　　(Bjarne Stroustrup，C++之父)

　　用户

　　36、“任何一个傻瓜都会用电脑。很多都会。”

　　(Ted Nelson)

　　37、“只有两个行业把客户称为‘用户’*。”

　　(Edward Tufte，信息设计大师)

　　*译者注：一个是计算机设计，另一个是毒品交易，computer design and drug dealing

　　程序员

　　38、“程序员在跟宇宙赛跑，他们在努力开发出更大更好的傻瓜程序，而宇宙则努力培养出更大更好的白痴。到目前为止，宇宙领先。”

　　(Rich Cook)

　　39、“你们当中很多人都知道程序员的美德。当然啦，有三种：那就是懒惰、急躁以及傲慢。”

　　(Larry Wall，Perl发明者)

　　40、“程序员的问题是你无法预料他在做什么，直到为时已晚。”

　　(Seymour Cray，超级计算机之父)

　　41、“那就是这些自认为痛恨计算机的人的真实面目。他们实际上真正痛恨的是糟糕的程序员。”

　　(拉瑞·尼文，科幻作家)

　　42、“很长时间以来我一直困惑不已，为什么一些又贵又先进的东西会一点用都没有。直到我突然想起，计算机不就是一台愚蠢之至却拥有难以置信的做聪明事能力的机器嘛，而程序员不就是聪明绝顶却拥有难以置信的干蠢事的能力的人嘛。一句话，他们简直就是天生绝配。”

　　(比尔·布莱森，旅游文学作家)

　　43、“不像学学涂涂画画也能让某人成为专家级画家，计算机科学教育不会让任何人成为一名编程大师。”

　　(埃里克·雷蒙，开源运动领袖)

　　44、“一个程序员是经历以下事情后仍能证明自己是严格的专家的人：他可以历经数不清的捶打，可取材于无关紧要的文档，用上面的争议数据作出模糊假设，并以此计算出测微精度的无数片面理解的答案,并由一个不可靠、脑袋充满质疑、公开宣称要让一个倒霉透顶、没有指望、毫无防备,要求第一时间获得信息的部门狼狈不堪、令人生厌的人使用一台准确度有问题的仪器去实施。”

　　(IEEE网格新闻杂志)

　　45、“运气好的黑客能用几个月的时间 – 生产出一个小规模的开发团体(比如说，7-8人)历尽艰辛一起工作了一年多才能做出来的东西。IBM经常报告说某些程序员的生产力要比其它工人高百倍，甚至更多。”

　　(Peter Seebach，黑客)

　　46、“最好的程序员跟好的程序员相比可不止好那么一点点。这种好不是一个数量级的，取决于标准怎么定：概念创造性、速度、设计的独创性或者解决问题的能力。”

　　(兰德尔·E·斯特劳斯，科技作家)

　　47、“伟大的车工值得给他几倍于普通车工的薪水，但一个伟大的软件代码作家，其价值则要等同于一个普通的软件写手的价格的1万倍。”

　　(比尔·盖茨)

　　编程

　　48、“就算它工作不正常也别担心。如果一切正常，你早该失业了。”

　　(Mosher的软件工程定律)

　　49、“靠代码行数来衡量开发进程就好比用重量来衡量飞机制造的进度。”

　　(比尔·盖茨)

　　50、“写代码的社会地位比盗墓的高，比管理的低。”

　　(杰拉尔德·温伯格，软件与系统思想家)

　　51、“首先学习计算机科学及理论。接着形成自己编程的风格。然后把这一切都忘掉，尽管改程序就是了。”

　　(George Carrette，杰出软件工程师,开源推广者)

　　52、“先解决问题再写代码。”

　　(John Johnson)

　　53、“乐观主义是编程行业的职业病;用户反馈则是治疗方法。”

　　(Kent Beck)

　　54、“迭代者为人，递归者为神。”

　　(L. Peter Deutsch)

　　55、“布尔值最好的一点是，就算你错了，也顶多错了一位而已。”

　　(无名氏)

　　56、“数组的下标是从0开始好还是从1开始好呢?我的0.5的折衷方案，以我之见，没有经过适当考虑就被否决掉了。”

　　(Stan Kelly-Bootle)

　　编程语言

　　57、“只有两种编程语言：一种是天天挨骂的，另一种是没人用的。”

　　(Bjarne Stroustrup，C++之父)

　　58、“PHP是不合格的业余爱好者创建的，他们犯了个小恶;Perl是娴熟而堕落的专家创建的，他们犯了阴险狡诈的大恶。”

　　(Jon Ribbens)

　　59、“COBOL的使用摧残大脑;其教育应被视为刑事犯罪。”

　　(E.W. Dijkstra)

　　60、“把良好的编程风格教给那些之前曾经接触过BASIC的学生几乎是不可能的。作为可能的程序员，他们已精神残废，无重塑的可能了。”

　　(E. W. Dijkstra)

　　61、“我想微软之所以把它叫做.Net，是因为这样它就不会在Unix的目录里显示出来了。”

　　(Oktal)

　　62、“没有一种编程语言能阻止程序员写出糟糕的程序来，不管这种语言结构有多良好。”

　　(Larry Flon)

　　63、“计算机语言设计犹如在公园里漫步。我是说侏罗纪公园。”

　　(Larry Wall)

　　C/C++

　　64、“搞了50年的编程语言的研究，我们难道就以C++告终啦?”

　　(Richard A. O’Keefe)

　　65、“写C或者C++就像是在用一把卸掉所有安全防护装置的链锯。”

　　(Bob Gray)

　　66、“在C++里你想搬起石头砸自己的脚更为困难了，不过一旦你真的做了，整条腿都要报销。”

　　(Bjarne Stroustrup)

　　67、“C++ : 友人可造访你的私有成员之地也。”

　　(Gavin Russell Baker)

　　译者：Friends：C++的友元，是一种定义在类外部的普通函数，但它需要在类体内进行说明，为了与该类的成员函数加以区别，在说明时前面加以关键字friend。友元不是成员函数，但是它可以访问类中的私有成员。友元的作用在于提高程序的运行效率，但是，它破坏了类的封装性和隐藏性，使得非成员函数可以访问类的私有成员。

　　68、“罗马帝国灭亡的其中一个主要原因是他们没有0 – 这样他们就没法给自己的C程序指明成功退出的路径了。”

　　(Robert Firth)

　　Java

　　69、“Java从许多方面来说就是C++–。”

　　(Michael Feldman)

　　70、“说Java好就好在运行于所有操作系统之上，就好比说肛交好就好在无论男女都行。”

　　(Alanna)

　　71、“好吧，Java也许是编程语言的好榜样。但Java应用则是应用程序的坏榜样。”

　　(pixadel)

　　72、“要是Java真的有垃圾回收的话，大部分程序在执行的时候就会把自己干掉了。”

　　(Robert Sewell)

　　开源

　　73、“软件就像性事：免费/自由更好。”

　　(Linus Torvalds)

　　74、“唯一对免费软件感到害怕的人，是自己的产品还要不值钱的人。”

　　(David Emery)

　　代码

　　75、“好代码本身就是最好的文档。”

　　(Steve McConnell，《代码大全》的作者)

　　76、“你自己的代码如果超过6个月不看，再看的时候也一样像是别人写的。”

　　(伊格尔森定律)

　　77、“前面90%的代码要占用开发时间的前90%。剩下的10%的代码要占用开发时间的另一90%。”

　　(Tom Cargill，C++领域中公认的专家)

　　软件开发

　　78、“好的程序员绞尽脑汁，务求考虑各种场景，幸得好的指南拯救我们，不必面面俱到。”

　　(Francis Glassborow，C和C++领军人物之一)

　　79、“在软件里面，我们鲜有有意义的需求。就算有，衡量成功的唯一尺度也取决于我们的解决方案是否解决了客户对问题是什么的观念的转变。”

　　(Jeff Atwood，Coding Horror Developer Blog的创始人)

　　80、“想想我们计算机程序的糟糕现状吧，很显然软件开发仍是黑箱艺术，还不能称之为工程学科。”

　　(Bill Clinton，前美国总统)

　　81、“没有伟大的团队就没有伟大的软件，可大部分的软件团队举止就像是支离破碎的家庭。”

　　(吉姆·麦卡锡，微软VC++总监)

　　调试

　　82、“一旦我们开始编程，就会惊讶地发现让程序正常没想象中那么简单。调试不可避免。那一刻我认记忆犹新，当时我就意识到，从今往后我生活的大部分时间都要花在寻找自己程序的错误上面了。”

　　(莫里斯·威尔克斯调试探索, 1949)

　　83、“调试难度本来就是写代码的两倍。因此，如果你写代码的时候聪明用尽，根据定义，你就没有能耐去调试它了。”

　　(Brian Kernighan，《C 程序设计语言》的作者之一)

　　84、“如果调试是除虫的过程，那么编程就一定是把臭虫放进来的过程。”

　　(Edsger W. Dijkstra)

　　质量

　　85、“我才不管它能不能在你的机器上运行呢!我们又没装到你的机器上!”

　　(Vidiu Platon，罗马尼亚的微软最佳学生合作伙伴MSP)

　　86、“编程就像性一样：一时犯错，终生维护。”

　　(Michael Sinz)

　　87、“有两种写出无错程序的办法;只有第三种有用。”

　　(Alan J. Perlis)

　　88、“软件质量与指针算法不可兼得。”

　　(Bertrand Meyer)

　　89、“如果麦当劳像软件公司那样运作的话，每一百个巨无霸就会有一个令你食物中毒，而他们的回应是，‘真对不起，这是一张额外附送两个的赠券。’ “

　　(Mark Minasi)

　　90、“永远要这样写代码，好像最终维护你代码的人是个狂暴的、知道你住在哪里的精神病患者。”

　　(Martin Golding)

　　91、“是人都会犯错，不过要想把事情彻底搞砸还得请电脑出马。”

　　(Paul Ehrlich)

　　92、“计算机比人类历史上的任何发明都更快速地导致你犯更多的错误–可能除了手枪和龙舌兰酒是例外。”

　　(Mitch Radcliffe)

　　预测

　　93、“能发明的东西都发明出来了。”

　　(查尔斯·杜埃尔, 美国专利局局长，1899年)

　　94、“我认为全球市场约需5台计算机。”

　　(托马斯·沃森, IBM董事长, 约1948年)

　　95、“看上去我们已经到达了利用计算机技术可能获得的极限了，尽管下这样的结论得小心，因为不出五年这听起来就会相当愚蠢。”

　　(约翰·冯·诺伊曼,约1949年)

　　96、“但这又有什么好处呢?”

　　(IBM先进计算机系统部的工程师对微芯片的评论, 1968年)

　　97、“我们没有理由让每一个人在家都拥有一台电脑。”

　　(肯·奥尔森,数据设备公司(DEC)总裁，1977年)

　　98、“640K对每一个人来说都已足够。”

　　(比尔·盖茨,1981年)

　　99、“Windows NT的RAM寻址空间可达2G，这比任何应用程序所需都要多。”

　　(微软, 谈及Windows NT的开发时所言, 1992年)

　　100、“我们永远也无法真正成为无纸化社会，直到掌上电脑一族发布擦我1.0*(WipeMe 1.0)为止。”

　　(安迪•皮尔逊，商界领袖)

　　*译者注：意思是说难道你大便不用纸吗?

　　101、“长此以往，除了按键的手指外，人类的肢体将全部退化。”

　　(弗兰克•劳埃德•赖特，建筑师)

恒德,得以成大业,失恒,失德,大业不成!!

admin — Fri, 22 May 2009 09:18:54 +0000

恒德,得以成大业,失恒,失德,大业不成!!

     尝思古人。所以能成圣神功化之事业。享圣贤仙佛之大名。历万古而不朽者。无非能尽人事之所致也。人事如何尽。在有恒。因恒之为德也。为成己、成人、成物之无上法门。这个法门。世人知之熟矣。然知之而能践行者盖鲜。所以说靡不有初。鲜克有终。苟能践行一个恒字。小则可以为善人、为君子。大则可以为圣人、与天地参。恒之为用大矣哉。然苟一失之。毕生不能成一事。立一业。终不过为一庸夫俗子而已。何则、孔子不云乎。南人有言曰。人而无恒。不可以作巫医。巫医者技艺小术也。技艺小术。犹且不可作。何况其他。孔子援引南人之言以垂教。不无深意在其中也。而其下又引易之言曰。不恒其德。或承之羞。言无恒德之人。必自承羞辱。於世无足轻重。不无深意在其中也。如是之人。不但不足言恒德。即并所谓恒心。亦未足以与言也。
   何为恒心。何为恒德。恒心者、恒德之用也。恒德者、恒心之体也。有体斯能充其用。有用斯能立其体。体用兼赅。才是中道。徵诸事实。方能有成。因德之为体。至善纯粹。即人有生之初。所禀受之一团天理。恒久不灭。故曰恒德。恒德者、常德也。即人之真常。人之天德也。人人有真常。有天德。则人人均能成圣贤君子。而其所以不能尽人成圣贤君子者。由於无恒故也。有恒之人。岂但自成圣贤君子而已哉。即三千大千世界之人。使之尽成圣贤君子。亦意中事也。但必恒於其德方可。若恒於其心。亦未必能有成。何以故、因人之心。可以善、可以恶。善则上达。恶则下达。此间即道心惟微。人心惟危之攸关。能知道心惟微者。则凡事小心翼翼。戒慎恐惧。拳拳服膺而弗失。久而不变。上达之道也。苟不能知微危之分别。虽有其恒。而终必下达。何以见之。如小人为名为利。日日取巧钻营。不达到目的而不止。一朝达到目的。则前之目的虽了。而后之目的又生。行险以侥幸。并不知足。亦不知止。一往直前。任情所之。如是用心用力。亦可以谓之恒。但如是之恒。是恒非所恒。终是下达之道也。由此看来。恒其心者。固莫若恒其德。恒其德者。真心常住。久於其道也。天地之道。恒久而不已。惟其恒久。故终又复始。循环不穷。如日月阴阳之精。得天之健以行。而能久照。四时一天道之卷舒。阴阳变化不息。而能久成。圣人法天。久於其道。而修己治人之事。处处洽浃。天下化成。如帝尧之亲九族。而九族皆睦。平章百姓。而百姓昭明。协和万邦。而黎民於变时雍。其化成天下之功。是何气象。是何能力。假使帝尧不能体天地恒久之道。克明峻德。又安能成圣人之名。而收天下化成之圣功耶。由此言之。可见万古此天地。万古此恒德。万古此万物。万古此恒德。万古此圣人。亦万古此恒德也。若当春而夏。当秋而冬。当生不生。当成不成。则为变怪。安得谓之恒。是天地失其德也。为人亦然。若德之不修。学之不讲。见义不为。不善不改。则为自暴自弃。亦不得谓之恒。是恒之於天地人物。其为德也大矣。是故易曰、观其所恒。而天地万物之情可见。诚不诬矣。
    且夫恒也者。修德之始基也。德者恒之积。恒之果也。所以易之系辞曰。恒以一德。又曰、恒德之固也。天地间无论立功立德。种因证果。未有不由恒而成者也。有恒有德。无有办不到之事。所以我辈讲修持。即当重在有恒。有恒然后乃能行成己成人之实功。挽回今世之否运。况夫恒德之不明也久矣。是故孔子曰。善人吾不得而见之矣。得见有恒者、斯可矣。又曰难乎有恒矣。由此说来。岂人心果尽无恒。而恒德之所以难得耶。曰、圣言非是之谓也。天下之大。非无恒者也。其所以慨人难乎有恒者。因人落在后天以来。蔽於物而溺於欲。辗转於名利卑靡之途。逐末忘真。相习成性，遂恒其所不当恒。故曰无而为有。虚而为盈。约而为泰。难乎有恒矣。此即量经恒卦之九四。所谓田无禽是也。田於无禽之地。虽久而终无所得。换言之、即是能恒而无德者也。恒而无德。不惟无功。且足以致败。故曰不恒其德。或承之羞。贞吝。所以恒之为道。尤贵乎中。故恒之九二日悔亡。悔亡者。能久中也。可久之道。中而已矣。然中之为道。又非胶於一定之谓也。故君子於修己应世之间。凡事以时中处之。无常而实有常。有常而若无常。千变万化。不离乎中。所以雷风变动不拘之物。而名其卦曰恒。如是为恒为德。岂有不能与天地同其用哉。

中国古代34位美女（附图）

admin — Sat, 02 May 2009 15:04:21 +0000

中国古代美女图春秋战国时期，越国有一个叫西施的，是个浣纱的女子，五官端正，粉面桃花，相貌过人。她在河边浣纱时，清彻的河水映照她俊俏的身影，使他显得更加美丽，这时，鱼儿看见她的倒影，忘记了游水，渐渐地沉到河底。从此，西施这个“沉鱼”的代称，在附近流传开来。

三国时汉献帝的大臣司徒王允的歌妓貂婵在后花园拜月时，忽然轻风吹来，一块浮云将那皎洁的明月遮住。这时正好王允瞧见。王允为宣扬他的养女长得如何漂亮，逢人就说，我的女儿和月亮比美，月亮比不过，赶紧躲在云彩后面，因此，貂婵也就被人们称为“闭月”了。

汉元帝在位期间，南北交兵，边界不得安静。汉元帝为安抚北匈奴，选昭君与单于结成姻缘，以保两国永远和好。在一个秋高气爽的日子里，昭君告别了故土，登程北去。一路上，马嘶雁鸣，撕裂她的心肝；悲切之感，使她心绪难平。她在坐骑之上，拨动琴弦，奏起悲壮的离别之曲。南飞的大雁听到这悦耳的琴声，看到骑在马上的这个美丽女子，忘记摆动翅膀，跌落地下。从此，昭君就得来“落雁” 的代称。

唐朝开元年间，有一美貌女儿叫杨玉环，被选进宫来。杨玉环进宫后，思念家乡。一天，她到花园赏花散心，看见盛开的牡丹、月季……想自己被关在宫内，虚度青春，不胜叹息，对着盛开的花说：“花呀，花呀！你年年岁岁还有盛开之时，我什么时候才有出头之日？”声泪俱下，她刚一摸花。花瓣立即收缩，绿叶卷起低下。哪想到，她摸的是含羞草。这时，被一宫娥看见。宫娥到处说，杨玉环和花比美，花儿都含羞低下了头。“羞花”称号得来。

西施沉鱼　貂婵闭月昭君落雁　玉环羞花，以中国古代的四大美女为原型，通过明快、细致的刺绣技艺，着力表现出四大美女的不同特征：西施的秀美与婉约，貂婵的恬静与内强，王昭君的孤寞与冷艳，杨贵妃的华贵与忧怨，无不被渲染的淋漓尽致。　　环肥燕瘦-杨玉环应该是和被誉为汉宫飞燕的赵飞燕相题并论，一肥一瘦，相映成趣。况且二人都是舞蹈家，都被看作是红颜祸水。赵飞燕汉宫飞燕

班昭：汉班固,班超之妹。代表作：续写汉书。

上官婉儿：上官仪孙女，号称巾帼首相第一人

班婕妤是名门之女，少有才学，汉成帝时被立为婕妤，赵飞燕姐妹得宠后，嫉恨班婕妤人品才学，班婕妤恐日久见危，求侍奉太后于长信宫，《团扇诗》应是作于长信宫中，这首小诗词彩清新，情致哀怨，而表现的却委婉含蓄，有一种怨而不怒的气度。　　《团扇诗》　　新裂齐纨素，鲜洁如霜雪。　　裁为合欢扇，团团似明月。　　出入君怀袖，动摇微风发。　　常恐秋节至，凉飙夺炎热。　　弃捐箧笥中，恩情中道绝。

　唐琬：陆游表妹兼妻子。　　代表作：钗头凤　　世情薄，人情恶，雨送黄昏花易落。晓风干，泪痕残，意缄心事，独语斜难。难、难、难！　　人成各，今非昨，病魂常似秋千索。角声寒，夜阑珊，怕人询问，咽泪妆欢。瞒、瞒、瞒！

薛涛：唐代女诗人，人称女校书。曾与当时著名诗人元缜唱和，实力不俗。　　代表作：吟梧桐诗（八岁时作）庭除一古桐，耸干入云中；枝迎南北鸟，叶送往来风

朱淑真：宋代著名女词人,知名才女，诗词皆擅，当然入选。　　代表作：有〈断肠集〉传世。

明代的官女大都出自京城门庭清白的小户人家，一旦被选入宫，就意味着从此与家人生死永不得见，而且明初的宫廷沿袭了元代惨烈的人殉制度，官女郭爱被勒令为明宣宗殉葬时入宫仅20天，《绝命辞》是临终时所作，字字血泪与父母诀别，自此后魂消影绝阴阳两隔。　　《绝命辞》　　修短有数兮，不足较也。　　生而如梦兮，死者觉也。　　先吾亲而归兮，惭予之失孝也。　　心凄凄而不能已兮，是则可悼也。

柳如是：明代著名才女，秦淮八艳之首，曾于当时两大著名诗人陈子龙、钱谦益切磋过武功，虎视群雌，不让须眉。

李师师宋徽宗的私爱…

陈圆圆冲冠一怒为红颜！

这个就叫李清照

晋武帝司马炎闻听诗人左思的妹妹左芬才情过人即纳入后宫，左芬因为德才超群每每被帝王群臣赞赏，使后宫佳丽见妒。一贯荒唐渔色的司马炎是历史上最无耻无为的帝王之一，左芬被封为贵妃，不过是司马炎为自己博得惜才的虚名，《晋书》中称左芬‘姿陋体羸，常居薄室’。《啄木诗》是左芬淡泊自律的生活写照。　　《啄木诗》　　南山有鸟，自名啄木。　　饥则啄木，暮则宿巢。　　无干于人，唯志所欲。　　此盖自卑，性清者荣，性浊者辱。

此为黄娥

卫子夫以一头乌黑靓丽的秀发,而闻名天下…

易求无价宝，难得有情郎的鱼玄机

顺治帝的董小宛

风尘三侠之张红拂，李靖爱妻

夏姬

汉章德窦皇后

汉和熹皇后，邓绥

李香君

代父从军–花木兰

蔡琰　蔡琰：即蔡文姬，东汉蔡邕之女。是我国著名女诗人。她的生年大约在汉灵帝熹平六至七年（177-178）间，原籍为陈留圉（今河南杞县）。　蔡琰在十六岁至十八岁期间，因夫死无子，又回到原籍娘家居住。到了兴平年间（194至195），也就是蔡琰十八、九岁时，为乱军所掳，作了南匈奴左贤王的妻子，在胡中十二年，生二子。　“文姬归汉”是我国历史上盛传的佳话．在史书中，至今未曾发现关于蔡琰归宿的记载。五言《悲愤诗》末尾的：“托命于新人，竭心自勖厉。流离成鄙贱，常恐复捐废。人生几何时，怀忧终年岁”等诗句，则预示着蔡琰“一生抱恨常咨嗟”（王安石语）的悲剧性结局。作《胡笳十八拍》，余述了自己一生不幸的遭遇。琴曲中有《大胡笳》、《小胡笳》、《胡笳十八拍》琴歌等版本。曲调虽然各有不同，但都反映了蔡文邪路思念故乡而又不忍骨肉分离的极端矛盾的痛苦心情。音乐委婉悲伤，撕裂肝肠。

花蕊夫人后蜀主孟昶的费贵妃，五代十国女诗人，青城（今四川都江堰市东南）人，也号花蕊夫人。幼能文，尤长于宫词。得幸蜀主孟昶，赐号花蕊夫人。后被赵匡胤招入宫中。代表作：述国亡诗宋灭后蜀时，只用了一万军队，而后蜀的十四万军人几乎不战而降，花蕊夫人随孟昶流亡北行，夜宿葭萌驿站，感怀国破家亡的哀愁，在馆壁上题了这首《采桑子》，因军骑催促，只得半阕，却一字一泪。

侯夫人隋炀帝在位期间广造高楼，并网罗天下美女数千名纳于迷楼中幽闭，侯夫人就是这几千名一辈子都没有见过隋炀帝的宫女之一，侯夫人最后自缢而死，一个美丽的才女，就这样被白白死去了，身后只留下了几首咏物寄意的空灵飘逸的小诗，让后人读来辄用伤怀。　　《春日看梅》　　砌雪无消日，卷帘时自颦。　　庭梅对我有怜意，先露枝头一点春。

卓文君。汉司马相如之妻。西汉临邛（属今四川邛崃）人，汉代才女，她貌美有才气，善鼓琴，家中富贵。卓文君丧夫后许多名流向她求婚，她却看中了穷书生司马相如。司马相如能弹琴作诗，长得又帅，卓文君从中领会到他的才华和情感，一心相爱。司马相如家里一无所有，卓文君随他私奔后，就开了个酒铺，亲自当掌柜，文君当垆卖酒，相如则作打杂，不怕人讥笑。后卓王孙碍于面子，接济二人，从此二人生活富足。后来司马相如终于成名天下。而文君夜奔相如的故事，则流行民间，并为后世小说、戏曲所取材。

.道韫：谢安侄女，“咏絮才”典出于斯人。代表作：《登山》峨峨东岳高，秀极冲青天。岩中间虚宇，寂寞幽以玄。非工复非匠，云构成自然。气象尔何然？遂令我屡迁。逝将宅斯宇，可以尽天年。

女皇武则天大帝古往今来唯此一女

甄皇后曹丕称帝后宠郭皇后，郭后恃宠中伤甄皇后，甄后从此失宠，抛开帝后的身份不谈，从《塘上行》里读到了一个妻子对丈夫相思到极致的、一往无悔的深情泣诉，可怜甄后最后等来的只是曹丕的一纸死令。甚至死后对尸身‘以发覆面、以糠塞口’的侮辱与凌虐 …《塘上行》蒲生我池中，其叶何离离。傍能行仁义，莫若妾自知。众口烁黄金，使君生别离。念君去我时，独愁常苦悲。想见君颜色，感结伤心脾。念君常苦悲，夜夜不能寐。

IT工程师职业生涯的红色警报

admin — Thu, 09 Apr 2009 01:42:56 +0000

IT技术人员是一群有热情而努力的人士,但当你的能力和你的实际工作能力严重失衡(也就是你的能力严重不能工作需要的)的时候,会严重打击你的工作热情,而项目也会不断面临着失败.而这些事情的发生是有一定预兆的.大致总结了一下,希望引起大家的注意

　　没有休息时间

　　你可以给自己很多借口,新升了职务,管理更多的项目,责任更重大了,手下的人素质不行,产品质量不高,等等,但这些都是最根本的原因,没有时间休息,最根本的原因就是你的能力不能满足现有职务的要求,所以你总是在忙,所有的事情都乱了,你做事情没有了条理,做事情的效率下降了很多，所以你再也没有时间休息了,而没有适当的休息和调整反过来又让你进一步降低了工作效率,于是成为了一种恶性循环.如果你已经出现了这种问题,最好能暂时停止工作,花一点时间好好思考一下,当前什么问题最紧急,处理方法有那些,将所有事情都列一个表,排个队,然后一个一个去做.高负荷而低效率的工作,是职业商业的一个杀手.

　　不间断的会议

　　你是一个领导了,不断的会议,一个接着一个,永远没有完,你没有时间思考,在会议上一个又一个问题迎面而来,而武功超群的你见招拆招.似乎很有成就感, 但却没有思考这些问题发生原因,也没有从根本上去解决这些问题,同样的问题在明天或者后天的会议上都在想你招手,何不坐下来仔细的想想,做好改善和预防, 将那些问题扼杀在未发生的时候,另外就是你的处理方法是否合适,效果如何,别忘了去检查一下,提高会议的效率和处理问题的效率,才是提高效率,改进质量的最好方式.不要满足去和风车搏斗,做一个IT歌德.

　　没有时间学习

　　如果是短时间内忙于项目进度,没有时间学习,那还好说,如果你最近一年都在忙,而没有时间学习和思考,那就是问题了,不说软件研发的新方法和新技术,就是在处理方法都是要不断提高和改进的,而学习和思考是提高你的技能最好的方法,所以你如果忙得连磨刀的工夫都没有,最好还是不要去上山砍柴了.少做几个项目,休息一下吧,然后自己仔细的读一些书,充充电吧

　　火气比较大,和同事的关系变差,你成了公司同事的共同的敌人

　　公司就是江湖,有江湖的地方必有矛盾,你有几个死敌不是什么问题,但如果公司所有人都成了你的敌人,那就是问题了,你在公司寸步难行,参加会议的时候象上战场,每天都在和客户、老板、下属在斗争中度过，晚上回家的时候总想找一个地方痛苦一通，甚至连妻子也不理解你，如果是这样，你要赶快反思了，你已经很危险了，现在的你就象一个刺猬一样，在保护你自己的同时，总是刺伤你的伙伴，别忘了刺猬总是在最紧张的时候才竖起那根根长刺

　　整天在忙,却不知道在做什么

　　成为著名的救火队长

　　你成了公司著名的救火队长，你总是处理那些最棘手的问题，你总能将问题解决掉，老板对你也很满意，甚至主动提出了加薪水的说法，但你想过没有，这些火灾为什么会发生，而这些火灾给公司造成了多大的危害，如果这些火灾是你的工作范围内，那你就更没有什么可得意的了，因为最好的救火的方法就是让这些火灾不发生(风险的预防)。每天都在救火的人，其实一种有小聪明.

　　而缺乏大智慧的表现，他们总是在那里跑来跑去去救火，却没有发现其他的救火队长因为危机预防处理做的好，正在那里喝茶。(不能及时发现风险隐患的人，不是一个好的管理人员和技术人员)

　　错误都是别人的,我没有责任

　　当问题发生的时候，而你又没有能力去处理的时候，最简单的方法是什么，逃避—–所有动物都会的本能表现，而人高于动物的表现是推卸责任给别人(哈哈，怪不得说人是最聪明的动物)。于是这个问题是你的下属无能，哪个问题是客户弱智，最后一个问题是你的领导不给你资源，方正你没有问题，如果是这样恭喜你了，这些情况说明你的能力已经严重不能工作的需要，而且你已经成为了公司的一个毒瘤，估计被清楚单位的时间已经不远了

　　推卸责任,工作不再是一件有意思的事情

　　严重的记忆力衰退,总是忘事情

　　记忆力衰退两个原因，一个是神经性的，这个是医学问题，不多说了一个是选择性遗忘，也就是因为你不允许别人违背你的意志，所以你会选择性遗忘你做出的那些承诺，(独裁的表现)，这种遗忘短时间内你就会回想起来，但你是不愿意承认的，为了面子，你也会坚持，结果别人对的评价就是，这个人怎么说话不算，刚说不到15分钟，这种人还是别和他打交道，祝贺你，你又失去了一个资源

　　做事情容易走极端

　　但事情很糟糕，而你又注定逃不掉的时候，最简单的方法往往是最有效的，在一个项目第一次处于极度危机中的时候，人们总是采用最极端的方法，有时候这些方法是有效的，于是你会不断使用这种方法，于是你会认为这极端的方法是一种可行的方法，当大家都疲劳了这种方法的时候(耐受度增大)，

　　你就会去寻找更极端的方法，(这个时候你已经习惯了极端)，于是一个循环接着一个循环，慢慢地，不但在工作上，而且在生活的所有方面你都已经习惯了这种极端，直到有一天，你发现你不再有朋友，你的亲人也不愿意和你交流

　　让部下做他们能力之外的事情

　　所用工作都强压给下边，不考虑部下是否可承受，不给他们以适当的训练，只是一味强调工期，你已经在工作上不能指导他们了，除了压还是压，大棒子是你唯一的工具，每天上班你的工作就是开会，然后就可以听到你一整天都在会议室向你的部下怒吼，如果是这样，仔细看一下你的体形，估计你的体重会严重上升，而且肝部也会隐隐做痛(肝火旺的表现)

昨天折腾了一个下午的wordpress博客，但无果。

admin — Tue, 07 Apr 2009 03:35:30 +0000

昨天折腾了一个下午的WORDPRES博客，主要是折腾博客下拉菜单。发觉自从博客从apache环境迁移到lighttpd服务器环境后，总好像存在或多或少的问题，就说这个下拉菜单吧。以前用得好好的。很正常，下拉菜单都能显示。但不知换了环境后，下拉菜单就不能展示。不知是服务器环境问题，还是什么问题，照理由，俺是将以前的博客全部迁移复制过来的。应该不会出现问题的。但不知道为何下拉菜单没有显示出来。昨天，俺重新换了套inove新的模板。但发觉下拉菜单还是不能显示出来。俺认为可能是数据库的表格字段问题或者表格内容出现问题。。否则，不会这样的。不会出现这种下拉菜单不显示问题的。。。再不是，那就是，lighttpd环境有问题。。只不过。俺这段时间较忙，要做的事蛮多的。这些小毛病，小错误，没有过多时间去处理。先放下吧。还有。那个wp-super-cache 的缓存插件问题，也要一并解决，很奇怪。只要，俺在后台启用这个插件，那前台首页就无法正常显示。不知为何。俺留意到在后台启用该插件时，总提示rewrite模块没有安装。不知是不是Lighttpd的rewrite模块没有安装好。要知道。那时候，那时，只要快些将博客迁移好，尽快恢复网站/博客，所以，对环境没有细究。所以，有一些功能模块都没有安装好。想着先凑合着用，先将网站恢复过来先。。。加上，平时，一些杂事较忙。所以。这事先放下。以后待比较有空时，才重点解决这两个问题，以及服务器的php技持模块问题。。。

面试中你必须要知道的语言陷阱

admin — Mon, 06 Apr 2009 12:25:04 +0000

面试极像一次相亲，我们希望找到一个能够了解自己优点的老板，单位则希望能找到优秀的员工。当陌生的双方相见后，都想在短短一席话中努力表现出自己的优点、说出聪明话或立即呈现出很棒的反应，以便给对方留下良好印象。面试，双方玩的其实是一场智力游戏。

　　面试官为了不致于“选错郎”，也许会在面试中设置种种语言陷阱，以探测你的智慧、性格、应变能力和心理承受能力。大家只有识破这样的语言陷阱，绕开它们不致于一头栽进去。

　　用“激将法”遮蔽的语言陷阱，这是面试官用来淘汰大部分应聘者的惯用手法。采用这种手法的面试官，往往在提问之前就会用怀疑、尖锐、咄咄逼人的眼神逼视对方，先令对方心理防线步步溃退，然后冷不防用一个明显不友好的发问激怒对方。

　　如：“你经历太单纯，而我们需要的是社会经验丰富的人”，“你性格过于内向，这恐怕与我们的职业不合适”，“我们需要名牌院校的毕业生，你并非毕业于名牌院校”，“你的专业怎么与所申请的职位不对口？”面对这种咄咄逼人的发问，作为应聘者，首先要做到的就是无论如何不要被“激怒”，如果你被“激怒”了，那么你就已经输掉了。那么，面对这样的发问，如何接招儿呢？

　　□ 如果对方说：“你经历太单纯，而我们需要的是社会经验丰富的人。”
　　■ 你可以微笑着回答：“我确信如我有缘加盟贵公司，我将会很快成为社会经验丰富的人，我希望自己有这样一段经历。”
　　□ 如果对方说：“你性格过于内向，这恐怕与我们的职业不合适。”
　　■ 你可以微笑着回答：“据说内向的人往往具有专心致志、锲而不舍的品质，另外我善于倾听，因为我感到应把发言机会多多地留给别人。”
　　□ 如果对方说：“我们需要名牌院校的毕业生，你并非毕业于名牌院校。”
　　■ 你可以幽默地说：“听说比尔盖茨也未毕业于哈佛大学。”
　　□ 如果对方说：“你的专业怎么与所申请的职位不对口？”
　　■ 你可以巧妙地回答：“据说，21世纪最抢手的就是复合型人才，而外行的灵感也许会超过内行，因为他们没有思维定势，没有条条框框。”

　　如果对方说：“你原单位这么好，你却要走，是不是在原单位混不下去只好挪个窝儿？”你若结结巴巴，无言以对，抑或怒形于色，据理力争，脸红脖粗，那就掉进了对方所设的圈套。应聘者碰到此种情况，要头脑冷静，明白对方在“做戏”，不必与他较劲。

　　挑战式的语言陷阱，这类提问的特点是，从求职者最薄弱的地方入手。

　　对于应届毕业生，面试官会设问：“你的相关工作经验比较欠缺，你怎么看？”对于女大学生，面试官也许会设问：“女性常常会对自己的能力缺乏自信，你怎么看？”如果回答：“不见得吧”、“我看未必”或“完全不是这么回事”，那么也许你已经掉进陷阱了，因为对方希望听到的是你对这个问题的看法，而不是简单、生硬的反驳。
　　对于这样的问题，你可以用“这样的说法未必全对”、“这样的看法值得探讨”、“这样的说法有一定的道理，但我恐怕不能完全接受”为开场白，然后婉转地表达自己的不同意见。

　　面试官有时还会哪壶不开偏提哪壶，提出让求职者尴尬的问题。如：“你的学习成绩并不很优秀，这是怎么回事？”“从简历看，大学期间你没有担任学生干部的经历，这会不会影响你的工作能力”等等。
碰到这样的问题，有的求职者常会不由自主地摆出防御姿态，甚至狠狠反击对方。这样做，只会误入过分自信的陷阱，招致“狂妄自大”的评价。而最好的回答方式应该是，既不掩饰回避，也不要太直截了当，用明谈缺点实论优点的方式巧妙地绕过去。

　　比如说，当对方提出你的学习成绩不很优秀时，你可以坦然地承认这点，然后以分析原因的方式带出你另外的优点。如，在校期间学习成绩之所以不很优秀，是因为我担任社团负责人，投入到社团活动上的精力太多。虽然我花在社团的心血也带给我不少的收获，但是学习成绩不是最优秀，这一点一直让我耿耿于怀。当意识到这一点后，我一直在设法纠正自己的偏差。

　　在面试中屡战屡胜的Michael就有过一次这样的面试经历。Michael的学习成绩并不算顶尖，面试时，这便成了考官发起攻击的要害：“你的成绩好像不太出众哦，你怎么证明自己的学习能力呢？”

　　Michael不慌不忙：“除了学习，我还有其他活动。不是只有成绩才能反映人的学习能力的。其实我的专业课都相当不错，如果你有疑问，可以当场测试我的专业知识。”Michael巧妙地绕开了令人尴尬的问题，将考官的注意力引导到他最拿手的专业知识上。

　　诱导式的语言陷阱。这类问题的特点是，面试官往往设定一个特定的背景条件，诱导对方做出错误的回答，因为也许任何一种回答都不能让对方满意。这时候，你的回答就需要用模糊语言来表示。

　　如：“依你现在的水平，恐怕能找到比我们企业更好的公司吧？”
　　如果你的答案是“YES”，那么说明你这个人也许脚踏两只船，“身在曹营心在汉”。如果你回答“NO”，又会说明你对自己缺少自信或者你的能力有问题。

　　对这类问题可以先用“不可一概而论”作为开头，然后回答：“或许我能找到比贵公司更好的企业，但别的企业或许在人才培养方面不如贵公司重视，机会也不如贵公司多；或许我能找到更好的企业，我想，珍惜已有的最为重要。”
　　这样的回答，其实你是把一个“模糊”的答案抛还给了面试官。

　　还有一种诱导式的语言陷阱是，对方的提问似乎是一道单项选择题，如果你选了，就会掉进陷阱。比如说，对方问：“你认为金钱、名誉和事业哪个重要？”

　　对刚毕业的大学生来说，这三者当然都很重要。可是对方的提问却在误导你，让你认为“这三者是相互矛盾的，只能选其一”。这时候切不可中了对方的圈套，必须冷静分析，可以首先明确指出这个前提条件是不存在的，再解释三者对我们的重要性及其统一性。
　　你可以这样组织语言，“我认为这三者之间并不矛盾。作为一名受过高等教育的大学生，追求事业的成功当然是自己人生的主旋律。而社会对我们事业的肯定方式，有时表现为金钱，有时表现为名誉，有时二者均有。因此，我认为，我们应该在追求事业的过程中去获取金钱和名誉，三者对我们都很重要。”

　　与此相类似的还有一种误导式陷阱。面试官早有答案，却故意说出相反答案。若你一味讨好，顺着面试官的错误答案往上爬，面试的结论一定是：此人无主见，缺乏创新精神。自然被列为淘汰之列。

　　还有一种测试式的语言陷阱。这类问题的特点是虚构一种情况，然后让求职者做出回答。比如“今天参加面试的有近10位候选人，如何证明你是最优秀的？” 这类问题往往是考察求职者随机应变的能力。无论你给自己列举多少优点，别人总有你也许没有的优点，因此正面回答这样的问题毫无意义。你可以从正面绕开，从侧面回答这个问题。

　　你可以回答说：“对于这一点，可能要因具体情况而论，比如贵公司现在所需要的是行政管理方面的人才，虽然前来应聘的都是这方面的对口人才，但我深信我在大学期间当学生干部和主持社团工作的经历已经为我打下了扎实的基础，这也是我自认为比较突出的一点。”这样的回答可以说比较圆滑，很难让对方抓住把柄，再度反击。

　　有时，面试官还会提出这样的问题：“你对琐碎的工作是喜欢还是讨厌，为什么？”
　　这是个两难问题，若回答喜欢，似乎有悖现在知识青年的实际心理；若说讨厌，似乎每份工作都有琐碎之处。因此，按普遍心理，人们是不愿做琐碎工作的（除非特殊岗位，如家庭钟点工），即考官明知故问，我们可以推测出其醉翁之意不在酒，而在“工作态度”。

　　我们可以这样表述自己的态度，“琐碎的事情在绝大多数工作岗位上都是不可避免的，如果我的工作中有琐碎事情需要做，我会认真、耐心、细致地把它做好。”
　　这句话既委婉地表达了大多数人的普遍心理——不喜欢琐碎工作，又强调了自己对琐碎事情的敬业精神——认真、耐心、细致。既真实可信，又符合对方的用人心理。

　　在各种语言陷阱中，最难提防、最具危险的，可能要算“引君入瓮”式的语言陷阱。

　　比如，你前去应聘的职位是一家公司的财务经理，面试官也许会突然问你：“您作为财务经理，如果我(总经理)要求你1年之内逃税100万元，那你会怎么做？”如果你当场抓耳挠腮地思考逃税计谋，或文思泉涌立即列出一大堆逃税方案，那么你就上了圈套，掉进了陷阱。因为抛出这个问题的面试官，正是以此来测试你的商业判断能力和商业道德。要记住，遵纪守法是员工行为的最基本要求。

　　比如，你正要从一家公司跳槽去另一家公司。面试官问你：“你们的老板是不是很难相处啊，要不然，你为什么跳槽？”也许他的猜测正是你要跳槽的原因，即使这样，你也切记不要被这种同情的语气所迷惑，更不要顺着杆子往上爬。如果你愤怒地抨击你的老板或者义愤填膺地控诉你所在的公司，那么你一定完了，因为这样不但暴露了你的不宽容，还暴露了你的狭隘。

　　面试中，面试官也许会设计出各种各样不同的语言陷阱，但是只要看准了，兵来将挡，水来土掩就是了。

如何做一名成功的IT工程师

admin — Mon, 06 Apr 2009 11:59:53 +0000

进入到IT这个技术圈，很多人是从工程师开始做起的，那么如何成长为一名成功的工程师呢？或者是如何成功地转换为下一个角色呢？你需要做哪些准备呢？作为MDE（Market Development Engineering）的工程师和产品开发的工程师，还是有些不同的，我下面重点想说的是比较通用的。

让我们先来看看成功的工程师是什么样子。在Sun公司里，工程师分为4个级别，从低到高依次是工程师（Engineer），高级工程师（Staff Engineer），杰出工程师（Distinguish Engineer），科学家（Fellow）。在工程师这个级别里又分为MTS1-4，也是依次从低到高的。Fellow，SUN公司总共没有几个，James Gosling是其中的一个，Bill Joy也是，最近离开SUN了，去开startup了。Sun的中国工程研究院（ERI）原来有DE，就是宫力，现在已经他离开了，暂时还没有。Staff Engineer，ERI有几个rotation过来的。不知道大家是否还记得James Liu，在MDE week上给大家烧烤的那个，他是Staff Engineer, 但我记不清楚他是否Senior Staff。

从一个MTS1或MTS2工程师做起，怎么准备自己走到下一步呢？一个很重要的概念就是管理自己：管理自己的目标，管理自己的时间，管理自己与其他人的沟通。

第一，要给自己设定一个目标，可以和自己的经理聊聊，自己的下一步在哪里，自己的优势在什么地方，通常他们会给出比较诚恳的建议的。我建议在制订这个长期的目标的时候也不要太长，比如说10年，那就太长了，说老实话，在20-30岁的这个阶段，3年后发生什么事情我们很难预测。所以我建议这个目标可以订的短些，比如2-3年。

第二，结合长期目标，给自己制定短期目标，比如说一年的，半年的，一个季度的，等等。制订目标的时候，有个SMART方法，想必大家都知道：s（specific，具体的，不能说空话，要用数据和时间说话）、m（measurable，可衡量的）、a（agreed，双方都同意的）、r（realistic，可实现的，可以达到的）、t（timebonded，有时间性的，可以考核）。

第三，在设定的时间，回顾自己的目标，检查完成的情况，如果没有完成，要总结是什么原因，并适当调整目标。

第四，管理好自己的时间，检查自己的大部分时间都在做什么，是不是在做最重要的事情，是不是大部分时间做了些不重要的事情，可是最重要的时间却没有时间做。管理时间需要对自己的工作进行优先级的评估，优先处理最重要的工作。发现了问题之后就要调整自己的习惯或方式，节约时间。随着你的级别越来越高，你会发现你的时间越来越少。可是你的加班不能无限延长，你还需要时间陪伴你的家人，你也需要时间休息。

第五，积极地学习。活到老，学到老，这句话没有错。有的工程师发现了一个正在进行BETA测试的新产品，认为对自己以后的工作有帮助，就马上拿来装上使用一番。有的工程师经常阅读和自己工作相关的各种标准和规范，对提高自己起了很大的作用。学习的范围要逐渐的宽一些，不要总是局限在纯粹的技术上，可以适当地学习些软技巧或商务等方面的知识。

第六，能够做决定。一个级别高的工程师，有责任做相应的决定。你的老板不会为你做所有的决定，你需要和你的老板商量，哪些是你应该做决定的，自己要把这些责任承担起来。最重要的决定是决定要做什么，如果这个决定没有做，那么尽管工作得再漂亮，到最后可能发现原来根本就是浪费时间。为了做正确的决定，你需要搜集相关的信息，没有足够的相关信息，可能做出的决定也是错误的。

第七，积极地沟通。谁是你最重要的客户？或者最重要的stakeholder？你的工作对谁影响最大？不要被动地等他们来找你，而是主动地去找他们，询问他们最关心的是什么，利用你的知识和经验，向他们建议哪些对他们最重要，提前和他们沟通项目计划，等等。工作展开后，要有定期的状态更新，碰到计划为的状况的时候，要立即和相关人员进行沟通。另外，找机会多和一些比你级别高的人或更有经验的人聊聊，有时候他们给你的一个建议，或无意中说的一句话，都会给你很大的启发。和他们的聊天，也经常能够给你些激励。

第八，认真地写报告。很多人不重视写报告或技术文档，这不利于工程师的成长。写报告是沟通的重要的环节。写报告的时候，首先要确定你的报告是写给谁的，谁在关心这个报告，关心的内容是什么。可以把自己想象成看报告的人，最想通过这个报告了解什么。报告也不仅仅是给你的老板看的，对于MTS4或者更高级别的晋升，是需要跨部门的讨论的。在一个10-20人的团队里，大家可以容易互相了解，在一个100人的团队里呢？就无法做到这点了。怎么让其他的团队里的人了解你的优点和技术专长呢？如果他们看到过你的报告，是很容易判断的。

总而言之，首先要定义自己的目标，然后学习和实践，通过证明自己的能力，最后的成功是水到渠成的。

IT路要如何走？——老程序员的10个忠告

admin — Wed, 01 Apr 2009 06:52:37 +0000

[1]好好规划自己的路，不要跟着感觉走！根据个人的理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深入了解，不要频繁跳槽，特别是不要为了一点工资而转移阵地，从长远看，这点钱根本不算什么，当你对一个行业有那么几年的体会，以后钱根本不是问题。频繁地动荡不是上策，最后你对哪个行业都没有摸透，永远是新手！　
　　　　
　　 [2]可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！　　　
　　 [3]不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。8057很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角落看示波器！技术以外的技能才是更重要的本事！！从古到今，一律如此！　　　
　　 [4]多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌撞撞，遇到重重困难，交不少学费，成功的概率大大降低！
　　 [5]知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务，法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！　
　　 [6]抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！　　　
　　 [7]逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱），犹豫不决，胆怯，多虑，教条式思维等，这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个月地摊，包准有效果，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好 ——尽管你可能技术不错！　　　
　　 [8]工作的同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！　　　
　　 [9]要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会…　　　
　　 [10]该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功！

计算机与文学修养

admin — Wed, 01 Apr 2009 06:50:38 +0000

最近在看一些文学书籍，收获颇大，琢磨着把自己的感想写出来，希望能给大家一些启发，当然能引起共鸣就更好啦。
　　
　　
　　
　　说起在看什么书，具体说不清，反正是在看王小波的杂文。里面很多观点很有创意也很有启发性，个人感觉是相逢恨晚。虽然是文学书籍，但是里面的内容却很启发人，无论是对学习哪个方向的人都一样，所以希望大家有时间多点看书，尤其是多看好书。
　　
　　
　　
　　看书的过程中，越来越发现自己在这几年感觉到不足的地方是什么，原来一直阻碍我在计算机能力方面发展的因素竟然是文学修养，这是意料之中也是意料之外，说是意料之中是因为自己一直有这个感觉，只是不敢承认，说是意料之外是因为自己果然猜对了，可惜没有认真对待。
　　
　　
　　
　　文学修养对计算机能力的影响，最简单一个就是一个人的文学功底对个人的阅读和理解能力有极大的影响。拿学生来说，教材是相同的，为什么有些人看一遍就明白，有些人看一遍就融会贯通，而有些人看十遍还不明白，其中排除天赋意外，其中一个就是文学功底的不一样，文学功底的不一样直接导致理解能力和吸收能力的不一样。鉴于此，该如何提高个人的阅读能力和理解能力呢？很直接很有效的方法：多看好书。至于什么是好书，我以为能给你以启发的，不会把你误入歧途的书都可以算是好书。不要告诉我你不知道什么是好书，因为我肯定你知道什么是坏书，从这个层面来讲，不是坏书就是好书。对于好书，我们要多看，不要挑剔太多，可能刚开始你会觉得不耐烦，这个时侯只要你能坚持下来，静静的把在网络上闲逛的时间用来把书看完，我敢肯定你有感觉到一个提高的感觉。其一是你能克制自己上网的欲望，这对自己来说是一个胜利的感觉，很好！其二，通过看书，你能明白一些原来你没接触过甚至连想都没想过的道理和事物，这个给人以启发。其三，在你看书的过程中，潜移默化之中会陶冶你的情操，提高你人生的境界。
　　
　　
　　
　　可能你会觉得上面说的和提高你的计算机能力无关，如果你真这样想的话，就大错特错了。看书是从内里改变一个人的性格和情绪甚至习惯，是一个根本的过程。看书是从内里把你自己改变，如果你知道自己的缺点，在看书的时候能着重去改正，这样收获就更大了。举个简单的例子，学计算机的人在外人看来都很急躁，原因是什么，我也不明白，但是我知道通过看书，多看书，多看好书能把这个毛病彻底改正，因为一本书再少也有一百多页，你能一次把它看完，并能领会它的思想的话，这个过程除了潜移默化之外，还有一个就是需要你的耐心。而耐心恰恰就是克服急躁的良药。
　　
　　
　　
　　学计算机的人很多时候并不缺乏专业知识，可是为什么就达不到自己的效果呢，我们不停的去看，同样的知识，看了有看，程序写了又写，可是为什么就是提高不了呢，最重要一个就是我们的程序缺乏神。而多阅读文学书籍却能在这方面得到很好的补充。以前本人也有同样的误解，以为学计算机的人只要把专业知识掌握了，就能写出好程序。可是专业知识学了那么多，代码，语法，原理都懂了。可是为什么就总是跟着别人的脚步走呢？就是因为我们缺乏自己的精神，说到这里，我想大家应该懂了吧？
　　
　　
　　
　　其实，编程就像学习写文章，先学习单词，然后学习语法，再然后学习造句，最后才是学习写文章。目前我们的学习并没有遵循这样一个途径，学习单词和语法以后，直接就是写文章，虽然是先写小文章再写大文章，但是毕竟跳过了一步，收效毕竟差了点。而且这个过程中很重要一点就是我们缺乏对“单词”的足够认识和理解就迫不及待的想要动手，虽然多动手是好事，但是乱动手未免会形成不良习惯，有时候还会打击到自己的信心，这可是得不偿失啊。所以说耐心是学计算机人的必须。循序渐进，一步一个脚印才是掌握计算机技术不变的真理。
　　
　　
　　
　　再回来谈编程，写一个好程序就像写一篇好文章，是否足够简洁、是否足够明了，是否足够严谨、是否有说服力（在程序上是否高效）都决定了你的文章你的程序的好坏。个人认为一个人的写作水平与一个人的编程水平有莫大的关系。因为写文章的构思过程与写程序的构思过程是类似的，有时候你写程序的时候遇到了问题找不出来，通过看文章或是自己随便写的什么很多情况下会有所顿悟，在这个我有切身的感受，在对着代码无语的时候我会随手拿起本书来看，或是到空间上随便写的随笔之类的能得到很大的启发。所以培养一个人的写作水平对于提高一个人的编程能力很有帮助。而怎样提高一个人的写作水平，最简单直接的方法就是多阅读好文章，潜移默化之中提高自己的整体思维进而影响编程能力。构思一篇文章，设计一个小故事，你不觉得跟构思一个程序很像吗？
　　
　　
　　
　　会写程序不难，难是难在写好程序就好像文章人人会写，写得好不好又是另外一回事。所以就出现了专门写文章的人，我们称之为作家另；外一类是专门写程序的人，我们称之为程序员；而一般的只会写程序而没有自己的思想指导的，只遵循一个惯性来写程序的人，我们称之为代码工人。对于代码工人，我们国家有很多，而真正才程序员却没有多少，就好像现在市场上写书的人越来越多，好书却越来越少一样，就是灵魂的缺失，就是急功近利的后果。
　　
　　
　　
　　我们写文章从记叙文开始写，同样，我们学习编程也是从“记叙文”开始写，写着写着差别就出来了，有些人的记叙文写了十几年还是一样，而有些人的记叙文却越来越精彩。其中有一个就是文学功底的不一样，再过一段时间，写得好的人就开始学习写议论文了，论据论点很充分，这个时侯就开始第二阶段的分化了：议论文写得好不好一个就是结构是否严谨、论据是否充分、论点是否明确、中心是否突出，就像编程的时候，各个部分的编写和安排是否合理，代码是否足够简洁高效，别人看起来是否清晰一样，这两个分化我暂时称之为一般的议论文和简洁有力的议论文，放在计算机编程上面来说就是可运行代码和高效代码。我们现在能达到前者的人估计不少，但达到后者的人估计不多，再然后进行第三次的分化，真正的程序员就诞生了，文学上就是真正意义上的作家（不是那些为了钱和迎合潮流而蛊惑大众的人），就像写作上的杂文和短篇小说，不要说杂文人人都会写，虽然说什么文体都不是的文章就叫杂文，但是我怕你写的杂文什么都不是。一篇好的杂文和一部好的小说，能把一个作家的思想有力的表现出来，让你读起来的时候没有感到一丝一毫的多余，而中心却又非常的明确，这就是真正程序员的高效代码。一篇好的小说，短短一千多字或者简简单单的几百字可以比一部长篇小说更感人肺腑，更能令人耳目一新，高效的代码也是一样，简洁但功能齐全高效而不搞笑，什么叫不搞笑？就是运行的时候不会出差错，叫人看笑话。这里面就有一个思想在里面，程序以正确高效、简洁、可见、可显、可维护为宗旨，庞大臃肿的代码就像一堆垃圾，怎么挑都挑不出精华。看好程序就像看好文章，我们在阅读别人的高效代码的时候，又有谁看到了人家的思想？或者只是简简单单的看到人家的高效而已？我们看的目的是领悟，而不是看也不是背。当然背比看要好，而领悟又比被要好。更严重的一个问题是：你看了吗？
　　
　　
　　
　　有过团队协作的人都知道，在一个团队里面，沟通是很重要的。但是大家是否发现，团队各成员之间的沟通是否存在问题呢？我们虽然拥有同样的母语，现在大家在同一个环境里面生活，但是我们来自各个地方，背景不一样，生活习惯不一样，同样的，我们的表达方式不一样。所以，沟通就是一个很大的问题，究其原因，其中一个表达不够严谨。简单举个例子，假设我家住在你家旁边，然后你问我，我住在哪？我的回答是，住在你家旁边。这个回答看上去没有问题。可是细想就发现问题了，这个附近的范围是多大，要求再严谨一点就是我家附近那么多房子你全住了吗？还有一个就是如果我家有两个房子，你说的是哪一个啊？当然，再说下去未免有吹毛求疵之嫌，可是问题的确是出来了，而且这个问题很明显，这就是一个表达不清的典型例子，不够严谨。如果你回答是什么街道几号这样的话又未免太严肃，令人咂舌，日常对话这样说未免让人怀疑有病，我们正常人说正常话，不过要严谨清晰一点。好一点的回答应该是这样的：“就在你家出门左手边第6个房子。” 这样说起来很明确不会引起误会。当然你要说第二间是从我家开始数起还是从哪里数起这样计较的话，我也没话好说了。现实上，这样说话的人很少，大家可能觉得这样说有点奇怪，其实就是因为现实上大家说话都不严谨所以就导致了我们编程和写文章都不严谨，一个大家都拥有的坏习惯就变成了一个好习惯。我们老是会觉得自己认为是这样别人也应该认为是这样，这时孟子教给我们的推己及人的方法，在中国存在几千年了，也难怪。可是没人告诉你，孟子的话就一定是正确的，就好像当年那个皇帝说：“没饭吃为什么不吃肉？”一样愚不可及，以己度人未必真，人与人之间是不一样的。所以大家应该在写文章上面做到严谨，同样在编程的时候要注意表达明确，程序简洁可读。当然，如果你想惩罚日后看你代码的人的话又另当别论，可是我怕到最后你自作自受。
　　
　　
　　
　　经常看书的人都会有这种感觉，觉得作者有时候表达不清，觉得有歧义。这个正常，现在的书多如牛毛，质量参差不齐，所以我们更要慎重的选择自己看的书，主要一个就是防止被传染，被带坏了。看到乱写一通的不要犹豫，扔了。选书是一个过程，看书是一个过程，看好书是一个漫长的过程，前面两个过程把握不好，最后一个过程遥遥无期，希望大家慎重。看书要看好书，同样写程序也是一样的，写程序就要写好程序，要给自己形成一个写好程序的习惯。专业课本上的知识教会你怎么写代码，怎么编程才能正确执行，这个毫无疑问，而一本好书，能教会你怎么写好代码，怎么写才写得心情舒畅，到最后连看的人也觉得如沐春风。这两者的区别就是：科学与艺术。前者是科学，教你怎么做正确，后者是艺术，教你怎么做好。写字也有好坏，何况编程呢。
　　
　　
　　
　　多阅读一些好文章，能提高一个人的思想修养，也能陶冶一个人的性情，编程最忌心浮气躁，多阅读好书，培养一个好的性情，营造一个好的氛围，制造一个好的坏境能让人心情愉快的工作，把编程变成一个享受的过程而不是任务和压力。当然，兴趣所在就更不一样。文学修养的提高在于提高一个人的思想水平，一个人的思想水平如何直接影响到一个人的编程习惯如何，这是由内到外的。有人说，多写些程序就好了，慢慢就会写出好的代码了。对于这个观点，我有不同意见，首先，多写程序是应该的，但是我认为多写烂的程序只会让写的程序更烂；再一个就是写出好代码的问题，我实在想不出在前一个前提的情况下，这个好代码是从哪里出来的，难道不停的制造普通钢板就能制造出人造卫星了吗？未必吧，只怕出来的连人造卫星的模型都不如，到头来还是普通钢板，可能还会因为机器陈旧而制造出质量更次的钢板。
　　
　　
　　
　　在培养计算机人员的文学修养方面，我们国家现在的教学目前还是空白的，从这个层面来说，我们国家的学生想在计算机工作方面摆脱代码工人的困境还是有一定难度的。通过对一些大学4年的课程安排可以看出，教我们怎么写代码的课程很多，可以说是太多了。读过大学的人都知道，我们思考的时间太少，作业太多，告诉我们要认真学习的话太多，告诉我们要如何学习才能提高我们能力的太少。可是大家忽略了一个很重要的事实，就是授之以鱼不如授之以渔，学习写代码是鱼，而学习怎么写好代码才是渔，那才是真正的精粹所在。对此，我认为，学校应该恰当的安排适量的文学课程是有必要的，原因有二，其一，从思想上提高大家的编程水平；其二，给学生一种文学上的氛围，我以为，那比同学间比赛写代码更重要。为了防止误解，我解释一下第一点，我说的思想上的正确引导，不是指毛泽东思想，邓小平理论三个代表之类的深奥理论，而是活生生的给大家一些好的思想，包括正确的人生观、价值观和世界观。最重要的是这个文学课程是不以提高就业率而设的，不然肯定会变质！
　　
　　
　　
　　关于文学修养，说了不少，现在说些具体一点例子，编程经典：Unix编程艺术。这本书怎么出名就不用我说了。可是我们要看它不是因为它出名，要看出名的可以到网上去看当红的影星歌星。我们要看的是这本书的内容，领会这本书的精神。里面谈到很多关于如何写好代码的意见，包括作者的很多切身感受，论代码量，估计我们加起来也比不上人家吧，所以这本书绝对值得大家一看。不知道大家是否看过这本书，是否有所感悟，这本书真正提到代码的地方很少，但是却能很正确的指引你怎么写好代码，能告诉你什么才是一个好的程序，能告诉你什么才叫艺术，要想从代码工人上升为程序员，我认为看这本书，理解这本书，并运用这本书的精神去编写我们的代码这三个过程绝对是必不可少的。当然，一家之言，不足为训。
　　
　　
　　
　　众所周知，国家兴办教育事业是为了培养人才，提高整个社会的水平，是想让各位成为社会的栋梁之才，为了早日实现我们国家的繁荣富强的。现在的情况还不算太坏，顶多培养了一批代码工人，而这些代码工人对社会是无害的，可是也有个别例子，马加爵不是学计算机的我们不算他，熊猫烧香事件估计大家还没忘记吧，一只熊猫三支香，整个社会乱慌慌。当然，后面这句话是我自己写的，可是这是我的切身感受，当时的感觉就是这样，每天的新闻都看到熊猫烧香早成什么什么损失，每天新感染多少台主机，出现多少个变种，为害直逼毒王宝座。熊猫烧香的代码写得怎样我不去讨论，因为我不够资格，熊猫烧香的作者不是大学生我也不说，我只说一个成功的教育是不会培养出这样的社会毒瘤的。后来很多人说这个病毒的代码并不复杂，我也不能发表什么评论，我只说说自己的感觉，就是那么多高科技人才（指计算机专业的）为什么就对付不了这只熊猫呢？最后好像还是作者本人自己写的杀毒程序吧。现在我的观点是，代码工人是对付不了这只熊猫的，真正能对付这只熊猫的是本文所说的程序员，有写好代码的能力，也有写好代码的精神。可是这个人，当时在哪里呢？从根源来讲，没有程序员不是大问题，问题是没有程序员也不能有毒瘤。毒瘤的出现恰恰就是因为我们国家在培养人才方面缺少对一个人的文化修养方面的培养。缺少对学生正确价值观和人生观的指引。而很多文学方面的书，却恰好能弥补这个缺陷，从思想上给我们指引，引领着我们学习和生活。如果我们的教育是成功的话，就不会出现一个人为了金钱去做为害整个社会的坏事，当然这个问题说开去太深奥了，不是本文的讨论范围。我们退出假设，返回现实，现实是毒瘤已经出现了，我们的程序员在哪里？

从技术人员到行业专家

admin — Wed, 25 Mar 2009 03:11:22 +0000

在个人成长过程中外部环境因素固然很重要，但决定个人命运的其实却是自身不安于现状，勇于超越自我，否定自我的求变精神。

“我应该朝哪个方向发展？我真正的追求在哪里？我不做这个还可以做什么？”这是师弟们常问我的问题，但我也经常被同样的问题困扰。消极的或是不愿改变的人可能会说：我还能做什么啊，不会别的，只能做这个了，其实我认为一个IT人还是有很多出路的，比如：可以钻研技术以成为技术专家、从项目管理成长为职业经理人、从需求分析过渡为咨询师、售前支持、从投标讲标谈判变为销售经理，你做乙方也许也会被甲方看中，转成客户方的技术人员，转行也是一个方向（好像最近网络上那个地产美女还是程序员出身），如果你的客户是做外贸的，也许你找准机会从他的供应商摇身一变就成了他的竞争对手。如果以上选择都不适合你，还有一个方向：从开发人员到行业专家。今天我来谈谈从开发人员成为行业专家所经历的几个阶段：

1.第一阶段海纳百川兼收并蓄

不少技术人员在毕业的前几年存在这种思想，认为我在学校数据结构是拿高分的，XX语言是很精通的，我能写出很“Sharp”很“牛”的程序，我的同学谁谁谁又掌握了某种新技术，我也不能落下，可老板却让我放下手中的程序去和客户学业务、做需求，甚至是用户培训或业务测试，烦人！懊恼！没劲！总是很郁闷，提不起一点兴趣，觉得简直是荒废自己的“武功”，浪费自己的时间，“我只管开发，不懂也不想了解业务”更愿意把精力和兴趣放在研究技术和揣摩产品本身上。其实这算是技术人员的通病，总是以技术和产品为中心的“本位主义”思考，而实际上无论是编程语言还是技术产品，都是解决现实人类问题的“工具”，当这个“工具”真正解决了问题，被很多用户在“用”时，才是技术人员最Enjoy，技术最有价值的体现，如果这个工具不是围绕实际问题而展开，不能满足于现实需求，就变成了个人爱好的“玩具”，失去了市场价值。

一个技术人员应当明白只钻技术，不问业务的态度，永远也造不出“物有其用”的工具，难以释放技术与产品的高科技力量，当然自身发展也受限受困，难以成长。如何才能获得客户的认同，做到“言用户之所言，想用户之所想”呢？这需要技术人员放下自己的技术架子，从零开始学习了解用户工作中所用到的专业知识、行业现状、发展方向、法律法规、政策环境等。获得客户认同的第一步，就是从与用户以用户的语言沟通开始的，这些“行话”是建立在对客户专业知识的一定程度的学习了解之上的。有了沟通，才能更好地得倾听用户的诉求，理解用户的反馈。只有积极学习客户业务，理解和洞察客户需求，从业务需要为出发点，才能将手中的技术转化为有价值的工具，才能与客户共同成长，发展共赢。
“一专多能”的人才受市场的青睐，“双学士”价值大于硕士的现状都在告诉，知识多样化的重要性和价值，而接触和了解一个陌生领域，与这个领域中的优秀人才进行思想火花的碰撞，迅速吸收他们累积多年的思想营养，是个人成长不可多得的好机会。
放下对“非技术”的抵触情绪，试着去理解你的客户，倾听他们的声音，学习他们的业务，才会赢得用户的“拥抱”，获得技术的最大成功――用户的认可和市场的回报。

2.第二阶段业务导向技术推动

摩尔定律预言了计算机硬件的更新速度，也决定着技术规范和产品的发展速度，每年每月每天都有新的技术理念和技术产品诞生，半年前还是很热门的技术，现在就可能被淘汰或取代，似乎半年不学新技术，技术人员心态上可能就有面临失业风险了。学习积累的速度永远赶不上知识更新淘汰的速度，很多做了5年的程序员都有这样的感慨：“技术发展太快了，我才用上了2.0，就出来了3.0！做技术太累人了，我学都学不过来！”

事物发展总是遵循着螺旋上升发展的趋势，从可操作性强的Client客户端应用到易管理维护的Web网络应用，再到SmartClient智能客户端和AJAX等Web2.0技术的出现，从C++和Smalltalk到Java和C#，每一种新技术，总会给人似曾相识的感觉，只要理解技术的核心思想，掌握技术的灵魂精髓，就可以“以不变应万变”，通过自身的技术积累“四两拨千斤”地用很小的学习成本掌握全新的技术，学习曲线可以很平滑。技术的积累是如此，行业知识和经验的积累更是如此，因为相较于日新月异的计算机和网络技术，行业知识和用户需求调整变化速度就要慢的多，更容易积累，也更有延续性。

“OnDem_and”不只是一句告知客户的广告语，更是在提醒产品与服务的提供者，只有理解客户的业务、顺应客户的需求才能提供令客户满意的产品与服务。应当以一个用户角色的眼光去重新审视为用户提供的技术解决方案和产品，是否是用户所真正关心的，是否真正解决了用户的问题。在此过程中，技术人员不仅学习积累了行业开发经验，而且对技术和产品本身也会有更深的理解，综观工作三四年以上的技术人员，面试官和猎头们最在意的并不是他所掌握的技术语言，而是他的项目经验和行业积累，这些经验和积累，是源于客户需求和行业知识的，价值远比会几种新技术大的多。

对于客户而言，最有价值的不是你掌握哪些技术，而是你能帮他们解决哪些问题。做到以业务为牵引导向，以技术为推进动力，理解和分析客户需求，组织和善用所掌握的技术，才能赢得市场，求得技术产品和个人的生存发展。

3.第三阶段业务至尊善变为王

作者以前有一位女领导，是从最基层的程序员做起的，曾经担任过国家某政府机构大系统XXX2000的项目经理，毫不夸张地说，她比政府机构的业务人员更懂行业业务，因为政府的业务人员和管理人员们都是各管一段，而她对各项业务的详细流程和逻辑、分支局业务、总局监管了如指掌。当她成为我的领导时，已经是该行业的一位资深业务专家，每有该局的业务信息化会议时，几乎有不请她就撑不起会议台面的感觉，当他们要进行流程和管理的一些改革时，总会听她的参考意见，是真正的非官方权威业务专家。当你比客户更了解客户的业务，比客户更知道客户的所需时，就可以剖析客户的业务，发现其中的不足，结合信息化技术的发展变革，为客户提供量体裁衣的他们最迫切需要的新体系新方案。这个新体系新方案当然不能仅仅是从技术出发的新体系新方案，而是从商业模式上、业务流程上、管理理念上提出的新模式，并提供与之配套的技术解决方案。在当今市场竞争日趋激烈的今天，“求变”已经是必不可少的生存法则。这个求变的过程，也是技术人员从被动接受业务知识到主动改写业务知识的完美蜕变。远到亚玛逊，近到阿里巴巴，无不是深刻理解和剖析了行业业务，颠覆传统理念，打破原有流程，推出全新业务模式，创造了一个又一个的商业奇迹，在这些耀眼的巨星光芒中，有无数的智慧在闪烁，而这些闪烁着的智慧，折射着那些懂得如何用技术工具完成业务模式革命的“影子战士”的积累和行动。

技术只是业务变革的推进动力和实现工具，能在技术层面支持用户的需求只能说“称值”，而如果能在业务层面引领用户行业进行业务变革和流程改进，那才是技术人员的“至尊境界”。当一名技术人员通过多年的业务积累，达到“一览众山小”的境界时，可能就会发现，职业和事业的发展视野，都可以打开“山外青山”的局面。职业方面可能承接对你高度认可的客户方抛来的橄榄枝，成为实至名归的行业专家，又或者拥有更大的抱负，想要以厚积而勃发的积累开创自己的事业，相信，你会感激和回味你我都曾无怨无悔地走过的IT路。

老牛仔麦克尼利的临别箴言

admin — Tue, 24 Mar 2009 14:08:14 +0000

IBM收购SUN已经进入尽职调查阶段，老牛仔麦克尼利领导的SUN日子也许屈指可数了。当年誉满天下的天才领袖中，比尔.盖茨仍然是世界首富，乔布斯仍然独树一帜，而牛仔麦克尼利也许什么都不能留下来，甚至硅谷著名的坏小子拉里.艾莉森的甲骨文帝国处境也远远好于SUN。陨落的SUN没有阳光！

　　IBM收购SUN，对双反的股东而言或许是好事。收购消息一经披露，SUN的股价就大涨80%。至少以宣布的67亿美金收购价看来，SUN的价值在金融危机中被低估了。

SUN每次媒体会议必亮的家底

　　但是对用户而言，这多半是个坏消息。IBM对SUN的收购，意味着在大型机和UNIX市场，IBM的垄断地位更加坚固，定价权更加突出，用户讨价还价的余地更小。

　　正如麦克尼利去年访华时所描述，IBM大型机业务在去年第三季度还有所增长，因为IBM将收费大幅度提高了。麦克尼利描述IBM的大型机是一个退出成本十分高昂的选择。设想一下如果用户选择放弃价格百万美元的大型机系统，单在财务上就将是一个艰巨的成本核销任务，更不用说大量应用移植的困难。

　　因为HP与康柏的合并，UNIX阵营中著名的Alpha芯片基本上被放弃了，连HP自己的PA-RISC也放弃了开发。当时主政惠普的卡莉这样来解释这个决断，单独维护和开发一个封闭系统成本高昂，更不用说是两个，因此惠普在UNIX转向了与Intel联合开发的安腾产品。但是安腾并没有给惠普和Intel带来什么压倒性优势，反而在大型机市场促成了IBM一家独大。

　　就在前不久，惠普和IBM还因为一份分析报告而打起了口水帐。在惠普资助的一项研究报告中，惠普引用Robert Frances Group结论说惠普的Integrity相比IBM Z系列大型机更能节省成本。旋即IBM的公关公司就发来了Robert Frances Group关于大型机的声明，Robert Frances Group首先否认了惠普关于成本的说法，然后重申了大型机任然是综合成本最优的选择之一。

　　IBM和惠普的口水仗是个小事，但是UNIX市场的销售额却占到了整个服务器市场的接近50%。这也是为什么惠普服务器销售台数远超过IBM，但是以销售额计算IBM任然是全世界服务器的老大。而SUN也仅凭销售数量远不及戴尔的UNIX系统而跻身前四。

SUN T5220 在2U的高度集成2个CPU16个核心128个线程

　　JAVA、MySQL、Solaris这也许是IBM看重SUN的理由。不过SUN每个产品IBM都有更强大的对应，例如DB2、AIX。在SUN的官方网站上，有一个SUN新进推出的T5440与IBM 570系统的性价对比。IBM 570上运行的AIX操作系统是按照核心数量收费，32核心的570系统，仅AIX许可收费就高达40000美元，接近30万人民币。而SUN的Solaris则是免费！从这个角度看，SUN的亏损和IBM的盈利就不那么难以理解。

　　同样，MySQL也是免费，而关于DB2的描述，从来就没有便宜这个词汇。至于JAVA，SUN重来没有在上面盈利，而利用JAVA作为开发工具，IBM的中间件却大赚其钱。

　　去年底，老牛仔麦克尼利中国行尽显老态，激情不再。当年煮酒的伙伴盖茨已经功成身退专心慈善，英雄乔布斯虽然与病魔抗争，但是iPOD和iPhone的成功塑造了苹果的健康。只有SUN在危机中苟延残喘。

　　面对无数的指责，麦克尼利说SUN仍然是一家伟大的公司，SUN保持着正向的现金流，SUN在技术研发上仍然保持着每年近20亿美元的投入，SUN保持着有1300万个Solaris的许可，600万JAVA的开发者以及截止到去年近30亿美金的现金……

　　但是SUN在经济危机中失血不止，面对去年第三季度SUN16.5亿美元的亏损，老牛仔也仅能搪塞，他说SUN面对着一个周期性的行业。确实，在经济危机中SUN的重心北美是重灾区，而SUN的最重要行业市场金融、电信就更是重灾区。可以想见，目前正急于保命的美国金融机构几乎不能给SUN带来任何新增收入，全球多数金融机构失血的状况要远远超过SUN。这是老牛仔无能为力的“百年难遇”。

　　跟保命相比，麦克尼利布道的开放和开源仅仅是远水，不但解了不了近渴还会削减更多的短期收入。开源的MySQL、JAVA以及Solaris能取得市场，但是却没办法帮助SUN渡过危机。

　　SUN引以为荣的UltraSPARC本来有机会焕发出新的生命，自包含CMT（芯片多线程）技术的T系列服务器上市，SUN在互联网应用中取得了性能和能耗的压倒性优势。SUN UltraSPARC T2一个芯片包含8个核心，每个核心包含8个线程，这就意味着每个芯片可以包含高达64个线程。虽然现在交付的T2芯片主频还不高，不过1.6G，但是对高度并行的互联网应用而言，多核心多线程技术显然比高主频具有更大的优势。而目前不论是互联网公司还是传统企业，使用WEB技术已经成为趋势。

　　实际上2007年发布的UltraSPARC T2本来有机会为SUN重获新生。2008财年第二季度，Sun的订单数量增长了22.8%。基于UltraSPARC T2处理器的服务器在新兴市场的同比增长几乎达到100%。但是突如其来经济危机让这一切嘎然而止。

　　集成虚拟化、信号处理、网络连接、安全特性、浮点单元和加速内存访问等等功能并在单芯片提供64个线程，仅90瓦的功耗，与同样是2007年发布的Power6形成鲜明的对照：Power6仅有两个内核但是主频高达4.7G。同为RISC阵营的IBM和SUN走了完全不同的两条路线。而技术路线的差异也正是两家公司市场重点的差异。
　　仅以华为这两家公司最大的客户为例，SUN的服务器存储产品通过华为集成卖给全球的电信运营商，华为对SUN而言是客户更是商业伙伴；而华为也是IBM全球最大的5个咨询客户之一，每年付给IBM上亿美金的费用。

　　IBM收购普华永道咨询业务前，就已经是仅次于EDS的全球第二大IT服务商，收购普华永道管理咨询业务后，IBM在IT服务方面更是如虎添翼。IBM给华为提供的，就是管理咨询以及IT支撑系统的搭建。例如华为最重要的一个支撑系统IPD（集成产品开发）就是在IBM咨询服务帮助下完成。

　　而SUN对华为就简单多了，华为作为全球主要的电信设备供应商，SUN无疑是重要的业务伙伴。SUN在电信行业的优势也是通过优势的合作伙伴来体现。

　　如此就不难理解SUN的服务器芯片要采用片上多线程技术而IBM服务器要采用高主频策略，多数电信应用或者互联网应用都比较容易并行操作。典型的如WEB服务，同时向多个用户提供服务，相互之间的关联性不高，多线程技术避免了线程的频繁调度而提高了效率。更重要的是SUN UltraSPARC T2提供多达64个线程，功耗仅仅90瓦，服务器密度能够大大提升，空间占用和能耗上有巨大的优势。

　　而IBM的Power6系列的服务器多数是用在联机事务处理中，要提高程序的并行性非常困难。更何况IBM的客户有太多的老旧应用，重写并优化这些应用几乎不可能。因此IBM Power6采用目前最高的主频4.7G，这样即便是老旧的单线程应用也能在IBM服务器上获得效率提升。

　　表面上看起来，IBM的产品与SUN不论是服务器、软件上都存在严重的重合，但是实际上这两家公司的产品都是面向不同的市场。例如数据MySQL，几乎很少有大型机构的ERP系统是基于MySQL。但是从世界上最大的网站到个人网站，使用开源的MySQL却比比皆是。倒是IBM的DB2在互联网市场几乎还是空白。

　　但是不论是传统的企业还是.COM公司，整个IT系统WEB化已经是不可争辩的趋势，从IT系统最严格老旧的银行系统到电子商务公司，几乎没有一家企业不需要建立WEB应用。

　　这样看来，IBM实在要感谢金融危机让老牛仔陷入弹尽粮绝的境地。SUN高昂的研发费用在经济危机中悉数变成了沉没成本，IBM可以用异乎寻常的低价收购这些专利。更何况SUN还有数量巨大的客户群体，金融或者电信行业迟早要走出低谷，下一次经济景气来临之时，这两个行业同样会迎来新的IT投资高峰。

　　麦克尼利的开源开放之剑还在炉中铸炼，但是处于失血状态的SUN已经等不到倚天剑出的时候，SUN的股东们迫切需要变现。

　　大量的客户群体，互联网应用方面领先的技术，可以最大限度的消除竞争，以及现在近乎白送的价格，IBM实在很难找到不收购的理由。至于惠普，并不是不想，而是惠普的消化系统确实很难在吃下EDS这样的巨无霸后还能垂涎SUN。要知道即便在半年之前，购买SUN基本上是一个不可能发生的笑谈。

　　真正的开源和开放并不是IBM的兴趣点，吞并SUN以后，IBM在高端UNIX王者地位更加稳固。Power6发布时，曾被认为是没落贵族最后的挽歌，但是所有的贵族都不会心甘情愿的退出历史舞台。也正如英国的革命胜利已经200年，白金汉宫的贵族们依然奢华不减。竞争的减少让IBM更能延续过往的辉煌。

　　但是对用户而言，这并不是一个美好的结局。SUN被收购，麦克尼利开源和开放的思想更应该被用户发扬。这也许是老牛仔留给用户的最后箴言。

软件工程师必读：编程修养

admin — Fri, 20 Mar 2009 15:01:22 +0000

什么是好的程序员？是不是懂得很多技术细节？还是懂底层编程？还是编程速度比较快？我觉得都不是。对于一些技术细节来说和底层的技术，只要看帮助，查资料就能找到，对于速度快，只要编得多也就熟能生巧。
我认为好的程序员应该有以下几方面的素质：
　1、有专研精神，勤学善问、举一反三。
　2、积极向上的态度，有创造性思维。
　3、与人积极交流沟通的能力，有团队精神。
　4、谦虚谨慎，戒骄戒燥。
5、写出的代码质量高。包括：代码的稳定、易读、规范、易维护、专业。
这些都是程序员的修养，这里我想谈谈“编程修养”，也就是上述中的第5点。我觉得，如果我要了解一个作者，我会看他所写的小说，如果我要了解一个画家，我会看他所画的图画，如果我要了解一个工人，我会看他所做出来的产品，同样，如果我要了解一个程序员，我想首先我最想看的就是他的程序代码，程序代码可以看出一个程序员的素质和修养，程序就像一个作品，有素质有修养的程序员的作品必然是一图精美的图画，一首美妙的歌曲，一本赏心悦目的小说。
我看过许多程序，没有注释，没有缩进，胡乱命名的变量名，等等，等等，我把这种人统称为没有修养的程序，这种程序员，是在做创造性的工作吗？不，完全就是在搞破坏，他们与其说是在编程，还不如说是在对源程序进行“加密”，这种程序员，见一个就应该开除一个，因为他编的程序所创造的价值，远远小于需要在上面进行维护的价值。
程序员应该有程序员的修养，那怕再累，再没时间，也要对自己的程序负责。我宁可要那种动作慢，技术一般，但有良好的写程序风格的程序员，也不要那种技术强、动作快的“搞破坏”的程序员。有句话叫“字如其人”，我想从程序上也能看出一个程序员的优劣。因为，程序是程序员的作品，作品的好坏直截关系到程序员的声誉和素质。而“修养”好的程序员一定能做出好的程序和软件。
有个成语叫“独具匠心”，意思是做什么都要做得很专业，很用心，如果你要做一个“匠”，也就是造诣高深的人，那么，从一件很简单的作品上就能看出你有没有“匠”的特性，我觉得做一个程序员不难，但要做一个“程序匠”就不简单。编程序很简单，但编出有质量的程序就难。
我在这里不讨论过深的技术，我只想在一些容易让人忽略的东西上说一说，虽然这些东西可能很细微，但如果你不注意这些细微之处的话，那么他将会极大的影响你的整个软件质量，以及整个软件程的实施，所谓“千里之堤，毁于蚁穴”。
“细微之处见真功”，真正能体现一个程序的功底恰恰在这些细微之处。
这就是程序员的–编程修养。我总结了在用C/C++语言（主要是C语言）进行程序写作上的三十二个“修养”，通过这些，你可以写出质量高的程序，同时也会让看你程序的人渍渍称道，那些看过你程序的人一定会说：“这个人的编程修养不错”。
　　————————
　　　　
　　　　01、版权和版本
　　　　02、缩进、空格、换行、空行、对齐
　　　　03、程序注释
　　　　04、函数的[in][out]参数
　　　　05、对系统调用的返回进行判断
　　　　06、if 语句对出错的处理
　　　　07、头文件中的#ifndef
　　　　08、在堆上分配内存
　　　　09、变量的初始化
　　　　10、h和c文件的使用
　　　　11、出错信息的处理
　　　　12、常用函数和循环语句中的被计算量
　　　　13、函数名和变量名的命名
　　　　14、函数的传值和传指针
　　　　15、修改别人程序的修养
　　　　16、把相同或近乎相同的代码形成函数和宏
　　　　17、表达式中的括号
　　　　18、函数参数中的const
　　　　19、函数的参数个数
　　　　20、函数的返回类型，不要省略
　　　　21、goto语句的使用
　　　　22、宏的使用
　　　　23、static的使用
　　　　24、函数中的代码尺寸
　　　　25、typedef的使用
　　　　26、为常量声明宏
　　　　27、不要为宏定义加分号
　　　　28、||和&&的语句执行顺序
　　　　29、尽量用for而不是while做循环
　　　　30、请sizeof类型而不是变量
　　　　31、不要忽略Warning
　　　　32、书写Debug版和Release版的程序
　　————————

1、版权和版本
——-
好的程序员会给自己的每个函数，每个文件，都注上版权和版本。
对于C/C++的文件，文件头应该有类似这样的注释：
/************************************************************************
*
*　文件名：network.c
*
*　文件描述：网络通讯函数集
*
*　创建人： Hao Chen, 2003年2月3日
*
*　版本号：1.0
*
*　修改记录：
*
************************************************************************/
而对于函数来说，应该也有类似于这样的注释：
/*================================================================
*
* 函数名：XXX
*
* 参　　数：
*
*　　　　type name [IN] : descripts
*
* 功能描述:
*
*　　　　…………..
*
* 返回值：成功TRUE，失败FALSE
*
* 抛出异常：
*
* 作　　者：ChenHao 2003/4/2
*
================================================================*/
这样的描述可以让人对一个函数，一个文件有一个总体的认识，对代码的易读性和易维护性有很大的好处。这是好的作品产生的开始。

2、缩进、空格、换行、空行、对齐
—————-
i) 缩进应该是每个程序都会做的，只要学程序过程序就应该知道这个，但是我仍然看过不缩进的程序，或是乱缩进的程序，如果你的公司还有写程序不缩进的程序员，请毫不犹豫的开除他吧，并以破坏源码罪起诉他，还要他赔偿读过他程序的人的精神损失费。缩进，这是不成文规矩，我再重提一下吧，一个缩进一般是一个TAB 键或是4个空格。（最好用TAB键）
ii) 空格。空格能给程序代来什么损失吗？没有，有效的利用空格可以让你的程序读进来更加赏心悦目。而不一堆表达式挤在一起。看看下面的代码：
　　ha=(ha*128+*key++)%tabPtr->size;
　　ha = ( ha * 128 + *key++ ) % tabPtr->size;
　　有空格和没有空格的感觉不一样吧。一般来说，语句中要在各个操作符间加空格，函数调用时，要以各个参数间加空格。如下面这种加空格的和不加的：
　　
if ((hProc=OpenProcess(PROCESS_ALL_ACCESS,FALSE,pid))==NULL){
}
if ( ( hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid) ) == NULL ){
}
iii) 换行。不要把语句都写在一行上，这样很不好。如：
　　for(i=0;i´9´)&&(a<´a´||a>´z´)) break;
　　
　　我拷，这种即无空格，又无换行的程序在写什么啊？加上空格和换行吧。　　
　　
　　for ( i=0; i 　　　　if ( ( a < ´0´ || a > ´9´ ) &&
　　　　　　 ( a < ´a´ || a > ´z´ ) ) {
　　　　　　break;
　　　　}
　　}
　　好多了吧？有时候，函数参数多的时候，最好也换行，如：
　　CreateProcess(
　　　　　　　　　NULL,
　　　　　　　　　cmdbuf,
　　　　　　　　　NULL,
　　　　　　　　　NULL,
　　　　　　　　　bInhH,
　　　　　　　　　dwCrtFlags,
　　　　　　　　　envbuf,
　　　　　　　　　NULL,
　　　　　　　　　&siStartInfo,
　　　　　　　　　&prInfo
　　　　　　　　 );
　　条件语句也应该在必要时换行：
　　
　　if ( ch >= ´0´ || ch <= ´9´ ||
　　　　 ch >= ´a´ || ch <= ´z´ ||
　　　　 ch >= ´A´ || ch <= ´Z´ )
　　　　　　　　　
iv) 空行。不要不加空行，空行可以区分不同的程序块，程序块间，最好加上空行。如：
　　HANDLE hProcess;
　　PROCESS_T procInfo;
　　/* open the process handle */
　　if((hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid)) == NULL)
　　{
　　　　return LSE_MISC_SYS;
　　}
　　memset(&procInfo, 0, sizeof(procInfo));
　　procInfo.idProc = pid;
　　procInfo.hdProc = hProcess;
　　procInfo.misc |= MSCAVA_PROC;
　　return(0);
　　　　　　　　　
v) 对齐。用TAB键对齐你的一些变量的声明或注释，一样会让你的程序好看一些。如：
typedef struct _pt_man_t_ {
　　int　　 numProc;　　/* Number of processes　　　　　　　　 */
　　int　　 maxProc;　　/* Max Number of processes　　　　　　 */
　　int　　 numEvnt;　　/* Number of events　　　　　　　　　　*/
　　int　　 maxEvnt;　　/* Max Number of events　　　　　　　　*/
　　HANDLE* pHndEvnt;　 /* Array of events　　　　　　　　　　 */
　　DWORD　 timeout;　　/* Time out interval　　　　　　　　　 */
　　HANDLE　hPipe;　　　/* Namedpipe　　　　　　　　　　　　　 */
　　TCHAR　 usr[MAXUSR];/* User name of the process　　　　　　*/
　　int　　 numMsg;　　 /* Number of Message　　　　　　　　　 */
　　int　　 Msg[MAXMSG];/* Space for intro process communicate */
} PT_MAN_T;
怎么样？感觉不错吧。
这里主要讲述了如果写出让人赏心悦目的代码，好看的代码会让人的心情愉快，读起代码也就不累，工整、整洁的程序代码，通常更让人欢迎，也更让人称道。现在的硬盘空间这么大，不要让你的代码挤在一起，这样它们会抱怨你虐待它们的。好了，用“缩进、空格、换行、空行、对齐”装饰你的代码吧，让他们从没有秩序的土匪中变成一排排整齐有秩序的正规部队吧。

　　　　　　　　　
3、程序注释
------
养成写程序注释的习惯，这是每个程序员所必须要做的工作。我看过那种几千行，却居然没有一行注释的程序。这就如同在公路上驾车却没有路标一样。用不了多久，连自己都不知道自己的意图了，还要花上几倍的时间才看明白，这种浪费别人和自己的时间的人，是最为可耻的人。
是的，你也许会说，你会写注释，真的吗？注释的书写也能看出一个程序员的功底。一般来说你需要至少写这些地方的注释：文件的注释、函数的注释、变量的注释、算法的注释、功能块的程序注释。主要就是记录你这段程序是干什么的？你的意图是什么？你这个变量是用来做什么的？等等。
不要以为注释好写，有一些算法是很难说或写出来的，只能意会，我承认有这种情况的时候，但你也要写出来，正好可以训练一下自己的表达能力。而表达能力正是那种闷头搞技术的技术人员最缺的，你有再高的技术，如果你表达能力不行，你的技术将不能得到充分的发挥。因为，这是一个团队的时代。
好了，说几个注释的技术细节：
i) 对于行注释（“//”）比块注释（“/* */”）要好的说法，我并不是很同意。因为一些老版本的C编译器并不支持行注释，所以为了你的程序的移植性，请你还是尽量使用块注释。
ii) 你也许会为块注释的不能嵌套而不爽，那么你可以用预编译来完成这个功能。使用“#if 0”和“#endif”括起来的代码，将不被编译，而且还可以嵌套。

4、函数的[in][out]参数
-----------
我经常看到这样的程序：
FuncName(char* str)
{
　　int len = strlen(str);
　　.....
}
char*
GetUserName(struct user* pUser)
{
　　return pUser->name;
}
不！请不要这样做。
你应该先判断一下传进来的那个指针是不是为空。如果传进来的指针为空的话，那么，你的一个大的系统就会因为这一个小的函数而崩溃。一种更好的技术是使用断言（assert），这里我就不多说这些技术细节了。当然，如果是在C++中，引用要比指针好得多，但你也需要对各个参数进行检查。
写有参数的函数时，首要工作，就是要对传进来的所有参数进行合法性检查。而对于传出的参数也应该进行检查，这个动作当然应该在函数的外部，也就是说，调用完一个函数后，应该对其传出的值进行检查。
当然，检查会浪费一点时间，但为了整个系统不至于出现“非法操作”或是“Core Dump”的系统级的错误，多花这点时间还是很值得的。

5、对系统调用的返回进行判断
————–
继续上一条，对于一些系统调用，比如打开文件，我经常看到，许多程序员对fopen返回的指针不做任何判断，就直接使用了。然后发现文件的内容怎么也读出不，或是怎么也写不进去。还是判断一下吧：
　　fp = fopen(“log.txt”, “a”);
　　if ( fp == NULL ){
　　　　printf(“Error: open file errorn”);
　　　　return FALSE;
　　}
其它还有许多啦，比如：socket返回的socket号，malloc返回的内存。请对这些系统调用返回的东西进行判断。

6、if 语句对出错的处理
———–
我看见你说了，这有什么好说的。还是先看一段程序代码吧。
　　if ( ch >= ´0´ && ch <= ´9´ ){
　　　　/* 正常处理代码 */
　　}else{
　　　　/* 输出错误信息 */
　　　　printf("error ......n");
　　　　return ( FALSE );
　　}
这种结构很不好，特别是如果“正常处理代码”很长时，对于这种情况，最好不要用else。先判断错误，如：
　　if ( ch < ´0´ || ch > ´9´ ){
　　　　/* 输出错误信息 */
　　　　printf(“error ……n”);
　　　　return ( FALSE );
　　}
　　
　　/* 正常处理代码 */
　　……

这样的结构，不是很清楚吗？突出了错误的条件，让别人在使用你的函数的时候，第一眼就能看到不合法的条件，于是就会更下意识的避免。

7、头文件中的#ifndef
———-
千万不要忽略了头件的中的#ifndef，这是一个很关键的东西。比如你有两个C文件，这两个C文件都include了同一个头文件。而编译时，这两个C文件要一同编译成一个可运行文件，于是问题来了，大量的声明冲突。
还是把头文件的内容都放在#ifndef和#endif中吧。不管你的头文件会不会被多个文件引用，你都要加上这个。一般格式是这样的：
　　#ifndef　<标识>
　　#define <标识>
　　
　　……
　　……
　　
　　#endif
　　
<标识>在理论上来说可以是自由命名的，但每个头文件的这个“标识”都应该是唯一的。标识的命名规则一般是头文件名全大写，前后加下划线，并把文件名中的“.”也变成下划线，如：stdio.h
　　#ifndef _STDIO_H_
　　#define _STDIO_H_
　　
　　……
　　
　　#endif
　　
（BTW：预编译有多很有用的功能。你会用预编译吗？）　　
　　

8、在堆上分配内存
———
可能许多人对内存分配上的“栈 stack”和“堆 heap”还不是很明白。包括一些科班出身的人也不明白这两个概念。我不想过多的说这两个东西。简单的来讲，stack上分配的内存系统自动释放，heap上分配的内存，系统不释放，哪怕程序退出，那一块内存还是在那里。stack一般是静态分配内存，heap上一般是动态分配内存。
由malloc系统函数分配的内存就是从堆上分配内存。从堆上分配的内存一定要自己释放。用free释放，不然就是术语–“内存泄露”（或是“内存漏洞 ”）– Memory Leak。于是，系统的可分配内存会随malloc越来越少，直到系统崩溃。还是来看看“栈内存”和“堆内存”的差别吧。
　　栈内存分配
　　—–
　　char*
　　AllocStrFromStack()
　　{
　　　　char pstr[100];
　　　　return pstr;
　　}
　　
　　
　　堆内存分配
　　—–
　　char*
　　AllocStrFromHeap(int len)
　　{
　　　　char *pstr;
　　　　
　　　　if ( len <= 0 ) return NULL;
　　　　return ( char* ) malloc( len );
　　}
对于第一个函数，那块pstr的内存在函数返回时就被系统释放了。于是所返回的char*什么也没有。而对于第二个函数，是从堆上分配内存，所以哪怕是程序退出时，也不释放，所以第二个函数的返回的内存没有问题，可以被使用。但一定要调用free释放，不然就是Memory Leak！
在堆上分配内存很容易造成内存泄漏，这是C/C++的最大的“克星”，如果你的程序要稳定，那么就不要出现Memory Leak。所以，我还是要在这里千叮咛万嘱付，在使用malloc系统函数（包括calloc，realloc）时千万要小心。
记得有一个UNIX上的服务应用程序，大约有几百的C文件编译而成，运行测试良好，等使用时，每隔三个月系统就是down一次，搞得许多人焦头烂额，查不出问题所在。只好，每隔两个月人工手动重启系统一次。出现这种问题就是Memery Leak在做怪了，在C/C++中这种问题总是会发生，所以你一定要小心。一个Rational的检测工作--Purify，可以帮你测试你的程序有没有内存泄漏。
我保证，做过许多C/C++的工程的程序员，都会对malloc或是new有些感冒。当你什么时候在使用malloc和new时，有一种轻度的紧张和惶恐的感觉时，你就具备了这方面的修养了。
　　
对于malloc和free的操作有以下规则：
1) 配对使用，有一个malloc，就应该有一个free。（C++中对应为new和delete）
2) 尽量在同一层上使用，不要像上面那种，malloc在函数中，而free在函数外。最好在同一调用层上使用这两个函数。
3) malloc分配的内存一定要初始化。free后的指针一定要设置为NULL。　　
注：虽然现在的操作系统（如：UNIX和Win2k/NT）都有进程内存跟踪机制，也就是如果你有没有释放的内存，操作系统会帮你释放。但操作系统依然不会释放你程序中所有产生了Memory Leak的内存，所以，最好还是你自己来做这个工作。（有的时候不知不觉就出现Memory Leak了，而且在几百万行的代码中找无异于海底捞针，Rational有一个工具叫Purify，可能很好的帮你检查程序中的Memory Leak）

9、变量的初始化
--------
接上一条，变量一定要被初始化再使用。C/C++编译器在这个方面不会像JAVA一样帮你初始化，这一切都需要你自己来，如果你使用了没有初始化的变量，结果未知。好的程序员从来都会在使用变量前初始化变量的。如：
　　1) 对malloc分配的内存进行memset清零操作。（可以使用calloc分配一块全零的内存）
　　2) 对一些栈上分配的struct或数组进行初始化。（最好也是清零）
　　
不过话又说回来了，初始化也会造成系统运行时间有一定的开销，所以，也不要对所有的变量做初始化，这个也没有意义。好的程序员知道哪些变量需要初始化，哪些则不需要。如：以下这种情况，则不需要。
　　　　
　　　　char *pstr;　/* 一个字符串 */
　　　　pstr = ( char* ) malloc( 50 );
　　　　if ( pstr == NULL ) exit(0);
　　　　strcpy( pstr, "Hello Wrold" );
但如果是下面一种情况，最好进行内存初始化。（指针是一个危险的东西，一定要初始化）
　　　　char **pstr;　/* 一个字符串数组 */
　　　　pstr = ( char** ) malloc( 50 );
　　　　if ( pstr == NULL ) exit(0);
　　　　
　　　　/* 让数组中的指针都指向NULL */
　　　　memset( pstr, 0, 50*sizeof(char*) );
　　　　
而对于全局变量，和静态变量，一定要声明时就初始化。因为你不知道它第一次会在哪里被使用。所以使用前初始这些变量是比较不现实的，一定要在声明时就初始化它们。如：
　　Links *plnk = NULL;　/* 对于全局变量plnk初始化为NULL */

10、h和c文件的使用
---------
H文件和C文件怎么用呢？一般来说，H文件中是declare（声明），C文件中是define（定义）。因为C文件要编译成库文件（Windows下是.obj/.lib，UNIX下是.o/.a），如果别人要使用你的函数，那么就要引用你的H文件，所以，H文件中一般是变量、宏定义、枚举、结构和函数接口的声明，就像一个接口说明文件一样。而C文件则是实现细节。
H文件和C文件最大的用处就是声明和实现分开。这个特性应该是公认的了，但我仍然看到有些人喜欢把函数写在H文件中，这种习惯很不好。（如果是C++话，对于其模板函数，在VC中只有把实现和声明都写在一个文件中，因为VC不支持export关键字）。而且，如果在H文件中写上函数的实现，你还得在 makefile中把头文件的依赖关系也加上去，这个就会让你的makefile很不规范。
最后，有一个最需要注意的地方就是：带初始化的全局变量不要放在H文件中！
例如有一个处理错误信息的结构：
　　char* errmsg[] = {
　　　　/* 0 */　　　 "No error",　　　　　　　　
　　　　/* 1 */　　　 "Open file error",　　　　
　　　　/* 2 */　　　 "Failed in sending/receiving a message",　
　　　　/* 3 */　　　 "Bad arguments",　
　　　　/* 4 */　　　 "Memeroy is not enough",
　　　　/* 5 */　　　 "Service is down; try later",
　　　　/* 6 */　　　 "Unknow information",
　　　　/* 7 */　　　 "A socket operation has failed",
　　　　/* 8 */　　　 "Permission denied",
　　　　/* 9 */　　　 "Bad configuration file format",　
　　　　/* 10 */　　　"Communication time out",
　　　　......
　　　　......
　　};
　　
请不要把这个东西放在头文件中，因为如果你的这个头文件被5个函数库（.lib或是.a）所用到，于是他就被链接在这5个.lib或.a中，而如果你的一个程序用到了这5个函数库中的函数，并且这些函数都用到了这个出错信息数组。那么这份信息将有5个副本存在于你的执行文件中。如果你的这个errmsg很大的话，而且你用到的函数库更多的话，你的执行文件也会变得很大。
正确的写法应该把它写到C文件中，然后在各个需要用到errmsg的C文件头上加上 extern char* errmsg[]; 的外部声明，让编译器在链接时才去管他，这样一来，就只会有一个errmsg存在于执行文件中，而且，这样做很利于封装。
我曾遇到过的最疯狂的事，就是在我的目标文件中，这个errmsg一共有112个副本，执行文件有8M左右。当我把errmsg放到C文件中，并为一千多个C文件加上了extern的声明后，所有的函数库文件尺寸都下降了20%左右，而我的执行文件只有5M了。一下子少了3M啊。
〔备注〕
-----
有朋友对我说，这个只是一个特例，因为，如果errmsg在执行文件中存在多个副本时，可以加快程序运行速度，理由是errmsg的多个复本会让系统的内存换页降低，达到效率提升。像我们这里所说的errmsg只有一份，当某函数要用errmsg时，如果内存隔得比较远，会产生换页，反而效率不高。
这个说法不无道理，但是一般而言，对于一个比较大的系统，errmsg是比较大的，所以产生副本导致执行文件尺寸变大，不仅增加了系统装载时间，也会让一个程序在内存中占更多的页面。而对于errmsg这样数据，一般来说，在系统运行时不会经常用到，所以还是产生的内存换页也就不算频繁。权衡之下，还是只有一份errmsg的效率高。即便是像logmsg这样频繁使用的的数据，操作系统的内存调度算法会让这样的频繁使用的页面常驻于内存，所以也就不会出现内存换页问题了
11、出错信息的处理
---------
你会处理出错信息吗？哦，它并不是简单的输出。看下面的示例：
　　if ( p == NULL ){
　　　　printf ( "ERR: The pointer is NULLn" );
　　}
　　
告别学生时代的编程吧。这种编程很不利于维护和管理，出错信息或是提示信息，应该统一处理，而不是像上面这样，写成一个“硬编码”。第10条对这方面的处理做了一部分说明。如果要管理错误信息，那就要有以下的处理：
　　/* 声明出错代码 */
　　#define　　 ERR_NO_ERROR　　0　/* No error　　　　　　　　 */
　　#define　　 ERR_OPEN_FILE　 1　/* Open file error　　　　　*/
　　#define　　 ERR_SEND_MESG　 2　/* sending a message error　*/
　　#define　　 ERR_BAD_ARGS　　3　/* Bad arguments　　　　　　*/
　　#define　　 ERR_MEM_NONE　　4　/* Memeroy is not enough　　*/
　　#define　　 ERR_SERV_DOWN　 5　/* Service down try later　 */
　　#define　　 ERR_UNKNOW_INFO 6　/* Unknow information　　　 */
　　#define　　 ERR_SOCKET_ERR　7　/* Socket operation failed　*/
　　#define　　 ERR_PERMISSION　8　/* Permission denied　　　　*/
　　#define　　 ERR_BAD_FORMAT　9　/* Bad configuration file　 */
　　#define　　 ERR_TIME_OUT　 10　/* Communication time out　 */
　　
　　/* 声明出错信息 */
　　char* errmsg[] = {
　　　　/* 0 */　　　 "No error",　　　　　　　　
　　　　/* 1 */　　　 "Open file error",　　　　
　　　　/* 2 */　　　 "Failed in sending/receiving a message",　
　　　　/* 3 */　　　 "Bad arguments",　
　　　　/* 4 */　　　 "Memeroy is not enough",
　　　　/* 5 */　　　 "Service is down; try later",
　　　　/* 6 */　　　 "Unknow information",
　　　　/* 7 */　　　 "A socket operation has failed",
　　　　/* 8 */　　　 "Permission denied",
　　　　/* 9 */　　　 "Bad configuration file format",　
　　　　/* 10 */　　　"Communication time out",
　　};
　　　　　　　　　　　　　　　
　　/* 声明错误代码全局变量 */
　　long errno = 0;
　　
　　/* 打印出错信息函数 */
　　void perror( char* info)
　　{
　　　　if ( info ){
　　　　　　printf("%s: %sn", info, errmsg[errno] );
　　　　　　return;
　　　　}
　　　　
　　　　printf("Error: %sn", errmsg[errno] );
　　}
这个基本上是ANSI的错误处理实现细节了，于是当你程序中有错误时你就可以这样处理：
　　bool CheckPermission( char* userName )
　　{
　　　　if ( strcpy(userName, "root") != 0 ){
　　　　　　errno = ERR_PERMISSION_DENIED;
　　　　　　return (FALSE);
　　　　}
　　　　
　　　　...
　　}
　　
　　main()
　　{
　　　　...
　　　　if (! CheckPermission( username ) ){
　　　　　　perror("main()");
　　　　}
　　　　...
　　}
　　　　　　　　　　　　　　　
一个即有共性，也有个性的错误信息处理，这样做有利同种错误出一样的信息，统一用户界面，而不会因为文件打开失败，A程序员出一个信息，B程序员又出一个信息。而且这样做，非常容易维护。代码也易读。
当然，物极必反，也没有必要把所有的输出都放到errmsg中，抽取比较重要的出错信息或是提示信息是其关键，但即使这样，这也包括了大多数的信息。

12、常用函数和循环语句中的被计算量
-----------------
看一下下面这个例子：
　　for( i=0; i<1000; i++ ){
　　　　GetLocalHostName( hostname );
　　　　...
　　}
　　
GetLocalHostName的意思是取得当前计算机名，在循环体中，它会被调用1000次啊。这是多么的没有效率的事啊。应该把这个函数拿到循环体外，这样只调用一次，效率得到了很大的提高。虽然，我们的编译器会进行优化，会把循环体内的不变的东西拿到循环外面，但是，你相信所有编译器会知道哪些是不变的吗？我觉得编译器不可靠。最好还是自己动手吧。
同样，对于常用函数中的不变量，如：
GetLocalHostName(char* name)
{
　　char funcName[] = "GetLocalHostName";
　　
　　sys_log( "%s begin......", funcName );
　　...
　　sys_log( "%s end......", funcName );
}
如果这是一个经常调用的函数，每次调用时都要对funcName进行分配内存，这个开销很大啊。把这个变量声明成static吧，当函数再次被调用时，就会省去了分配内存的开销，执行效率也很好。
　　

13、函数名和变量名的命名
------------
我看到许多程序对变量名和函数名的取名很草率，特别是变量名，什么a,b,c,aa,bb,cc，还有什么flag1,flag2, cnt1, cnt2，这同样是一种没有“修养”的行为。即便加上好的注释。好的变量名或是函数名，我认为应该有以下的规则：
　　
　　1) 直观并且可以拼读，可望文知意，不必“解码”。
　　2) 名字的长度应该即要最短的长度，也要能最大限度的表达其含义。
　　3) 不要全部大写，也不要全部小写，应该大小写都有，如：GetLocalHostName 或是 UserAccount。
　　4) 可以简写，但简写得要让人明白，如：ErrorCode -> ErrCode,　ServerListener -> ServLisner，UserAccount -> UsrAcct 等。
　　5) 为了避免全局函数和变量名字冲突，可以加上一些前缀，一般以模块简称做为前缀。
　　6) 全局变量统一加一个前缀或是后缀，让人一看到这个变量就知道是全局的。
　　7) 用匈牙利命名法命名函数参数，局部变量。但还是要坚持“望文生意”的原则。
　　8) 与标准库（如：STL）或开发库（如：MFC）的命名风格保持一致。
　　

　　
14、函数的传值和传指针
————
向函数传参数时，一般而言，传入非const的指针时，就表示，在函数中要修改这个指针把指内存中的数据。如果是传值，那么无论在函数内部怎么修改这个值，也影响不到传过来的值，因为传值是只内存拷贝。
什么？你说这个特性你明白了，好吧，让我们看看下面的这个例程：
void
GetVersion(char* pStr)
{
　　pStr = malloc(10);
　　strcpy ( pStr, “2.0″ );
}
main()
{
　　char* ver = NULL;
　　GetVersion ( ver );
　　…
　　…
　　free ( ver );
}
我保证，类似这样的问题是一个新手最容易犯的错误。程序中妄图通过函数GetVersion给指针ver分配空间，但这种方法根本没有什么作用，原因就是–这是传值，不是传指针。你或许会和我争论，我分明传的时指针啊？再仔细看看，其实，你传的是指针其实是在传值。

15、修改别人程序的修养
———–
当你维护别人的程序时，请不要非常主观臆断的把已有的程序删除或是修改。我经常看到有的程序员直接在别人的程序上修改表达式或是语句。修改别人的程序时，请不要删除别人的程序，如果你觉得别人的程序有所不妥，请注释掉，然后添加自己的处理程序，必竟，你不可能100%的知道别人的意图，所以为了可以恢复，请不依赖于CVS或是SourceSafe这种版本控制软件，还是要在源码上给别人看到你修改程序的意图和步骤。这是程序维护时，一个有修养的程序员所应该做的。
如下所示，这就是一种比较好的修改方法：
　　/*
　　 * —– commented by haoel 2003/04/12 ——
　　 *
　　 *　 char* p = ( char* ) malloc( 10 );
　　 *　 memset( p, 0, 10 );
　　 */
　　
　　/* —— Added by haoel　 2003/04/12 —– */
　　 char* p = ( char* )calloc( 10, sizeof char );
　　/* —————————————- */
　　…
当然，这种方法是在软件维护时使用的，这样的方法，可以让再维护的人很容易知道以前的代码更改的动作和意图，而且这也是对原作者的一种尊敬。
以“注释 – 添加”方式修改别人的程序，要好于直接删除别人的程序。
16、把相同或近乎相同的代码形成函数和宏
———————
有人说，最好的程序员，就是最喜欢“偷懒”的程序，其中不无道理。
如果你有一些程序的代码片段很相似，或直接就是一样的，请把他们放在一个函数中。而如果这段代码不多，而且会被经常使用，你还想避免函数调用的开销，那么就把他写成宏吧。
千万不要让同一份代码或是功能相似的代码在多个地方存在，不然如果功能一变，你就要修改好几处地方，这种会给维护带来巨大的麻烦，所以，做到“一改百改”，还是要形成函数或是宏。

17、表达式中的括号
———
如果一个比较复杂的表达式中，你并不是很清楚各个操作符的忧先级，即使是你很清楚优先级，也请加上括号，不然，别人或是自己下一次读程序时，一不小心就看走眼理解错了，为了避免这种“误解”，还有让自己的程序更为清淅，还是加上括号吧。
比如，对一个结构的成员取地址：
　　GetUserAge( &( UserInfo->age ) );
虽然，&UserInfo->age中，->操作符的优先级最高，但加上一个括号，会让人一眼就看明白你的代码是什么意思。
再比如，一个很长的条件判断：
if ( ( ch[0] >= ´0´ || ch[0] <= ´9´ ) &&
　　 ( ch[1] >= ´a´ || ch[1] <= ´z´ ) &&
　　 ( ch[2] >= ´A´ || ch[2] <= ´Z´ )　　)
　　
括号，再加上空格和换行，你的代码是不是很容易读懂了？　　

18、函数参数中的const
-----------
对于一些函数中的指针参数，如果在函数中只读，请将其用const修饰，这样，别人一读到你的函数接口时，就会知道你的意图是这个参数是[in]，如果没有const时，参数表示[in/out]，注意函数接口中的const使用，利于程序的维护和避免犯一些错误。
虽然，const修饰的指针，如：const char* p，在C中一点用也没有，因为不管你的声明是不是const，指针的内容照样能改，因为编译器会强制转换，但是加上这样一个说明，有利于程序的阅读和编译。因为在C中，修改一个const指针所指向的内存时，会报一个Warning。这会引起程序员的注意。
C++中对const定义的就很严格了，所以C++中要多多的使用const，const的成员函数，const的变量，这样会对让你的代码和你的程序更加完整和易读。（关于C++的const我就不多说了）

19、函数的参数个数（多了请用结构）
-----------------
函数的参数个数最好不要太多，一般来说6个左右就可以了，众多的函数参数会让读代码的人一眼看上去就很头昏，而且也不利于维护。如果参数众多，还请使用结构来传递参数。这样做有利于数据的封装和程序的简洁性。
也利于使用函数的人，因为如果你的函数个数很多，比如12个，调用者很容易搞错参数的顺序和个数，而使用结构struct来传递参数，就可以不管参数的顺序。
而且，函数很容易被修改，如果需要给函数增加参数，不需要更改函数接口，只需更改结构体和函数内部处理，而对于调用函数的程序来说，这个动作是透明的。

20、函数的返回类型，不要省略
--------------
我看到很多程序写函数时，在函数的返回类型方面不太注意。如果一个函数没有返回值，也请在函数前面加上void的修饰。而有的程序员偷懒，在返回int的函数则什么不修饰（因为如果不修饰，则默认返回int），这种习惯很不好，还是为了原代码的易读性，加上int吧。
所以函数的返回值类型，请不要省略。
另外，对于void的函数，我们往往会忘了return，由于某些C/C++的编译器比较敏感，会报一些警告，所以即使是void的函数，我们在内部最好也要加上return的语句，这有助于代码的编译。

21、goto语句的使用
---------
N年前，软件开发的一代宗师--迪杰斯特拉(Dijkstra)说过：“goto statment is harmful !!”，并建议取消goto语句。因为goto语句不利于程序代码的维护性。
这里我也强烈建议不要使用goto语句，除非下面的这种情况：

　　#define FREE(p) if(p) {
　　　　　　　　　　　　free(p);
　　　　　　　　　　　　p = NULL;
　　　　　　　　　　}
　　main()
　　{
　　　　char *fname=NULL, *lname=NULL, *mname=NULL;
　　　　fname = ( char* ) calloc ( 20, sizeof(char) );
　　　　if ( fname == NULL ){
　　　　　　goto ErrHandle;
　　　　}
　　　　lname = ( char* ) calloc ( 20, sizeof(char) );
　　　　if ( lname == NULL ){
　　　　　　goto ErrHandle;
　　　　}
　　　　mname = ( char* ) calloc ( 20, sizeof(char) );
　　　　if ( mname == NULL ){
　　　　　　goto ErrHandle;
　　　　}
　　　　
　　　　......
　　
　　　　
　　 ErrHandle:
　　　　FREE(fname);
　　　　FREE(lname);
　　　　FREE(mname);
　　　　ReportError(ERR_NO_MEMOEY);
　　 }
也只有在这种情况下，goto语句会让你的程序更易读，更容易维护。（在用嵌C来对数据库设置游标操作时，或是对数据库建立链接时，也会遇到这种结构）

22、宏的使用
------
很多程序员不知道C中的“宏”到底是什么意思？特别是当宏有参数的时候，经常把宏和函数混淆。我想在这里我还是先讲讲“宏”，宏只是一种定义，他定义了一个语句块，当程序编译时，编译器首先要执行一个“替换”源程序的动作，把宏引用的地方替换成宏定义的语句块，就像文本文件替换一样。这个动作术语叫“宏的展开”
使用宏是比较“危险”的，因为你不知道宏展开后会是什么一个样子。例如下面这个宏：
　　#define　MAX(a, b)　　 a>b?a:b
当我们这样使用宏时，没有什么问题： MAX( num1, num2 ); 因为宏展开后变成 num1>num2?num1:num2；。但是，如果是这样调用的，MAX( 17+32, 25+21 ); 呢，编译时出现错误，原因是，宏展开后变成：17+32>25+21?17+32:25+21，哇，这是什么啊？
所以，宏在使用时，参数一定要加上括号，上述的那个例子改成如下所示就能解决问题了。
　　#define　MAX( (a), (b) )　　 (a)>(b)?(a):(b)
　　
即使是这样，也不这个宏也还是有Bug，因为如果我这样调用 MAX(i++, j++); ，经过这个宏以后，i和j都被累加了两次，这绝不是我们想要的。
　　
所以，在宏的使用上还是要谨慎考虑，因为宏展开是的结果是很难让人预料的。而且虽然，宏的执行很快（因为没有函数调用的开销），但宏会让源代码澎涨，使目标文件尺寸变大，（如：一个50行的宏，程序中有1000个地方用到，宏展开后会很不得了），相反不能让程序执行得更快（因为执行文件变大，运行时系统换页频繁）。
因此，在决定是用函数，还是用宏时得要小心。

23、static的使用
——–
static关键字，表示了“静态”，一般来说，他会被经常用于变量和函数。一个static的变量，其实就是全局变量，只不过他是有作用域的全局变量。比如一个函数中的static变量：
char*
getConsumerName()
{
　　static int cnt = 0;
　　
　　….
　　cnt++;
　　….
}
cnt变量的值会跟随着函数的调用次而递增，函数退出后，cnt的值还存在，只是cnt只能在函数中才能被访问。而cnt的内存也只会在函数第一次被调用时才会被分配和初始化，以后每次进入函数，都不为static分配了，而直接使用上一次的值。
对于一些被经常调用的函数内的常量，最好也声明成static（参见第12条）
但static的最多的用处却不在这里，其最大的作用的控制访问，在C中如果一个函数或是一个全局变量被声明为static，那么，这个函数和这个全局变量，将只能在这个C文件中被访问，如果别的C文件中调用这个C文件中的函数，或是使用其中的全局（用extern关键字），将会发生链接时错误。这个特性可以用于数据和程序保密。

24、函数中的代码尺寸
———-
一个函数完成一个具体的功能，一般来说，一个函数中的代码最好不要超过600行左右，越少越好，最好的函数一般在100行以内，300行左右的孙函数就差不多了。有证据表明，一个函数中的代码如果超过500行，就会有和别的函数相同或是相近的代码，也就是说，就可以再写另一个函数。
另外，函数一般是完成一个特定的功能，千万忌讳在一个函数中做许多件不同的事。函数的功能越单一越好，一方面有利于函数的易读性，另一方面更有利于代码的维护和重用，功能越单一表示这个函数就越可能给更多的程序提供服务，也就是说共性就越多。
虽然函数的调用会有一定的开销，但比起软件后期维护来说，增加一些运行时的开销而换来更好的可维护性和代码重用性，是很值得的一件事。

25、typedef的使用
———
typedef是一个给类型起别名的关键字。不要小看了它，它对于你代码的维护会有很好的作用。比如C中没有bool，于是在一个软件中，一些程序员使用int，一些程序员使用short，会比较混乱，最好就是用一个typedef来定义，如：
　　typedef char bool;
　　
一般来说，一个C的工程中一定要做一些这方面的工作，因为你会涉及到跨平台，不同的平台会有不同的字长，所以利用预编译和typedef可以让你最有效的维护你的代码，如下所示：
　　#ifdef SOLARIS2_5
　　　typedef boolean_t　　 BOOL_T;
　　#else
　　　typedef int　　　　　 BOOL_T;
　　#endif
　　
　　typedef short　　　　　 INT16_T;
　　typedef unsigned short　UINT16_T;
　　typedef int　　　　　　 INT32_T;
　　typedef unsigned int　　UINT32_T;
　　
　　#ifdef WIN32
　　　typedef _int64　　　　INT64_T;
　　#else
　　　typedef long long　　 INT64_T;
　　#endif
　　
　　typedef float　　　　　 FLOAT32_T;
　　typedef char*　　　　　 STRING_T;
　　typedef unsigned char　 BYTE_T;
　　typedef time_t　　　　　TIME_T;
　　typedef INT32_T　　　　 PID_T;
　　
使用typedef的其它规范是，在结构和函数指针时，也最好用typedef，这也有利于程序的易读和可维护性。如：
　　typedef struct _hostinfo {
　　　　HOSTID_T　 host;
　　　　INT32_T　　hostId;
　　　　STRING_T　 hostType;
　　　　STRING_T　 hostModel;
　　　　FLOAT32_T　cpuFactor;
　　　　INT32_T　　numCPUs;
　　　　INT32_T　　nDisks;
　　　　INT32_T　　memory;
　　　　INT32_T　　swap;
　　} HostInfo;

　　typedef INT32_T (*RsrcReqHandler)(
　　 void *info,
　　 JobArray *jobs,
　　 AllocInfo *allocInfo,
　　 AllocList *allocList);
C++中这样也是很让人易读的：
　　typedef CArray HostInfoArray;
于是，当我们用其定义变量时，会显得十分易读。如：
　　HostInfo* phinfo;
　　RsrcReqHandler* pRsrcHand;
这种方式的易读性，在函数的参数中十分明显。
关键是在程序种使用typedef后，几乎所有的程序中的类型声明都显得那么简洁和清淅，而且易于维护，这才是typedef的关键。

26、为常量声明宏
——–
最好不要在程序中出现数字式的“硬编码”，如：
　　int user[120];
　　
为这个120声明一个宏吧。为所有出现在程序中的这样的常量都声明一个宏吧。比如TimeOut的时间，最大的用户数量，还有其它，只要是常量就应该声明成宏。如果，突然在程序中出现下面一段代码，
　　for ( i=0; i<120; i++){
　　　　....
　　}
120是什么？为什么会是120？这种“硬编码”不仅让程序很读，而且也让程序很不好维护，如果要改变这个数字，得同时对所有程序中这个120都要做修改，这对修改程序的人来说是一个很大的痛苦。所以还是把常量声明成宏，这样，一改百改，而且也很利于程序阅读。
　　#define MAX_USR_CNT 120
　　
　　for ( i=0; i 　　　　....
　　}
这样就很容易了解这段程序的意图了。
有的程序员喜欢为这种变量声明全局变量，其实，全局变量应该尽量的少用，全局变量不利于封装，也不利于维护，而且对程序执行空间有一定的开销，一不小心就造成系统换页，造成程序执行速度效率等问题。所以声明成宏，即可以免去全局变量的开销，也会有速度上的优势。

27、不要为宏定义加分号
-----------
有许多程序员不知道在宏定义时是否要加分号，有时，他们以为宏是一条语句，应该要加分号，这就错了。当你知道了宏的原理，你会赞同我为会么不要为宏定义加分号的。看一个例子：
　　#define MAXNUM 1024;
这是一个有分号的宏，如果我们这样使用：
　　half = MAXNUM/2;
　　
　　if ( num < MAXNUM )
等等，都会造成程序的编译错误，因为，当宏展开后，他会是这个样子的：
　　half = 1024;/2;
　　
　　if ( num < 1024; )
　　
是的，分号也被展进去了，所以造成了程序的错误。请相信我，有时候，一个分号会让你的程序出现成百个错误。所以还是不要为宏加最后一个分号，哪怕是这样：
　　#define LINE　　"================================="
　　
　　#define PRINT_LINE　printf(LINE)
　　#define PRINT_NLINE(n)　while ( n-- >0 ) { PRINT_LINE; }
　　
都不要在最后加上分号，当我们在程序中使用时，为之加上分号，
　　main()
　　{
　　　　char *p = LINE;
　　　　PRINT_LINE;
　　}
这一点非常符合习惯，而且，如果忘加了分号，编译器给出的错误提示，也会让我们很容易看懂的。
28、||和&&的语句执行顺序
————
条件语句中的这两个“与”和“或”操作符一定要小心，它们的表现可能和你想像的不一样，这里条件语句中的有些行为需要和说一下：
　　express1 || express2
　　　　
　　先执行表达式express1如果为“真”，express2将不被执行，express2仅在express1为“假”时才被执行。因为第一个表达式为真了，整个表达式都为真，所以没有必要再去执行第二个表达式了。
　　express1 && express2
　　先执行表达式express1如果为“假”，express2将不被执行，express2仅在express1为“真”时才被执行。因为第一个表达式为假了，整个表达式都为假了，所以没有必要再去执行第二个表达式了。

于是，他并不是你所想像的所有的表达式都会去执行，这点一定要明白，不然你的程序会出现一些莫明的运行时错误。
例如，下面的程序：

　　if ( sum > 100 &&
　　　　 ( ( fp=fopen( filename,”a” ) ) != NULL )　 {
　　　　
　　　　 fprintf(fp, “Warring: it beyond one hundredn”);
　　　　 ……
　　}
　　
　　fprintf( fp, ” sum is %id n”, sum );
　　fclose( fp );
本来的意图是，如果sum > 100 ，向文件中写一条出错信息，为了方便，把两个条件判断写在一起，于是，如果sum<=100时，打开文件的操作将不会做，最后，fprintf和fclose就会发现未知的结果。
再比如，如果我想判断一个字符是不是有内容，我得判断这个字符串指针是不为空（NULL）并且其内容不能为空（Empty），一个是空指针，一个是空内容。我也许会这样写：
　　if ( ( p != NULL ) && ( strlen(p) != 0 ))
于是，如果p为NULL，那么strlen(p)就不会被执行，于是，strlen也就不会因为一个空指针而“非法操作”或是一个“Core Dump”了。
记住一点，条件语句中，并非所有的语句都会执行，当你的条件语句非常多时，这点要尤其注意。

29、尽量用for而不是while做循环
---------------
基本上来说，for可以完成while的功能，我是建议尽量使用for语句，而不要使用while语句，特别是当循环体很大时，for的优点一下就体现出来了。
因为在for中，循环的初始、结束条件、循环的推进，都在一起，一眼看上去就知道这是一个什么样的循环。刚出学校的程序一般对于链接喜欢这样来：
　　p = pHead;
　　
　　while ( p ){
　　　　...
　　　　...
　　　　p = p->next;
　　}
当while的语句块变大后，你的程序将很难读，用for就好得多：
　　for ( p=pHead;　p; p=p->next ){
　　..
　　}
一眼就知道这个循环的开始条件，结束条件，和循环的推进。大约就能明白这个循环要做个什么事？而且，程序维护进来很容易，不必像while一样，在一个编辑器中上上下下的捣腾。

30、请sizeof类型而不是变量
————-
许多程序员在使用sizeof中，喜欢sizeof变量名，例如：
int score[100];
char filename[20];
struct UserInfo usr[100];
在sizeof这三个的变量名时，都会返回正确的结果，于是许多程序员就开始sizeof变量名。这个习惯很虽然没有什么不好，但我还是建议sizeof类型。
我看到过这个的程序：
　　pScore = (int*) malloc( SUBJECT_CNT );
　　memset( pScore, 0, sizeof(pScore) );
　　…
　　
此时，sizeof(pScore)返回的就是4（指针的长度），不会是整个数组，于是，memset就不能对这块内存进行初始化。为了程序的易读和易维护，我强烈建议使用类型而不是变量，如：
对于score：　　 sizeof(int) * 100　 /* 100个int */
对于filename：　sizeof(char) * 20　 /* 20个char */
对于usr：　　　 sizeof(struct UserInfo) * 100　 /* 100个UserInfo */
这样的代码是不是很易读？一眼看上去就知道什么意思了。

另外一点，sizeof一般用于分配内存，这个特性特别在多维数组时，就能体现出其优点了。如，给一个字符串数组分配内存，
/*
* 分配一个有20个字符串，
* 每个字符串长100的内存
*/
char* *p;
/*
* 错误的分配方法
*/
p = (char**)calloc( 20*100, sizeof(char) );

/*
* 正确的分配方法
*/
p = (char**) calloc ( 20, sizeof(char*) );
for ( i=0; i<20; i++){
　　/*p = (char*) calloc ( 100, sizeof(char) );*/
　　p = (char*) calloc ( 100, sizeof(char) );
}
（注：上述语句被注释掉的是原来的，是错误的，由dasherest朋友指正，谢谢）
为了代码的易读，省去了一些判断，请注意这两种分配的方法，有本质上的差别。

31、不要忽略Warning
----------
对于一些编译时的警告信息，请不要忽视它们。虽然，这些Warning不会妨碍目标代码的生成，但这并不意味着你的程序就是好的。必竟，并不是编译成功的程序才是正确的，编译成功只是万里长征的第一步，后面还有大风大浪在等着你。从编译程序开始，不但要改正每个error，还要修正每个warning。这是一个有修养的程序员该做的事。
一般来说，一面的一些警告信息是常见的：
　　1）声明了未使用的变量。（虽然编译器不会编译这种变量，但还是把它从源程序中注释或是删除吧）
　　2）使用了隐晦声明的函数。（也许这个函数在别的C文件中，编译时会出现这种警告，你应该这使用之前使用extern关键字声明这个函数）
　　3）没有转换一个指针。（例如malloc返回的指针是void的，你没有把之转成你实际类型而报警，还是手动的在之前明显的转换一下吧）
　　4）类型向下转换。（例如：float f = 2.0; 这种语句是会报警告的，编译会告诉你正试图把一个double转成float，你正在阉割一个变量，你真的要这样做吗？还是在2.0后面加个f吧，不然，2.0就是一个double，而不是float了）
　　
不管怎么说，编译器的Warning不要小视，最好不要忽略，一个程序都做得出来，何况几个小小的Warning呢？

32、书写Debug版和Release版的程序
----------------
程序在开发过程中必然有许多程序员加的调试信息。我见过许多项目组，当程序开发结束时，发动群众删除程序中的调试信息，何必呢？为什么不像VC++那样建立两个版本的目标代码？一个是debug版本的，一个是Release版的。那些调试信息是那么的宝贵，在日后的维护过程中也是很宝贵的东西，怎么能说删除就删除呢？
利用预编译技术吧，如下所示声明调试函数：
　　#ifdef DEBUG
　　　　void TRACE(char* fmt, ...)
　　　　{
　　　　　　......
　　　　}
　　#else
　　　　#define TRACE(char* fmt, ...)
　　#endif
于是，让所有的程序都用TRACE输出调试信息，只需要在在编译时加上一个参数“-DDEBUG”，如：
　　cc -DDEBUG -o target target.c
于是，预编译器发现DEBUG变量被定义了，就会使用TRACE函数。而如果要发布给用户了，那么只需要把取消“-DDEBUG”的参数，于是所有用到 TRACE宏，这个宏什么都没有，所以源程序中的所有TRACE语言全部被替换成了空。一举两得，一箭双雕，何乐而不为呢？
顺便提一下，两个很有用的系统宏，一个是“__FILE__”，一个是“__LINE__”，分别表示，所在的源文件和行号，当你调试信息或是输出错误时，可以使用这两个宏，让你一眼就能看出你的错误，出现在哪个文件的第几行中。这对于用C/C++做的大工程非常的管用。

综上所述32条，都是为了三大目的--
　　1、程序代码的易读性。
　　2、程序代码的可维护性，
　　3、程序代码的稳定可靠性。
　　
有修养的程序员，就应该要学会写出这样的代码！这是任何一个想做编程高手所必需面对的细小的问题，编程高手不仅技术要强，基础要好，而且最重要的是要有“修养”！
好的软件产品绝不仅仅是技术，而更多的是整个软件的易维护和可靠性。　　
软件的维护有大量的工作量花在代码的维护上，软件的Upgrade，也有大量的工作花在代码的组织上，所以好的代码，清淅的，易读的代码，将给大大减少软件的维护和升级成本。

坚持和良好心态近乎道

admin — Fri, 20 Mar 2009 14:54:51 +0000

过去有一位年轻和尚，一心求道，希望有日成佛。但是，多年苦修参禅，似乎没有进步。
有一天，他打听到深山中有一破旧古寺，住持某老和尚修炼圆通，是得道高僧。
于是，年轻和尚打点行装，跋山涉水，千辛万苦来到老和尚面前。
两人打起机锋。
年轻和尚：请问老和尚，你得道之前，做什么？
老和尚：砍柴担水做饭。
年轻和尚：那得道之后，又做什么？
老和尚：还是砍柴担水做饭。
年轻和尚于是哂笑：那何谓得道？
老和尚：我得道之前，砍柴时惦念着挑水，挑水时惦念着做饭，做饭时有想着砍柴；得道之后，砍柴即砍柴，担水即担水，做饭即做饭。这就是得道。

翻译成程序员，编一个故事：
过去有一位程序员，一心想追求技术，希望有一天能成为顶级高手。但是，多年学习，似乎没有进步。
有一天，他打听到某高手，到首都北京，其水平享誉业界，是公认的权威。
于是，程序员打点行装，从牙缝里挤出差旅费，坐火车来到北京，迷几次路后，咬牙打的找到高手。
两人开始探讨程序员应该怎么个人发展的问题。
程序员：请问高手，你在名声大震之前，干什么？
高手：在公司写程序。
程序员：成名之后呢？
高手：还是在公司写程序。
程序员于是哂笑：那有什么不一样？
高手：没什么不一样，不过我近来进步，做事情更专心，不再老是想着写程序发不财。这样我就成高手。

其实，写程序就是写程序。这本身就和前途啊，财富啊不直接关联。只不过时代使然，使它成为刚好是个待遇较好，也是较有机会的行业。因此，年轻一代涌向这个行业，只有一小部分人是兴趣使然。这样，我们所见到的，有毅力，沉得下心的人颇为难得。很多人，坐在电脑屏幕前，要么视为苦差事，要么东张西望，不能定心。如此哪能成功。

每一行都有自己的道，和尚想成佛，俗人想成功。但是不管是谁那行，都只有定心苦修，克服心魔才能有所建树。

也效仿古人写一偈：
一年两年刚入行，三年四年不值讲。
五六七年识门道，八九十年算登堂。

高效开发与彻底测试

admin — Thu, 05 Mar 2009 06:14:35 +0000

一、“千般路”与“磨豆腐”

很久以前听一个故事：从前有个小伙子，少时有大志，长大后却无好营生，开了个豆腐作坊，每天磨豆腐累得腰酸背疼。每到夜深人静，小伙子辗转反侧，总想找条更好的“事业之路”，可是想过千百条、尝试过几十条路，都走不通。夜不成寝，白天干活更累，小伙子不由慨叹：“晚上想过千般路，白天还得磨豆腐”。

不久以前看过一篇文章：《CMM欺骗了中国的软件业》，内容是对CMM热的反思。CMM当然不会主动欺骗人民，实际上是我们的软件业自己欺骗自己。我们从来不缺少“某某模式”，“面向某某”，“某某认证”等等听起来美妙无比的东西，问题是实际的研发过程中能做得到码？现实是残酷的，美妙的概念漫天飞舞，开发过程仍然是作坊式的，正是：“晚上想过千般路，白天还得磨豆腐”。

中国的故事通常都有圆满的结局，现在接着说“磨豆腐”的故事。过了很长时间，小伙子终于面对现实，不再沉迷于不切实际的空想，用心磨好豆腐，闲时琢磨些个窍门，慢慢地，他的豆腐质量越来越好，每天产量也越来越多，作坊越开越大，成了远近闻名的“豆腐老板”，后来，他做起了别的生意，发现年轻时的空想，其实很多都是可行的，因为现在“能力”和“财力”都不同。

再说软件开发。我们不反对任何理论、技术、方法、模式等等，但第一，您的企业或团队做得到吗？不要做“如果开发时间延长一倍，就可以做到”之类毫无意义的假设。第二，做了真的有效益吗？效益是指扣除成本之后的收益。如果不具备这两点，那么还是不要整天想着“千般路”，首先想想如何好好的“磨豆腐”吧。

对于所有软件开发来说，代码编写都是无可逃避的“磨豆腐”。改进代码编写工作，高率效低成本地开发出高质量的代码，对于软件产品能否在激烈的竞争中胜出，对于软件企业的生存和发展，都具有重要的现实意义。

本文是Visual Unit应用的范例项目C++代码文档生成器的主题文档，叙述的正是改进代码编写工作的方法和工具，所有内容均经过实战检验，具有”可行”和”效益”两个特征，”可行”是指较低门槛或没有门槛，凭现有条件即可实施；”效益”是指能产生立竿见影的效果。

本文所援引的范例项目，模拟最糟糕的开发团队，最混乱的开发流程：由很少写代码的测试和预研部门开发，人员不固定，时间也不固定，谁有空就写上一些；没有设计，没有文档，基至也不在代码文件中保存编码人员的信息，成员完全依赖于阅读代码和测试用例来理解其他成员写的代码；除了简单的命名规则外，没有其他规范，甚至连一个函数原则上不能超过50行之类的基本规范也没有（范例中有超过200行的函数CMacro::Unwind()，一万多条路径）。任何开发团队和开发流程都会好于范例项目的开发团队和开发流程，因此，范例所展示的方法和工具，具有”广泛可行性”。

本文介绍如何进行高效编码调试和实现彻底的单元测试。编码调试是任何软件开发都无可逃避的工作，在Visual Unit的支持下编码调试，只是把本来就一定要做的工作改变一下方式，不需要多做什么，就可以大幅提高编程效率和质量；另一方面，Visual Unit彻底改变了单元测试难于实施或成本昂贵的局面，无论团队中开发与测试人员的比例是怎么样的，都可以轻松快捷地实现彻底的单元测试。

　
二、高效编码调试

任何软件开发，都离不开编码调试。对于稍为复杂一点的函数，一般来说，编写几行代码，就要执行一下，看它们是否按预想的工作，然后再继续写，写完后还要将各种可能输入都执行一下。如何执行？一般由别的代码来调用，也就是说需要驱动，驱动通常是在开始编写函数实现代码之前建立，这样才能一边编写一边调试。驱动大致可分为自然驱动和专门驱动。

自然驱动：利用项目中已有的代码作为驱动，通常是在被调试的函数中加断点，从界面执行一个需要调用该函数的功能，调试器中断时就可以调试了；专门驱动：为需要调试的函数编写专门的驱动代码，通过执行驱动代码来执行被调试函数。

自然驱动的主要优点是不需要其他工作就可以直接调试，甚至感觉不到需要驱动，主要缺点是输入数据通常是公共的，即很多代码都使用相同的输入源进行调试，实际输入往往是经过其他代码处理后的中间结果，要针对各种可能输入都进行调试往往很困难，造成调试不全面，程序员的思维受到局限，难于做到全面地考虑各种可能输入。

专门驱动的主要优点是输入数据是专门针对于被测试程序，容易做到比较全面，程序员的思维也会比较全面，对编写功能齐全的健壮的程序很有好处，要针对某种特定输入进行调试比较容易，缺点是需要花费大量的时间来编写驱动代码。

显然，自然驱动的主要问题是不全面，代码错误较多，专门驱动的主要问题是编写驱动代码很费时。有没有更好的方法，既不需要编写驱动代码，又能方便且全面地调试？有！这就是自动驱动，即在Visual Unit的支持下编码调试，不但无需费时间写驱动代码，更拥有多种独特的便利，可以大幅提高编码调试的质量和效率。

Visual Unit是单元测试工具，但也是高效编程调试的支持环境，在Visual Unit的支持下调试，既全面又省时：
自动生成驱动代码，但又可以方便地设定调试输入；
测试用例编辑器列出全部输入，可以很方便地检查是否全面。
除了上述优点外，在Visual Unit的支持下调试，还可以：
可视化地选择调试输入；
调试过程中还可以切换输入；
无限制的后退，重复。

上述仅是免费的个人版的功能，对于企业版用户，实际上大多数单步调试都可以省略：
自动输出参数、成员变量的输入输出值，返回值，用户也可以用简单的语法输出任何变量或表达式的值，这些数值都是上下文相关的；
显示在一个用例下，程序所执行的代码，可以很方便地查看程序是否按预想的流程执行。
程序无论多复杂，无非就是执行一些代码，读写、计算一些数据，因此，上述两方面信息已完整地描述了程序行为，一眼就能看出程序干了什么，通常可以很快判断程序是否按预想的工作并找到出错原因，比单步调试要快得多。

下面以实例来进一步分析三种调试方式的优缺点。这里所用的示例是范例项目中的CExFunction::ParseOneParameter()函数，这是一个很普通的函数，读者也可以随便拿其他有些复杂度的代码来比较。该函数的功能是解析C++代码中的一个参数，原形如下：
PARAMETER* CExFunction::ParseOneParameter(CTokenList& iList);
PARAMETER 是保存一个参数对象的结构，定义如下：
struct PARAMETER

{

CString type; //参数类型

CString name; //参数名

CString defVal; //缺省值

CString array; //如果参数是数组，保存[]及[]内的文字常量

};

参数iList是一个输入参数（范例的命名规则是用i表示输入参数），传递由C++代码中的一个参数经过词法分析转换获得的记号对象序列，例如参数int* pi，将转换为三个记号对象，分别对应于：int, *, pi。该函数将记号对象序列解析到一个PARAMETER结构的指针中，并作为返回值返回。

在这个示例中，如果要进行比较全面的调试，输入至少要考虑以下可能：
普通输入，如int i；
类型中有符号，如int* pi；
类型中有多个符号，如int*& pi；
模板类，如CList list；
带缺省值，如int i=0；
数组，如int ai[10]；
类型有多个单词，如const unsigned int& i；
缺少参数名，如const int；

我们在编写这个函数的实现代码前，首先建立调试驱动，以例边编码边执行调试。

自然驱动

假设界面和要调用这个函数的其他代码都已完成。在函数的入口处插入断点，以调试方式运行工程，在界面中选择要生成文档的工程目录，点击”生成文档”，程序中断时就可以调试了。这种方式相信所有程序员都很熟悉，并且很多人都会认为这种方式最省时，但实际上，这种方式只是开头省时，当你试图把各个可能输入都调试一遍，就会发现它很费时：可能输入通常分散分布于输入源中（这里的输入源是代码文件），如果要比较全面地调试，通常要整理输入源，否则几乎不可能全面地调试，也就是说，要全面地调试，仍然要费时间整理输入，并不能完全依赖自然输入；
要针对某种输入进行调试，例如要调试参数带有缺省值的情形，一般通过反复跟踪直到想要的输入出现，或者设置条件断点拦截所需要输入，反复跟踪当然费时不少，设置条件断点也是要花时间的，并且有时无法满足需要，很多时候，要针对特殊输入进行调试都是很大费时的；
由于是公共输入源，输入数据很难管理，尤其是条件断点更不可能无限期地保存，以后需要再次调试时可能要做很多重复工作。
如上所述，自然驱动并不省时，不过这种方式的时间消耗隐藏在调试过程中，通常不会引起重视，其实”隐藏于调试过程中”，其成本更大，因为分散了开发人员的注意力，影响思维的连续性。
自然驱动的更主要问题是不全面，开发人员常常会将思维局限于现有的输入源，导致一些可能输入根本就没有考虑到，在本例中，很可能只是试一下解析一两个文件，检查得到的结果是否正确，如果文件中没有带数组的参数，那这种输入很可能就被忽略掉。这种不全面，导致代码功能不齐，健壮性差，后期测试和维护成本居高不下，甚至导致项目的失败，因此，这是看起来高效，实际上很低效的方式，读者可以在看完后面两种方式的介绍后，自已尝试并对比一下，可以拿任何有一定复杂度的代码编写来对比，不局限于这里所举的例子。

专门驱动

专门驱动离单元测试只有一步之遥了，只要在驱动代码中添加判断预期输出的语句就构成了完整的测试代码，因此，在实际工作中，采用专门驱动最好是边编码边测试，并使用测试代码作为调试驱动。下面是为函数CExFunction::ParseOneParameter ()编写的调试驱动代码：
{CExFunction* pObj = new CExFunction();

CTokenList iList;

CTokenReader reader;

reader.ReadTokenList(iList, “int i”);

PARAMETER* ret = pObj->ParseOneParameter(iList) ;

ASSERT( ret->type == “int” );

ASSERT( ret->name == “i” );

reader.ClearTokenList(iList);

delete pParam;

delete pObj;}

上面的代码其实是一个测试用例的完整代码，测试代码通常都是很简单的，功能无非是使被测试的代码得于执行，被测试代码通常都涉及到外部数据，如参数、成员变量、全局变量什么的，这些数据当然要设定初始值，例如，上面的测试用例是将字符串”int i”经过CTokenReader对象的ReadTokenList方法转换成CToken对象指针的列表作为参数iList的输入。

在实际工作中，函数的输入输出常常不是简单的数据类型，而是某些对象甚至是对象的集合，本例中，输入的数据就是CToken对象指针的列表。这种情况下，一般借助现有的代码来生成数据，通常，这些”现在代码”都是存在的，因为即使不做测试，也总有代码要调用该函数的，调用代码本来就需要生成相应的数据。本例中，CTokenReader::ReadTokenList()函数就是把字符串转换为CToken对象指针的列表。

只要写完了第一个测试用例的代码，更多的用例就简单了，只要拷贝并对输入输出数据进行修改就行。细心的读都可能已注意到，第一个测试用例的前后加了{}，这是为了多个测试用例可以使用相同的变量名。

使用这种方法，建立测试代码通常是很快的。编写很简单的函数时不需要调试，当然也不需要测试代码。测试代码的组织也很简单：一个产品工程对应一个测试工程，一个产品类对应一个测试类，一个需要测试的产品函数对应一个测试函数。测试工程可以加一个简单的界面，以便执行指定的测试，也可以使用相应的工具如CppUnit。

再回到我们的主题：调试。有了测试代码，调试就简单了，要调试某种输入，只要在相应的测试用例中加断点就行了。使用这种方式，仅就调试来说，好处也是非常明显的：
所有输入在一起列出来，调试比较全面，程序员的思维也会比较全面；
要调试指定的输入很容易，通常不需要高级断点，更不需要通过反复跟踪来捕捉需要的输入；
调试数据可以永久保存，避免了以后修改代码时的重复工作。

自动驱动

在Visual Unit的支持下编码调试，除了兼具自然驱动和专门驱动的优点外，还能享受Visual Unit的独特殊功能带来的便利。

首先我们用个人版来说明，个人版是免费的版本，并且开发商也提供免费的基本技术支持。

Visual Unit具有丰富的文档，包括视频教程，这里不再叙述其基本使用方法。只要选择要测试(调试)的类和函数(如果使用企业版的IDE插件，会根据当前文档和光标位置自动选择)，VU就会生成测试代码，并弹出测试用例编译器。VU是自动生成测试代码，而不是自动生成测试用例，也就是说，输入输出数据是由用户指定的，不过VU已经生成了输入输出数据的声明。下面是本例中VU生成的第一个测试用例的输入输出：

输入部分：
CTokenList iList =

输出部分：
ret ==

这里的“=”和“==”仅仅表示可能需要赋值或判断输出，对于基本数据类型，可以直接填写数值，高级数据类型需要灵活处理(详细信息请查看帮助或教程)。只要把输入输出改为这样就完成了第一个测试用例的建立：

输入部分：
CTokenList iList = //多余的=会自动删除

CTokenReader reader

reader.ReadTokenList(iList, “int i”)

输出部分：
ret->type == “int”

ret->name == “i”

更多的测试用例，只要点击”新建”，就会自动拷贝当前用例，只要修改输入输出就行了。这里没有涉及到成员变量和变局全量，不过都很简单的(成员变量用点操作符访问，全局变量直接访问)，请查看帮助。

可以看出，使用VU建立调试支持环境是很快速的：对于第一个测试用例，输入输出比较复杂时需要写少量简单的代码，输入输出简单时直接填写输入输出数值，其他测试用例只需点击一个按钮拷贝现有测试用例并修改输入输出就行，可以选择相近的用例来生成新的用例，这样通常只需要修改一两个数据就可以得到想要的用例。

那么，还可以得到哪些好处呢？
方便地进入调式：在被调试函数的入口加断点，并调试测试工程即可进入调试；
方便地选择输入：在测试用例编辑器中轻点鼠标即可指定要调试的输入，如果执行了测试，只要点击出错的测试，就会自动选择相应的输入；
方便地切换输入：调试过程中，不需要退出调试，就可以切换到其他输入：只要在测试用例编辑器中选择另一个测试用例，用调试器的”执行到光标所在行”命令回到函数入口，即可切换到新的输入；
无限制后退重复：用调试器的”执行到光标所在行”命令可以自由地后退和重复执行，其实现的原理是”重来”，后退时相关数据也会”还原”，感觉上是真正的”后退”，这个奇特而有用的功能是VU生成的测试代码自动实现的。

上述是免费的个人版所具有功能，VU企业版除了具有这些功能外，还具有”描述程序行为”的功能：
自动输出参数、成员变量的输入输出值，返回值，用户也可以用简单的语法输出任何变量或表达式的值。这些数值都是上下文相关的，也就是说，同一个用例的相关值放在一起；
显示在任一个用例下程序所执行的代码，可以很方便地查看程序是否按预想的流程执行。
程序无论多复杂，无非就是执行一些代码，读写、计算一些数据，因此，上述两方面信息已完整地描述了程序行为，很容易看出”程序干了什么”。这个功能大幅度地提高了开发人员的工作效率：
帮助整理、验证编程思路：写几行代码，就可以看看”程序干了什么”，轻松判断”现在所写的对不对”，也比较容易想清楚”接下来要怎么写”。
快速找出程序错误：根据输入输出数据和所执行的代码，通常可以很快判断程序是否按预期工作并找到出错原因，比单步调试要快得多。
编程的时间消耗主要不在于敲键盘，而在于编程思路和调试，VU企业版可谓”对症下药”，在这两方面大量提高工作效率。

以上所述，都是针对软件开发过程中无可逃避的工作：编码调试。仅从时间上来说，对于编写调试有一定复杂度的程序，使用专门驱动，可能比自然驱动多费一点时间，但也是完全合算的，至于自动驱动，如果使用VU个人版，大概能省时10%，如果使用企业版，则可以省时20-50%!读者可以自行尝试比较一下。是否省时还不是最重要的，更高的价值在于：使用专门驱动或自动驱动编码调试，实际上也已经把令人望而生畏的单元测试工作完成了一半，并清除了实施单元测试的最主要障碍。

　
三、实现彻底单元测试

是什么使单元测试难于实施？首先是代码的可测性。可测性是什么？如果一个类具有基本的可测性，那么把它加入到另一个工程后（当然有关联的文件也要加入）能够通过编译，这其实是很低的要求，但对于一个有一定规模的项目，如果开发调试时使用自然驱动，在完成编码后才进行单元测试，那么通常都不具有可测性，因为开发人员常常在无意之中使代码之间产生了不当耦合，这些不当耦合累积起来，会使整个项目的代码纠缠在一起，造成难于测试。

使单元测试难于实施的另一个方面是建立测试用例。在本例中，如果由不熟悉代码的测试人员建立测试用例，那么他很可能不知道如何生成CToken对象指针的列表。

如果边开发边使用专门驱动(测试代码放在另一个工程中)或自动驱动调试，那么一旦出现影响可测性的不当耦合就会及时发现及时解决，保证了代码的可测性，另一方面，由于至少建立了一个测试用例，测试人员建立其他用例时只要修改一下输入输出数据，从而大大降低建立测试用例的难度。总之，使用专门驱动或自动驱动调试，在不增加开发工作量的同时，已经为单元测试打一下了坚实的基础。

范例项目V0.1处于这样一个阶段：刚刚完成代码编写，并未完成单元测试，现有的多数测试用例都是编码时用于调试的。在此基础上，单元测试由谁做，难度都不大。VU的典型应用是通过三个阶段来完成针对一个函数的彻底的测试：
1）基本功能测试：测试代码的基本功能；
2）完成白盒覆盖：在现有用例的基础上，使用测试用例设计器为未覆盖的语句、条件、分支、路径设计测试用例，达到100%语句、条件、分支、路径覆盖；
3）执行自动边界测试捕捉意料之外的错误。
以上三阶段可以由不同人员在不同时间完成，团队可以根据实际情况做出灵活安排，下面是一个典型的开发测试流程。

1）开发人员边开发边使用VU调试测试，完成基本功能测试。在VU的支持下开发调试，可以大幅提高开发效率，绝不会影响开发进度。也许读者会认为，开发人员没有时间去设计测试用例，其实这是一种误解，开发人员写代码时肯定要想清楚代码的功能并且要使用基本的输入进行调试，这些就是基本的测试用例，实际上不需要多做什么。开发人员提交代码同时提交测试代码和测试报告。如果项目已完成或部分完成编码，也建议先由程序员首先对重要代码进行基本的功能测试。
2）测试人员检查基本测试用例是否符合设计，并在此基础上完成白盒覆盖和边界测试。由于有了初步的测试，保证了代码可测性，不可能产生因为不当耦合造成难于测试的状况；在现有用例的基础上，使用测试用例设计器找出遗漏用例也不会有太大障碍，这就使测试人员的工作易于进行。测试人员只需要提交更新过的测试代码和测试报告，不需要另外记录测出的问题。
3）开发人员下载新的测试代码和测试报告，执行整体测试，然后针对报告了错误的函数执行函数测试以获取详细信息，必要时进行调试，找出错误，修改代码，使所有测试通过，再次提交产品代码和测试报告。
4）测试人员再次执行整体测试，验证所有的测试均已通过。

以上流程是动态和反复的，并不是编码完成后再单元测试。开发人员写完一个类后即可提交代码由测试人员完成白盒覆盖和边界测试。另外，团队可以根据开发与测试人员的比例调整工作份额，如果团队没有测试人员，那么由开发人员完成全部单元测试也是可行的。

彻底的单元测试对于软件开发来说，其价值是难于估量的：除了保证局部代码的质量外，有了单元测试，任何时候修改代码后都可以通过回归测试来自动检查修改是否引入错误，这就使开发过程可以适应频繁变化的需求，系统分析、概要设计和详细设计都可以做得简单一些，也更能适应螺旋式开发过程，以后的维护升级成本也会大幅降低，同时，高质量的代码使集成测试和系统测试的工作量降低很多(实际上单元测试已包含了大部分的集成测试)，发现问题后的修改也会高效得多。总之，要提高软件开发质量、降低软件开发成本，最有效的改进就是进行彻底的单元测试，如果不进行单元测试，任何流程改进都无法保证产品质量，因为，程序始终是由代码构成的，代码的质量没有保证，软件的质量拿什么来保证？单元测试并不排斥其他过程改进，相反，单元测试对开发流程中的所有环节几乎都有促进作用。

下边再谈谈关于白盒覆盖的话题。使用VU实施单元测试，100%的语句、条件、分支覆盖通常都是很容易的，路径覆盖有时候会很难，例如，我们所举的例了，CExFunction::ParseOneParameter ()，有九十多条路径，要覆盖似乎不现实或没必要，这种状况通常是设计不合理造成的，例如，CExFunction::ParseOneParameter ()函数的代码分为三块：1、解析缺省值，2、解析数组，3、解析类型和参数名，前两块解析了缺省值和数组后把相应的Token从列表中删除，这样的话，第3块与前两块是没有逻辑关系的，但是，这3块代码会组合出很多路径，没有逻辑关系的代码所组合出来的路径是没有意义的，这些代码具有”高耦合低内聚”的特征，不应该放在一个函数中。范例中另外写了一个函数：CExFunction::ParseOneParameter2()，把以上三块代码分别独立出来自成一个函数，这样每个函数都能完成100%的路径覆盖，重构后的代码既易于测试，也易于维护。范例中有大量类似的函数，甚至有超过200行的函数，这是为了检验VU的适应能力，以后的版本是会进行重构。我们建议程序员完成编码后，检查一下路径数量，如果路径很多，代码很可能需要分拆，合理的路径数量应该是等价类数量的一至两倍。另外，从逻辑结构图也可以看出来：图中有两个或两个以上串联的复杂分支结构，往往表示代码的结构有问题。

VU的逻辑结构图具有屏蔽对象的功能，因此，遇到上述情形时可以通过交替屏蔽部分分支结构的方式来实现路径覆盖，但这不是我们推荐的方式，因为它虽然可以保证测试的完整性，但并没有改进代码的结构。

关于单元测试和范例项目，还有很多值得叙述的话题，例如内存泄漏测试以及一些复杂问题的处理等等，这里暂且不谈。最后谈谈已完成编码的项目的单元测试。对于已完成编码的项目，最好先由开发人员”去耦合”，方法是将代码文件从底层向上排列，按顺序依次将文件加入到另一个工程并编译，如果产生编译错误，则想办法消除编译错误，VU提供了文件排序工具，具体的使用方法请查阅帮助中《测试旧工程》部分。完成“去耦合”后，由开发人员对自己编写的代码完成基本功能测试，测试人员完成白盒覆盖和边界测试。对于编码过程中使用自然驱动调试的已完成编写的代码，完全由测试部门进行单元测试通常是很难的。
附：
C++代码文档生成器（源代码下载）

本软件的主要功能是解析C/C++代码，依据代码及注释自动生成代码文档。点击这里浏览本文档生成器依据自身代码生成的文档，文档格式为XML，需要XML解析器的支持，请允许ActiveX运行，如仍无法浏览，请下载安装微软的XML插件。

这是凯乐软件测试部主持的一个开源项目，模拟最糟糕的开发团队，最混乱的开发流程，以恶劣环境下的实战检验和展示Visual Unit在软件开发和测试中的应用。此项目由很少写代码的测试和预研部门开发，人员不固定，时间也不固定，谁有空就写上一些；没有设计，没有文档，基至也不在代码文件中保存编码人员的信息，成员完全依赖于阅读代码和测试用例来理解其他成员写的代码；除了简单的命名规则外，没有其他规范，甚至连一个函数原则上不能超过50行之类的基本规范也没有（范例中有超过200行的函数CMacro::Unwind()，一万多条路径）。总之，此项目所展示的编码调试方式和单元测试方法，是任何开发团队都可以实施的。详细信息，请阅读相关文档：《高效开发与彻底测试》。

代码文档生成器使用说明

1) 不需要安装，双击启动；
2) 选择要生成文档的项目目录，可以选择多个目录；
3) 在编译条件输入框中添加编译条件（可选）；
4) 选择文档的保存目录；
5) 点击”生成”，即可生成XML文档；
6) 将XSL目录下的文件拷贝到文档目录，点击index.htm即可浏览文档；
7) 通过修改XSL目录下的文件可以定制显示格式或装饰页面。

项目源代码使用说明

源代码包括产品工程和测试工程:
产品工程目录：/源代码/Docer/
测试工程目录：/源代码/TestDocer/

安装Visual Unit1.3，启动VC6，将产品工程目录及Visual Unit安装目录/include/添加到搜索路径，更详细的信息请查看Visual Unit帮助《新建测试工程-VC6》。

产品工程可以使用VC6直接编译。

测试工程的编译运行：
1）启动Visual Unit(个人版或企业版)，导航窗口->菜单->目录，选择产品工程和测试工程的目录；
2）试一下编译测试工程，如果通不过编译，请查看帮助《编译错误》章节的说明；
3）在导航窗口选择要测试的源文件，如产品工程目录下的ExFunction.cpp文件；
4）在导航窗口函数列表中选择一个函数，如ParseOneParameter，编译并执行测试工程（Execute Program或Ctrl+F5），即可执行测试。
5）企业版用户可以使用IDE插件，自动选择要测试的文件和函数，请查看帮助中《使用IDE插件》章节。
6）要调试程序，添加断点，如在CExFunction::ParseOneParameter()入口处加断点，执行调试(Go或F5)，即可进入调试，调试前可以打开测试用例编辑器选择调试输入(测试用例)，调试过程中也可以切换用例，请参考帮助《排错–调试》。企业版用户，可以直接执行IDE插件的调试命令，无需手工断点。
7）大多数代码（比较简单的除外）都是边开发边在Visual Unit的支持下调试的，不需要界面，随便选择一个函数都可以立即进入调试，也可以随便增删修改调试输入（使用测试用例编辑器）。
8）目前版本仅实现了最基本功能，为了检验和展示VU的适应能力，很多代码不完善或有重构的必要，同时也有很多测试用例不完整。如果您有意扩展本项目的功能，请在Visual Unit的支持下编码调试，即使是免费的个人版，也能大幅提高开发的效率和质量。　
　
变量命名规则

m 成员变量
g 全局变量
s 静态变量
p 指针
i 输入参数
o 输出参数

示例
CString name; //局部变量
CStrin mName; //成员变量
CString iName; //输入参数
CString& oName; //输出参数
CString gName; //全局变量
CString* pName; //局部变量，指针
CString* mpName; //成员变量，指针
CString* ipName; //输入参数，指针
CString* opName; //输出参数，指针
CString* iopName; //输入输出参数，指针

男人应该相信自己，没有什么不可以

admin — Wed, 18 Feb 2009 02:36:00 +0000

1。男人应该相信自己，没有什么不可以

　　　　李小龙,虽然他英年早逝，年仅33岁。但他在好莱坞浮沉数载，四部半带有革命性
质的功夫影片傲然出世，让全世界为之惊服。“我是一个中国人！我为了替中国武术争一
口气！”他的夙愿终于得偿，而由之引发的全球功全球功夫狂热至今不退。

　　　　名言：“我绝不会说我是天下第一，可是我也绝不会承认我是第二！”

男人要有激情

　　　　迈克尔•乔丹来自纽约的布鲁克林区，后来进入北卡罗莱纳大学学习，在那里，
他的篮球天赋开始显现。加盟芝加哥公牛队后，乔丹率队6次获得NBA总冠军，5次赢得最有
价值球员的称号。两度宣布退役，又两度宣布复出，最终于2003年从华盛顿奇才队退役。
据估计，截止2002年，飞人乔丹的财产总数为4 亿200万美元。乔丹是美国最伟大的篮球运
动员。

　　　　名言：我可以接受失败，但我不能接受放弃。

男人要有才华

　　　　作为二十世纪最成功的报人之一的查良镛一手为明报社评，一手为新派武侠小说
，他的身上体现了冯友兰先生所提出的儒家人格的最高标准：“阐旧邦以新命，极高明而
道中庸”。金庸先生对于历史的见解至为深刻透析，所著《鹿鼎记》、《笑傲江湖》等著
作风行华人世界。他使白话的语言艺术达到了全新的高峰，堪称汉语的奇迹。

　　　　名言：草木竹石皆可为剑！

男人要坚强

　　　　蒂芬.霍金，一位残疾人，22岁时他不幸罹患一种可怕的慢性病—–肌肉萎缩症
。但是霍金并没有向病魔屈服，用安装在轮椅上的电脑教课。毕生致力于解答存在于天文
物理界的三大难题：宇宙是怎样形成的？宇宙如何终结？在宇宙爆炸前，宇宙是个什么样
子？

　　　　名言：当你面临着夭折的可能性，你就会意识到，生命是宝贵的，你有大量的事
情要做。

男人要幽默

　　　　1984年以“跑龙套”身份踏足影视圈的周星驰，已经以其独一无二的无厘头式幽
默，一人开创了香港电影的新方向。他无厘头的搞笑方式有独特的魅力存在，而能够以喜
剧得到影帝封号的可能就只有他了. 奋斗的艰辛，并不是每个人都能理解的。

　　　　名言：太多了，说不过来。人个认为，最有意思的，就是那句：其实，我是一个
演。多少辛酸和无奈都包含在里面了。

男人要有智慧

　　　　盖茨被誉为电脑奇才、20世纪最伟大的计算机软件行业巨人。36岁成为世界最年
轻的亿万富翁。1999年《福布斯》评选，盖茨居世界亿万富翁首位，纯资产850亿美元。被
《时代》周刊评为在数字技术领域影响重大的50人之一。比尔•盖茨的笑脸和蒙娜莉莎的
笑脸一样是值得我们去研究研究的。

　　　　名言：这世界并不会在意你的自尊。这世界指望你在自我感觉良好之前先要有所
成就。

男人要踏实

　　　　每一个人都有他自己的生长季节。很多人都已注意到了李嘉诚的幸运，天时、地
利，等等。也如很多人注意到的，尽管每一代人都有可重复性，但李嘉诚却是空前绝后的
。李嘉诚大概是香港市场诸巨人中少有的出身贫寒者，少有的长青树，在市场和管理的各
个领域和各个层面都成功过的佼佼者。可能用踏实形容李嘉诚并不恰当，但从一个连小学
文凭都没有的学徒，到亚洲首富，必定是一步一个脚印走过来的。

　　　　名言：信誉是不可以用金钱估量的，它是生存和发展的法宝。

男人要善良

　　　　雷锋精神曾经影响了一代人，他堪称是新型人格的代表，也是中国人民
解放军整体形象的一个缩影。他所承载的“全心全意为人民服务”的精神是集体主义文化
传统在新时期的发展。

　　　　名言：人的生命是有限的，可为人民服务是无限的，我要把有限的生命投入到无
限的为人民服务中去。

男人要有梦想

　　　　丁磊，中国最年轻的首富.于1997年6月创立网易公司，凭借敏锐的市场洞察力和
扎扎实实的工作，网易公司为推动中国互联网的发展做出了重要贡献，同时丁磊也将网易
从一个十几个人的私企发展到今天拥有近300员工在美国公开上市的知名互联网技术企业。

　　　　名言：世界上投资最少，甚至每天睡觉都可以有成千上万的收入有哪种？网络游
戏便可以。

男人要有霸气

　　　　中国统一的秦王朝的开国皇帝。嬴姓，名政。秦庄襄王之子。13岁即王位，39岁
称帝。自公元前230年至前221年，先后灭韩、魏、楚、燕、赵、齐六国，终于建立了中国
历史上第一个统一的、多民族的国家–秦朝。横扫八荒，统一六国，始创封建中央集权制之模式，雄才也；筑万里长城，开军事防御之奇思，大略也。

　　　　名言：大地在我脚下，万物在我手中。

男人要豁达

　　　　苏轼，一个旷世奇才，士大夫心仪神往的人格典范，民间妇孺喜闻乐道的豪士雅
客，有一派刚直不屈的执著风节、一颗善于解脱的智慧心灵和一副眼见天下无一个不是好
人的善良心肠。苏轼的魅力是一个谜。历经多少磨难，还是那么潇洒豁达，人生的大悲哀
在他笔下化成一股豪侠之风，令人荡气回肠。

　　　　名言：明月几时有，把酒问青天。

男人要浪漫

　　　　李白，字太白。人称诗仙。母梦长庚星而生。通诗书、喜纵横术、击剑为任侠。
喜欢李白“虎鼓瑟兮鸾回车，仙之人兮列如麻”的浪漫和那份“抚剑夜吟啸，雄心日千里
。誓欲斩鲸鲵，澄清洛阳水”豪迈飘逸。

　　　　名言：古来圣贤皆寂寞，唯有饮者留其名。

男人要忠诚

　　　　岳飞，南宋军事家，民族英雄。其母姚氏在他背上刺了“精忠报国”四个大字，
这成为岳飞终生遵奉的信条。岳飞善于谋略，治军严明，在其戎马生涯中，他亲自参与指
挥了126仗，未尝一败，是名副其实的常胜将军。

　　　　名言：“还我河山！”

男人要英明

　　　　康熙，清代皇帝，即清圣祖爱新觉罗•玄烨，满族，年号康熙，故亦称康熙帝。
是中国历史上在位时间最长，而又功绩卓著的著名皇帝。他在位时期，智擒鳌拜，剿撤三
藩，南收台湾，北拒沙俄，订《尼布楚条约》，西征蒙古，兴修水利，治理黄河，鼓励垦
荒，薄赋轻税，爱民如子。

　　　　名言：德政服天下

男人要有野心

　　　　拿破仑，这位天才军事家，在他壮烈的一生中，打过无数次的胜仗，他将法国带
到了颠峰时期，成为盘踞欧洲的霸主。

　　　　名言：“不可能”这个词只有在傻瓜的字典里才能找到。

男人要有魅力

　　　　周恩来，集中华民族广博的智慧于一身，扬炎黄子孙完美的魅力于中外，具有独
特的人格魅力。

　　　　名言：我们爱我们的民族，这是我们自信心的源泉。

已经将博客移到新的域名下面。

admin — Tue, 03 Feb 2009 06:54:23 +0000

那晚，半夜睡不着，就想着起床，将博客移植移到新域名下面。经过一番折腾。弄到凌晨六点，终于成功移植，现在新的域名已经生效。域名为：http://www.evajiang.net.cn evan是俺英文名，jiang是俺本姓，所以，就注册为evanjiang.net.cn ，由于，俺不想直接将新域名指到原来博客所在的那个目录下面的某个子目录，因而，就在新域名所在目录重新安装了wordpress，并且将相应的修改过的php源文件，图片移到新目录下面。以及将模板以及插件移到新目录下面。然后在wordpress后台激活。只是在原来移植博客数据时，遇到一点障碍。但很快解决。后来，将博客的数据库表导出，然后再导入到新博客数据库对应的数据表里，最后，博客成功移植。只是那个永久链接，如终有问题。网页的永久链接可以生成，但在游览器訪問时，总说是404错误。但相信这个问题很快会可以解决。这个问题拖这么久没有解决，只是俺一直没有认真正视这个问题所至。没有认真思考解决问题所至，相信，俺正视这个问题后，会很快解决这个问题。

一直在考虑将winxp操作平台换成Linux或者Freebsd/opensolaris的。

admin — Fri, 30 Jan 2009 15:09:38 +0000

一直在考虑将winxp操作平台换成Linux或者Freebsd/opensolaris的。但都是担心这些开源操作系统在安装时，对分区系统的影晌，担心重新分区会影晌现存的其它分区的文件，造成数据丢失。一直没有换。还有。就是不知选用那个好。用Linux，还是用Freebsd 。俺倾向于用Linux，因为现有的开源软件跟linux的兼容性要好。而Freebsd，事后配置的过程会多一些。会比较占用时间。但是用Linux会比较容易。所以。一直在考虑的。

决定单独注册一个域名用于技术博客。

admin — Fri, 30 Jan 2009 15:06:12 +0000

再三考虑一下，决定单独注册一个域名用于温室小花技术博客。这个域名就是www.evanjiang.net.cn 主要是方便生成静态网页，方便给搜索引擎搜录！也方便记忆与推广。俺现在还没有弄清楚，为何总是不能生成成功生成静态网页。俺怀疑是因为没有给各个文类写上英文简写。所以。无法正常生成静态网页。这几天。抽空汇了域名钱，就将这个博客移植一下。