原文:http://www.oudahe.com/p/86/

作者：编程小技巧

【说明：我是从1979年上大学期间开始编程，1982年大学毕业，至今仍在编程岗位上。在这里，我想跟大家一起分享一下我的职业经历，总结自己这些年来的历程，这也许能让年轻的程序员少走一些弯路，成长得更快；或许更好一些，能让大家从中得到一些启发，早日进入优秀程序员的阶段，实现梦想，释放激情。欢迎多交流。谢谢！】

第一阶段，最初是在学校里学习计算机基础知识，学习经典的程序设计语言，编写测试用的小程序。这个过程可以说是对计算机和程序设计的入门阶段。这个阶段主要是培养了自己对计算机软件的兴趣，打下了良好的计算机基础知识。

第二阶段，而后参加工作，从事计算机软件开发工作。按照工作要求，一边学习，一边编程，终于可以让自己的程序投入运行了。在这个阶段我突然感觉到了自己的价值，感觉到了软件的神奇，并且自己编写的软件成为了实用产品。这个阶段实现了学习到生产的过渡。

第三阶段，随着工作的增加，开始编写各种程序，开发各种系统，这时候忙于编程知识的积累和应用。应该说在这个阶段自我感觉很充实，好像有做不完的事，程序设计水平还处在语言级阶段。

第四阶段，随着积累了一定编程技巧之后，我开始想这样的问题：我是不是最好的程序员？我能否编写出最好的程序？这个过程是一个反思的阶段。我对自己的要求是：不但要会编程序，而且要编好程序，从关注程序数量开始转向关注程序质量。

第五阶段，开始在提高自己的软件开发水平上做文章。经过各种系统开发，尤其是大型系统的开发，发现了软件中有许多功能是重复的。因此，有一段时间把精力花在编制各种库函数上，通过不同系统调用相同的函数，以便减少重复开发，实现功能共享。当时比较得意的是库函数不是我一个人在调用，而是整个项目小组都在调用，甚至不同的系统也能调用，从而体会到编写库函数特别有价值。这个阶段的标志是库函数，程序员水平上升到库函数那一级。

第六阶段，到了库函数那一级后，很快就发现，单单实现程序函数级的调用是远远不够的。当你做了很多项目，包括大项目和小项目，尤其是做过跨行业的项目之后，你就会把库函数的共享思想用于项目开发。你就会想这样一个问题：为什么不同项目不能有相同的架构？如果有相同的架构，那么开发就有了相对的标准，我们就有可能通过配置的方法实现相同架构的系统。于是我提出了IASG（交互式软件自动生成器）思想，并在C语言和其他一些语言中实现了IASG实例。记得最快的一次是编写一个系统（公安部门的自行车信息管理系统，主要用于丢失自行车信息登记）只用了3个小时（从需求到安装盘）。这个事情对我影响很大。我在这个阶段上升了一个很大的台阶，从程序上升到软件。核心思想就从库函数共享上升到软件共享。具体过程是建立一个通用的系统架构，架构中有许多共同的功能，例如，参数设置、用户权限管理、库表管理等。另外还提供信息建立查询开发模板，通过配置和特殊功能的编制就能很快完成了一个系统的开发。现在想起来 IASG距离我已经有20年了。

第七阶段，到了IASG阶段后，我发现无论技术如何提高，都无法改变开发落后于需求的现实。通俗地说就是：程序员水平再高，仅仅是拉车水平高，但是，应该在什么路上拉车程序员并不知道。如果这条路是一条光明的路，则程序员越拉越有劲，有前途；如果这是一条死胡同，则程序员白费工夫；如果这是一条漫长的路，前途不明，则程序员可能要累倒在路上。现实中程序员水平低、收入低；系统需求不明确，系统开发周期一拖再拖；系统重复开发多，信息甚至不能在一个企业内实现共享，更不用说在企业之间、行业之间实现共享了；各种企业级的软件ERP、CRM、BI层出不穷，也没有哪个能满足中国的市场；各种新技术、新概念不断出现，却没有哪种技术或概念能真正发挥其内在价值，最终还是处于被学习、被运用的阶段。这个过程是程序员脱离技术本身，开始思索、开始求源的阶段。在这个阶段的程序员的思想有了质的飞跃。以前光拉车不看路，现在要抬头看路了。

第八阶段，有了抬头看路的想法，于是我踏上寻路征程。我首先弄明白了我们脚下的路是什么样的，为什么这条路那么不平坦、不宽广。从软件生命周期来看，软件主要由用户需求发起，用户需求是软件生存的根本理由。由于企业、用户的不同而导致不同的需求——大量的无序的需求，这种需求驱动方式必然造成了我前面介绍的各种现象。这个阶段是寻找根源的阶段。只要我们找到了根源，就可以有机会解决问题。这个过程相对来说比较困难，这不仅需要编程技术，还需要很多方面的知识。若要了解这个根源，就迫使你学习和积累更多程序以外的知识。

第九阶段，当我找到软件是需求驱动方式之后，就开始考虑什么是用户需求？用户为什么要提出这些需求？我们可以更深入地分析用户需求产生的根源，我们能否让无序需求变成有序需求呢？当然针对这些问题我们都进行了深入分析，其过程也很难在这里展开说明。我只能说，最后结论是用户的需求来源于企业的经营。很多人思考问题还是就需求而论，并没有站在企业经营角度去考虑问题。千万不要小看这个变化，这个变化最终会产生一个理论。于是我们尽可能地站在企业经营角度看待企业经营方式、企业管理、企业信息化等。但是，我们最终要解决企业经营这个概念问题，如果我们都不能明确企业经营这个概念，或者我们不能科学地定义企业经营这个概念，那一切基于企业经营的各种具体现象就如同无本之源一样无序泛滥。就像ERP、CRM等所谓企业信息化产品一样，由于没有一个企业经营定义的支撑，只能就企业经营的某个方面提出解决方案。这些产品不缺乏需求的支持，缺乏的是最基本的企业经营定义的支持。而这个概念就是EOM。
EOM是从定义企业经营角度入手，把我们今后要开展的各种研究和开发活动都放在一个理论可支持的基础上。只有定义了企业经营之后，我们才有可能分析我们需要什么软件，我们的软件采用什么技术才能实现企业经营的目标。而程序员则通过EOM了解到企业经营需要什么样的软件，这个软件有多大的价值，这个软件采用什么技术才能实现，自己要提高哪方面的技术水平才能获得更大的价值。
这个过程就是EOM阶段，通过EOM了解软件的根源和有价值的软件所在，进而选择自己未来的方向。

第十阶段，当我建立了EOM之后，便开始了EOM实现阶段。这个实现阶段分为两部分，通过这两部分的结合，我们就可以逐步看到EOM软件产品的实例，看到EOM的真正价值。
第一部分是EOM的业务实现。当我们明确了EOM之后，就可以根据EOM来重新规划企业信息化的整体架构，可以细分这个架构中的各种平台产品、通用产品、专业产品，可以细分出这个架构实现的各种技术架构和实现手段，可以细分出这个架构中的各种标准功能和标准信息。通过这样的分析，我们的程序员就可以根据自己的特长和爱好以及价值的判断来选择其中的软件产品和技术。在明确目标和方向的情形下，通过自己的努力，不断提高自己的各种技能水平，让自己的价值和企业经营价值有机地结合在一起，从而实现自己的理想。
第二部分是EOM的技术实现。有了EOM并根据EOM理论构建企业信息化的架构后，我们就必须从技术上实现这个架构，否则这个架构将永远停留在理论阶段，不具有可行性。我们可以采用现有的各种技术来实现这个架构，但是，现有的技术都是基于原有的业务需求而建立和发展的，它适用于原来的应用对象。目前的 EOM是一个全新的企业经营理念，因此，我们必须建立一种新的软件架构来适应和最好地实现这个理念。幸运的是，我们找到了称作NSS（New Software Structure）软件新架构的技术，该技术体现了适应企业经营发展方向，将软件合理分层，用最新的软件技术按照架构的方式规范软件开发的模式，可以实现最大范围的功能共享，实现软件的可扩展性。
这个阶段可以让程序员在软件产品业务设计或软件产品技术实现上等多个方面进行深入钻研，并且成为领域专家。这和我们平时涉及的简单的需求分析和简单的技术实现有着本质区别。

从我的程序员经历可以看出，程序员的成长是无止境的，只要有的放矢地努力，就会一步步登高向上。我认为程序员成长经历主要有三大阶段，即通用技术阶段、市场阶段、专业技术阶段。
1）通用技术阶段是程序员专注编程水平提高的阶段，也就是说“只拉车不看路”阶段。这个程序员能做的事情那个程序员也能做，程序员的替代性很强，程序员市场价值相对较低，程序员只关注编程技术本身。
2）市场阶段是程序员跳离技术层面开始考虑为什么要开发这个软件，这个软件有什么价值的阶段，通过求软件之源来重新认知自己的方向。
3）专用技术阶段是程序员认知了这个软件和技术有很大的市场价值，全身心投入到这个领域中去，并在这个领域成为专家的阶段。程序员不但要懂技术，更要懂得客户业务，不同的程序员的技术和业务变得没有可比性，这种稀缺性造就了程序员极大的价值。

这三个阶段其实就是三个过程，每一个过程都是一次飞跃。程序员知道自己可以飞多高，依靠的是程序员的学习和眼界；而程序员能飞到哪里，那就要靠程序员自身的努力。一个程序员可以没有能力，但是不可以没有眼界。