软件在能够复用前必须先能用。

–Ralph Johnson

优秀的判断力来自经验，但经验来自于错误的判断。

–Fred Brooks

‘理论’是你知道是这样，但它却不好用。‘实践’是它很好用，但你不知道是为什么。程序员将理论和实践结合到一起：既不好用，也不知道是为什么。

–佚名

当你想在你的代码中找到一个错误时，这很难；当你认为你的代码是不会有错误时，这就更难了。

-Steve McConnell《代码大全》

如果建筑工人盖房子的方式跟程序员写程序一样，那第一只飞来的啄木鸟就将毁掉人类文明。

-Gerald Weinberg

项目开发的六个阶段：

充满热情

醒悟

痛苦

找出罪魁祸首

惩罚无辜

褒奖闲人

–佚名

优秀的代码是它自己最好的文档。当你考虑要添加一个注释时，问问自己，“如何能改进这段代码，以让它不需要注释？”

-Steve McConnell《代码大全》

我们这个世界的一个问题是，蠢人信誓旦旦，智人满腹狐疑。

–Bertrand Russell

无论在排练中演示是如何的顺利(高效)，当面对真正的现场观众时，出现错误的可能性跟在场观看的人数成正比。

–佚名

罗马帝国崩溃的一个主要原因是，没有0，他们没有有效的方法表示他们的C程序成功的终止。

–Robert Firth

C程序员永远不会灭亡。他们只是cast成了void。

–佚名

如果debugging是一种消灭bug的过程，那编程就一定是把bug放进去的过程。 –Edsger Dijkstra

你要么要软件质量，要么要指针算法；两者不可兼得。

–(Bertrand Meyer)

(有思想的话…)

有两种方法能写出没有错误的程序；但只有第三种好用。

–Alan J. Perlis

用代码行数来测评软件开发进度，就相对于用重量来计算飞机建造进度。

–比尔-盖茨

最初的90%的代码用去了最初90%的开发时间。余下的10%的代码用掉另外90%的开发时间。

–Tom Cargill

程序员和上帝打赌要开发出更大更好——傻瓜都会用的软件。而上帝却总能创造出更大更傻的傻瓜。所以，上帝总能赢。 –Anon

“设计是一个发现问题、而不是发现解决方案的过程” —— Leslie Chicoine

“功能说明书里不存在可操作性” —— 37 Signals

“过去的代码都是未经测试的代码” —— Michael Feathers

“任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码”

——

Martin Fowler

“测试是来表明bug的存在而不是不存在” —— Edsger Dijkstra

“简单不先于复杂，而是在复杂之后” —— Alan Perlis

1. 无风不起浪

别紧张，这也许只是一场消防演习

代码设计是否糟糕，从某些地方就可以看出来。比如：

?a. 超大类或超大函数

?b. 大片被注释的代码

?c. 逻辑重复

?d. If/else嵌套过深 程序员们通常称它们作代码异味(Code Smell)

，但是就我个人认为“代码警报”这个名字更为合适一些，因为它有更高的紧迫感的含义。根本问题处理不当，终将引火烧身。

译注：Code Smell中文译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，开发人员可以通过这种smell（异味）在代码中追捕到问题。

2. 预防为主，治疗为辅

好吧，我相信了！

20世纪80年代，丰田公司的流水作业线因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自己的部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生产、解决问题，也不能由其继续生产而导致更棘手且更高代价的修复/更换/召回后的问题。

程序员总会做出生产率就等同于快速编码的错误臆断。许多程序员都会不假思索地直接着手代码设计。可惜，这种Leeroy Jenkins式鲁莽的做法多会导致软件的开发过程变得很邋遢，拙劣的代码需要不断的监测和修改——也可能会被彻底地替换。最终，生产率所涉及到的因素就 不仅仅是写代码所消耗的时间了，还要有调试的时间。稍不留神就会“捡了芝麻丢了西瓜”。（因小失大。）

译注：Leeroy Jenkins 行为：WOW游戏中一位玩家不顾大家独身一人迎敌，导致灭团。

3. 不要孤注一掷 （过度依赖某人）

一个软件开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。 译注： bus factor 即指公共要素，比喻了开发过程中的一些共同因素。如果挤上 bus 的 factor 越多，bus 就越不稳定，所以要控制好 bus factor ，以免问题发生。

换句话说，如果你的团队突然失去了一个主力成员，你会怎么办？生意依旧进行还是戛然而止？

很不幸，大多数软件团队都陷入了后一种情况。

这些团队把他们的开发员培养成了只会处理他们自己专业领域的“领域专家”。起初，这看起来是一个比较合 理的方法。它 对汽车制造装配生产线很适用，但是为什么对软件开发团队就不行呢？毕竟，想让每个成员都掌握所编程序的细微差别也不太可能，对吧？

问题是开发人员不容易轻易替换掉。虽然当每位成员都可用时，“抽屉方法”很有效，但如果当“领域专家”突然因人事变动、疾病或突发事故而无法工作 时，抽屉 方法立马土崩瓦解。（所以，）软件团队有一些看似多余实则重要的后备力量是至关重要。代码复查、结对编程和共有代码可用成功营造一个环境，在这个环境中， 每位开发人员至少表面上是熟悉自己非擅长领域之外的系统部分。

4. 种瓜得瓜，种豆得豆

《注重实效的程序员》一书中有这样一段话解释“破窗理论”：不要留着“破窗户”（低劣的设计、错误的决策或者糟糕的代码）不修。发现一个就修一个。 如果没有足够的时间进行适当的修理，就先把它保留起来。或许你可 以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采取一些措施，防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素（我们将在其他地方接触到），但（对“破窗”）置之不理，肯定会更快地加速系统崩溃。

简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了惯性的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。写好你的代码，它才更可能经得住时间的考验。

译注：《注重实效的程序员》，作者Andrew Hunt / David Thomas。该书直击编程陈地，穿过了软件开发中日益增长的规范和技术藩篱，对核心过程进行了审视――即根据需求，创建用户乐于接受的、可工作和易维护 的 代码。本书包含的内容从个人责任到职业发展，直至保持代码灵活和易于改编重用的架构技术。从本书中将学到防止软件变质、消除复制知识的陷阱、编写灵活、动 态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容。

译注：破窗理论（Broken Window theory）：是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：如果有人打坏了一幢建筑物的窗户玻璃，而这扇

窗户又得不 到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户。发现问题就要及时矫正和补救。

5. 欲速则不达

经理、客户和程序员正日益变得急躁。一切都需要做的事，都需要马上就做好。正因如此，快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试？好吧，你可以先完成一次测试运行，然后你就可以随时回来继续测试它。

当访问Y属性时，会不会碰到奇怪的对象引用错误？无论怎样，把代码放到try/catch语句块中。我们要钓到大鱼啦！

是不是似曾相识呢？这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟，我们有最后期限，还得满足客户和经理。但不要过于频 繁操 作，否则你会发现你的代码不稳定，有很多热修复、逻辑重复、未测试的方案和错误处理。最后，你要么是把事情草草做完，要么是把事情好好做完。

6. 三思而后行

“敏捷开发”这个词最近被频繁滥用，经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者，看到产品朝正当方向有实质进 展，我们理应高兴。但意外的是，UML图和用例分析似乎并不能满足我们的愿望。所以，在不知自己做什么的情况下或者不知自己身处何处时，我们开发人员经常 就稀里糊涂地写代码了。

这就好比你要去吃饭，但你根本没有想好去哪里吃。因为你太饿了，所以你迫不及待地找个餐馆，定个桌位。然后你上车开车后沿途在想（找地方吃饭）。只 是，这样会耗费更多的时间，因为你要过较多的U型弯道，还在餐馆前停车，也许最后因等待时间过长而不吃了。确切地说，你最后应该能找到地方吃饭，但你可能 吃的饭并不是你想吃的，并且这样花费的时间，可能比你直接在想去的餐馆订餐所花的时间更长。

7. 如果你惟一的工具是一把锤子，你往往会把一切问题看成钉子

看见了吧？我早就说过动态记录在这个项目中很有效

程序员有一种倾向，当一谈到他们工具时，其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”，我们就会在接下来所有的项目上都用到它。学 习新东 西仿佛是一种煎熬，有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。一定要摒弃这种想法，按我们所知道的去做，即 使那不是最完美的解决方法。

坚持自己所知很简单，不过从长远的角度讲，选择一个适合这项工作的工具要容易得多。否则，就会与你的职业生涯格格不入。

8. 沉默即赞同

我什么都没看见！没看见！

"破窗理论"与"变成惯性理论"有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码，那你每天都将和糟糕的代码相伴了。

同样地，如果你看到别人写出了糟糕的代码，你就要跟这个人提出来。注意，这时候机智就应该用上场了。一般情况下，程序员都愿意承认他们在软件开发中还是有不懂的地方，并且会感谢你的好意。互相帮助对大家都有利，而对问题视而不见，只会使问题一直存在。

9. 双鸟在林，不如一鸟在手

如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想 目标， 但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。

10. 能力越大，责任越大

毫无疑问，软件已成为我们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者 航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子

便说明了我们正行使着多大的权利。你今 天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧！

 

第二篇：【免费下载】一个80后Java程序员的成长道路

来源于：/blog/

一个80后Java程序员的道路

写给想了解部分程序员职业发展生涯的人看，写给准备跳槽的程序员们看，写给有过和我类似经历的同行们看，写给自己看，写给我的女朋友看，写给其他行业中也想去努力拼搏的人看。

一、我的情况简介

我是一名有3年多工作经验的程序员，或者说是高级软件工程师。

本科曾经就读于西安电子科技大学，学过数学专业，那时候国家建立了36所示范性的软件学院，我一眼热就改专业、转学院，学了软件工程。这个教育背景写到简历上应该还是不错的，不过我在软件学院其实没怎么学软件，所以找工作的时候自己心里都没底。

没好好学软件的原因是那时候觉得软件也不是我喜欢的，又打算考个经济学的研究生，想以后搞企业。最终研究生也没能考上，

又要养活自己，所以只好还是以软件开发为生，在西安一家国企性质的IT公司工作，公司主要给银行做，公司老总也是原来银行的一些小领导。

就这样，我在这个公司从毕业一直干了3年，从一开始我没什么基础，java都要自己现学（学校里是开这门课了的，毕设也用java做的），到三年之后我跳槽离开，可以说积累了一些开发经验。从工资级别上看，离开时也是高级软件工程师里的最高级了。

套用一句郭德纲的经典台词：“我很欣慰”。

三年里做过5，6个项目，还有1，2个自己做的小项目，从一开始的简单的修改一些变量、常量，用ireport一点一点画一些表格，到用cognos开发报表，做一些BI项目的前端展示，到独立开发模块，再到最后和我的小师父一块研究jbpm开发工作流的业务项目。顺便提一下我的小师父，也是我的同事，只因为他比我还小，但技术上很牛，又带过我，所以简称小师父了。

回想三年，虽没有像很多更牛、更成功的程序员们的经历辉煌，但从我自己来看，我真的“很欣慰”。

因为，我知道，我一点一点磨到这一步中间的代价是什么，是我多少个夜晚没睡好觉，去一点一点抠代码该怎么写换来的。三年了，我真真正正睡过几个舒心的觉呢？

但我又觉得我可能不适合这个行业，我没有Robbin或者我的小师父那么牛的技术。别人我不知道，单从我小师父干活时表现出的那种素质，技术，我就总觉得我真是太菜了，而且我还耗费那么多时间不睡觉去一点一点学，还花银子去买各种技术书籍，这些我小师父是很少去做的。我发现我们的“投入产出比”实在过于悬殊。

回过头想一下，我觉着我当时选择转到软件工程专业也挺合适我的，因为我原先是学的数学，是理科，转到软件工程，算是工科，从理科转到工科这才是我转专业的本质，我认为虽然我在开发上技术还不够精湛，但是我要是在理科可能混的更惨。我喜欢工科，我喜欢可以时不时的出些小成果的工作。

所以说，做到现在我也喜欢上了这个工作，这个行当，而且我希望自己技艺能更精湛，或者说编码能更快点、质量能更高点，并且我庆幸我在第一份工作经历中能遇到技术高手，又能亲自带我、教我，更庆幸的是我通过第一份工作经历使我对软件开发有了更多的兴趣，让我对自己的定位不模糊。虽然我现在不如这些技术牛人，但是我会坚持，借用一句名言“I came,I saw,I conquer”。我相信有那么一天，我会做的很好，我不会担心自己在工作时间里憋不出那几行代码，我不会为了消除这种担心而用宝贵的睡眠时间去提前开始思考、编码，我不会不敢给项目经理报我的进度。

我以为经过这三年的经历我能得到很多很多的回报，但是当我从这个公司辞职后去找第二家公司的时候，我发现我能得到的回报是IT界的一种普遍回报的平均数。

二、 第一次跳槽

从西安那家公司离职后，我来到北京，开始我的第一次跳槽经历，三个月找工作的经历，让我知道了我到底值多少钱，更让我知道了什么是竞争的残酷性、理智性。

其实我找到第一份工作的过程很简单，由于原来部门的经理是我的校友，可能出于对学校的一种回报，答应给软件学院一些招聘名额，当时什么都不会的我就去试了试，又正巧面试我的副经理出差，就由经理问了问一些笔试中的问题，和一些Java方面的问题，我记得答的不怎么样，不过可能也没完全答错，也就过关了。后来想想，经理主要是做C的开发，那个副经理才是Java出身，如果真让副经理面了，恐怕结果也不会这么顺利。

也就是说，我第一份工作得来的还是很容易的，没有经过那么多次的选择。

也许正是第一份工作得来的相对容易，第二次找工作的经历就被上帝公平地安排一下，参加应聘的次数变多了，找工作的时间也

延长了，用了3个月才定了下来。

人未到北京，网上的简历已经投了很多，到了北京没几天就有招聘的电话打来。

三、 人力外派的招聘

1. 人力外派公司的职位

是一家做人力外派的公司给我打来的电话。由于我有银行业软件开发的背景，而他们也正有某国有银行的项目需要，所以给我打了电话。到北京之前我就想，不能定的太快，要多比较一下，卖个好价钱。出于比较的心理，我答应到公司去面试。

公司就在上地那个有着亚洲第一厅堂的大厦里，来之前由于住的地方不能上网，也没好好查这个公司的基本情况，并不知道是做人力派遣的，到了之后，公司的总监很哥们似的把我拉到角落，给我介绍大致的情况。

“公司目前有两个职位，一个是给某银行做报表方面的项目，算是高级软工，另一个是给国家某总局做项目，并且是跟另一家公司合作，算是系统分析师级别”。一听这个情况，我首先反应，希望能更上一层楼，做做系统分析师，所以就说想做后者。再说到待遇，银行那个项目给到税前6K，某总局的那个项目可以给到7K。

2. 期望待遇与实际待遇有差距

我以为凭在西安工作了三年，而且又被原单位非常认可的程度（包括获得优秀员工的奖励，工资级别是高级软工的最高级这两点），我认为我在北京应该得到至少至少7K的水平。而这个系统分析师的职位也才给到7K,使我相当不爽。但是我也知道，不争取是得不到好东西的，我就给那总监说，我的理想待遇是8K，总监说不太可能。

虽然价钱没谈拢，但是我还是想试试自己的面试能力，就同意和合作公司的技术方面的负责人去面试。

我原本以为就自己去面试，中途又加了一个，听总监说有近10年的工作经验了，能力相当强，我是一个尊重经验的人，因此对这位大哥也是抱着十分尊崇的心情的。

我、10年经验的大哥以及外派公司的总监，我们三人就到了某总局的项目开发现场，与合作公司的技术负责人见面。

3. 第一次跳槽之第一次面试

来之前，我大致准备了一下，主要是想了想该怎么介绍自己的项目经历什么的。由于我最后一个项目的经历算是集大成之作，而且也因这个项目得到了“优秀员工”的荣

誉，所以我着重准备了最后一个项目，有关工作流的项目。

面试主要也是问经历。合作公司的负责人拿着我的简历看，我给他在来个同期声，把我的经历介绍一下，其实这个介绍和简历上的也差不多。

我介绍自己：在某某年几月到某某年几月，我参与某信托投资公司的综合业务系统的开发，主要利用了JBPM工作流引擎实现该系统的流程部分。我的主要职责是对JBPM进行了技术攻关、分配一些模块、开发公用接口等工作。

负责人问了我如何对JBPM进行的技术攻关的问题。其实当时有我小师父在，他基本已经弄清了JBPM的使用了，因此我的主要任务是把这个工作流引擎运用在项目中，比如做出一个实际的例子，但是也有一部分对JBPM学习的任务。我就大致说了一下对JBPM技术攻关的过程，比如看了JBPM提供的例子、技术文档，而且我们部门还邀请了上海一家公司给我们做了几次咨询、培训，把他们运用JBPM的项目拿出来给我们进行了讲解。为了体现出我的价值，我着重强调了自己在这个项目中封装了一些流程的接口，用于给项目组成员使用，使他们不必对JBPM更深入了解，降低了开发难度。

之后，负责人又问了问以前我做过的项目，也没什么太特别的问题，这里就不再赘述了。

轮到10年经验大哥面试了，这位老兄瘦瘦的，戴副眼镜，歪歪一坐，一副谁也不

吊的样子。负责人也像问我似的，让他自己说说自己的经历，我一听我都快坐不住了。这位老兄经验丰富，而且听他说自己非常喜欢玩各种新技术，很喜欢自己鼓弄，由于这个项目中可能用到有关搜索方面的东西，他也说自己也用过搜索引擎lucense，其实这个我也见过，可惜从没碰过，当时很后悔，至少也应该了解了解啊，这样至少有的说嘛。

负责人又问了他有没有做过项目经理，他说也做过，不过还是喜欢做技术，所以也没做多久。给我的感觉就是，技术很牛，很有经验！

我真是都不想再待在那个面试的房间里了，明摆着我就是一个陪衬。不过，我还是想，既来之则安之，面就面到最后。

合作公司的技术负责人面试完毕了，合作公司的项目经理也过来面试我们。项目经理问了我们一些个问题，我记得的一个问题是让我说说我的优缺点。

4.我的缺点

其实在离开上一家公司之前，技术总监曾经找我最后谈话，了解我离职后的打算以及对项目后期的建议，谈完后，我特意问了技术总监一个问题，我问他认为我的缺点有哪些，我希望通过领导的眼睛看到我不能看到的问题。

由于我们原先的公司规模不大，软件开发部总共也就100人左右，而且我当时所在的信托项目由于问题很多，技术总监直接进入我们项目组，指导我们的设计，并对我们实现的功能进行把关，最紧张的时候项目组全体成员14，5个人封闭开发，这也包

括技术总监，因此技术总监对我们项目组每个人的情况都非常了解。

在我眼中，技术总监是一个很聪明，看问题能看到本质的人，因此我信他说的。

作为领导，作为有着丰富职场经验的老手，他首先评价我有很多不错的地方，比如我能够从大局看待项目，这主要是指当时我们项目极度缺乏详细设计文档，而缺乏设计文档在开发初期给项目组造成了很多开发上的困难，开发人员不能又开发，又琢磨要实现什么。我把这个问题反馈给了技术总监，并且详细的列出了需要哪些功能的详细设计文档。

负责写详设的是我另一位师傅，这位同事在我进入第一个项目组的时候给了我很大帮助，这次我没有给我这位师傅留太多面子，直接把问题反应给了技术总监，估计也造成了我和这位师傅之间的一些隔阂。

接着技术总监看我对自己缺点的问题还是比较认真的，就继续说了下去。他说其实我在项目中也暴露出一些问题，可能也不算是缺点等等的，可见技术总监的说话还是滴水不漏的，一点也不会把事情搞得让我很难堪。

他认为我在项目紧张开发的那段时间里没能安排好自己的工作，当时分配给了我几项工作，包括开发公用模块、给其他开发人员分配任务以及开发一些自己的模块等等，在这些工作开展的时候，我没能把精力集中在对流程核心接口的开发中，有些任务可以分给其他人来做的没有分配，导致代码质量不是很高、效率底下等情况。技术总监也说，

这也有他们分配任务没考虑过细的原因等等。

我在听完他说我的这个缺点之后，我的心里其实没有太服气，但也说不出到底是什么不服，可能有这样一个想法，为什么你们当时不给我指正呢？为什么项目经理有那么多问题，技术总监都给他及时的批评指正，而我却得不到领导的这种指导呢？我不服气的是，我认为技术总监偏袒项目经理，说难听点就是有帮派习气。

虽然我对技术总监有不满的情绪，但是对他做事的风格，实事求是分析问题的方法还是非常佩服，所以对技术总监说的我的缺点很留心，离职后，我立马琢磨他所说的意思。

后来我在吸收了技术总监意见的基础上，总结出了我的缺点就是，有时候不能安排好自己工作的优先级。针对这样的问题，我自己想了想解决方法，应该先把公用的东西优先做出来，涉及到别人的东西也要先做，可以分配给别人做的应该分出去，自己只做精力允许的、最重要的那部分。

我到现在都对我当时向技术总监征求个人缺点的看法很得意，技术总监看问题就是不一样，如果让我自己总结自己的缺点，怎么也不可能想到自己在安排自己的工作上出问题。而且经过提炼，我还可以把自己的缺点放到面试中去说。

5.出人意料的结果

我把自己的缺点讲给合作公司的项目经理，面试又进行了一会就结束了，人力公司

的总监和合作公司的负责人出去商量最终结果。

在这空当，我主动找10年经验大哥聊了聊，我表达了我对他技术上、经验上的钦佩，而且希望以后能交流交流的意愿，我向他要了手机号码。没想到这位老兄说“你要我电话干嘛，没必要给你电话”，让我很诧异，我心说了，还有这么刺头的人，他又说“最近装修搞得他头都晕了，别再给我打电话了“之类的，简直让我觉得很尴尬，一下子对他的敬意全无。

人力公司总监回来了，结果很明显。他用车把我俩往回送，对那老兄说了一些什么，那老兄到了就下了，就剩总监和我了，他问我说“你猜录取谁了？”，我很平静的告诉他，肯定是那位有着10年工作经验的大哥无疑了。

但是，结果出乎我的意料，总监说录取我了。

我很意外，总监跟我解释道，主要看中我的团队意识，虽然那位老兄有10年经验，但是不易合作，即使技术强也不合适，因此决定要我。

听到这个结果，自己还是比较满意的，毕竟是首战告捷了，虽然我是不会选择去这家人力外派公司的，但是对自己能够获得这个工作机会还是很高兴的。

经过第一家公司的面试，虽然是人力外派类的公司的面试，但是由于成功过关了，所以自己的信心增强了。

四、兵败外企

1.T公司

其实在来北京之前，自己心里就已经有非常向往的公司了，也就是外企T公司。

知道T公司是因为我原来的同事强子曾经应聘过T的西安分公司，而且这个公司在软件行业内的口碑非常好，在IT红黑榜网站上查这个公司的评价，基本都是好评，不像其他公司似的，某某公司拖欠工资、某某公司领导很坏之类的负面评价。这些都与T公司绝缘。

最让我对T公司产生兴趣的还是他们的开发方式。

2.敏捷开发

T公司在开发上很有特色，公司采用敏捷开发方式，我理解敏捷开发是一种开发方法论，为了能成为T公司的员工，我买了本《敏捷开发》的影印版开始看。

敏捷开发大致就是说以实际的软件、代码作为和客户交流需求的载体，而不是用文档，欢迎变化而不是遵循计划之类的。

在来到北京不久，一家专业的编程方面的杂志社联合T公司举行一

年一度的敏捷中国大会，我到了北京的时候已经错过了报名参会的时间，不过好在我跟杂志社联系了一下，补上了报名。

会议组织得很专业，包括宣传材料、会议胸牌、茶歇等都组织的非常好。会议由许多演讲组成，值得一提的是，大会的主题演讲的演讲者也是敏捷开发的提出者之一，同时也是T公司的科学家。

我参会的目的很明确，想通过敏捷开发大会进一步了解敏捷开发，另一个就是想多和T公司的员工们交流一下，取得应聘T公司的经验。

实际上，T公司主办的这个敏捷开发大会的目的也是和我的目的类似，也是要宣传敏捷开发的理念，宣传T公司，而且提倡参会人员和T公司的员工自由交流。

演讲的很多都是老外，虽然我极力认真去听他们讲的是什么，但是我英语还没达到能直接听懂他们在讲什么。

虽然参加了这个会的收获一般，但是由于和T公司能走的更近，所以觉得也是做应聘准备的一个重要步骤，我想象在应聘的时候可以给他们说我参加了这个会议，从一个侧面也能表明我对敏捷开发的兴趣。

3.电话面试

开过这个敏捷大会后，我就开始着手准备

因为看重，所以慎重。

我到网上搜关于T公司的面试、笔试了。T公司的应聘信息，包括笔试、面试的题目等等，结果不多。倒是碰到一个做T公司职位的猎头，就加了MSN，我说明了我的情况，这个女猎头主要做高端的，也就是5年以上工作经验的。我追着问她T公司招聘的流程，甚至题目。女猎头心地很善良，发给我一份文档，写了T公司面试的一些情况。

T公司是外企，外企面试一般都是先进行一次电话面试，电话面试可以使人力了解应聘者的口语水平，电话面试通过后再真正面试。女猎头的文档列出了T公司电话面试的一般问题，比如有个人介绍、曾经遇到的一些困难什么的。看上去问题都不太难，我用英文把教育经历、三年的工作经历、项目中承担的责任、收获都写成了稿子，并熟记于心。

投简历后的第2，3天进行了电话面试，时间定的是下午4：00，到了3：50的时候我还没有不一样的感受，可是当时间到了3：55的时候，我发现自己心跳加速了，到了4：00的时候简直不能平静了。

好在T公司是4：00多给我打来的电话，我尽力地平息着我的紧张。首先人力要求我做一个英语的个人介绍，这个不难，我已经有了稿子，只

要照着念就OK了，不过在念的过程中我还是有意识的放慢速度，稍微打些磕巴，免得被看穿。

个人介绍很快念完了，人力开始提问了，“what is your challenge in your current job?”，其实我已经听懂了她所问的，就是说遇到过什么挑战，但是由于紧张，突然听不懂“current”这个单词，问题说完了我就在不停的回想current到底是什么意思。我估计因为我已经离职了，当前并没工作，而她问在current job（当前工作）中遇到什么挑战就导致我有点神智不清了，不过很快我反应了过来，从稿子中找到遇到的困难那部分，就开始往上套。

首先我说了个技术上的挑战，如何在信托项目中使用JBPM工作流引擎，以及如何把这个工作流引擎结合具体业务在项目中使用。说完，人力继续问我如何解决的，我就把技术总监给我们指明的要把“业务和流程分开”的解决思路说了。之后人力又继续追问，还有没有其他方面的挑战。我都被问得快有点撑不住了，想了想就把自己当时没能安排好自己工作优先级的这个缺点改造了一下，说了说。但是由于这部分没能预先准备，边想边说，说得特别磕巴，有的词发音都没发准。

说到半截，可能人力已经知道我的外语水平了，就不要我再用英语折磨她了，让我可以说中文了，我就把没能用英语表达清楚的地方用中文重新说了一下。

时间已经过去了15分钟，最后人力让我提问，为了给人力留下深刻印象，我问了5，6个问题，有关于敏捷开发在T公司的开发效果的，有对敏捷开发能否在大型项目中应用的，有关于T公司是否做国内项目的，反正我尽可能的想了很多问题，体现自己对他们公司的兴趣。

这个电话面试时间总共有20分钟，完后我的感觉并不太差，不过我也明确地知道了我的英语口语水平实在不怎么样，但是，我总以为上天会照顾我，至少让我能过了电话面试这第一关，哪怕让我进入下一关再出局。

4.晴天霹雳

想到这里，我心情还不错地和女朋友一块去逛超市买东西,从超市高高兴兴买了东西回来后，我习惯性的看了一下邮箱，发现了T公司的一封信。信的内容让我失落到谷底：

“After careful consideration, we are unable to match

your skills and background with any of our current open positions.”

晴天霹雳！

而且原以为要几天才会有结果，一看邮件到达的时间就是我电话面试后的15分钟后，我觉着他们太轻率了！但也只能接受这个结果。

我反复琢磨着“技能和背景与现有职位不匹配”一句的含义，最终，我理解为一方面,我原先的工作单位规模不大,另一方面,我原先的开发方式也和他们的不同，我虽然看了敏捷开发的书，但是从没实践过，更别说口语水平了，真是彻底失败。

那一晚我想丢了魂似的，可不么，理想实现不了，真是很痛苦。不过，我总归还得继续找工作，这家最理想的不行那就换点别的吧，退而求其次，还是希望能进入到外企工作，不但拿钱多，而且学到的东西也多。

从网上看到有路X社北京研发中心的招聘启事，我给他们也投了，没多久，来了个电话面试，让我说了说经历，用中文问了些诸如HashMap和HashTable的区别之类的问题，过后也没有了音信。

后来，通过猎头我还接到了S公司的电话面试，S公司是发明了J语言的公司，电话面试的内容也大同小异，我用我磕磕巴巴的英语应付了这些电话面试。

再后来，通过其他猎头还给一家韩国公司投了简历，囧的是，连猎头这关都没过。

5.认识自我

这几家外企的应聘，我基本都在电话面试就结束了自己前进的步伐，

几次失败让我非常现实地认识了我当前的水平、经验、技能、背景这几个方面，与外企要求的条件相比差距还是相当大的。口语不过关，工作过的单位也不是规模大的公司，做过的项目也不是非常大，这些都导致了我和我最向往的公司以及那些高薪的外企的远离。

清楚了自己的水平，自己也认为目前应聘外企是不适合的。而现在，

我要做的是改变求职的方向，不能把重心都放在外企上，所以最终我决定以应聘国内的大型公司为主。这么做是希望自己可以从大公司中学到小公司所欠缺的更加规范化的东西。

五、 转变方向有代价

1. 做ERP的大公司K

继续在人才网上搜索大公司，联系到了一家，是在ERP领域做得很大的K公司。 K公司的笔试，试题分了几类，量很大，题目应该说不算难，包括JAVA的一些基础知识、写SQL查询语句等等。还有要写一个单例类的题，我没想起来怎么定义的，忙发短信找同事求援，幸亏小师父找了一个，让我少丢10分。

上午笔试，下午面试。面试时间比较长，首先面试官先介绍了一下K公司，K公司是做ERP产品的大型公司云云。我还是介绍我做过的项目，尤其是对工作流技术的

研究以及在项目中的运用这方面着重多讲，并引起和面试官的一些讨论。气氛还比较融洽，席间我投瞄到我上午的笔试卷子，好像是60多分。面试到了最后，面试官认为我所讲的经历都是项目经历，而K公司是以做产品为主，这其实是一个差别。

面试过后，回去等待结果，过了几日，K公司人力约我和北方区的总经理见面，我也如约而至，其实主要是总经理再和我聊聊期望薪水，再了解一下我过去的经历。关于期望薪水，我给K公司报的是9K，但是我也说可以考虑减少到8K，其实我心里算计的怎么也应该比7K要多。

K公司规模很大，招聘流程也很长，北京公司这边负责笔试面试等工作，最后还要把我的资料送到总公司那边，总公司再进行一下最后把关，我也被告知我需要等待1周左右的时间来等结果。

在这一周里，正好又有家做咨询、技术解决方案的公司找到我。

2. 挣开源的钱

姑且给这家公司起名叫P公司好了，公司的发展方向比较独特，利用开源软件给做软件开发的公司提供咨询、技术支持的服务赚钱。

P公司代理了从操作系统到数据库以及web服务器等各方面的开源软件，通过卖许可证、技术咨询等方式挣软件开发商的钱。

可能正是因为我在简历中有“开源”的关键字，又在项目中用过JBPM，所以得到了P公司的面试机会。公司有位副总，人称马总，曾经在美国带过项目，而且巧的是也用JBPM开发过项目，还拿到了一个美国的大奖，9年后回到了祖国。马总相信开源，也很会玩开源的东西。

3. 与马总的上海之行

和马总交流并且能得到他的一些指导，对我而言也是种收获。在我眼中一些技术高手、大牛们总是高高在上，很难沟通。

马总却很具有亲和力。P公司在上海召开了一个给软件开发商宣讲开源解决方案的大会，到了快开会的时间还有很多人没到场，为了不让已经到的人等的心急，马总上台预热，他称之为“和大家聊聊天”，他的“聊天”方式很放松，做几个小调查，比如问谁知道“开源”，还推出了有奖问答，凡是举手回答问题的还能得奖，使得会场气氛很热烈。

我也跟着去了上海，和马总一块给一家上海的软件公司将开源报表的解决方案，我侧重讲解iReport的使用。由于JasperSoft出了一个管理报表的引擎JasperServer，用于管理报表，权限等信息。马总让我对这方面也进行了解，尤其是在机子上配置好这个软件用于讲解，整了一晚上也没整出来，马总用候机的时间给配了出来。

那天正好K公司给我打电话，商量薪酬的事情，他们给我开了一个非常吃惊的价钱，开的是6K，而我期望能在9K，听到这个价钱我很难接受，因此直接就说这个价格没法接受之类的话，后来想想有点后悔。

凭着用过iReport，做报表的过程讲解的还算到位，但是对如何使用参数、变量这些稍微复杂的地方，我就没太多讲，能看出来有些让马总失望。

在结束上海之行的时候，马总找了个机会跟我谈了一下，我记住了他的一句话，说“你还要再上三个台阶才行”，这句话我觉着是对我的一个十分中肯的评价，虽然工作三年了，也做过一些项目，似乎有了些积累，但是并没在技术上特别精通，而且在沟通方面也没能锻炼的很好。我认为这种技术支持、咨询类的公司需要既懂技术又能讲解、还能懂架构的技术支持人员。

4. 从开发转变为咨询？我准备好了吗？

我对P公司有好感，主要是两个方面，一个是开源，另一个就是马总，我觉着我如果选择开源作为事业的方向将能引导我走向成功，再加上有马总这样的经验丰富的领导指导、培养我，我觉着我将会有很不错的前途。

但我认为自己还是一名水平不太高的软件开发工程师，还需要用几年时间向架构师、项目经理的方向奋斗才行，而做咨询、技术支持是属于需要依靠很丰富的经验才能做好一种工作，虽然我能快速学习，但还是会缺乏在项目中的实践，很难给客户以很好的支持，最终可能也会让马总失望。

从上海回来后，我和人力谈了我的想法，我说自己还是应该在开发上面多做一些工作，目前的工作可能不适合，把P公司的应聘结束掉了。

5. 从做项目转变为做产品，也要付出点代价。

我又赶紧和K公司联系，K公司人力抓住了K公司是做产品的而我是做项目出身的这一差别作为6K待遇的理由，又说让我权衡是进入一个大型的平台以后不断发展，还是为了眼前的待遇而放弃进入大公司。我更看重K公司这样的大发展平台，但是还是希望人力能再提高一些待遇，毕竟我这是在北京工作，刨去税真的感觉“回到了解放前”。

人力让我等几天和总公司协调，最后等来的结果就是，总部不批准我的应聘申请。 我很难过，因为我找工作已经从5月20号一直找到了7月20多号了，K公司又是大公司，我后悔从一开始就把不满意薪水的话说给了人力，又忙和人力又沟通看有没有什么补救，因为毕竟北京公司这边认为我还是不错的，可是结果已经出来了，也无法改变了。

如果应聘上了，那种薪酬，也就是从做项目转变为做产品要付出的一种代价吧。

6. 从做银行业务的软件开发转换为给某家居公司做系统？

这种可以转变我工作方向的机会很多。有一家家居公司B要上ERP系统，用的SAP的ERP，但是有些功能还是要自己开发，因此他们想招一些高级软件工程师。

面试中谈了谈项目经验，走走过场，基本就搞定了。待遇是税前7K。

面试完了，我也就决定了，肯定不去。

我想以我目前三年的开发经验，到企业中做信息化的工作，要做到技术总监或者CIO的话肯定也是很难的。因为很多人都是在有了很丰富的软件实施经验后，才跳到非软件公司做企业自身的信息化方面的工作的，我自然还不合适。

7. 从开发转变为测试？代价依然很高。

找工作找到现在，出现了没有可选的局面了，有点抓狂，有点绝望。这时候，一家知名公司，神X公司约我面试。和面试官谈了才知道，虽然我投的是这家公司的高级软件工程师，但是他们想找我过来做测试，这个测试不是一般的黑盒测试，要写测试代码、脚本之类的。考虑到如果在这样的大公司做测试也是一种机会，我也乐意考虑这个职位。但是谈到待遇，只比应届生的工资高点，实在是打击，面试官的理由是我对写测试脚本还有网络性能这些测试方面的东西还不了解，还需要学习一段，所以给这个价钱。

事后，我想了，我如果应聘了测试，就是在用我的弱势去应聘，而把我的强项（开发经验）没体现出来，那自然得不到好的待遇，虽然是一个机会，但是我还是希望在软件开发这条道路上继续发展，即使我选择换一种方向，经过自己衡量所需要付出的代价，我还是选择放弃这个知名公司的测试的职位。