Archive for May, 2009

怎样成为一个好程序员(2)

May 7, 2009

前面已经说过,做好程序员或是做其他任何的职业,最重要的就是要做好平衡。关于这个再啰嗦几句。世间之事真的都是需要平衡。比如找对象,古人要讲究门当户对,跟平衡是一个意思。比如吃饭,把自己吃到撑死和饿出胃病来之间也要做到平衡。与人发生争执时恨不得拿刀子捅死对方与一味的忍气吞声之前也要平衡。

这么想的话真的是觉得中国的古人太了不起了,几千年前就提出了中庸这个词。了不起。要平衡盖因为凡事都有利弊,越不平衡越走极端则越容易产生弊大于利的情况。

又因为人一出生就注定要死。人生苦短,而我们想要做到的事情、想要学会的东西没有止境,不懂得平衡,不懂得选择,不知道取舍,是不行的。(西方人也很牛,说,Life is short, but to learn a profession (an art) takes a long time)

当然,我们必须承认,不一样的人,平衡对他的标准也是不一样的。

好了,说完平衡的重要性,我们说说怎样才能达到平衡吧。

让人很遗憾的是,一般来说,只有时间,大把大把的时间,才能让人懂得平衡。时间是最好的老师嘛。古人说得好,千里之行,始于足下。罗马不是一天建成的。

那么,就真没有捷径可走?

也不是。答案还是在古人的话里面找。子曰:吾一日三省吾身。

就是说,改变世界要从改变自己做起。认识世界要从认识自己做起。

我的理解就是,要不停地测量自己的行为的效果。每天都总结一下,自己跟昨天相比,是不是更平衡、成熟、进步?如果有,那么能不能更上一楼?如果没有,那么是在哪里出了问题?不停的改进。别人的好方法要学习,但是如果他的方法不适合你,那照搬照抄是不行的。邓小平就很伟大,提出了要搞中国特色的资本主义。哦,错了,是中国特色的社会主义。都没关系啦,反正不管黑猫白猫,能抓老鼠就是好猫。

这就是测量的重要性。不测量你不知道平衡的。事实上测量和平衡是一个概念。天平是一种测量的仪器,它能告诉你左边和右边的物体是否重量相等(从而达到平衡)。

古人说,两利相权取其重,两害相权取其轻,就很好的把平衡和测量统一起来了。取,有取就有舍,说的就是平衡,轻、重,说的就是测量。

有一本书,叫《成功人士的七个习惯》,是本好书。可以看看。

但作为一个程序员,还有一本书,《高效编辑器作用者的七个习惯》,更要看看。里面对于平衡,有非常精僻的见解(但不是直接的)。作者说,现在任何一个(好)编辑器,都有好多好多的好功能。有些人想通过看书学会所有的功能,不要!

正确的做法是,先有选择的学会几个基本的,最重要的功能。然后就开始使用这个编辑器。期间注意不断观察(测量)自己,是不是在做很没有效率的事情。比如,不停地按方向键、翻页键,以把光标移到你想要找的地方,就是一个没效率的表现。这时候,就去找书看,学会更有效的做法,再开始下一个使用、测量、改进的循环。

问题又来了,前提是你怎么才知道什么是没有效率,什么是有效率的呢?

Advertisements

怎样成为一个好程序员

May 5, 2009

我总梦想有一天自己成为一个伟大的程序员,现在这个梦想和现实的距离还很遥远。但是如果要问怎样做一个好程序员的话,我很有一些看法…

一,最重要的一点,要懂得平衡。

说这是最重要的一点也不为过,因为程序员的生命中要平衡的东西实在是太多了。我隐隐觉得,是不是对其他职业的人们来说,这也是最重要的呢?比如说,搞革命工作的人,有一个很重要的理论指导文件,毛泽东写的《矛盾论》,其实就是要做到主要矛盾、次要矛盾之间的区分、平衡,要懂得这两者在特殊条件下的相互转变,等等等等。

举一个简单的例子,程序员都要看书学习,关于看书的平衡,就是一门很大的学问。书要看多少本?看多快?哪些书可以看仔细一点,哪些书翻翻就行?这本书我现在翻翻,将来仔细看,还是现在仔细看,将来再拿出来翻翻?

又比如,现在设计模式很流行,那么,看完GOF的那本设计模式以后,关于怎么使用这么多的模式也有一个很重要的平衡问题。每种模式什么时候该用,什么时候不能用?这个其实在那本经典的著作中已经讲得很清楚,对每一种模式的优缺点理解透彻,尤其是缺点,那么做到平衡就不难了。

新程序员容易犯的一个毛病,叫做过犹不及。学完面向对象以后,什么程序都用类,不仅如此,还要用上继承。学了设计模式,就在哪儿都来一个工厂,再来一个抽象工厂,什么Singleton。就象大腕里的那个神经病说的,什么玩意儿时髦就整什么。这就是没有彻底理解这些技术造成的。搞不懂什么时候该用,什么时候不该用。

如果实在一时半会儿不能学会怎么平衡的话,有一个很好的办法,叫做克制。尽量不用一些复杂的新鲜玩意儿,就准没错。

这么说不过瘾,下面列一个表,看看有哪些东西要平衡

1. 怎么给变量起名?用匈牙利命名法不?szFooBar?用骆驼式?fooBar?下划线式?foo_bar?

2. 变量名取多长合适?5个字符,10个字符?最长可以忍受多长?全局变量给什么标准,局部变量呢

3. if while for 语句后面的{ 另起一行还是不另起一行?

4. 一段代码没用了,是删掉,还是注释掉?为什么?你怕什么?

5. 函数名前加不加注释?如果加,写不写你的名字、日期、?

6. 写不写文档?用word写,还是.txt?

7. 画不画UML?用visio,还是白板加相机?

8. 用不用设计模式?用其精髓,还是皮毛?

9. 用不用TDD?精髓,还是皮毛?

10. 什么是精髓,什么是皮毛?

11. 看书的时候要囫囵吞枣,还是全盘接受,还是批判性的阅读。要站得比作者高,他说什么想想对不对,还是比他低,他说什么就是什么。

12. 读别人的代码,要读得多透?哪一块要读透,哪些不用?

13. 自己写代码,写之前想多久?什么都不想,上来就写?想了半天,什么也不写?

14. 写多少代码之后,编译一下,看看出了什么错误?写两行就编译一次?全写完再编译?还是写了几个函数之后?

15. 写多少个函数能解决问题?只有一个main? 用一百个函数来打印hello world?

16. 做出一个决定以后能不能再改?不能轻易改的决定,花多少心思做?随便改的决定,花多少?

17. 写代码最重要的是什么,执行效率?用汇编?内存占用要少?变量名重用?(这一条不需要平衡。因为标准只有一个,就是要易懂。只要代码可理解,即使它的逻辑是错的也无所谓。如果代码不可理解,那么,你根本不知道逻辑是对是错,为什么对为什么错,执行快还是慢,为什么快,为什么慢。所以,下一次,我会聊一下可理解的代码对一个好程序员的重要性)。

今晚就写这些了。