懂模式又咋样？不还是一个技工吗？

模式现在是国外一些大学的必修课了，模式属于技术，技术不能绝对化，了解了就可以，也不必从技术引申到其它领域，理性逻辑性思维比形象化思维更重要。

看来楼主是没有见识过真正的技工，蓝领程序员。我见过的真正的技工是不思考的，为了实现而实现，按照某种死的模式，机械的编码，仅考虑代码一级的实现，不考虑怎样实现更合理更好。也就是说我觉得真正的蓝领程序员缺乏的是创造力，缺乏的是思考。作为一个刚从广州返回大连的同行，我深有感触。“蓝领的概念”这在大连这种对日外包项目中十分的常见甚至是普及，只是大家都不晓得而已，客户要求你必须这样写，你没有选择余地，任务进度紧而多，容不得你去思考，所以导致大家做一个程序，不去思考，形成了一种恶性循环。如果说客户的要求是死的，也就是它是一种规范，那么你至少要知道自己为什么要遵守这个规范，也就是说要思考自己为什么这样而不是那样。提到了设计模式我感觉它其实是鼓励思考的，鼓励创新的，如果你行的话，你也可以有自己的设计模式。即使是套用一种设计模式，也需要自己的思考，什么场合，情况适用？所以，我觉得真正掌握设计模式的人不会是一个蓝领技工。
最近听说东软的培训有专门针对外包项目的定制式的软件开发培训，无论什么起点的人都可以参加，我想这种培训就是生产出所谓的蓝领技工的吧？可怕

所以感觉区别是否蓝领程序员的本质在于你是否善于思考是否喜欢思考。

以前我反对蓝领工人，现在我不是那么反对了，我想：现在是制造，以后大概是中国软件制造，一个大型J2EE项目可能是多个组件和模块或框架拼装而成，到时真的可能只需要精通某个环节的软件组装工人就可以，高中毕业即可。

也许到这个时候，软件真的是一个产业了。

楼上说法我部分赞同，我想我自己大概很长时间，或者永远也只能达到“蓝领”这个层次。楼上的楼上所说的创新，我觉得狭隘了点。我们什么时候能有点更能体现能力的创新呢？比如啥时候发明一种音频格式压缩算法，可以无损压缩80%，我随便举举例子。我只是想说明我这样一种观点，当你能做的事情，别人不能做了，那才是真正意义上的摆脱“蓝领”。

可是软件得本身特点决定了他注定不能像工业化一样得生产线。君不见自动化设备和生产线得引入导致大量得工人下岗么？如果软件也可以出现所谓得蓝领，那么自动化代码生成工具替代这种蓝领得一天那是必然得事情，但是这似乎不是意见易事。

就最软件蓝领我个人认为很有可能在某个阶段爆发性的出现，并且也是应该出现，到软件行业成熟的那一天一定是这样的。所谓软件行业成熟不是说到了人吃人的那一天，而是软件业象其他行业那样在也不是朝阳产业的时候。就现在而言，我们已经基本上实现了许多软件自动化，就我的队伍和公司，居于某种框架的代码和配置文件(Dao,Vo,Ejb,Struts-config.xml,cache.xml,application.xml.DatabaseInfo.xml等等)全部生成，包括一些业务接口(Command模式)业生产，剩下的就是我们的软工按设计进行业务逻辑编写。呵呵，是在话，现在的这些活高中生经过简单的培训（熟悉框架，给一些DEMO），就可以信任了。完全不必要一个本科的。当然这种情况出现，要该公司要有很成熟的软件过程和软件积累。

作个你说的那种代码生成工具不是件难事，可是它丧失了人对项目的控制，做出来的项目也是那种不伦不类的软件项目，这种软件质量是不敢保证的。

^_^，如果真的到了你说的自动化程度，那么你们公司可以只需要几个需求分析，业务建模的人就够了，这样所有的东西都是可以控制的，理想到了人月不是神话的境地。

呵呵以前是学建筑工程的，所以看到模式和UML的时候觉得很亲切。
我比较认同会出现软件蓝领，首先要说的是一个产业必须形成金字塔型的结构方能稳定，而软件行业恐怕现在最多只能算以恶柱型结构或纺锤结构。

软件蓝领是解决软件行业的产业化必然，这样才能建成一个真正的金字塔结构，如果你不想做底层那么就尽量做到高层。

而作为建筑这个行业的荣耀或辉煌离不开建筑工人，但却不是建筑工人所带来，在建筑行业成熟之前，能工巧匠能反映一个“技”的境界，但是无论古代不成熟时期还是现在建筑成熟的阶段，设计师恐怕永远是必须存在，而且是这个行业的最耀眼的星星实际上还是建筑师，甚至是开发商。

建筑行业是开发商出钱、建筑师牵头、结构师配合计算，辅助设计师绘图制图人员完成工程图纸的绘制，工程队承包工程建设，大量的工人建设，监理人员和设计师负责监督项目的执行情况。

现在只能说对软件工人的要求比较高，如同古代的能工巧匠实现各种设计师的设计，甚至自己偶尔做一些小小的设计，雕刻出精美的雕塑，做出优雅的结构，但是这样的能工巧匠在当今社会却也越来越少应该来说已经不算蓝领工人只能算匠。

如果有一天中国软件发展出现大量的软件蓝领我觉得也没有什么，因为我们可以选择做一个产业的上层建筑，有开发商、设计事务所、监理工程师、工程承包方和蓝领工人，你可以选择你自己的发展方向，最后说的是只有分工没有贵贱之分，一个结构的关键施工人员，例如钢结构中最优秀的焊工恐怕工资水平亦不低于一些设计师。

总体说来，我觉得中国需要软件蓝领，但是并不应该过分强调，我想在这里讨论的人，更多的是想做设计师。

其实纵观建筑和军队的建设，也许能更多的让我们看到软件的发展的方向。

就像只要设计人员而由机器自动完成程序最后的编制和组装，看上去像天方夜谭，但是若美国人可以告诉全世界，他可以派无人机器去打一场战争，恐怕现在大家越来越看得到这种前景，而不再认为是天方夜谭，如同一场没有地面部队的南斯拉夫战争，让中国意识到我们和对手的差距，恐怕软件业也有一天会让我们意识到这种差距。所以不要过分学习印度，因为它没有带来优秀的思想，我们可以走相同的路，但是要看得更远，还是多看看美国人在做什么吧。

建筑业的发展历史可以说是软件发展史的几个数量级的倍数了，如果说软件也有那么一天，那么我想至少我们是赶不上了。建筑业可以发展到目前的结构，是因为建筑业慢慢经过沉淀的变得规范而可以量化。可是就目前来看，软件本身很多东西是无法进行量化的和规范的。建筑业的需求可以说是规范的，难道一栋大楼盖好了，客户会提出把掉中间一层楼去掉的需求么？可是软件可以，而且可以在中间在加上一层，十分普遍；同样，建筑是可以量化的，每根承重的柱子的承受力都可以计算，盖一层楼需要几天都可以准确的预算，软件可以么？如果软件有了一天可以这样的量化和规范，那么软件也可以像建筑一样。
其实我也赞同楼上兄台的金字塔的概念，这是必须的，难道一个公司所有的人都搞设计么？恰当的分工是必须的，即使在现在，相信大多数软件公司也有明确的分工，而且相信大家都是从底层的泥瓦匠开始做起的。可是软件蓝领的定义是什么？我在前面就提到过，关键是你有没有自己的职业生涯规划，你去不去思考问题。同样工作了几年，为什么你的写出的程序赏心悦目了，你的薪水上涨了？而很多人却是原地打转，还做着和刚开始水平一样的程序？
很多软件外包公司过分的鼓励甚至是鼓吹规范，所以为程序员们上了一道枷锁，是他们变成蓝领程序员。记得Tom DeMarco曾经对于外包企业热衷于cmm有过如下的评述：他们根本就是无可适从――他们无法适应变化，他们无法在这种全新的环境中找到自己的位置，所以他们总得给自己找点什么东西来信仰。William Clifford曾经说过，人们常常会根据自己的愿望而虔诚地相信一些东西，但愿望的强烈并不能使信仰变得可靠不过，对于只做外包项目的企业（例如很多印度软件公司）来说，CMM倒是一个不错的能力衡量标准。只有对于这种不需要动脑筋、不需要创新的企业，CMM才有意义。如果让我来评价，我会认为CMM是软件企业的耻辱符：等级越高，说明企业越缺乏创造力。当然，说法可能有些偏激，但是这些评述与鄙人大连的cmm5公司的就职经历是不谋而和的。企业因循守旧，全部是面向过程的开发模版，但是各种估算、度量、计划、进度控制的模板一应俱全，大家不接触新的思想，新的技术，更不要说创新了。在这样的公司中，甚至你分析设计人员、项目经理的工作都是非常“规范”的，更不要说程序员了，你的任何创新与公司的规范是背道而驰的，在项目中你是颗棋子，你的想法，建议必须在“规范”之中。在这种规范之下，一个程序员想实现自己的职业生涯可能么？
软件究竟将何去何从或者说程序员的职业生涯将何去何从？谁能为它指条明路？

当软件业及其相关的一切没法发展到如此规范的时候，非要去规范软件业，相信会适得其反。所以必要的软件蓝领只有在真正软件业真正规范的年代才应该出现。这一天还远。

to all，
呵呵，很巧，我真的认识很多由建筑工程专业转过来的，告诉你我也是我。因为建筑工程专业的背景，所以对软件似曾相识，所以我入行后对什么设计模式，面向组件开发，框架(说真的和建筑上的框架结构有点神似哦)亲切感，也这样做了，很有成效哦。现在基本我们的思路是公司有自己的成熟框架以及有自己的基本类库，我在上面已经说了，那些都是公司的财产，是公司知识的积累。很多道友应该晓得一个软件质量是如何来保证的，我现在就负责公司cmmi se 过程改进，我随便跟大家探讨探讨，软件质量是由过程，人，工具(包括方法)来保证的，那么好过程是一个好的软件质量的基本保证，熟练技能的人(熟练公司的开发方法和工具，熟悉公司的开发过程)是公司好的软件质量物质资源，好的工具(包括方法)是公司好的软件质量的保证手段。那么如果一个公司能做到cmmi3级(真正作到而不只是认证通过)，那么我想他完全可以把需求，设计，开发，测试，维护等独立，而开发的完全可以用所谓的软件蓝领(好难接受)。呵呵，但是这样的，不能依赖那个技术高手或项目经理，^_^，这个说起来就话就很长了。
就上面的道友提出的：

－－－>>>>作个你说的那种代码生成工具不是件难事，可是它丧失了人对项目的控制，做出来的项目也是那种不伦不类的软件项目，这种软件质量是不敢保证的。
>>>>>>>

其实我我告诉你，你的理解在现实中是错的。代码生成工具和丧失了人对项目的控制没有任何联系，项目的控制是由项目经理来做的，深层次更是公司来控制的，呵呵，得知道一个软件过程成熟得公司或组织是不会考虑你一俩高手或项目经理个人离开得。代码生成工具是居于公司的开发框架来做得，是公司级得不是某个项目组自己在做得，然后做他得人走了就不行，或者他得工具不是居于公司的开发框架而作，是自己乱发挥，个人程能公司是不卖帐的了。其实我们都知道要按一个框架开发，必须遵循框架的规约或约定，代码生产器是生成出符合框架的规约或约定的代码，说很简单的就DAO，由很多不同的实现方法，但公司框架是这样实现的那么就应该生成这样的DAO,而不是其他的，进一步说，你会问我，DAO不就是DAO吗，那还有什么，但我只举一个例子就行了，DAO里面A公司是用了jdbc来直接系列化的，但B公司是封装了Hibernate来系列化的，更有C公司是要用
ejb来实现系列化的或者使用OJB等等其他O/R Mapping工具，呵呵，还有很多关于框架的要求，这里就不说了，我的观点是代码生成工具不只是提高效率还可以保证制品的质量的一个很好的手段，人工编码容易因各种因素出现"误",并且比不上代码生成工具更能保证代码风格的统一。

记住了，过程，人和工具是质量保证的三大要素，而人不是指多厉害的技术高手或项目经理，是熟练公司的开发方法和工具，熟悉公司的开发过程的人。这里不能深入，因为太多的东西了。老实说我心里也很反感什么蓝领软件人，但这只是因为我们程序员的“高傲”的心里作怪而已，但潮流不能因为我们“高傲”的心而止的，我现在就已经看到了，你要是接触日本外包项目的话，感触就更多了。我老觉得日本人可能早就知道有这么一天了，对产业链他们也分析过，所以把下游的东西包给我们，然后过了十年或者更长时间我们中国上游的能力就会削弱......题外话。

软件项目的真正风险或者质量不稳定因素主要的不是在于稳定不变的部分，而是在于变数，代码生成工具只能针对某些通用的实现，遇到真正复杂的业务是你代码生成工具能解决的了的么？