昨天中午的时候，项目组的另外一个小组的同志下楼跟我讨论关于联机报表系统的相关设计。报表系统是我年初设计的，统一了批量报表与联机报表的API，程序员能够无差别的进行报表开发。现在多了一个需求：所有的页面上联机报表的显示统统加上Excel导出功能，并能够进行模板切换。这个需求说来轻巧，但是工程庞大：整个系统2000多张页面要进行报表输出！经过约一个小时的讨论，我提出了大致的解决思路，然后重新说明了现有报表的设计结构。他们终于能够兴冲冲的跑上楼做详细设计了。按照他们的最初的想法以及现有的编码规范，需要编写2000多个BO, DAO, 以及对应的Action; 而经过讨论后的设计，将这一部分变化独立开来，只需要进行一组独立功能的开发，其他的，只需要在页面上加一个小小的链接即可。

嗯，系统上线了，是不是仅仅会编码的人员参与维护就可以了呢？事实不是这样。在后期，却要求相关人员具备更强的能力——因为小小的改动就会影响整个系统——只有相关人员具备足够丰富的经验才可以。从各种系统的开发经验来说，编码从来不是项目的瓶颈——改动才是。一旦需求确定了，编码框架确定了，一个高级程序员花一个下午便可以做出代码生成器，一下生成数以千计的各种文件。因此，在真正形成规模的系统中，软件蓝领的存在毫无意义。在我们这个庞大的系统中，每个人——对，每个人，都或多或少，无论是明显指派的还是隐含的，都参与了业务的设计。不存在纯粹的编码人员。后果便是——那些设计不好的，或者编码不过关的，成为后期维护的工作所在。

无独有偶，晚上回公司培训，另外一个项目的PM跑过来问我：有人没？我说，要啥样的？他说：”懂JavaScript, HTML的。新招来的那些学生水平不行，得要个高水平的带一带。”我想，这样的人还好找。”还得懂Java，还有FreeMarker，最好有架构的思路。” 我呆了。这分明是找一个高级程序员嘛。这样的人，哪里都需要。BJUG的maillist上，每周都会有两到三封招聘的邮件。这是一个需要高水平程序员的时代，而不是需要蓝领的时代。

软件外包也许需要软件蓝领，我不清楚相关的运作机制，因此不便妄下定论。但是，作为一个喜爱编程的程序员，谁又甘心自己永远处于编码的位置呢？从Keso的blog上看的，几乎所有的web2.0项目都是一个always beta的项目；然而，我却可以说，几乎所有的大型的项目都是always beta的状态，这是当前客户多变的需求引起的。这种情况下，需要的软件开发者具备更丰富的技能和经验。