2009年4月5日星期日

如何面对单调重复的任务

转载时请注明出处:http://blog.csdn.net/absurd/

我们每个人都喜欢做有挑战的,能学到新东西的任务,而不愿意去那些单调重复的,没有什么新意的事情。然而常常事与愿违,在软件开发中,前者并非主流,而后者占了大多数。前者未必每次都能轮到你,而后者也总是要人完成的。

面对后者,你可以选择拒绝接受任务,但那会让人觉得你工作态度不好,以后好的差事可能就轮流不到你了;你可以选择走人,换个地方去做,但那也只能祷告,祈求上帝保佑你在别的地方遇到好任务。其实这都不是好的做法,相反我们应该接受并搞掂它,应该想法转换它们,完成任务但又不必自虐,从中还能学到东西。下面是我的一些经验:

1.
让电脑去做单调重复的工作。Unix文化有一个原则:宁愿花机器一分,不花程序员一秒。单调重复的工作多数都是有规律可循的,有规律可循就可以让电脑来做。

实例一:在早些年代,那时还没有听说autobuild这个概念,发布版本是一件痛苦事情。你要从CVS上取出源代码,编译各个版本((英文版,
日文版) x(大企业版, 小企业版,
试用版)),再制定各个版本的安装包,最后上传到FTP服务器上。如果整个过程顺利,四个小时差不多了,但事实是从来没有顺利过,结果通常要花费两三天才能完成。编译出错,手工拷贝文件出错,上传时放错目录如此等等。那位负责做版本的大姐还算有耐心,坚持做了大半年时间,后来这事没费多大劲就推到我头上了(呵,大家都认为我好欺负)。我接手后,第一件事是花了两天用bash写了个脚本,把整个过程自动化了,在接下来一个版本中进行了验证,并修正几个脚本里的问题,后来发布版本时几乎不用人干预了。

实例二:如果有人问我写得最多的程序是什么。我一定会回答是代码产生器,前前后后、大大小小至少写过十几个代码产生器,小的可能是用bash+awk来做的,也就上百行代码,大的用C/C++来写,动则数千行代码,最大的竟达8000多行C++代码。大部分代码产生器都为我节省了不少时间,或者至少把单调重复的事情变得有趣一点了,而且得到的代码也更稳定可靠。

2.
换种思路,看有没有捷径。有些事情单调重复,本来也是可以让电脑去做的,但是开发相应的工具要费更多的时间,得不偿失,这时不换一种思路,或许别有洞天。

实例一:曾接到一个任务,要求找出一个公共函数库里的所有全局变量。那个库是个大杂烩,里面什么东西都有,凌乱而庞大。时间期限是一周,时间比较充足,即使一个文件一个文件的去找,时间也来得及,但那太痛苦了。更麻烦的是这个库是变化的,可能刚刚完成任务,又有人加了一个全局变量,这样就很难拿到一个最新的结果。怎么呢,我想,编译器肯定是知道哪些是全局变量的,所以第一反应是拿一个开源的编译器修改一下,让编译器告诉我结果。修改编译器可能也要一周时间,但利用它随时可以得到最新结果。有没有更简便的办法呢?猜想VC输出的map文件或许有些帮助,打开map文件一看,果然如此。让VC编译该库并输出map文件,取出全局变量列表,搞掂了。从接受任务到完成任务前后不到一个小时。

实例二:前几天,同事拿一个第三方库,编译时发现那个库是用带硬件浮点数的toolchain编译,而我们的toolchain用的是软浮点数。尽管反汇编出来,没有发现浮点指令,但编译器就是不让链接该库。我们的方案是,反汇编它再重新编译它。但反汇编出来的格式与as的输入格式有些差异,要花不少时间去修改,修改之后发现还是编译不过去。最后,这个任务又落到我头上了。我想既然没有用浮点指令,编译器不让编译可能是因为一个标志引起的,于是花了点时间去研究ELF(linux下的可执行文件格式)文件格式。果然是文件头中一个标志引起的,写了个小程序为该库加上这个标志位,编译就通过了。

3.
换种心情,坦然接受。如果面对一项任务,你别无选择时,那就坦然接受它吧。然后想法说服自己,让自己有个好的心情,这样的任务总是要有人做才行。还可以告诉自己,一定要从中学到点东西,即使从中学不到技术,也要从中学会忍耐。

当我从QA组进入RD组时,我任务是把Win32程序移植到linux下。这个任务比较重要,但绝不是什么好任务,工作本身单调不说,别人还瞧不起。他们认为这都是很简单的,不用动脑子的体力活。同组的同事很多都走了,新来的同事也呆不了多久。但我坚持下去了,移植的同时去研究那些代码,去研究Win32和linux在编程上的差异,
一年之后我成了少数几个了解整个系统架构的人,编程能力大有提高,对软件的可移植性也有了较深的理解。

~~end~~
如何面对单调重复的任务

转载时请注明出处:http://blog.csdn.net/absurd/

我们每个人都喜欢做有挑战的,能学到新东西的任务,而不愿意去那些单调重复的,没有什么新意的事情。然而常常事与愿违,在软件开发中,前者并非主流,而后者占了大多数。前者未必每次都能轮到你,而后者也总是要人完成的。

面对后者,你可以选择拒绝接受任务,但那会让人觉得你工作态度不好,以后好的差事可能就轮流不到你了;你可以选择走人,换个地方去做,但那也只能祷告,祈求上帝保佑你在别的地方遇到好任务。其实这都不是好的做法,相反我们应该接受并搞掂它,应该想法转换它们,完成任务但又不必自虐,从中还能学到东西。下面是我的一些经验:

1.
让电脑去做单调重复的工作。Unix文化有一个原则:宁愿花机器一分,不花程序员一秒。单调重复的工作多数都是有规律可循的,有规律可循就可以让电脑来做。

实例一:在早些年代,那时还没有听说autobuild这个概念,发布版本是一件痛苦事情。你要从CVS上取出源代码,编译各个版本((英文版,
日文版) x(大企业版, 小企业版,
试用版)),再制定各个版本的安装包,最后上传到FTP服务器上。如果整个过程顺利,四个小时差不多了,但事实是从来没有顺利过,结果通常要花费两三天才能完成。编译出错,手工拷贝文件出错,上传时放错目录如此等等。那位负责做版本的大姐还算有耐心,坚持做了大半年时间,后来这事没费多大劲就推到我头上了(呵,大家都认为我好欺负)。我接手后,第一件事是花了两天用bash写了个脚本,把整个过程自动化了,在接下来一个版本中进行了验证,并修正几个脚本里的问题,后来发布版本时几乎不用人干预了。

实例二:如果有人问我写得最多的程序是什么。我一定会回答是代码产生器,前前后后、大大小小至少写过十几个代码产生器,小的可能是用bash+awk来做的,也就上百行代码,大的用C/C++来写,动则数千行代码,最大的竟达8000多行C++代码。大部分代码产生器都为我节省了不少时间,或者至少把单调重复的事情变得有趣一点了,而且得到的代码也更稳定可靠。

2.
换种思路,看有没有捷径。有些事情单调重复,本来也是可以让电脑去做的,但是开发相应的工具要费更多的时间,得不偿失,这时不换一种思路,或许别有洞天。

实例一:曾接到一个任务,要求找出一个公共函数库里的所有全局变量。那个库是个大杂烩,里面什么东西都有,凌乱而庞大。时间期限是一周,时间比较充足,即使一个文件一个文件的去找,时间也来得及,但那太痛苦了。更麻烦的是这个库是变化的,可能刚刚完成任务,又有人加了一个全局变量,这样就很难拿到一个最新的结果。怎么呢,我想,编译器肯定是知道哪些是全局变量的,所以第一反应是拿一个开源的编译器修改一下,让编译器告诉我结果。修改编译器可能也要一周时间,但利用它随时可以得到最新结果。有没有更简便的办法呢?猜想VC输出的map文件或许有些帮助,打开map文件一看,果然如此。让VC编译该库并输出map文件,取出全局变量列表,搞掂了。从接受任务到完成任务前后不到一个小时。

实例二:前几天,同事拿一个第三方库,编译时发现那个库是用带硬件浮点数的toolchain编译,而我们的toolchain用的是软浮点数。尽管反汇编出来,没有发现浮点指令,但编译器就是不让链接该库。我们的方案是,反汇编它再重新编译它。但反汇编出来的格式与as的输入格式有些差异,要花不少时间去修改,修改之后发现还是编译不过去。最后,这个任务又落到我头上了。我想既然没有用浮点指令,编译器不让编译可能是因为一个标志引起的,于是花了点时间去研究ELF(linux下的可执行文件格式)文件格式。果然是文件头中一个标志引起的,写了个小程序为该库加上这个标志位,编译就通过了。

3.
换种心情,坦然接受。如果面对一项任务,你别无选择时,那就坦然接受它吧。然后想法说服自己,让自己有个好的心情,这样的任务总是要有人做才行。还可以告诉自己,一定要从中学到点东西,即使从中学不到技术,也要从中学会忍耐。

当我从QA组进入RD组时,我任务是把Win32程序移植到linux下。这个任务比较重要,但绝不是什么好任务,工作本身单调不说,别人还瞧不起。他们认为这都是很简单的,不用动脑子的体力活。同组的同事很多都走了,新来的同事也呆不了多久。但我坚持下去了,移植的同时去研究那些代码,去研究Win32和linux在编程上的差异,
一年之后我成了少数几个了解整个系统架构的人,编程能力大有提高,对软件的可移植性也有了较深的理解。

~~end~~

没有评论: