高质量编程C语言的学习方法

企业如何招聘到高质量的程序员？求解答

对此，你是不是很惊讶呀？但确实有一些自称为程序员的人几乎不会编程。

直到今天，仍会有一些招聘者告诉我，他们总会遇到一些应聘者无法通过最基本编程测试。

现在有一些服务可以帮助你解决在线测试应聘者的问题，比如 Interview Zen 和codility。

看开发者在互联网上的个人资料 任何名副其实的开发者应该有一份关于他们工作经历的简历。

它不必十全十美，我只关注应聘者在互联网上因帮助他人而留下来的点点痕迹。

向我展示你在 Stack Overflow 上的相关资料，凭此我可以了解你专注于哪些方面的技术信息，同时解决了哪些技术问题；给我一个你曾参与的开源代码库的链接；给我你的专业博客地址？Tumblr？Twitter？或其他一些我不曾听过的名字？不错，我可以好好看看。

向我展示你曾设计的应用，你曾工作过的网站，及你在其中担任怎样的角色。

雇佣适合企业文化的人 正如GitHub，我发现很好地融入企业文化比整天埋头苦工更容易获得成功。

我们会在面试过程中和应聘者谈论哲学，我们十分重视这个过程。

我们希望来 GitHub 工作的员工了解他们将要进入的这个企业，确认他们能很好地适应公司的环境。

这个过程包括一块吃饭，一起谈论企业文化、哲学、我们曾经犯过的错误、未来的规划等话题。

早些时候，我们招聘只注重应聘者的技能，而对于他是否适应企业文化，是否懂哲学并不太关注。

很自然，这些招聘并没收到很好的效果。

所以现在我们不仅注重应聘者的技能，是否能融入我们也是我们考察的重要部分。

据我所知，不是所有的业务领域都有相应技术圈子，但如果有，招聘者一定要尽可能地从技术圈子中招人。

因为该圈子中的技术人员会自然而然地对你企业所做的事感兴趣，也会很容易融入到与他们意愿一致的企业中。

这些应聘者较好适应企业文化的可能性是异常高的。

这也正是招聘者乐于见到的。

与应聘者电话沟通内容需结构清晰 上面提到的事你都完成了，现在是时候给应聘者打个电话了。

记住这个电话不是用来聊天的，而是为了筛选应聘者。

所以通话的内容是关于技术话题的，而且结构层次要清晰。

如果内容不太合适，你和应聘者都会被带离此次通话的目的。

内容应该覆盖技术基础，总结下来有下面几点： 快速编程。

如：编程实现从 Int 数组中找出最大的 Int 型数据；一些基本的设计。

脚本语言和正则表达式。

如：请从该目录中提取包含电话号码的文本文件列表，并以特定格式输出。

数据结构，如，你什么时候会采用哈希表 ，而不是数组？比特和字节，如：程序员为什么问说出“oct (31) == dec (25)”类似这样的笑话。

该举措的目的，是为了到下一流程后，可以节约应聘者和招聘者更多的时间。

你一定要坚持自己的立场，如果发现该应聘者多点不符后，尽早放弃该面试过程。

请应聘者参与实际项目 应聘者顺利通过了上文提到的四关，是时候进行面对面的面试了吗？现在还不是时候。

我曾见过一些应聘者，他们也顺利通过了上文提到的层层考验，但最终在实际工作中，并不能很好地完成实际任务。

如果你想确定无疑地判断他是否是一个优秀的应聘者，那就给他一个实际的项目做。

我说的不是一般的、抽象的编程任务，而是你们公司现在正在进行的某产品的一个实际开发模块——你本计划交给公司实际员工做的任务。

选择一个测试项目，在理想的情况下可以在几天，也可能最多在一个星期或两个星期内完成。

应聘者可以在公司里完成，也可以远程工作。

我知道不是每个企业都能把他们的项目切分成一些这样的小项目，分给应聘者在公司外完成——但可以尽力尝试让应聘者在公司内完成。

我个人认为，如果你无法为优秀的应聘者分配这样一个微项目，很可能说明你为现在员工分配的任务存在不合理性。

如果应聘者出色地完成了所分配的测试项目。

恭喜你，你找到了一个高素质的应聘者，他已被证明可以出色完成各项工作。

到现在为止，我所见过的通过该项考验的所有应聘者都能在实际工作中很好的完成任务。

准确地说，也不是百分之百保证，但我把该项测试看得很重要，因为在应聘者还未被雇佣前，你可以近距离地观看他在实际项目中的表现。

如果测试项目没成功，就把在该项目上所付出的代价看作一笔“退出费”，这相比请公司的 4 或 5 个人来进行一场昂贵的面试过程便宜多了。

最坏的情况是，把该项目用于下一个优秀的应聘者。

是时候与应聘者见面了 最后，你应该选一个时间与面试者见上一面了。

这是必然的，但通过之前所进行的一系列测试，你应该 95% 地确认这个应聘者就是很好的雇佣对象后再与他见面。

我并非面试专家，但我不喜欢问一些很难的问题，适度就好。

任何事都无法绝对保证 请正确看待上文所列举的招聘流程。

它们有时很成功，有时也会失败。

根据你自己的特殊情况，调整这些建议，贴合你的想法，忽略某些步骤（虽然我强烈建议你最好不要省，即便是跳过第一步）。

即便在最理想的环境下，招聘人才也是一件很难的事情。

一个工作机会的获得会受很多因素的影响，往往不受人的控制。

正如人们说的，人本来就很复杂。

如果把工作看作一种关系，每周需花 40 多个小时相处的关系，那么公司和招聘者都应该有一种信念，努力找到适合自己的对方。

我们的目的不只是找到一个工作，或雇佣一个人，而是为了生活乐趣，为了创造一种友爱的关系。

怎样编写高质量的测试用例

测试用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。

以上可以看出测试用例在整个测试工作中的地位和作用，以下编写了关于如何写好测试用例的一些个人建议： 　　1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。

只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。

　　2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。

　　3、尽量多参加项目组内的会议。

比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。

什么是“极限编程”？

ExtremeProgramming（极限编程，简称XP）是由KentBeck在1996年提出的。

KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。

Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。

1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。

它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

什么是软件开发 软件开发的内容是：需求、设计、编程和测试！ 需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。

比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理等交流。

设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。

你一定要按照这个来做，否则可能会一团糟。

编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。

测试：目的是让你知道，什么时候算是完成了。

如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。

否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。

软件开发中，客户和开发人员都有自己的基本权利和义务。

客户： 定义每个用户需求的商业优先级； 制订总体计划，包括用多少投资、经过多长时间、达到什么目的； 在项目开发过程中的每个工作周，都能让投资获得最大的收益； 通过重复运行你所指定的功能测试，准确地掌握项目进展情况； 能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划； 能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。

开发人员： 知道要做什么，以及要优先做什么； 工作有效率； 有问题或困难时，能得到客户、同事、上级的回答或帮助； 对工作做评估，并根据周围情况的变化及时重新评估； 积极承担工作，而不是消极接受分配； 一周40小时工作制，不加班。

这就是软件开发，除此之外再还有其它要关心的问题！ 灵巧的轻量级软件开发方法 一套软件开发方法是由一系列与开发相关的规则、规范和惯例。

重量级的开发方法严格定义了许多的规则、流程和相关的文档工作。

灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起来相对较容易。

在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。

程序的质量很难控制，调试程序很繁琐，程序员之间也很难读懂对方写的代码。

1968年，EdsgerDijkstra给CACM写了一封题为GOTOStatementConsideredHarmful的信，软件工程的概念由此诞生。

程序员们开始摒弃以前的做法，转而使用更系统、更严格的开发方法。

为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。

随着遇到的问题更多，规则和流程也越来越精细和复杂。

到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。

人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大的辅助开发工具（CaseTools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。

为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。

失败的原因很简单，这个世界没有万能药。

因此，一些人提出，将重量级开发方法中的规则和流程进行删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。

在这些流程中，合乎实际需要的规则被保留下来，不必要的复杂化开发的规被抛弃。

而且，和传统的开发方法相比，轻量级流程不再象流水生产线，而是更加灵活。

ExtremeProgramming（XP）就是这样一种灵巧的轻量级软件开发方法。

为什么称为“Extreme”（极限） “Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。

一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

XP的软件开发是什么样 1极限的工作环境 为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。

每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。

所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游戏……。

2极限的需求 客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。

开发人员和客户一起，把各种需求变成一个个小的需求模块（UserStory），例如“计算年级的总人数，就是把该年级所有班的人数累加。

”；这些模块又会根据实际情况被组合在一起或者被分解成更小的模块；它们都被记录在一些小卡片（StoryCard）上，之后分别被程序员们在各个小的周期开发中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试（功能测试）。

每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。

而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。

3极限的设计 从具体开发的角度来看，XP内层的过程是一个个基于测试驱动的开发（TestDrivenDevelopment）周期，诸如计划和设计等外层的过程都是围绕这些展开的。

每个开发周期都有很多相应的单元测试（UnitTest）。

刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。

通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。

XP提倡对于简单的设计（SimpleDesign），就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。

XP强调抛弃那种一揽子详细设计方式（BigDesignUpFront），因为这种设计中有很多内容是你现在或最近都根本不需要的。

XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求。

4极限的编程 既然编程很重要，XP就提倡两个人一起写同一段程序（PairProgramming），而且代码所有权是归于整个开发队伍（CollectiveCodeOwnership）。

程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。

任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。

5极限的测试 既然测试很重要，XP就提倡在开始写程序之前先写单元测试。

开发人员应该经常把开发好的模块整合到一起（ContinuousIntegration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。

除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。

所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

XP中的重要惯例和规则 1项目开发小组（Team） 在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。

而且，这个小组中必须至少有一个人对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项目计划等。

这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕最终用户的需求而展开的。

程序员是项目开发小组中必不可少的成员。

小组中可以有测试员，他们帮助客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的交流沟通等等。

项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP鼓励每个人尽可能地为项目多做贡献。

平等相处，取长补短；这就是最好的XP开发小组。

2计划项目（PlanningGame）、验收测试、小规模发布（SmallReleases） XP开发小组使用简单的方式进行项目计划和开发跟踪，并以次预测项目进展情况和决定未来的步骤。

根据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过测试的、可以使用的系统。

计划项目 XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。

不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。

针对这两个问题，XP中又两个主要的相应过程： 软件发布计划（ReleasePlanning）。

客户阐述需求，开发人员估算开发成本和风险。

客户根据开发成本、风险和每个需求的重要性，制订一个大致的项目计划。

最初的项目计划没有必要（也没有可能）非常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。

而且，这个计划会在实施过程中被不断地调整以趋精确。

周期开发计划（IterationPlanning）。

开发过程中，应该有很多阶段计划（比如每三个星期一个计划）。

开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新功能，或者会在一个周期内同时做两方面的工作。

但是，经过每个开发周期，用户都应该能得到一个已经实现了一些功能的系统。

而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。

在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。

这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。

这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。

每过两三个星期，客户总能够实实在在地看到开发人员已经完成的需求。

在XP里，没有什么“快要完成了”、“完成了90%”的模糊说法，要不是完成了，要不就是没完成。

这种做法看起来好象有利有弊：好处是客户可以马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做出来的东西，可能会很不满意甚至中止合同。

实际上，XP的这种做法是为了及早发现问题、解决问题，而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加 哪个内容等等。

验收测试 客户对每个需求都定义了一些验收测试。

通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。

XP开发人员把这些验收测试看得和单元测试一样重要。

为了不浪费宝贵的时间，最好能将这些测试过程自动化。

频繁地小规模发布软件（SmallReleases） 每个周期（Iteration）开发的需求都是用户最需要的东西。

在XP中，对于每个周期完成时发布的系统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。

这样，软件开发对于客户来说，不再是看不见摸不着的东西，而是实实在在的。

XP要求频繁地发布软件，如果有可能，应该每天都发布一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。

这些版本的一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。

3简单设计，PairProgramming，测试驱动开发，重整和优化 XP程序员不但做为一个开发小组共同工作，还以两个人为一个小开发单元编写同一个程序。

开发人员们进行简单的设计，编写单元测试后再编写符合测试要求的代码，并在满足需求的前提下不断地优化设计。

简单设计 XP中让初学者感到最困惑的就是这点。

XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。

这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。

在XP中，设计过程几乎一直贯穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。

整个设计过程是个螺旋式的、不断前进和发展的过程。

从这个角度看，XP是把设计做到了极致。

PairProgramming XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。

这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。

看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。

——这种工作方式极大地提高了工作强度和工作效率。

很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。

开始时总是不习惯的，而且两个人的效率不会比一个人的效率高。

这种做法的效果往往要坚持几个星期或一两个月后才能很显著。

据统计，在所有刚开始PairProgramming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高效。

项目开发中，每个人会不断地更换合作编程的伙伴。

因此，PairProgramming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。

这不但有利于个人，也有利于整个项目、开发队伍和公司。

从这点看，PairProgramming不仅仅适用于XP，也适用于所有其它的软件开发方法。

测试驱动开发 反馈是XP的四个基本的价值观之一——在软件开发中，只有通过充分的测试才能获得充分的反馈。

XP中提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等；与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。

另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。

即，任何人在往代码库中放程序（CheckIn）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。

这样，测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充足的反馈。

重整和优化(Refactoring) XP强调简单的设计，但简单的设计并不是没有设计的流水帐式的程序，也不是没有结构、缺乏重用性的程序设计。

开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重整和优化（Refactoring）。

这个名字最早出现在MartinFowler写的《Refactoring:ImprovingtheDesignofExistingCode》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。

Refactoring的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。

但XP强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。

当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。

4频繁地整合，集体拥有代码（CollectiveCodeOwnership），编程规范 XP开发小组经常整合不同的模块。

为了提高软件质量，除了测试驱动开发和PairProgramming以外，XP要求每个人的代码都要遵守编程规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查其他人写的代码。

频繁地整合（Integration） 在很多项目中，开发人员往往很迟才把各个模块整合在一起。

在这些项目中，开发人员经常在整合过程中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍使用整个系统，然后就马上交付给客户验收。

对于客户来说，即使这些系统能够通过终验收测试，因为使用时间短，客户门心里并没有多少把握。

为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USERSTORY（每次整合一个新的USERSTORY）。

每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。

整合后，就发布一个新的应用系统。

这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。

通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。

集体拥有代码（CollectiveCodeOwnership） 在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。

因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。

同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。

针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。

这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。

为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。

（从这点，我们可以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。

） 编程规范 XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。

因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现CollectiveCodeOwnership的重要前提之一。

5Metaphor（系统比喻），不加班 XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。

XP认为加班是不正常的，因为这说明关于项目进度的估计和安排有问题。

Metaphor（系统比喻） 为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。

比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。

” 不加班 大量的加班意味着原来的计划是不准确的，或者是程序远不清楚自己到底什么时候能完成什么工作。

而且，开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。

XP认为，如果出现大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源。

XP中一些基本概念的简介 UserStory：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。

开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory。

StoryEstimates和开发速度：开发小组对每个UserStory进行估算，并根据每个开发周期（Iteration）中的实际情况反复计算开发速度。

这样，开发人员和客户能知道每个星期到底能开发多少UserStory。

ReleasePlan和ReleaseScope：整个开发过程中，开发人员将不断地发布新版本。

开发人员和客户一起确定每个发布所包含的UserStory。

Iteration（开发周期）和IterationPlan：在一个Release过程中，开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。

TheSeed：第一个开发周期（Iteration）完成后，提交给客户的系统。

虽然这不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块。

ContinuousIntegration（整合）：把开发完的UserStory的模块一个个拼装起来，一步步接近乃至最终完成最终产品。

验收测试（功能测试）：对于每个UserStory，客户将定义一些测试案例，开发人员将使运行这些测试案例的过程自动化。

UnitTest（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。

Refactoring(重整和优化)：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。

小结 XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。

XP方法使开发人员始终都能自信地面对客户需求的变化。

XP强调团队合作，经理、客户和开发人员都是开发团队中的一员。

团队通过相互之间的充分交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件。

XP的设计简单而高效；程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早地将软件交付给客户。

XP程序员能够勇于面对需求和技术上的变化。

XP很象一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好后，一幅美丽的图画就会呈现在你面前。

如何提高编程技巧？

编程是个靠脑力,更多的人因为这个烦琐的问题而不愿去在它身上浪费时间.程序的语言其实是很有意思的,要学好一种计算机语言需要恒心和毅力.要有没日没夜的思考精神.通过一种类型的题学会解决其它的问题举一反三.程序也就是解决问题的步骤.思考好做事之前的准备工作(其中的条件)这样就可以编程序了.

大家认为最好的编程语言是什么？下载地址？教程？

/******我觉得写得比较好的文章*******/ 这个问题是每一位学习编程的初学者都会遇到而且很迷茫的问题，在这里发表一下个人观点，仅供参考： 1.每一种程序都有其发展的历程，没有任何一种程序是万能的，比如说我们都知道的C语言，开发C的初衷就是为了让程序员能脱离那种原始的汇编的环境， 可以在高级语言环境中对内存地址进行控制，所以C语言在底层操作上来讲要优越于其他高级语言；比如Pasical语言的初衷就是为了程序设计中的教学使用， 所以Pasical语言的语法结构很严谨；比如Fortran语言，开发的初衷就是为了工程计算，所以他的数学逻辑工程逻辑功能模块就相当强大，等等………… 2.现在的语言已经发展到面向对象的高级语言，像我们现在所熟知的Java、.Net、Delphi 等语言，他们开发应用软件来说基本没有太大的区别， 因为他们的库都已经很丰富，我们开发起来也相对较简单一些，他们的差距也就紧紧在于市场占有率和所在公司开发选择问题上了。

还有另外一个就是一些数据库编程的语言比如SQL、PB等语言，他们的数据库功能相当强大，由于微软产品的市场占有，所以大家比较倾向于SQL语言， 因为他的应用面要广一些，但是不乏有些朋友会基于一些其他的想法选择其他类型的数据库编程语言。

解释类语言，作为B/S开发模式的语言， 也是根据其市场占有规模来分，一般来讲市场占有率越高的语言程序，那么它的库要丰富一些，我们操作起来要相对容易些。

所以说， 现在流行的应用软件开发的语言来讲，我们一般考虑的是市场占有率高的，就会有更多的工作机会来等待我们；但是一些市场占有率稍低的开发语言（有自己特色的）， 工作机会自然少一些，但是报酬相对要高一些，物以稀为贵嘛！ 3. 各种语言的选择 如果编写对性能要求苛刻，或和操作系统结合紧密的程序，必然选择C。

如果编写到处可用的程序，选Java。

如果编写大程序，可能的话尽量用脚本语言如Python、Ruby，不行了再用Java和C。

因为脚本语言带来了生产力。

编写文本的处理程序用Perl或Ruby。

编写知识的处理程序用prolog。

编写最灵活，最模糊的程序用Lisp。

编写office程序用vba。

编写服务器端程序，PHP、（采用自己熟悉的语言来写，例如Perl、Python、Ruby）CGI、ASP、（熟悉Java就用）JSP都是选择。

编写数据库程序用vb或delphi。

如果要追求性能和程序的能力，要完全发挥操作系统的能力，使用C/C++语言是合适的。

在Windows环境下用VC，在Unix-like环境下用。

如果不是追求和操作系统完美结合，而只是性能，又要追求跨平台性，那么仍然选择C，但可以选择跨平台的库，如qt、gtk、fox、wxWindows。

如果要编写游戏也有跨平台选择：SDL。

如果不满意C领域标准的不统一，不满意C的容易出错，不满意C的面向对象特征不彻底。

如果不在乎跨平台，Windows平台可以选择C#，maC平台可以选择CoCo。

如果需要跨平台，可以选择Java。

如果需要跨平台，又要广泛的支持的话，选择Java。

在Unix-like下，最方便的工具语言是Perl，它有强大的社区和代码库的支持。

如果只作为简单应用的工具语言，Python和Ruby是更好的选择，他们的跨平台移植性好，应用也比较广泛。

其中Python更适合入门和交流，长期使用也不错。

Ruby是对Python不满意的另一个选择，它提供了很多额外的功能。

如果要选择一个程序的嵌入语言，原来有Lisp、Basic和Java，现在还可以选择Python和Ruby。

如果在要求动态解释执行语言，而又不想学其他语言的话，C程序员的选择是pike，Java程序员的选择是beanshell。

在Java平台，又想用脚本语言的话，可以用Python。

最正统的基于文档的语言或叫动态页面语言是JavaScript。

最专门的服务器端语言是PHP，当然也有很多其他选择。

XML语言以XUL为最着名，dtml也算一个，你自己也可以用XML作为自己特殊用途的语言。

比如jedit就用XML作为一种模式定制语言。

XML语言是一种比较先进的趋势 ，比现有的语言在特殊领域更高效。

要找容易实现的语言，Lisp和Tcl是选择。

Lisp的数据和程序融为一体的能力和自由是其他语言都没有的。

现在出现了一个Lisp的现代化的变种：REBOL。

如果有基于事实的编程的需要的话，prolog和Clips是必然。

4.其实说到最后，也许大家都已经迷糊了，因为我自己也迷糊了（不要扔我！谁啊？怎么还有鸡蛋？！*—%##*），不过只需要一个简单的道理： 选择什么方向（数据库、应用软件、底层开发等等），那要看我们对什么感兴趣，对什么有一种亲切感；选择好了方向，在选择需要那个具体的语言， 那就要看市场占有，公司发展前景，我们需要得到的利润回报等因素（不过，作为同种类的语言，一个真正的程序员是可以很好的跨越这种平台的， 也就是说你最好不要只学习一种语言）！ 5.如果你为了挣钱，就学Java C# VB 之类的快速开发工具; 如果你是为了挣钱还想搞搞技术， 就学C++之类的语言; 如果你想搞系统开发, 你就要从硬件，汇编，一点一点学起了

C语言的学习方法

首先申明，本人不是什么高手，但自认为对c还比较熟悉，可以给你提点建议： 1、学习C语言，要从入门到精通，需要读哪些书（从简单的到难的排序，越详细越好，最好都能注释下选择这本书的理由）？ 入门阶段：还是老谭那本。

理由：虽然不能说它写得有多好，但是你现在要做的是入门，要快速的掌握c的基本语法，这本书很好理解，能够让你在最短的时间内大致掌握这门语言的概更。

第二阶段：《c程序设计语言》(The C Programming Language)和《C语言解惑》(The C puzzle book) 理由：《the c programming language》号称c语言圣经。

其实它也只是一本介绍基础语法的书，不做入门教程是因为对于初学者来说，它难度稍大，之所以推荐，是因为它能让你---系统而严密的---把C语言知识构架整理一遍。

《c语言解惑》，系统的整理了c语法中容易让你产生迷惑或容易犯错的地方(如a+++++b等)，这时候你才算真正开始学习c语言了.（以上两本现在出重印了,应该在书店可以买到） 第三阶段：《C陷阱与缺陷》(C Traps and Pitfalls)和《高质量c/c++编程指南》 理由：《c陷阱与缺陷》是让对c的理解有质变得一本书，如如何理解(*(void(*)())0)()等问题，我的感觉是看完这本书让我真正从小菜鸟变成了老菜鸟。

《高质量...》，终于有一本国产的了，呵呵，我认为这本书是把你从土匪变成正规军的最好指南，该书涉及编程风格、效率、重载、健壮性等一些列之前很难注意的问题。

(以上两本《c陷阱...》已绝版，不过网上可以下载到中英文版，《高质量...》本身就是网络书，很容易找到) 其它推荐书：《c专家编程》《c和指针》 说实话这两本书我并没有看过（或看完），但有口皆碑，都是经典之作，不过都已经绝版，仔细找找网上有下载的。

2、有哪些好的C语言练习（越难的越好）？ 对语言本身的练习其实就是你对它的理解，用得多了，注意得多了，自然就ok了。

其它思维上的练习主要是算法和数据结构方面的，严老的《数据结构题集（C语言版）》如果你能做完就相当了不起了。

3、要学精C语言，还要具备哪些条件？ 其实c语言也只是一个工具而已，就像锄头一样，你每天挖地锄田自然就精通它了。

只要不是白痴，应该都没有问题。

4、C语言学完后接下去要学哪些语言好？ 这个我就没有资格回答了，因为除了少量汇编和c++，我大部分只用到了c,不过也许是一脉相承的c++吧。

c是面向过程的语言，学习c++面向对象的思想。

5、各位网友如果在学习计算机语言方面还有一些独到的见解，欢迎提出! 不是我提出的，不过真的很经典——“天下程序一大抄”,呵呵。