昨日是十一黄金周之后的第一个工作日，也就是在昨天看到网上消息说，国家相关部门正在考虑调整所谓的黄金周休假方案。已经记不清楚黄金周这样的休假制度施行了多少个春秋了，隐约记得刚刚出台黄金周制度的时候，当时还是很兴奋的，因为毕竟是当时是学生，对于一下连休7天甚至更多感到很是兴奋，不过现在面对黄金周我实在是兴奋不起来，因为深深感到黄金周给自己和周围的人带来的’痛苦’。

中国在未改革公民休假制度之前，那时国人还是休小礼拜，后来改成大小礼拜轮休，最后改成目前的8小时工作制，每周都是大礼拜。即使这样中国人的平均工作时数在世界范围来讲还是蛮高的，人们的休息时间较少。国家最初出台黄金周政策我想一是考虑到拉动经济快速增长；二是同时给国人一段较长时间的放松时间。前者的目的达到了，黄金周的经济拉动作用不可小视，但是其弊端也许是当初决策者估计不足的。而第
二个目的真的达到了么？值得商榷。

黄金周是给大家回家探亲准备了充足的时间，但是大家回家真的是那么容易么？
现在人们一提到黄金周，想的也许不是如何休息，而是如何买车票、船票和飞机票。毕竟在拥有13亿人口的泱泱大国，国民集中一个时段迁移给交通运输业带来的压力之大可想而知。本来想做飞机的，却买不到机票，只能做长途火车；想做硬卧的，却只能买到坐票；那些买不到火车票的，只能去买高价且不舒适的汽车票，更有甚者还有那些根本买不到合适票的人。同样这样的情况助长了’黄牛党’一族的快速增长。一票难求的情况估计只要黄金周的存在就难以根治。这里还要重申的是：中国不仅仅只有一个十一黄金周，还有春节黄金周、五一黄金周。三个黄金周，三次人口大迁移。辛苦的，或者说痛苦的是老百姓啊。

黄金周是给大家出游准备了充足的时间，但是大家都玩好了么？
记得去年黄金周过后，一幅照片让我震惊，在天安门前的金水桥上满满登登的都是人，如果不是前人将金水桥造的结实，我还真是担心这座桥会被压踏。毕竟前人不会想到今天会有如此多的人站在这座桥上。今年黄金周之后大家在电视、报纸、网络媒体上看到的也是各个景区人满为患、票价上涨、服务质量急剧下降的报导，故宫游览人数超出最大接待量的2倍，八达岭长城又’下了饺子’，九寨沟更是采用了限时入景区的策
略。尽管国家加大了景点和文物的保护力度，但是你不得不承认在如此大的游览人数面前这些保护规定显得那么脆弱，这不是治本的方法。

黄金周出台有其历史原因，但随着中国经济的发展，人们发现其带来的弊端日益严重，到了急需改革的阶段了。我个人希望取消五一、十一这两个黄金周，但是要延长春节的假期，毕竟春节这个黄金周是无论如何不该取消的。还有一条就是总的休假时间是不能减少的，如果新方案不能保证这一点，那就是倒退了。

毕业后就一直从事于服务器端程序的开发，主要客户是中国移动，大家知道移动的产品都是电信级的，稍出差错后果都是严重的，所以在我们平时的工作中除了研发之外，还有的就是对我们卖给移动的产品的维护性工作，而这种维护性工作要求就是要"迅速解决现场的问题"。这几个月维护工作占据了我很大一部分精力，说实话，有些烦了，但是从另外一个角度来看，也说明了我们的产品在维护性方面做的不够好，否则移动的工作人员或当地的技术支持人员通过手册或者查看系统日志的方式就可以解决问题的。这让我反思。

一般来说，我们的产品在交付时都是有详尽的用户手册的，现场人员可以根据维护手册来查找问题所在。另外维护工作也是分层次的，在运行我们产品的各省移动公司都有我们的当地技术支持人员，而移动自己的网管人员在多年的维护过程中也逐渐的积累了丰富的问题解决经验。一般问题发生后，移动的人员都会试着自己来尝试解决，当其无法解决时，会将问题告诉当地的技术支持人员，只有在技术支持人员也解决不了问题的时候，问题才会反馈给我们研发人员，而研发人员就成为了系统的最后一道保护伞了。移动人员的素质我们自然控制不了，我方技术人员我们会尽可能的通过培训和讲解的方式传授解决问题的办法，并通过他们自己在维护过程中积累经验，但是一旦问题提交给研发人员，我们就需要在远程以最快的时间将问题解决。

研发人员一般来说对业务熟悉，对功能是如何实现也有把握，但是一个系统往往是很庞大的，很可能是经过"几代人"前离后继"(前人离职了，后人来继承)完成的，所以到最后很可能整个产品组内没有一个人对整个系统的每个角落都了如指掌的，这时问题就出现了。

对于研发人员来说，他们最擅长的就是通过问题现象去到代码里分析，现场产品因为在运行，一般来说我们不可能去用调试工具直接调试现场运行的程序的。而问题的现象一般是通过系统日志体现出来的；也就是说在研发人员解决问题这层，系统的运行日志对解决问题起着至关重要的作用。这样一来系统日志设计的好坏直接会影响到你解决问题的效率和质量。

而通过日志定位问题所在的代码位置一般有如下几个现象：

[现象一]  当你用某一个错误日志去search in project的时候，居然发现：
if (condition1 | condition2 | condition3)
      你查询的日志输出;
输出该日志的条件是多个或的关系，而且每个condition也许是一个复杂的函数调用，这会大大延长你跟踪问题的时间；

解决方法：
a) 尽量减少condition1 | condition2 | condition3的使用；
b) 对于复杂和关键地方的处理，给出"点睛"的注释；

[现象二] 当你用某一个错误日志去search in project的时候，居然发现：
Project中存在不止一条这样的错误日志，其位置可能分布在Project的不同源文件中的不同位置。这同样会大大延长你跟踪问题的时间和难度。

解决方法：
我们套用"幸福的家庭往往是相同的,不幸的家庭各有各的不幸"来说明：成功的日志往往格式相同，失败的日志各有各的特征。如果每条错误日志的特点都不相同，那么当我们search的时候，就可以一次定位问题所在了。

[现象三] 当你用某一个错误日志去search in project的时候，居然发现：
该日志是在一个宏的定义中输出的，而该宏散布在Project的各个角落。

解决方法：
不要在宏(广泛使用的宏)中做任何日志输出。

当然上述的某些解决方法可能与代码的可读性或者精炼性有悖，这就要看你是如何抉择的了，根据具体情况三思而后行。

另外对于查找问题而言，关键而详尽的注释会给研发人员带来很大帮助，否则他就很可能陷入复杂的业务逻辑中，长时间不能自拔了。

以上一点私人见解，仅供参考。