标签 程序员 下的文章

不是不奉献

中午在CSDN上看到一则新闻,说的是"中国开源社区热潮背后 缺少奉献型人才",看完后有些感触,也就想在这里说两句。

谈到为开源项目奉献,我认为首先要具备三个条件:
1、投身开源的热情,即有奉献的意愿;
2、参与开源的技术能力,这里是指能参与到某开源项目核心或主力开发行列的能力;当然你要说参与开源的形式是多样的。如提交一个bug,辅助做一个模块测试同样也是为开源奉献,这里我也不否定,见仁见智。
3、时间与精力,无后顾之忧或者说生存之忧患。

我认为在中国绝不缺乏符合前两个条件的程序员,而且应该为数不少。中国程序员是愿意奉献的,也是有能力奉献的,但是中国程序员太累了,大多数没有足够的时间精力去奉献。

在与从美国出差回来的同事闲谈中得知了美国程序员的轻松生活。所谓"轻松"无非不愁钱,工作压力小,可自由支配时间多。而这些恰恰是中国程序员所缺少的。大家都知道目前中国软件业发展的确很快,但是不可否认的是中国软件公司多处于软件产业链的低端,技术含量不高,但劳动强度却很大。比如给日本人做外包,日本人是很矫情和苛刻的,当然日本人的质量意识值得我们学习,不过这是题外话了。给日本人做软
件的一个特点就是要写大量的文档,一个文档不到10页,却要反复的改来改去,改到中国项目经理满意,改到日本人满意。很多人没日没夜的加班其实都做了些什么呢?其实很可能就是在那不到10页的文档上改来改去。我没参与过外包项目,更没有参与过日本外包项目,但是以上都是身边同事的亲身经历,这里我是不敢妄言的。大好的青春时光就这样在没有任何激情和创造力的工作中虚度了。这不能怪我们的程序员,因为我们需要赚钱吃饭。

中国软件公司的产品中行业产品或项目居多。做过行业软件的人一定知道:做行业软件,一定要懂业务,只有成为行业专家才能有发展。可怜这些程序员了,整天忙于如何熟悉业务,如何满足客户变化多端的需求。做电信或者金融行业软件的人晚上还要配合客户搞升级,解决问题,这样的程序员能不累么。中国程序员虽然累,但是收入却不高,对比蒸蒸日上的房价,物价,利率,曾经的中高收入阶层的程序员也无语了。从学校步入社会后才知道曾经的买房、买车的梦想实现起来也不是那么容易。这样的情况下:程序员也就开始功利化了。做了2年技术羽翼丰满些后,转向管理的,转向销售的,转向行业专家的,转向技术支持的,转向客服的,考公务员以得到轻松生活的,甚至是转行的,都是大有人在的。这也不能怪我们的程序员,因为程序员的父母、老婆、孩子还得吃饭治病啊。

以上是从一个热爱技术的程序员的角度去分析的,也许这就是中国程序员的众生相。不过每个人有自己的生活方式,大家也不必为了缺少对开源的奉献而感到愧疚,用新名词说:这就是国情,不是我们一己之力可以改变的了的。

与欧美程序员相比,中国程序员还是很年轻的。在欧美你会见到年龄在40-50岁之间的程序员,而中国这样的程序员早已不写程序而成为管理者了。在公司办公室的座位上环顾四周,你会发现周围都是刚毕业的年轻人,他们有激情,有实力,这说明中国程序员还是很有潜力的。我相信在将来会有越来越多的中国程序员活跃在世界开源软件领域,为之默默奉献。

附:我知道的中国程序员发起的有影响的开源项目:XRuby, JFox

浅谈如何编码使程序更易维护

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats