呃, 不要误会,这不是我给出的建议,我暂时还算不上“优秀”的软件技术人员。
是这样,这几天,从美国那边过来几个比较有经验的同事,因为相对来讲,中国这边的团队比较年轻,因此安排了一个“Open Forum” 的讨论会,让他们与中国的同事分享一下成长经验。他们一个是中国人,清华硕士毕业后去了美国,有10年的工作经验了;一个是美国人,有20年的工作经验。
其间有一个人问了个问题:“要成为一个比较资深、优秀的技术人员,你觉得什么是最重要的?” 这两位同学给出了看法基本一致,概括起来就以下两点:
- Don't treat the code you not own as blackbox
每个人写代码,其所涉及的方面不仅仅是你所”负责“的那些模块,你往往需要从整个系统的层面来考虑问题:我所依赖的那些模块是怎么工作的,怎样正确的使用他们?怎样高效的使用他们? 以及谁依赖于我,我的改动会对后续模块产生什么样的影响,等等。听起来蛮简单的一个道理,但要做到其实并不那么容易。尤其在一个有几百的模块的大系统中。很多人的工作方式是直接发封信去问那个模块的owner或者expert,的确很"高效",但是如果你需要长期在这个系统中工作,你需要经常接触这些模块,那么最“高效”方式恐怕是你好好研究一下这些模块,搞清楚其组成与工作方式,所谓磨刀不误砍柴工。不要认为这与我没有直接关系就可以不管,将其看成一个"blackbox",其实在程序员面前,只要你愿意,什么都是“whitebox”,任何程序都没有什么magic,只是以最简单的规则与逻辑组合起来的东西而已。
而最关键的是,只有这样,你才会进步,你才会渐渐成为某一领域的专家。不然,正如你所注意到的那样,有些人在干了N年之后,问他整个系统是怎么工作的,他都说不出个子丑寅卯来。
- Don't assume, just confirm
假设害死人,害死你自己,或者害死别人。举两个例子:
1. 在调试程序的时候,我们经常会做了自以为是的假设:注册表应该没问题吧、DLL数据的初始化也不会出错的,那么会是消息传递出错了吗? 好像也不会~~~。 我们一直在思考,却不去求证,而这所谓的思考,就是假设,然后在自己错误的假设下愈行愈远。这是害死自己。
2. 作为某一领域的权威,人家发信问你个问题,你不太确定,于是回道“我觉得”应该是这样,或者应该是那样,然后人家照你“觉得”的方式试了一天,不行,然后和你说不灵,然后你再“觉得”一下,继而又浪费人间一天时间。这是害死别人。
其实为什么要做这些假设呢,你完全可以停下来,花个5分钟或者10分钟去确认一下,不就什么都ok了?一步一步踏踏实实往前走,才是真正的往前走,依靠在那些浮云般的假设,你始终都在摇晃。而且,正是这一次次的确认,才构成了你真正的经验,不然,若干年后,你有的只有自己的假设和别人告诉你的结论。
其实做不到这两点的,关键还是懒:懒得去研究学习,懒得去确认。所以,要成为优秀的技术人员,归根结底还是勤奋啊!
posted on 2010-06-09 16:53
楚天清秋 阅读(93)
评论(0) 编辑 收藏 引用