编程经历的一些思考——一个工作4年老鸟的职业思考（转载）

软件工程这个概念对于我来说太大，软件开发的概念相对涵盖范围小一些，对于我来说还是太大。在很多种情况下，编码，依然是主要工作内容。我想很多人都有类似的经历（大牛请跳过此段）：

1.大学时专业是计算机。学过的课程多而全。有些人课余会主动学习下网页、flash、作图，Java，Oracle。

2.毕业后第一份工作往往是从维护别人的软件或协助测试开始，主要是调试源代码,利用SQL事件探查器研究逻辑,对SQL的接触和操作较多.主要遇到的问题是下标无效,SQL语句性能过低的问题。陆续的会根据对所在项目的了解情况，分配到一些模块中的小的修改或简单功能的添加。这个时候往往学习和积累了一部分数据库的知识，慢慢了解整个项目的组成，对其中的一个或几个部分的实现能够了解的比较深入。使用的语言跟着项目走，比如开始工作时第一个项目是用C#的，自己会主动去学习，之后的一般也会参与C#项目。

3.毕业后一年左右，对经历过的项目从编码角度上有了足够的了解。对其中的一些实现开始思考为什么，一般是从数据源操作的编码部分接触到工厂模式进而开始主动学习一些设计模式相关的知识，学的时候似懂非懂，用的时候也很少能清晰的分辨出哪种场景需要应用哪些模式。了解应用程序的分层，写一些自定义的控件。开始主动购买一些书籍，设想把项目的每个环节都吃透，从需求分析、概要设计、详细设计到开发、测试、部署和维护。对UML开始感兴趣和进行学习。这个阶段对自己的未来设想往往是成为一个项目经理。

4.毕业后两年左右，开始产生一些厌倦情绪，原因可能很多，比如自认为水平不错但工资涨的太慢，发现很多项目就是不断变化的需求导致的不断修改代码和加班，发现对领导取而代之的路漫长并且希望较小。但是还是在业余坚持自己学习一些软件开发有关的知识，经常逛一些开发论坛和博客，一边鄙视别人对某个环节或知识点的无知，一边迷茫自己的发展。

5.面对技术的更新换代经常思考该不该跟进，面对一些新出现的和当前工作无关的新技术思考到底该不该学习。考虑自己承接一些私活，对代码生成、快速开发、开源界面控件和BS系统界面开始学习、收集。这个时候往往由于国内很多公司的共性（一个通用框架基础上所有程序由此修改而来）导致在日常工作中没有太大的挑战性或深入学习的机会，自己开始读一些经典的技术书籍，如企业应用架构模式、领域驱动设计等等。

牛人请略过上面的部分，这个是我经历的一部分，直到后来转行从事网站推广和优化。即使转行后我仍然还是很喜欢跟开发有关的东西，依然关注着如Entlib、EF和ASP.NET MVC，依然经常写下载一些demo，写一些简短的代码，有时是工作需要，有时自娱自乐。

工作了四年多了，诸如编译原理、操作系统这样的课本知识，早就只剩下书名还有印象，当然读书时也没专研。软件工程、UML、模式这些也基本上成了快要忘却的怀念了。坦白的说在我从事软件相关的行业时，编码和不断修改代码占据了大部分时间。其他的知识很少有实际应用的机会。言必专业名词，两句话不离模式、领域驱动或企业级等等我做不来，可能是我学艺不精，现在更是离开开发工作两年多的原因吧。

大学开始学的是C语言，写的代码主要是数学问题求解,字符串操作,排序,文件操作,流程模拟。程序以函数调用为主.工具使用VC6.0为主。这个阶段就是分析求解问题的步骤，把步骤封装到函数里，然后在流程中调用函数。C语言用函数来封装数据，用函数调用封装流程。我认为自定义的函数分两种，第一种常规函数，与流程无关，封装特定功能或提取重复出现的相关代码。第二种流程函数，用来封装整个流程中的一个或多个环节。 后来学习了C++，写的代码差不多还是这些，类和对象的概念很难应用。开始尝试把数据和数据操作封装到类里。

后来接触了.NET，学习了C#。C#用类封装数据，用事件响应封装流程。类分两种，第一种常规类，与流程无关，封装特定功能或提取重复出现的相关操作。第二种类通过方法封装一个或多个流程的一个或多个环节，并通过事件触发来完成流程调用。我自己用C和C#写代码的共同点都是按照要实现的功能或者要解决的问题对数据以及其操作封装到函数还是类中。也许很多书上都强调如何抽象出对象，把相关联的数据及其操作放到一个类里，我不觉得这话有多大内涵。用C语言，我们也是在流程的每个环节通过函数进行了数据和操作的封装。真要说不同点，就是C语言有全局变量存储数据，可以通过传参完成函数对数据和操作的封装，而C#的类的成员可以直接承载数据。在流程上，C语言要通过循环和条件判断等来处理不同流程，而C#中的事件在这方面完成了同样的功能。

换种分类方式，函数分为功能性函数（非流程函数）和流程函数。非流程函数和具体业务流程无关，一般指预定义库函数和自定义的功能性函数和第三方的函数库中的函数。重构提取的函数也大都属于此类，因为如果通过重构提取了每个流程都包含的某些环节作为一个函数，那这些环节是否判定为流程的环节就值得斟酌。流程函数是这样一种函数，即该函数被调用时只是某个具体流程的环节。 对象则封装了相关数据在一个或多个流程中的环节。这是以函数作为单元和以类作为单元的很大区别。单元是由语言决定的，但是使用可以由人决定。

我理解的OO建模是抽象与精简现实的过程，某种语言的代码仅仅是模型的一种表现方式。流程驱动和事件驱动的基础都是先分析功能后实现功能，流程驱动弱化了实体模型，而事件驱动则强化了这一点。没有绝对的流程化，也没有绝对的事件化。事件驱动包含了流程驱动，流程驱动也蕴含了事件驱动。而流程无论是在面向过程还是面向对象中都是必须体现的。

我从事过C语言的Vxworks嵌入式开发工作，也从事过.NET的开发工作，参与过对日外包的大型项目，也参加过.NET开发的大型的面向国外用户的软件项目。读过很多书，看过很多帖子和讨论，经常看一些demo和开源程序。对于很多程序，我自己将其归到2类中：

1.以数据处理为主，主要体现在其需要持久化的数据本身就足以表达大部分的意义。采用何种平台和语言并没有本质上的区别。比如一套一直用excel维护的文档改用CS或BS形式的行业软件，但程序代码中主要的处理仍然只是增删改查，几乎没有或只有很少的业务逻辑需要处理。而且往往这种类型程序的最终作用就是提供一个二维表格界面或直接导出excel用作其他用途。几乎我见过的大多数XX数据管理系统都可以归到这个分类。只要了解需要操作的这些数据，无论是原始的excel还是数据表，大多数人几乎很快就可以做出来一个类似的程序。虽然我对面向对象并不够了解，但我绝不认为这些程序适合用来做面向对象的例子。我理解的面向对象的优势除了扩展以及复用的价值，就是它在复杂业务逻辑的场景下的优势。

2.以业务逻辑为主，数据本身无法表达复杂一些的逻辑。其数据持久化无论采用数据库还是xml文件甚至平面文件没有本质上的区别。比如一些关于银行业务方面简单的例子，各种类型的客户办理很多业务时需要走的流程，甚至一个类型的客户办理不同的业务也是很复杂的，我想这个不需要我找个代码出来大家看，如果你实际去过银行的话。把银行的数据以二维表的界面形式还是excel的形式展现出来，我相信一般人绝对不会通过这些数据了解到需要走哪些流程，满足哪些条件才能形成某种结果。虽然都包含对数据的增删改查，但这个对比很多XX管理系统差别巨大。

有人可能说我在回避面向对象和面向过程的倾向，我想如果仔细看了上文，应该不难看出：1.无论面向过程还是面向对象我都一知半解。2.在上文我已经表达出来了，面向过程包含在面向对象中，面向对象有其适用的场景，也有很多场景根本不适用。