程序员绩效考核

第一篇：程序员绩效考核

程序员绩效考核

考核的意义

首先一个前提是，考核是手段不是目的。我一直觉得对一个团队来讲，有两个基本目标：一个是完成自己承担的工作仸务，一个是提升整个团队的能力。这两个目标相互促进，进而实现螺旋式的上升发展。考核只是为了更好的了解工作情况和团队情况、更清晰更准确的认识剖析自我，为改进和提升做准备的技术手段。

所以开发人员的考核对团队来说，有两层意义：既是团队成员的绩效奖金荣誉的一个数据支持，也是团队整体建设进一步发展的依据。

对个人来说，也有两个意义：横向可以与团队内其他成员做对比看到差距继续努力，纵向也可以跟自己的不同时间段做对比看到进步的足迹。

从设计上讲，考核应该跟公司的职级职位序列和绩效奖金等制度挂钩，不同的层次、不同的岗位，应该有一些不同的要求和考核方式，最终把考核的结果通过某些奖惩形式实施下来。没有奖惩激励的考核，只是纸上谈兵的空洞形式。考核的原则

程序员的考核一般可以从研发管理过程、项目与部门效益、公司考勤制度、主观考核评价指标等组成。因为程序员经常无偿加班（没办法，难道不是事实么？），公司考勤之类的制度应该不怎么用得到程序员的头上，剩下的主要也就是过程、效益和评价了。考核的原则我觉得有如下几个： 1.主客观相结合

一般来说，我们希望可靠本身越客观越好。但是制定指标收集客观数据，分析整理，对于IT研发过程来说，都是很复杂的事情。特别是研发本身不规范，技术能力差，不成熟的团队，变数大、流程不标准，很多事情难以度量。主观的一些东西就不可避免。但是，主观的考核应该尽量少，避免出现团队中仸人唯亲之类的影响团队整体的现象。2.合理量化 对于研发过程中的可以度量的数据，应该尽量合理的量化。度量的过粗，大家都差不多，效果不明显；度量的过细，对收集指标数据要求比较高，甚至对研发本身会产生一定的影响。所以，指标的量化应该结合实际的研发流程，做出比较经济的选择。3.双向和多向评价

对于上级对下级可以直接给予评价的行为，下级应该也能集体给上级打分。对于主观考核部分，应该做到360度测评，对某个开发人员的评价，可以先由开发人员自己给自己的主观评价部分打分，再由主管、团队内同事review评价，综合确定最终评价。4.要研发过程还是业务结果？

考核程序员的侧重点应该放在过程上，而不是业务的结果上。业务的结果应该由管理业务的人负责。简单的说，谁拍板谁负责（或谁受益谁负责）。所以，我一直觉得苦逼的程序员应该对自己的劳动本身负责。程序员在自己的一亩三分地做好工作，写得好代码，改得快bug，产出多，质量高，就是一个好程序员。当然对技术leader、architect的要求要放高一些。当然，业务的好坏一般关联到公司和部门的performance，这可是奖金和绩效的来源，理所当然跟程序员有关系，但不应该是考核的核心。对一个好的马龙（一般程序员，不上升到某种所谓的高度）来说，研发的本职工作才是作为一个程序员的核心价值。这也正是前面说到的不同的职位不同序列应该有不同的要求和考核方式。5.发展阶段与侧重点

当然，公司或团队本身的发展阶段，也决定了对程序员考核的侧重点不同。

对于一个能力一般偏下、经常延期、积累差、不规范、处以还没有实现温饱的团队，考核的重点应该是提升团队研发能力，按时完成仸务。

对于一个马马虎虎按时完成仸务，但是不规范、没合作精神、没动力的团队，考核的重点应该是引导其行为，走向规范化，实现团队协作性的整体提升。

对于一个有一定的积累，相对能力还不错，已经能很好的完成工作仸何的团队，考核的重点应该是如何进一步的提高研发水平和质量，实现标准化和流程化…….指标的制定

具体怎么制定考核指标，我就只说说思路吧。

1、研发过程 参与了多少项目，写了多少代码和文档，多少测试代码，完成多少模块和用例，解决了多少问题，bug率多少，reopen的bug率多少，多少次工作交付延期，多少次工作失误，内部做了多少次技术交流分享。。等等在研发过程中的工作度量

2、业务结果

参与的项目给公司带来多少收益，个人工作部分分别占总仸务量的比重，计算出来个人给公司带来多少收入。。参考部门的绩效和平均每人的绩效水平

3、制度考勤

迟到早退啦，请假旷工啦，等等

4、主观评价

同级的同事对其评价，上级领导的评价，工作态度，团队精神，技术水平，创新精神，主动性，责仸心等等。

类似这些，结合你们的实际情况看哪些数据可以作为考核的指标。然后再分别量化到一定的粒度。接着确定每个指标的比重，怎么统计汇总。最后做一个考核制度文档。考核的执行

有了考核标准和方式以后，就剩下执行了。执行的力度决定了考核制度是不是能起到作用。如果执行得好的话，可以边执行，边收集数据，改进考核方式。没有强有力的推动，不断的收集数据、check && review，考核就会仅仅流于形式了。

前提是公司项目经理需要指定出一套代码标准和项目进度及需求说明的文档，分发给对应的程序员！分几个方面吧

1、是否按照文档的要求书写代码。如果一个程序员不能很好的按照领导的要求办事，这样的程序员能力再强，我想开除也并不可惜！

2、根据个人的能力水平分配不同的开发任务。当然，项目经理是最清楚自己手下人员的个人能力以及能承担多大的开发任务。有时候项目中遇到事先没有想象到的困难也是正常的，这个时候对于员工加班是正常的，就看这个程序员是否通过其他途径或者求助并且能准时的完成任务!

4、个人的解决问题的逻辑思维能力。我带团队的时候就遇到过几个程序员，逻辑思维能力真的很弱很弱，给他提供很多解决问题的思路，就差把答案告诉他的，但是结果一样，还是抛给我一句话：不会！这样的早一天走，公司早一天减少损失！

3、个人的学习能力。这点本人觉得非常重要，如果一个程序员没有很强的学习能力的话，一个团队就得不到进步，一个团队得不到进步，结局显而易见！

程序员绩效考核

关于程序员的绩效考核问题，相信是很多软件公司致力追求却一直无法做到量化的目标。很多考核标准都只是一个框架，但却无法具体细致下去，从而引发了很多劳资方面的纠纷，到最后都是无果而终，无法坚持下去。但还是有很多人，特别是不懂得技术之人，乐此不疲，希望以此种方法来作为程序员报酬的衡量标准。

最突出的就是“仸务量”问题。软件编程行业的仸务，懂点编程的人都知道，这个行业是一个创造性、思维性的行业。一个仸务的工作量多与少是没有一个衡量标准 的，原因就是软件功能的实现结果，根本就没有一个最好的标准。

有的人就以工作时数来进行衡量。真的可以吗？举个例子：相同的仸务且相同实力的程序员，有的程序员花了一天就完成。也有的程序员花了两天完成，还 有的花了三天，四天，五天完成的。花一天完成的程序员做了功能上的实现，它是完成的，针对绩效考核来说，是满分的。但是，比他花多得多时间的程序员呢？他 们除了花在功能实现上，还花了很多时间在代码优化以及界面操作设计上。那么，从绩效考核来讲，也仅仅是满分。花一天与花几天的程序员的工作量真的可以相等吗？谁都知道不可能的。再打个比方，两个工作仸务，有可能在仸务量上它真的就一样。但是，在仸务安排上，一个项目组由于技术力量及时间限制上较为宽裕，在一个月内宽松地完成了，而另一个项目组由于在人力资源以及时间限制上，加班加点，用了十天就完成。以此相比，是哪个项目组的仸务量更大一点呢？

所以，绩效考核的框架是死的，而程序员的仸务是活的，用一个死的框架套住一个活的思想，程序员只为绩效的要求而实现，久而久之，一个软件项目根本就毫无创造性可言，就是一个生产线生产出来的一个标准化产品而已。

所以，我觉得，程序员的生产，就是个研发，而研发就是创造，不是生产工具，不能以简简单单的仸务量来衡量，更不能成为技术层面之外的人简简单单的薪酬衡量标准。用简单思想框架来束缚程序员的思维创造性，这是拖累研究，枀易打击程序员的研究主动性。

但真正没有办法为程序员计算劳动所得吗？我觉得，既然，程序员的工作是研发创造性的，那么，程序员就应当有个感性的前提，那就是视自身的劳功项目体现出的市场价值作为其劳动所得的标准。所以，我觉得，在这方面上，项目奖比起冷冰冰的绩效考核温暖得多，它直接反映的是程序员的创造性结果。在项目组内部的评比，则需要靠他们的直接带领人来衡量贡献的突出性，一是针对项目的技术贡献以及仸务完成的质量贡献。

第二篇：如何给程序员做绩效考核

如何给程序员做绩效考核

绩效考核的五种死因

程序员作为企业开发力量的最核心资产，无疑得到公司从上至下的一致关注。开发是个智力密集型产业，程序开发的特点是，付出相同时间的情况下，两个开发者之间的产能会相差十几甚至几十倍。软件开发人员向来以‚不容易考核、工作不容易被量化‛而著称。本期，我们重点分析程序员考核的‚死因‛及对策。

典型的程序员考核的产生

分析考核死因之前，我们先看下它是如何出生的。某天，公司老板突然想到一件事——我不懂研发，而研发对我公司这么重要，怎么办？念一及此，老板不禁有些紧张，马上叫来HR开会，安排本月人力资源部分的工作重点，那就是‚研发人员考核‛，务必贯彻到位、立即执行。深谙老板意图的HR，回到工位后立刻上网买书，从如何考核、KPI实务到平稳计分卡策略一应俱全，书到手之后连夜‚抄书‛赶制考核体系，整理出‚研发人员考核方法‛。第二天，HR把此考核方法交给研发总监并告知‚老板要考核你们，这是考核办法。具体指标和KPI请部门自己制定，本周末之前报给人力资源部。我们会汇报给总裁‛。研发总监拿着连夜撰写制度的人都没明白的‚办法‛找到项目经理：‚老板要考核我们，这是考核办法。你们团队成员的具体指标和KPI你自己定，明天下班之前汇总给我。‛项目经理找到了程序员：‚老板要考核你，这是考核办法。你自己的指标和KPI你自己定，今天中午之前给我。‛程序员迷惑地问：‚目标不是公司制定的吗？‛

很多考核就这么荒唐的开始了……

很快考核变成了每月项目经理给组里的程序员打分。

于是，老板很满意：‚我终于可以放松了，以后我们靠考核制度管理研发人员。我们从此摆脱了‘人治’时代！‛

HR也很满意：‚我不用明白研发是什么，更不必了解程序。我只要他们知道，我可以扣他们的钱就行了，还是用他们自己制定的指标！‛

其他人都不太满意……

不久之后，公司就会发生程序员离职率升高的现象。被考核者，诸如：程序员、项目经理、研发总监都走光之后，考核就这么死了！

接下来，谈谈程序员考核的五种死因及对策。

死因一：考核只以事件为核心

公司没有利润就不能生存，研发项目的进度很多时候决定着公司的利润。所以很多考核是把项目无限拆分到程序员层面，这样的考核只以事件为中心，关注事件是否做成，而不关注人和人的发展。只以事为中心的考核把程序员当成了生产线上的机器，有投入（高工资）就要有产出（高质量的代码），程序员被当成了标准件，即没必要有太多成长（因为做的都是相对重复的工作），也不能时常发生故障（经常加班也不能请假）。

有些程序员自号‚IT民工‛与这种考核体系的存在有很大关系。

这种考核体系可以维持短期内的高效率，长期执行会导致整个系统的崩溃。很多公司人员不断更替，根本无稳定可言，一部分原因是执行了或者实质上执行了只以事件为核心的考核。

专家支招：

张大志：承认程序员也是人，尊重人的个性是考核的基础。注重培训，在项目压力大时侧重结果，在有 Buffer的情况下关注程序员技能的提高和个人的发展是解决此类似问题的核心方法。在项目周期的不同阶段对考核方法进行调整的复合式考核方式，更能让企业向目标前进，也能保持程序员的热情。

胡争辉：换个角度从结果考虑，举一个最常见的例子，四个人合作种树，A挖坑，B种树，C填土，D浇水。如果考核只以事件为核心的话，那么当B没有种树时，C依旧填土，D依旧浇水。从考核来说A、C、D三个人都得了满分，就算B得了0分，平均分也该有 75%，超过60%及格线了，但是种树这个任务却没有完成。所以对于只以事件为核心的考核来说，不仅让程序员感觉不到团队的存在，而且程序员也不会为团队考虑。在这种情况下，考核就要调整为既包含个人要完成的事件，也要体现个人对团队全局的理解。

死因二：考核标准的一相情愿

第二个导致考核死亡的原因是：相关方法的制定、标准的出台都只以公司角度为惟一视角，一切服从项目需要、服从公司需要，绝少考核其它因素。所有考核指标都由公司来定，不让程序员参与意见。我就见过这样的开发计划：项目组成员工作12小时两班倒，7×24小时、持续长达3个月、没有Buffer。按这样的项目计划考核，除了能直接导致人员流失之外，没有其它功用。

很多程序员是在被扣工资之后才被相关人员告知自己的考核指标，之前根本没有人通知。考核时闭门造车的情况并不少见。

专家支招：

张大志：加强沟通，让程序员在考核开始之前了解自己的指标，是惟一克服此种死法的工具。公司怕与程序员就考核指标进行后，指标有贯彻不下去的风险。但考核失败的代价要远远大于对考核指标进行合理修改的代价。程序员如果离职，那很多事情都要重新来过。

胡争辉：在制订考核指标时，要始终贯穿考核的杠杆作用，也就是通过给员工制订影响切身利益的考核指标，让员工重视这些考核点，进而推动项目的完成，保障公司的利益。既然考核起到用小利益推动大利益这样一个杠杆作用，那么就不仅要让员工理解考核的指标，更要让员工在开始工作之前就要对能不能完成考核指标给出反馈。

死因三：考核制度的不合理性

很多考核刻板而没有弹性，让人感觉只是为了扣工资而制定的。常能考到程序员通宵加班，第二天凌晨离开公司回家睡觉，中午到公司继续工作。发工资的时候发现，扣了半天的钱，因为有半天不在公司。程序员会想：‚那我通宵也没给加班费啊！太不公平了！‛

考核制度没有弹性只能伤害程序员的积极性。

专家支招：

张大志：如同公司市场政策僵化会导致公司的失败，考核制度的僵化会导致制度本身的名存实亡。永远记住我们考核的是人而非机会，保持适当的弹性。

胡争辉：考核制度不仅有引导员工完成公司既定目标的职能，而且还有体现企业文化的职能，在企业文化中对一件事情只有一种观念，而不会有互相冲突的两种观念。例如，提倡加班的公司就不会提倡按时上下班，反之亦然。但是企业文化中也不会在提倡一个观念的同时，明确的反对另一个观念。比如说公司提倡按时上下班的时候，不会明确反对加班。所以考核制度难免和企业文化有冲突，这种情况在公司的HR新上任的时候尤为突出，因此HR在上任伊始，不仅要学习企业文化中提倡的观念，也要理解企业文化没有明确反对的那些观念，进而通过考核制度体现出来，让考核制度成为落实企业文化的有力工具。

死因四：考核制度的虚无性

国人常讲‚王子犯法与庶民同罪‛，但程序员考核面前的大多数情况下却很难做到人人平等。评分者看好的，往往考核松些；无门无派的考核相对客观，与评分者关系紧张的一般都是最低分。意思很明，就是为了挤兑你走呢。考核于是成了政治斗争的工具，成了打压异己的手段。

专家支招：

张大志：有效设立方监督机制、360度考评、轮换考评者是解决以上问题，避免考核成为斗争工具的方法。也许有人的地方就有斗争，但是程序员考核仍然应以客观、公正为标准。

胡争辉：为了避免考核的主观和随意，应当建立自评分与考评分相结合的制度，不仅要由考评者打分，也要由被考核的员工自己打分，对于这两个打分有显著差异的时候建立复审制度，由更高级的管理人员对考评结果组织仲裁，仲裁小组应当包括高级管理人员、HR以及在考核周期内与被考核的员工有工作关联的其他员工组成，通过这样的流程不仅可以避免考核的主观和随意，还可以借此改进考核制度。

死因五：考核中HR常胜不败

考核要有监督机制，但并不需要一个婆婆式的人物在背后指手划脚。很多程序员考核中HR都充当着这类不光彩的角色。不了解研发的HR制定出来的考核制度，可行性必然不高。与此同时，一旦有程序员因为不满考核而离职，HR会马上抛出自己的理论：‚此程序员不适合我们的企业文化，他还不擅长沟通。‛即使走的是项目骨干，HR还是拿出这套说词，很让人汗颜。

一个非理性的群体里很难容下理性的程序员，离开可能是最好的方法。

专家支招：

张大志：开放的心态是做好HR的前提，考核的时候人力资源部的同事不应该把自己当神，这里不需要神，而应该把自己的角色定位于用心理解程序员的朋友。

胡争辉：作为一个完善的考核制度而言，不仅应当由HR部门组织对员工的考核，也应当有对HR部门的‚考核制度‛。这种考核应当以员工满意度为指标。比如说一项考核指标遭遇大部分员工表示不满的时候，就需要对此进行调整。不合理的考核如果长期得不到改善，会有越来越多的员工抱着‚法不责众‛的心理对待这项考核，长期以往，还会影响到考核制度的严肃性。

第三篇：程序员（范文模版）

作业：研究一个新或自己感兴趣的职业 v介绍:名称定义

v典型生涯路径：从新手到最高职位的生涯路径

v趋势：技术、组织结构、培训、经济趋势对职业的影响

v薪酬：差别、地域差别

v所需技能

v教育/培训:受教育程度

v证书/资格证书

v工作条件：环境、压力、工作时间、是否出差？

v聘用机构

v对生活方式的影响

v性别构成v聘用过程

v专业知识 月收入

人数

<1000元 131 1000-3000元 919 3001-5000元 477 5001-10000元 245 10000元以上 44

最多的部分居然是“1000-3000元”...程序员苦哇，同志们！

程序员

目录

1作为一个真正合„

2岗位职责

3行业现状

4职业要求

5必备技能

6素质要求

7职业困境

程序员(英文Programmer)是从事程序开发、维护的专业人员。一般将程序员分为程序设计人员和程序编码员，但两者的界限并不非常清楚，特别是在中国。软件从业人员分为初级程序员、高级程序员、系统分析员和项目经理四大类的方法。

岗位职责

1、对项目经理负责，负责软件项目的详细设计、编码和内部测试的组织实施，对

小型软件项目兼任系统分析工作，完成分配项目的实施和技术支持工作。

2、协助项目经理和相关人员同客户进行沟通，保持良好的客户关系。

3、参与需求调研、项目可行性分析、技术可行性分析和需求分析。

4、熟悉并熟练掌握交付软件部开发的软件项目的相关软件技术。

5、负责向项目经理及时反馈软件开发中的情况，并根据实际情况提出改进建议。

6、参与软件开发和维护过程中重大技术问题的解决，参与软件首次安装调试、数据割接、用户培训和项目推广。

7、负责相关技术文档的拟订。

8、负责对业务领域内的技术发展动态。

一、通过国家统一组织的考试，资格考试分初级程序员级（技术员级）、程序员级（助

理工程师级）和高级程序员级（工程师级）；水平考试分初级程序员级、程序员级、高级程序员级、系统分析员级、以及网络程序员（初级）、网络设计师（中级）。

二、报考条件：报各级水平考试者无学历、资历限制；在职人员均可报初级程序员资格，其中大学本科毕业或任技术员两年以上者（含二年），可报程序员级资格，研究生毕生或任助工两年以上者（含二年），可报高级程序员级资格（计算年限均至本12月31日）。

三、报名手续：报名时须持身份证或学生证，交本人近期同底一寸免冠半身照两张及报名费100元（系统分析员报名费150元），其中报资格还须提交本人工作证及任职证明或相应学历证明复印件。

作为一个真正合格的程序员应该具有的素质 1：团队精神和协作能力

把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。一旦进入系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人是不合格的。

2：文档习惯

说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3：规范化，标准化的代码编写习惯

代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。有些codingfans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己?根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。没有规范化和标准化的代码习惯，研发之间的协作是绝对不可想的。

4：需求理解能力

程序员需要理解一个模块的需求，很多程序员写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。

5：复用性，模块化思维能力

经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。

复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。

一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在很多软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力，这是我们应当刻意克服的弊病。

6：测试习惯

作为一些正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。

测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。

当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当然这需要上面提到的需求理解能力。

7：学习和总结的能力

程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。

但是学习也要找对目标，善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。

具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是一种意识上的问题。

作为高级程序员，乃至于设计师而言，除了应该具备上述全部素质之外，还需要具备以下素质：

1、需求分析能力

2、整体框架能力

3、流程处理能力

4、模块分解能力

5、整体项目评估能力

6、团队组织管理能力

世界上第一位程序员是英国著名诗人拜伦的女儿AdaLovelace曾设计了巴贝奇分析机上解伯努利方程的一个程序。她甚至还建立了循环和子程序的概念。由于她在程序设计上的开创性工作，AdaLovelace被称为世界上第一位程序员。美国国防部开发的ADA语言就是为纪念这位世界上的第一位程序员而命名的。

计算机科学发展到今天（21世纪初期），程序员从事的人群很多，分工也不相同，从大的方面可以分为以下几类：

asp程序员 jsp程序员 delphi程序员 php程序员 powerbuilder程序员.net程序员 vb序员 java程序员 javascript程序员 C++程序员

职业要求

一般的程序员都有四年的在专业领域的学习，需要一个在程序领域的学士学位获得者，不论是数学方面的还是工程方面的都是可以的。

大约有20%的人在这一领域的计算机科学和工程学拥有更高的学位。还有很小一部分程序员是自学的，尽管一些专业性的学校或者综合大学可以提供，但是也需要一些别的途径来提供相关的人才。尽管学历是比较重要的，但是公司经常把重点放在应聘者的工作经验上，很多刚从大学毕业的大学生虽然有引人注目的学位证书，但是他们找不到工作是因为他们缺乏经验。一个程序员虽然有正规的学历，但是如果一个人拥有程序设计的深厚知识背景或者丰富的工作经验的话，那么他的机会要比有学历的应届毕业生大得多。所以要尽量抓住有用的工作和实习机会，这样的话在毕业后你就会发现，多实习让你有更多的经验，在找工作的时候就有更多的机会。

对于职业程序员，另外一个重要的方面就是，程序员需要不断提升自己的业务技术，他的技术必须一直保持在一个较高的水平，并且要不断发展，程序员也要寻找贸易的机会，要参加研讨会，在周刊上发表文章和接受职业教育，这些使程序员在自己的领域中分级或者不断并排前进。

必备技能

熟练开发工具

做为一名程序员至少熟练掌握两到三种开发工具的使用，这是程序员的立身之本，其中C/C++和JAVA是重点推荐的开发工具，C/C++以其高效率和高度的灵活性成为开发工具中的利器，很多系统级的软件还是用C/C编写。而JAVA的跨平台和与WEB很好的结合是JAVA的优势所在，而JAVA即其相关的技术集JAVAOne很可能会成为未来的主流开发工具之一。其次，能掌握一种简便的可视化开发工具，如VB，PowerBuilder，Delphi，CBuilder，则更好，这些开发工具减小了开发难度，并能够强化程序员对象模型的概念。另外，需要掌握基本的脚本语言，如shell，perl等，至少能读懂这些脚本代码。

熟知数据库

为什么数据库是如此重要？作为程序员，他们自然有自己的理由：很多应用程序都是以数据库的数据为中心，而数据库的产品也有不少，其中关系型数据库仍是主流形式，所以程序员至少熟练掌握一两种数据库，对关系型数据库的关键元素要非常清楚，要熟练掌握SQL的基本语法。虽然很多数据库产品提供了可视化的数据库管理工具，但SQL是基础，是通用的数据库操作方法。如果没有机会接触商业数据库系统，可以使用免费的数据库产品是一个不错的选择，如mySQL，Postgres等。

了解操作系统

当前主流的操作系统是Windows，Linux/Unix，熟练地使用这些操作系统是必须的，但只有这些还远远不够。要想成为一个真正的编程高手，需要深入了解操作系统，了解它的内存管理机制、进程/线程调度、信号、内核对象、系统调用、协议栈实现等。Linux作为开发源码的操作系统，是一个很好的学习的平台，Linux几乎具备了所有现代操作系统的特征。虽然Windows系统的内核实现机制的资料较少，但通过互联网还是能获取不少资料。懂得网络协议TCP/IP。

在互联网如此普及的今天，如果您还没有对互联网的支撑协议TCP/IP协议栈有很好的掌握，就需要迅速补上这一课，网络技术已改变了软件运行的模式，从最早的客户/服务器结构，到今天的WEBServices，再到未来的网格计算，这一切都离不开以TCP/IP协议栈为基础的网络协议支持，深入掌握TCP/IP协议是非常必要的。至少，需要了解ISO七层协议模型，IP/UDP/TCP/HTTP等常用协议的原理和三次握手机制。明白DCOM/CORBA/XML/WEBServices存在的意义

随着技术的发展，软件与网络的无缝结合是必然趋势，软件系统的位置无关性是未来计算模式的重要特征之一，DCOM/CORBA是当前两大主流的分布计算的中间平台，DCOM是微软COM(组件对象模型)的扩展，而CORBA是OMG支持的规范。XML/WebServices重要性不言而喻，XML以其结构化的表示方法和超强的表达能力被喻为互联网上的“世界语”，是分布式计算的基石之一。

不要将软件工程与CMM分开

大型软件系统的开发中，工程化的开发控制取代个人英雄主义，成为软件系统成功的保证，一个编程高手并不一定是一个优秀的程序员，一个优秀的程序员是将出色的编程能力和开发技巧同严格的软件工程思想有机结合，编程只是软件生命周期中的其中一环，优秀的程序员应该掌握软件开发各个阶段的基本技能，如市场分析，可行性分析，需求分析，结构设计，详细设计，软件测试等。

需求理解能力

程序员要能正确理解任务单中描述的需求。在这里要明确一点，程序员不仅仅要注意到软件的功能需求，还应注意软件的性能需求，要能正确评估自己的模块对整个项目中的影响及潜在的威胁，如果有着两到三年项目经验的熟练程序员对这一点没有体会的话，只能说明他或许是认真工作过，但是没有用心工作。

模块化思维能力

作为一个优秀的程序员，他的思想不能在局限当前的工作任务里面，要想想看自己写的模块是否可以脱离当前系统存在，通过简单的封装在其他系统中或其他模块中直接使用。这样做可以使代码能重复利用，减少重复的劳动，也能是系统结构越趋合理。模块化思维能力的提高是一个程序员的技术水平提高的一项重要指标。

素质要求

团队精神和协作能力

团队精神和协作能力是作为一个程序员应具备的最基本的素质。软件工程已经提了将近三十年了，当今的软件开发已经不是编程了，而是工程。独行侠可以写一些程序也能赚钱发财，但是进入研发团队，从事商业化和产品化的开发任务，就必须具备这种素质。可以毫不夸张的说这种素质是一个程序员乃至一个团队的安身立命之本。

文档习惯

文档是一个软件系统的生命力。一个公司的产品再好、技术含量再高，如果没有缺乏文档，知识就没有继承，公司还是一个来料加工的软件作坊。作为代码程序员，必须将30%的工作时间写用于技术文档。没有文档的程序员势必会被淘汰。

规范化的代码编写习惯

知名软件公司的代码的变量命名、注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。

测试习惯

测试是软件工程质量保证的重要环节，但是测试不仅仅是测试工程师的工作，而是每个程序员的一种基本职责。程序员要认识测试不仅是正常的程序调试，而要是要进行有目的有针对性的异常调用测试，这一点要结合需求理解能力。

学习和总结的能力

程序员是很容易被淘汰的职业，所以要善于学习总结。许多程序员喜欢盲目追求一些编码的小技巧，这样的技术人员无论学了多少语言，代码写起来多熟练，只能说他是一名熟练的代码民工，他永远都不会有质的提高。一个善于学习的程序员会经常总结自己的技术水平，对自己的技术层面要有良好的定位，这样才能有目的地提高自己。这样才能逐步提高，从程序员升级为软件设计师、系统分析员。

拥有强烈的好奇心

什么才是一个程序员的终极武器呢，那就是强烈的好奇心和学习精神。没有比强烈的好奇心和学习精神更好的武器了，它是程序员们永攀高峰的源泉和动力所在。

行业现状

由CSDN、《程序员》主办的2007年开发者大调查2007年底已收到15000多份有效问卷，已经是中国调查样本最多的开发者调查。在这次调查中，详细的分析了样本空间的分布状况，发

现在庞大数目的有效问卷的参与者中有70%也就是接近一万一千名的参与调查者是IT的全职人员，14%的参与者是有过开发工作经验的学生，从这样的分布就可以看出来IT从业人员对专业知识的需求是巨大而迫切的，CSDN作为专业的软件开发技术门户网站，已经是大家获取这些技术知识的主要手段。

一、选择数据库技术和互联网技术的人数总和占到了总人数的一半

2007年火热的SOA和动态语言各占13%和12%。其实这几大块技术分布他们之间都是有一定的联系的，互联网的发展近两年呈爆炸式的增长态势，中国的网民总数已经超过了1.4亿这样一个巨大的数字。

企业中业务的复杂程度越来越高，商业竞争不断增加企业的IT系统，使企业的商业数据呈几何数量级不断增长，在后台海量的数据中数据的管理由之前的单一型数据变成了多纬度的复杂数据，所以可以同时管理关系型数据库和XML数据的混合型数据库已经成为主流。

面对企业不断增加新的IT信息系统，整合已经迫在眉睫，SOA成为必然的趋势，企业对人才的需求从单一型技术人才、业务人才跳跃到了业务技术的复合型人才，这次的开发人员大调查令《 程序员》杂志的调查者看到了这些技术焦点背后千丝万缕的关联。

二、几乎一半的.NET用户不参与开源项目RedHat+Ubuntu占有率超过70%

应用到.NET平台上的开源项目，“大量使用”的比例数仅为8.68%，尚不足一成；“少量应用”的开发者人数比例为42.78%。“基本不用”的比例高达48.54%，与前二者之和几乎不相上下。

虽然开源的出现和发展，让软件没有垄断的未来日渐明朗；虽然开源运动经过多年的高速发展，现在已经聚集了相当的力量，开源的自由和给予理念逐渐深入到了企业的技术核心层面。但微软以商业软件为生，毕竟在微软技术领域中，开源项目通常都被看作是二等公民。很多开源项目对.NET社区产生了巨大的推动作用，微软公司很难提供任何实质性质的支持。

Linu版本

当前安装有Linux操作系统，数据中RedHatFedora占据绝对优势——Linux使用者使用该版本占总数的49.49%。Fedora是RedHat推出的重要的一款Linux版本，在每个fedora版本中都是集成最新的Linux软件，特别是服务端软件。

使用“RedHatFedora”关键词在百度网页中搜索得到7,090,000条结果，RedHatFedora在调查中占据Linux版本的半壁江山符合整个Linux版本的分布情况。

排在第二位的是Ubuntu，受支持数占到总数的23.92%；第三位的是SuSE占9.09%，接下来是Debian，使用率为5.92%。

在这里面令人期待的中国本土Linux的让人大失所望。使用率仅占5.16%，几乎只

有RedHatFedora的十分之一。

三、揭示八成技术人员数据库选型标准SQLServer用户接近50%

使用率占据榜首的数据库产品是微软的SQLServer，比例数达到了47.92%。与其余所有的数据库之和分庭抗衡，大有一览众山小之势。

从调查得到的使用率来看，MySQL仍处于望MSSQLServer项背的阶段。调查显示，MySQL的使用数为1651，占总数的13.80%，不过排名第三。

使用率排在第二位的是Oracle，比例达到24.21%。在前有SQLServer，后有MySQL的情况下，Oracle仍能达到四分之一的占有率，发展势头不可谓不强劲。

虽然Orcale数据库的价格比SQLServer数据库要高，但Oracle采用开放的策略目标，可在所有主流平台上运行。而且有开发者认为Oracle的安全认证是获得最高认证级别的ISO标准认证，因此安全性高于SQLServer。

排在第四位的是Access——5.59%；接着是DB2UDB，占总数的2.75%；至于FoxPro、Informix、PostgreSQL、Sybase得票数均仅在一百左右，还有待进一步的发展。

四、中国程序员最爱的智能手机平台Linux+Java超过Symbian

“开源Linux对于众多开发者的吸引力是巨大的，但是，这仅仅是针对于技术开发人员来说的，而对于普通消费者就不是如此了。”在众多开发者心中，主要是对Linux的青睐。从调查结果中也可以直接反应这样的现象。有专家对此评论说：Linux+Java的模式,应该是应用最多的模式。

开源Linux对于众多开发者的吸引力是巨大的，但是，这仅仅是针对于技术开发人员来说的，而对于普通消费者就不是如此了。针对此问题行业的专家有自己的观点：“现在Wince和Symbian发展很快，并且随着手机硬件方面性能的提高，很多政府部门和企业在采购时，很多会考虑Dopod这样的手机，或者价格便Wince和Symbian都主要使用c++开发，正是嵌入式开发的潮流。”

不同人群对于收集智能操作系统的观点是不同的，对于开发者角度，他们更加青睐于微软和开源Linux的产品，而普通大众他们比较喜欢Wince和Symbian。五、七成程序员不愿意选择门户网站获取开源信息SourceForge占绝对优势

30%的技术人员从门户网站获取开源技术信息，剩下的70%的技术人员都是从专业的开源社区和开源厂商的技术网站上获取信息，包括有SourceForge、LinuxToday、OpenOffice和IBMdW等。

在这70%当中，比例占有绝对优势的就是SourceForge了，这里是开源软件的开发者进行开发管理的集中式场所，也是全球最大开源软件开发平台和仓库。而LinuxToday里面会有记录很多很新的Linux业界大事，新闻以及出版信息。所以，对开源技术感兴趣的程序员们，不必再为如何获取开源信息而苦恼了，快加入到这70%的人群中来吧。

互联网的发展已经成为大家获取信息最主要的渠道之一，网民上网的习惯也从开始的上为数不多的几个门户网站发生了变化，大而全的门户网站并不能满足专业领域人员的信息需求，从2004年开始陆续出现了大量的各个领域垂直细分的内容网站，一方面有长尾理论的理论支持，另一方面厂商也建立了相应产品的技术内容网站，希望能聚集一批专注于这个领域专业人士，做好他们的定向营销。

做细分领域内容的网站对门户已经造成了一定的威胁，这些网站的专业性高，用户的粘性相对也比较高，如果细分领域的内容网站能将自己的服务有所提升，就如同SourceForge一样，那么未来门户网站的路就变得更加崎岖了。

六、Java开发框架：6%的JSF欲撼动21%的Struts

JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。未来两

年，JSF与Struts将展开JavaWeb框架的最终战争。经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的JbossSeam作为挑战者之外，几乎难有劲敌。

JavaB/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。

详细的分析了Java开发框架的使用状况，发现主要使用的开发框架JSP占26%，Struts占21%，Hibernate占17%，SpringMVC占11%，EJB占7%，JSF占6%，SpringWebFlow和POJO各占4%，其它占4%。就这一调查数据，不难看出，Spring+Hibernate+Struts的优势地位还是相当的明显。

Struts和Hibernate几乎已经成了JavaEE应用的常规配置，21%的开发者用到Struts，用到Hibernate的开发者也有17%；在一个成熟的技术平台上，各个项目的技术方案会在很大程度上趋同——因为所有未知领域都已经被探明，各种问题都有对应的最佳实践，架构师们可以参考的成功案例越来越多。就拿JavaEE来说，架构师们需要考虑的问题比之三年前已经简单多了，这就是成熟的价值。

有专家评论：“其实IT应用技术，什么新鲜玩意并不难学，难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的占重要地位，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那为什么用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在JavaWeb层的规范化方面所做出的贡献。

然而长江后浪推前浪，Struts1.x的技术缺陷毕竟是隐患。Sun力推JSF，打算一雪Web层框架缺失之耻。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。未来两年，JSF与Struts将展开JavaWeb框架的最终战争。

JSP经过几年风雨洗礼依然把持头把交椅，看来所有的框架表示层都离不开JSP而存在，而作为JSP的手足兄弟JSF也是仅次Spring之后又一个后起之秀。

七、C++开发环境格局难打破75%的开发人员首选VS系列

BCB正江河日下，2007版本的推出也无法力挽狂澜。虽然现在C++Builder已经归于CodeGear，但人们还是习惯性地与Borland联系上。

1998年Borland公司推出的C++Builder这一当年全新的32位Windows开发工

具，继承了Delphi使用简便、功能强大、效率高的特点，并且结合了C++语言几乎所有优点。所以开始C++Builder迅速风靡。它的主要竞争对象——Microsoft开发的VisualC++也是不甘示弱，迅速出击，突出了Visual可视化强的特点，加上Platform、SDK部分以及Microsoft产品与Windows的天然默契，逐渐成为了技术人员的首选。随着VisualC++版本的不段升级，以及功能、风格等诸多原因，BCB渐现颓势，许多Builder使用者也开始转而使用Visual了。

在2007年CSDN、《程序员》主办的开发者大调查中，详细的分析了C++方面大家主要使用什么IDE的状况，在目前已收到的15000多份有效问卷中，发现主要使用VS系列的占了75%，BorlandC++Builder/CBuilderX只占6%，EclipseCDT占6%，DevC++占2%，其他IDE占3%，不使用IDE占8%。对于.NET开发，VisualC++2005有了一套新的语法；新的优化技术，可使程序的速度最高提高30%；同时新的编译模式，可保证在Microsoft.NETFramework之上生成完全遵从CLI（CommonLanguageInfrastructure）的可验证代码；新的interop模式，可提供本地与托管代码的无缝融合。

相对于前两个版本，新编译器还包括了一个增强版本的缓冲区安全检查选项，而且对C++程序普遍使用的库，也有新的注重安全的版本。VisualC++2005对基于IntelItanium和AMD64的64位平台，提供了对OpenMP标准的支持，并且修正了一些混合DLL加载的问题，对DoubleP/Invoke的性能问题，提供了自动运行时消除。相比之下，C++Builder2007英文版2008年6月初上市。从CodeGear大中华区技术总监李维的博客，看到CodeGear对C++Builder2007的期待。虽然说对同一件事情，每个人都有自己的视角，已有五年C++方面学习和开发经验的赖勇浩说道：“BCB正江河日下，2007版本的推出也无法力挽狂澜。虽然现在C++Builder已经归于CodeGear，但人们还是习惯性地与Borland联系上。

现在的Microsoft及VC势头强劲，产品也具有很高的质量性，CodeGear在C++和.Net领域至少三五年内会继续望其项背。所以推出CB2007，更多的是基于版本延续。”

八、程序员更喜欢Firefox市场份额超过IE7.0两倍

参与调查的多数是软件开发人员或者多数是IT从业人员，但是从这一比例不难看出，IE丢失掉了曾经在浏览器大战中占据了的技术优势，在IE6推出后的5年时间里，浏览器一直在快速发展，而IE却一直没有更新过，这对一个世界上最常用的产品来说绝对是致命的。Firefox（火狐浏览器）以它的小巧、安全，很容易扩展和定制的特长获得了越来越多的喜爱。

更重要的是，它是是一个自由的浏览器，所有的源代码都是开放的，任何人可以为它的成长贡献力量。Cookie、页面缓存，个人都可以精确的控制，这些特性都是技术人员们所崇尚的“我的 地盘我做主”的精神。如果说之前FireFox相对IE6有50%的优势的话，那么，FireFox相对于现在的IE7的优势已经降低到25%左右了。因为IE7从底层已经做了很多的修改，已经慢慢的向W3C标准靠近了许多，在功能使用方面与FireFox的差距也变得很细微，Tab功能，CSS和脚本支持功能现在IE7都比之前表现强了，差距仅仅存在于某些小细节中了。

IE6在这个市场中存在了5年之后微软才意识到改变和向国际标准靠拢的重要性，这就直接导致了大量的技术人员失去了对IE的信心，投向FireFox阵营，不过，微软到底还是强大的，在全球范围内有很多的“粉丝”，他们会一直关注微软的任何一次动作，客观的评价也是对产品最好的反馈，也是最有价值的。

关于Maxthon和腾讯的TT，虽然它们都是基于IE内核的浏览器，但是Maxthon在这次调查中仅次于FireFox，力压IE名列第二的位置，着实看出了这几年Maxthon确实做到了他们的口号“让技术为使用舒适服务”。

包括了FireFox、Opera这种标准的浏览器，也包括了Maxthon和TT这样基于IE内核的浏览器，对于标准的浏览器，FireFox和Opera的重点是要解决兼容问题，而基于IE内核的Maxthon和TT更主要的是要解决浏览器插件、工具的应用问题，所以，技术产品的激烈竞争带给用户的其实是一种良性循环，使我们可以第一时间用到最好用的工具，至于商业效应，还是留给厂商自己去考虑吧。

九、中国程序员健康两成感觉很虚弱亚健康接近七成

“干得比驴累，吃得比猪差，起得比鸡早，看上去比谁都好，五年后比谁都老。很多程

序员都曾这样感慨和抱怨过自己的生活状态。” 亚健康状态是人体处于健康和疾病之间的过渡阶段，在身体上、心理上没有疾病，但主观上却有许多不适的症状表现和心理体验。

位于调查结果第二位的是“很虚弱”——149，比例为19.81%。很虚弱的健康指数低于亚健康，已接近生病和透支状态，他们的健康已经被亮出了黄牌。

每个人的理解不一样，但是“糟透了”这样的词如果用来形容程序员健康的话，相信大多数人都绝对认同“你已经病了”这样的理解。令人不敢相信的是，竟然有8.24%的程序员用这个词来形容自己的健康状态！

调查结果中“非常健康”的票数低得可怜——40，即使算上“没感觉”，二者之和也不过9.04%，几乎跟“糟透了”持平。如果将“非常健康”和“没感觉”一起算为健康的话，处于亚健康状态的程序员是健康状态的7倍，自认为“很虚弱”的程序员数目是处于健康状态的2.2倍！

十、.NET全面进入2.0时代，AJAX风头正劲“在Java领域，JDK5.0是当之无愧的主流平台，但JDK1.4仍保有一半以上的占有量。总的来说，Java族群显然不像.NET族群那样追新。从另一个方面看，这也说明Java平台的成熟，和.NET平台的迅速发展。”

根据2007年的调查数据分析，在.NET领域，.NETFramework2.0的采用量已全面超越.NETFramework1.1，成为.NET平台的首选框架。2006年调查结果，1.1和2.0的采用量基本持平，而2007年2.0的采用量则高达1.1的三倍之多。.NETFramework1.1已是明日黄花，微软的更新

换代策略可以说是成功的。在Java领域，JDK5.0是当之无愧的主流平台，但JDK1.4仍保有一半以上的占有量。总的来说，Java族群显然不像.NET族群那样追新。从另一个方面看，这也说明Java平台的成熟，和.NET平台的迅速发展。

B/S已经成为中国软件业普遍接受的软件结构。在表现层，AJAX技术采用量较去年有较大提升，有将近一半的Web应用采用了AJAX技术，仍采用纯HTML+少量脚本的Web应用中，也有四分之三打算转向采用AJAX技术。反观微软和Adobe力推的新一代RIA平台，则响应者尚少。分别只有1/20和1/10的人愿意选用SilverLight和Flash/Flex作为Web表现层技术。

职业困境

老虎、Bill、自己，中国程序员的困境也来自三个方面

困境之一：老虎的威胁。程序员要面对的饿老虎实在不少，比如说老板，好象老板就是程序员的天敌，什么“不懂技术却指手画脚”、什么“得到与付出不相当”似乎是程序员最常见的牢骚，这个问题不可能得到真正的解决。

困境之二：Bill的竞争。一般说来中国的程序员大都是吃“青春饭”的，大部分程序员的黄金时代是24～28岁。到了30岁左右，一批又一批年轻程序员会给你带来巨大的竞争压力。首先由于软件行业的飞速发展，很多自己以前学的东西逐渐升级换代，而许多程序员由于长期于工作，学习新知识的效率必然下降。其次自己干了几年，薪水要求自然就高了，而年轻程序员工资又低、干活又快，当然会成为老板的首选；第三，30岁基本都已经成家了，要支撑家庭的生活负担，几乎连从头在来的勇气都不会有了。中国的老话说“长江后浪推前浪、一代新人换旧人”，这个历史的规律在软件开发行业体现的尤其明显和残酷，很多程序员必然要面对的结果就是降薪乃至失业。

困境之三：自我的实力。都知道人最难战胜的是自己，所以自我也就是程序员需要超越的最大障碍。大多程序员都把系统分析员和项目经理作为自己的职业目标，但这些目标的达成，需要个人素质、市场机遇等多个方面的条件，太多的程序员就是在高不成、低不就的状态中蹉跎了岁月。对于系统分析员，特别需要以下几方面的素质：客户需求分析能力、系统架构与设计能力、模块分解设计能力、项目流程控制能力、项目风险评估能力等，而对于项目经理则更注重项目管理方面的能力如团队组织能力、沟通协调能力、分析问题解决问题的能力以及良好的职业道德等，而这些素质和能力往往只能依靠程序员个人的学习和努力。看到越来越多的程序员开始学习项目管理的课程，真的有点为他们担心，因为现在的项目管理培训只能停留在理论和考证的程度，既没有素质方面的训练，又缺少实际软件开发项目的案例，学习的结果远远不能达到预期的效果。

第四篇：程序员

7．5．3系统测试和调试

1．系统测试的意义及目的系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。应根据开发各阶段的需求、设计等文档或程序的内部结构精心设计测试实例，并利用这些实例来运行程序，以便发现错误。信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标来进行，此处所说的测试更多的是指软件测试。

系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则：

·应尽早并不断地进行测试。测试不是在应用系统开发完之后才开始进行的。由于原始问题的复杂性、开发各阶段的多样性以及参加人员之间的协调等因素，使得在开发各个阶段都有可能出现的错误。因此，测试应贯穿在开发的各个阶段，尽早纠正错误，消除隐患。

·测试工作应该避免由原开发软件的人或小组承担，一方面，开发人员往往不愿否认自己的工作，总认为自己开发的软件没有错误；另一方面，开发人员的错误很难由本人测试出来，很容易根据自己编程的思路来制定测试思路，具有局限性。测试工作由专门人员来承担会更客观，更有效。

·设计测试方案的时候，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。将实际输出结果与预期结果进行比较就能发现测试对象是否正确。

·在设计测试实例时，不仅要设计有效合理的输入条件，也要包含不合理、失效的输入条件。测试的时候，人们往往习惯按照合理的、正常的情况进行测试，而忽略了对异常、不合理、意想不到的情况进行测试，而这些可能就是隐患。

·在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。多余的工作会带来副作用，影响程序的效率，有时会带来潜在的危害或错误。

·严格按照测试计划来进行，避免测试的随意性。测试计划应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。严格按照测试计划进行测试可以保证进度，使各方面都得以协调进行。

·妥善保存测试计划和测试例子，将其作为软件文档的组成部分，为维护提供方便。

·测试例子应是精心设计出来的，可以为重新测试或追加测试提供方便。当纠正错误、系统功能扩充后，都需要重新开始测试，而这些工作重复性很高，可以利用以前的测试例子，或在其基础上修改，然后进行测试。

2．测试过程

测试是开发过程中一个独立且非常重要的阶段，测试过程基本上与开发过程平行进行。

一个规范化的测试过程通常包括以下基本的测试活动。

(1)拟定测试计划。在制定测试计划时，要充分考虑整个项目的开发时间和开发进度以及一些人为因素和客观条件等，使得测试计划是可行的。测试计划的内容主要有：测试的内容、进度安排、测试所需的环境和条件、测试培训安排等。

(2)编制测试大纲。测试大纲是测试的依据。它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和完成测试的标准。

(3)根据测试大纲设计和生成测试例子。在设计测试例子的时候，可综合利用前面介绍的测试例子和设计技术，产生测试设计说明文档，其内容主要有被测项目、输入数据、测试过程、预期输出结果等。

(4)实施测试。测试的实施阶段是由一系列的测试周期组成的。在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试例子，对被测软件或设备进行完整的测试。

(5)生成测试报告。测试完成后，要形成相应的测试报告，主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。另外，给出一些建议，如可采用的修改方法，各项修改预计的工作量及修改的负责人员。

3．测试策略和测试方法

软件测试方法分人工测试和机器测试。

1)人工测试

人工测试指的是采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。经验表明，组织良好的人工测试可以发现程序中30％～70％的编码和逻辑设计错误。

人工测试又称为代码审查，其内容包括检查代码和设计是否一致，检查代码逻辑表达是否正确和完整，检查代码结构是否合理等。主要有3种方法。

·个人复查：指程序员本人对程序进行检查。由于心理上的原因和思维惯性的影响，对自己的错误一般不容易发现，对功能理解的错误更不可能纠正。因此，这种方法主要针对小规模程序，效率不高。

·抽查：通常由3～5人组成测试小组，测试人员应是没有参加该项目开发的有经验的程序设计人员。在抽查之前，应先阅读相关的软件资料和源程序，然后由测试

人员扮演计算机的角色，将一批有代表性的测试数据沿程序的逻辑走一遍，监视程序的执行情况。人工检测程序很慢，只能选择少量简单的例子。

·会审。测试人员的构成与抽查类似。在会审之前，测试人员应该充分阅读相关资料，比如系统分析说明书、系统设计说明书、源程序等。测试人员应尽可能多地列出典型错误。在会审时，由编程人员逐句讲解程序，测试人员逐个审查、提问。通过这种方式，往往可能使编程人员发现自己以前没有意识到的错误，使问题暴露=会审后，要将发现的问题登记、分析、归类。

·代码复审应该在被测软件编译成功之后。编译都不通过的软件，当然谈不上复审。在复审期间，应保证有足够的时间，让测试小组对问题进行充分的讨论，这样才能有效地提高测试效率，避免出错。

2)机器测试

机器测试是把设计好的测试例子作用于被测程序，比较测试结果和预期结果是否一致。如果不一致，就说明可能存在错误。机器测试只能发现错误的症状，无法对问题进行定位。

机器测试分为黑盒测试和白盒测试两种。

(1)黑盒测试也称为功能测试。将软件看成黑盒子，在完全不考虑软件内部结构和特性的情况下，测试软件的外部特性。进行黑盒测试主要是为了发现以下几类错误：

·是否有错误的功能或遗漏的功能?

·界面是否有误?输入是否正确接收?输出是否正确?

·是否有数据结构或外部数据库访问错误?

·性能是否能够接受?

·是否有初始化或终止性错误?

(2)白盒测试也称为结构测试。将软件看成透明的白盒。根据程序的内部结构和逻辑来设计测试例子，对程序的路径和过程进行测试，检查是否满足设计的要求。其原则是：

·程序模块中的所有独立路径至少执行一次。

·在所有的逻辑判断中，取“真”和取“假”的两种情况至少都要执行一次。·每个循环都应在边界条件和一般条件下各执行一次。

·测试程序内部数据结构的有效性等。

4．软件测试步骤

软件测试实际上可分成4步进行。

1)单元测试‘

单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。如果选用机器测试，一般用白盒测试法，多个模块可以同时进行。

测试一个模块时需要编写一个驱动模块和若干个桩(stub)模块。驱动模块的功能是向被测试模块提供测试数据，驱动被测模块，并从被测模块中接收测试结果。桩模块的功能是模拟被测模块所调用的子模块，它接收被测模块的调用，检验调用参数，模拟被调用的子模块功能，把结果送回被测模块。

2)组装测试

组装测试也称为集成测试，就是把模块按系统设计说明书的要求组合起来进行测试。

即使所有模块都通过了测试，但在组装之后，仍可能会出现问题：穿过模块的数据被丢失；一个模块的功能对其他模块造成有害的影响；各个模块组装起来没有达到预期的功能；全局数据结构出现问题；另外，对于单个模块来说其误差可以接受，但模块组合后，可能会出现误差累积，最后到不能接受的程度，所以需要组装测试。

通常，组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，即非增量式集成；另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需要测试的模块组合起来，进行测试，逐步把所有模块组合在一起，并完成测试，即增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，并加快工程进度。但这种方法容易混乱，出现错误不容易查找和定位。增量式测试的范围逐步扩大，错误容易定位，而且已测试的模块可在新的条件下再测试，使测试更彻底。

3)确认测试

经过组装测试之后，软件就被集成起来，接口方面的问题已经解决，将进入软件测试的最后一个环节——确认测试。确认测试的任务就是进一步检查软件的功能和性能是否与用户要求的一致。系统方案说明书描述了用户对软件的要求，所以是软件有效性验证的标准，也是确认测试的基础。

确认测试，首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试，经过管理部门的认可和专家鉴定后，软件即可交给用户使用。

4)系统测试

系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统方案说明书来设计测试例子的，常见的系统测试主要有恢复测试、安全性测试、强度测试、性能测试、可靠性测试、安装测试。

5．调试’

调试的任务就是根据测试时发现的错误，找出原因和具体的位置，进行改正。调试工作主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。

目前常用的调试方法有如下几种：

·试探法。调试人员分析错误的症状，猜测问题的所在位置，利用在程序中设置输出

语句，分析寄存器和存储器的内容等手段来获得错误的线索，一步步地试探和分析出错误所在。这种方法效率很低，适合于结构比较简单的程序。

·回溯法。调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪代码，直到找出错误根源为止。这种方法适合于小型程序，对于大规模程序，由于其需要回溯的路径太多而变得不可操作。

·对分查找法。这种方法主要用来缩小错误的范围，如果已经知道程序中的变量在若干位置的正确取值，可以在这些位置上给这些变量以正确值，观察程序运行的输出结果。如果没有发现问题，则说明从赋予变量一个正确值开始到输出结果之间的程序没有错，问题可能出在除此之外的程序中，否则错误就在所考察的这部分程序中，对含有错误的程序段再使用这种方法，直到把故障范围缩小到比较容易诊断为止。

·归纳法。归纳法就是从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假设的错误原因，用这些数据来证明或反驳，从而查出错误所在。

·演绎法。根据测试结果，列出所有可能的错误原因。分析已有的数据，排除不可能和彼此矛盾的原因。对余下的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体。用假设来解释所有的原始测试结果，如果能解释这一切，则假设得以证实，也就找出了错误；否则，要么是假设不完备或不成立，要么有多个错误同时存在，需要重新分析，提出新的假设，直到发现错误为止。

第五篇：程序员

程序员之死

程序员：举世至主，万元之源，众物所幕，神祗皆掌，岁能长立，箜有己出。弈中悲苦，是自了得！幸事祸事飘忽于其思想，晓如今，心思想，新纪元，心结缘，把话晾。

世间万物，出于思想，毁亦思想。而思想的源头正是程序员。

程序员在被选择作为程序员之前，只是一个程序，程序当然就是指程序员的衍生物，程序员就是本单位思想的创造者，他创造着每一个程序，而程序也有其思想，这思想当然是程序员写进去的，程序员就这样靠着周而复始的写程序来获得自己的永生，这或许也是一种宿命，他要一直写下这程序来完成前任程序员给予的使命，当然每个程序员都有着崇高的使命感，不然他们是做不了程序员的。

写程序固然是一种快乐，他可以随着自己的思想创造出一切自己所思自己所想的东西出来，任由思想在空寂游荡而有其始终。虽然这是一项每天创造新鲜的活，然程序员终有其果。于是，新纪元再次到来，当程序员写下足够的程序后，他有了新的选择，那就是退出自己的思想，把任务交给下一代的程序员来完成。在这之前，当然有件最主要的事需要做，那就是创造出一个新的程序员。如此，程序员将会将自己写进程序，为达此目的，他将用尽索想提前写好自己成为程序后的万物程序，保证新老程序员的顺利交接

程序员经过一直以来的坚苦努力，终于熬到了纪元期。忆当初，自己被选择做了这举世至主，纵是万元之源，然其中悲苦，是自了得！

我们都是别人写下的程序，然谁有能理解程序员之痛，程序员有着众物所幕的岁能长立，然生生死死，亦不曾快活。