可以把一个软件研发工作者的从业经历大致划分为3个阶段：

第一阶段是新手期

这个阶段的典型特征是容易被新技术的华丽外表所迷惑。当在网上看到一种新技术的介绍或者心得，立即产生了大量肾上腺素的分泌，干什么都想用一用，如果这时有人跟他说你的这项工作用这个不合适的话，要是性子急的人估计就直接开始骂娘了，性子缓些的也会想尽理由说服你使用这个新东西，实在没办法的话，吃不下东西睡不着觉也想另找个地方用一下。

第二阶段是中级程序员阶段

这个阶段的程序员对技术、和工具的选择已经审慎了很多，可以根据具体的需求来选择需要采用的技术，可以写出详细的需求调研报告并提出设计方案，优点、缺点分析得清晰明了。在应用层面也有较强的全局理解力，在团队中也具有相当的协作能力，因此具备较强的解决问题的能力。

第三阶段是高级程序员/分析师/架构师阶段

进入这个阶段的前提是多年的工作经验，广阔的知识面和对系统底层到高层的全面认识，已经使其进入了无语言无工具的层次。也就是能任何清楚地感知每种编程语言的优劣、使用范围、编码禁忌，对一个大型工程能有最全面的了解，在选择语言和确定技术方案的时候不会被自己对语言或技术工具的偏好（或者根本已经无所偏好）所影响，真正明白了其实别管是神马语言、神马技术，归根到底咱们的对象还不是CPU、内存、硬盘和网络，该做的事情一件都不能少，所谓的技术框架是对初级程序员用的，真正高级了不研究个清楚透彻都不敢让你进来。即使对同一种语言，在不同的操作系统中，如Visual C++和Unix C、AIX XLC、GNU G++等等的区别，以及不同版本之间的区别也了如指掌。

用七句话总结我对架构师的定义：

以工程思维全面理解业务需求

基于模型和基础模式抽象简化

提出恰当可行的整体解决方案

在限定资源范围完成明确目标

满足业务需求且保证系统质量

在可预见的周期内具备扩展性

并在系统生命周期内持续演进

那就都该怎样去做呢？

多做项目，多思考

不要害怕做事，刚毕业的同学最缺的就是工作经验（《程序员：增加编程经验的3种途径》），乱七八糟的项目能让你很快就了解了一个公司的业务与使用的技术，并且可以多接触同事与客户。当你毕业后刚进一家公司时，如果主管没有把你安排到项目组工作，那真的很杯具，因为他认为你还不能胜任工作或者你的加入会让项目组更糟。

参与开源项目

自己开发框架与工具，可以让你快速的从一个初级程序员转变成更高级的程序员或分析师或架构师，因为这个过程中给你提供了为其他程序员服务的机会，你有动力去了解其它程序员的工作需求，你可以把你的框架或工具写得很好，接口简单灵活并且性能好，分析师和架构师就经常要干这种让人力成本降低的事。

写技术博客

写技术博客是一种可以快速提高的方法，但是一个人能坚持每周写技术博客，那是需要付出很多代价，写博客并不是要我们写出高质量的文章才发表，我们可以分享自己的一些小经验，也可以分享自己的体会。

优秀JAVA程序员必看的书籍

《JAVA编程思想》在有了一定的Java编程经验之后，你需要“知其所以然”了。这个时候《Java编程思想》是一本让你知其所以然的好书，它对于基本的面向对象知识有比较清楚的交待，对Java基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。

《Agile Java》中文版

这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的 过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。另外这本书成书很新，以JDK5.0的语法为基础讲解，要学习JDK5.0的新语法也不错。

《重构 改善既有代码的设计》

这本书名气很大，不用多介绍，可以在闲暇的时候多翻翻，多和自己的实践相互印证。这本书对产生影响是潜移默化的。

《测试驱动开发 by Example》本书最大特点是很薄，看起来没有什么负担。可以找一个周末的下午，一边看，一边照做，一个下午就把书看完，这本书的所有例子跑完了。这本书的作用是通过实战让你培养TDD的思路。

架构师的经验体现在什么地方呢？举一个例子：

比如一个复杂的分布式系统，时时刻刻处理业务请求，要设计一套机制，保证所有的业务都能处理完成，无论成功失败。

简单的开发思维会考虑，尽可能的捕获异常，给每一种错误类型编号，中途失败的流程要进行回退，相信设计能否覆盖所有情况。

有经验的架构师则会清醒的认识到，这样的系统随着不断升级和持续运行，一定会出现各种各样的问题，不出问题是不可能的。

应用的潜在bug、业务逻辑漏洞、数据异常、网络抖动、硬件故障、人工误操作，甚至还有莫名其妙未能找到原因只能归结为灵异事件的问题，会层出不穷，等你解决。

我们需要做的是尽可能监控、捕获到异常情况，通过技术手段修复多数的问题，少数不常见的或者难以自动解决的问题最终还是要考虑通过人工方式处理。

我们的目标是解决问题，通过分析，调整架构，优化逻辑，旧的问题解决后，还会有新的问题。

只要系统运行，就需要维护，软件工程理论中系统上线后期维护都是一个重要的阶段，此时系统是动态的，业务是连续的。

用近几年很多人用过的比喻，开着飞机修飞机，开着火车修火车，在原有的系统上做修改，并不比从头做一个系统轻松。

就像是CAP理论下，多数的选择是最终一致性，即通过努力，无限趋近于问题最小化，时刻准备着迎接新问题，动态平衡才是系统运行的常态。

我和大牛之间有多少距离？

跟很多人一样，刚毕业时我觉得作为程序员，只要努力，加上少许天赋便可以获得一些成绩。

工作一段时间后，对自己和其他人的认识也越来越清晰，逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大，接受这个事实这让我郁闷了很久。

再过一段时间，发现自己已经能够客观的评价自己的能力，也意识到了距离并不是那么重要，只要想办法跑的更快，就足够了。