经常有学生在学习了一些.net知识之后，感觉那些c#知识和控件离做一个产品太遥远，特别是在上内训班的时候，学生本身已经对.net的那些知识点点都已经熟悉，但是，就是不知道如何将这些知识“拼凑”出一个具体实用的系统。
每个人都会经历一些认知阶段，有时候，我也在反省自己的这些“来时路”。遂有此文。我认为自己在成长过程中经历过这几个阶段是最让我印象深刻的。
1 拖拉控件阶段：最开始做系统的时候，就是复制已经做好的页面，然后对着产品经理提供的原型拖拉控件，设置属性，编写事件代码和相应的逻辑。总是稍有疑问，就逮着开发组长和产品经理问个明白。总之，开发组长分给自己的那一亩三分地还是要清楚的。
2 自己开始独立承担，做开发组长的阶段：往往这个时候，自己开始做那些“从无到有”的活，也就是怎么样构建一个页面，让开发组员来copy?这个地方涉及到一个思路的转变，如何将一些功能划归为一个个页面的组合，具体页面又是如何布局？每个人到这个时候又往往是最迷茫的，最犹豫，最反复的。往往我们总是按照以前的思维在琢磨一些具体的点上的表结构、算法，业务逻辑，同时又想着是Outlook式的还是portal式的界面。折腾好一阵子就是不能保证能够把一个软件稳当、完整的开发出来。这个时候往往的思想就是典型的页面驱动开发的思想，以设计好一个个页面为导向，向后台代码延伸。
3 “曾经在幽幽暗暗、反反复复中追问，才知道平平淡淡从从容容才是真”：经过第二个阶段，经过几个项目的挣扎，慢慢的开始知道如何组织系统，设计界面。不再是一股脑儿的往页面上拖拉控件，在一个gridview里面放dropdownlist,放四五个按钮，而是开始想着如何将一个页面简单化，单一化，就像拳击一样，不要想着一拳击倒对手，而是通过一系列简短的组合拳进行。看看咏春拳也是的，咏春拳适合短距离之内的“粘打”，因为它鲜明的特色就在于连续的组合套路和发力。（看了我们好几个项目，包括软件学院信息化项目，绩效考核系统，一看就知道设计人员还没有到这个阶段。仔细看过IBM,微软，或者国内的金蝶的一些产品的UI设计，你会发现，他们的一些很简单的修改都会拿出一个页面来折腾，你会发现他们的页面跳转很“厉害”，我想，除了他们在设计的时候除了方便功能分离之外，这种做法，也可保证产品出去之后，第三方产商也容易去结合客户需求去定制）。页面简单化有很多方式，分离出控件，框架、主题、更重要的是页面之间的组合。现在基本上做一个项目，每个功能的实现，我都会对应四个页面：add,edit,list,operator.分别负责增加，修改，查询和一些操作逻辑。从某种意义上来说，这种固定的4个页面的模式，也实现很好的规范化。同时，页面背后的代码也趋向简单，更多逻辑交向业务逻辑层，或者剥离出一个“装饰层”，负责对界面相应事件对业务逻辑的组合调用。 这个阶段有点像产品经理的角色那种味道。
4 经过一些项目的历练之后，自己更开始着眼一些项目如何有序的安排各个功能的组织实现。 其实，这个阶段要受益于以前跟行软的产品经理魏东的交流，他有一句话至今让我印象深刻：“在中国做什么事情，首先考虑后续工作开展之后如何管理起来；做系统也是的，做一个功能，首先考虑这个功能的实现如何在你的控制范围内。”，其实，这演变出的一个思想，就是测试驱动的思想：实现一个功能，首先考虑如何能够测试这个功能是否正确。每个功能都正确，随着他们的组合，相应的bug就少。（偶是学数学的，这点深有体会，我们的那些定理、公理最开始很简单，后来经过一些朴素的推演，延伸出更加复杂的定理，继而构成了整个理论体系，即便最后那些什么希尔伯特空间让我们觉得无可琢磨，但，无人怀疑他们的正确性。）具体在设计系统的时候，我也开始按照测试驱动的思想保证自己每一步都是正确的，这样，雪球越滚越大，依然有信心，相信自己的那些实现。具体来说，大的来说，我会优先设计那些基础的功能，管理的功能，小的页面来说，我会先考虑设计list,然后再去考虑add,edit,operator（为什么不是常规的先add,再list,再edit?按照流程是如此啊？！自己想想，呵呵），这个阶段总体来开始倾向于开发组长、产品经理的组合了。
5 架构设计阶段：这个部分主要还是自己知识的广度。努力中....