人们可能会比较自然地去关注一些出彩的地方,比如说某人一场比赛做了七八道题,或者最后几分钟对了一道题(特别是又拿到冠军的),并称之为英雄。我觉得,光做到这点,充其量叫做野人(比常人力气大一点)。要成为英雄,还必须用脑子。我认为,英雄善于以用自己的智慧和实力。面对实力弱于自己的对手时,要将对手玩弄于股掌之间,不给别人任何机会;面对实力相当或高于自己的对手时,要懂得迂回前进,争取最大的取胜希望。或者,借用yini的话,就是do more with less。
Comars曾经给代码能力作过一个比较准确的定义。2004年暑假时,Comars曾经说过:他认为150行以内的题目,他的1Y率非常高,并且保持稳定;而当代码长度超过150行以后,1Y率就开始急速下降了。如果我们画出一条1Y率的曲线的话,150行就是一个转折点。我们不妨认为,150行就是Comars当时的代码能力。一年以后,经过努力,Comars把代码能力提高到了250行。不过,这已经是后话了。
二、如何提高代码能力
我一直觉得写程序和写文章是一个对很好的类比。
写文章需要先从宏观入手,构思文章的结构。写程序同样需要。一个好的结构,就是一个好的开始。一个好的开始,是成功的一半。
一篇好的文章需要各种句式和词藻的合理组合。体现到写程序上来,就是一些单句以及三五行的小结构的熟练使用。这些都是需要平时总结和积累的。
但凡文章写得好的人,一定看过很多别人写的文章。同样的道理,多看别人的程序,用心地去看,也可以提高自己的代码能力。
我鼓励队员去看别人写的程序,特别是像Comars这样的选手写的程序。从优秀的程序中,我们可以体会别人良好的程序结构,同时也可以学到很多写程序的技巧——三五行的小技巧。在和Comars做队友的两年时间里,我通过看Comars的程序,学会了很多小技巧。逐渐地,我觉得我写的某些程序已经和Comars有点相像了。
那么,如果身边没有Comars这样优秀的选手可以借鉴,该怎么办呢?其实没关系。任何一个程序都是可以看的。一个程序,就算写得再差,总还会有一两个闪光点,要想办法把它们找出来。另外,程序里写得不好的地方,也要一一找出来。
读程序,从某种角度来看,就像读史。好的历史是用来借鉴的;不好的历史则应该引以为戒。读程序也是一样,择其善者而从之,其不善者而改之。
三、谨慎地对待STL和SCL
STL - Standard Template Library。在ICPC的选手中,STL是相当受欢迎的。的确,如果STL用得好,程序可以精简很多。既提高了编程的速度,也提高了编程的准确性。
SCL - Standard Code Library,就是标准程序库。对很多选手来说,SCL可是命根子啊 :)
我觉得STL和SCL都不是坏东西,但是需要谨慎地使用。
我向来不主张队员一进队就开始用STL(虽然这种现象普遍存在 :()。我认为,STL的作用是锦上添花,而不是雪中送炭。比方说,一个heap写得很熟练的队员,我觉得他可以偷偷懒,用一下STL。但是,那些不太会写heap的队员,就不应该用STL里的heap。因为,他们真正应该做的是掌握写heap的能力——这才是最本质的代码能力。
学会用STL是件很爽的事情。但是须知有所得必有所失。如果过早地接触STL,会让你失去很多锻炼代码能力的机会。
至于SCL,我的主张是尽量不用。
不可否认,队里确实有一些人SCL用得很好。但是,我至今仍然没有见过一个SCL用得很好,同时有拥有很强的代码能力的人。同样是有所得必有所失,你平时习惯了去抄程序,必然少了很多自己构思程序的机会,从而影响代码能力的提高。
当然,我也不是完全反对去使用SCL,偶尔用一下也是可以的,例如在比赛中。但是,需要注意的是,一定要用自己整理的SCL。我见过有人拿着一本别人整理的SCL,虽然内容很齐整,但是我没见他用对过。因为这本SCL不是他整理的,他自己都不知道每个程序在使用的时候应该注意些什么,于是一用就错。
后记:其实代码能力这个话题让Comars来讲可能更适合一点,因为他更有心得。不过他现在忙于杀鸡 :)
FAQ ceshi 2008-04-16 22:33:17.0
整理了13个以前遇到的问题,如果想起什么新的问题的话,再慢慢更新。
(注: 这其中有很多问题和回答都是从别人那里记下来,或者根本就是别人整理的)
1. 就快要比赛了,我们队还存在很多问题,怎么办?
正视你们的优势和劣势,承认它们的存在。
借用yini的话,比赛就是一个“do more with less”的过程。你要清楚自己的more和less。无论自己是more还是less,我们就是要去do more。
2. 比赛前应该想什么?
有人说,比赛前应该完全不想比赛的事情,放松自己的心情。我觉得这并不是很妥当。
在我看来,比赛前就应该去想比赛本身,把全部精力放在比赛上。可是,这难道不会影响心态吗?我认为不会。所有影响比赛心态的事都不属于比赛本身,例如排名、胜负,都是比赛以外的事。
3. 比赛中,领先了怎么办?落后了怎么办?和对手咬得很紧怎么办?出现问题怎么办?
比赛中有很多种状态,领先、落后、平分秋色、稳定、混乱……但是,归根结底,这都是一些状态。
对于自己所处的状态,我们要以局外人的眼光来看待,这样才能作出理性的判断。
作为局内人,我们需要知道,已经发生的事不可改变,我们可以做的就是在剩下的时间中do more。
注意,do more不等于“拼命”,还是要理性地去分析自己究竟还能做多好。
4. 自己或者队友实力太弱,怎么办?
很多人都会钦佩实力强的人,鄙视实力弱的人。但是,最起码在一支队里,这样的事情不应该发生。
我们要清楚每个队员的强弱,用纯理性的眼光去看待这些问题。你可以为一个队员的不足而着急,但是决不可以为此而埋怨他/她(或许完全做到这一点是不可能的)。
实际上,无论是谁,放在队里一定是有用的。再不济,读题的事情总可以做,还可以模拟sample、出一些测试数据……不要认为这些事情是低级的。它们和想算法、敲题一样,都是对队里的贡献。你可以想想,有谁可以跳过读题,直接去想算法、敲程序的?
5. 如何面对自己的队友?
如果可以把一支队看成一个整体的话,那么为什么不把它比作一个人呢?这样一来,每个队员就相当于身体的一部分。似乎没有哪个人的左右手是会分彼此的。如果这样去想(注意,是要这样去想,而不是仅仅懂得这个道理),我觉得你已经不需要再讨论这个问题了。
6. 对手太强了,怎么办?
如果你完全不是他们的对手,那为什么又要称他们为“对手”呢?
前面也提到了,比赛就是一个“do more with less”的过程。即便你们是全场最差的队,即便你们根本没有实力去争取哪怕是一个倒数第二的名次,你们同样可以do more。
可能你99%会输掉这场比赛,但是请你正视这个概率,勇敢地去面对可能到来的失败。
. 我们的进步速度总是不如预期,怎么办?
没有关系。每个人的预期总会或多或少的带点理想的色彩,所以实际的效果一般来说总是不如预期的。有时,甚至会出现只有预期的1/3到1/2的情况。但是,只要你坚持不懈地去做,不动摇自己的信念,最后的成绩一定不会差。记住,你遇到过的困难,你的对手也会遇到的。
一、如何定义代码能力
Comars曾经给代码能力作过一个比较准确的定义。2004年暑假时,Comars曾经说过:他认为150行以内的题目,他的1Y率非常高,并且保持稳定;而当代码长度超过150行以后,1Y率就开始急速下降了。如果我们画出一条1Y率的曲线的话,150行就是一个转折点。我们不妨认为,150行就是Comars当时的代码能力。一年以后,经过努力,Comars把代码能力提高到了250行。不过,这已经是后话了。
二、如何提高代码能力
我一直觉得写程序和写文章是一个对很好的类比。
写文章需要先从宏观入手,构思文章的结构。写程序同样需要。一个好的结构,就是一个好的开始。一个好的开始,是成功的一半。
一篇好的文章需要各种句式和词藻的合理组合。体现到写程序上来,就是一些单句以及三五行的小结构的熟练使用。这些都是需要平时总结和积累的。
但凡文章写得好的人,一定看过很多别人写的文章。同样的道理,多看别人的程序,用心地去看,也可以提高自己的代码能力。
我鼓励队员去看别人写的程序,特别是像Comars这样的选手写的程序。从优秀的程序中,我们可以体会别人良好的程序结构,同时也可以学到很多写程序的技巧——三五行的小技巧。在和Comars做队友的两年时间里,我通过看Comars的程序,学会了很多小技巧。逐渐地,我觉得我写的某些程序已经和Comars有点相像了。
那么,如果身边没有Comars这样优秀的选手可以借鉴,该怎么办呢?其实没关系。任何一个程序都是可以看的。一个程序,就算写得再差,总还会有一两个闪光点,要想办法把它们找出来。另外,程序里写得不好的地方,也要一一找出来。
读程序,从某种角度来看,就像读史。好的历史是用来借鉴的;不好的历史则应该引以为戒。读程序也是一样,择其善者而从之,其不善者而改之。
三、谨慎地对待STL和SCL
STL - Standard Template Library。在ICPC的选手中,STL是相当受欢迎的。的确,如果STL用得好,程序可以精简很多。既提高了编程的速度,也提高了编程的准确性。
SCL - Standard Code Library,就是标准程序库。对很多选手来说,SCL可是命根子啊 :)
我觉得STL和SCL都不是坏东西,但是需要谨慎地使用。
我向来不主张队员一进队就开始用STL(虽然这种现象普遍存在 :()。我认为,STL的作用是锦上添花,而不是雪中送炭。比方说,一个heap写得很熟练的队员,我觉得他可以偷偷懒,用一下STL。但是,那些不太会写heap的队员,就不应该用STL里的heap。因为,他们真正应该做的是掌握写heap的能力——这才是最本质的代码能力。
学会用STL是件很爽的事情。但是须知有所得必有所失。如果过早地接触STL,会让你失去很多锻炼代码能力的机会。
至于SCL,我的主张是尽量不用。
不可否认,队里确实有一些人SCL用得很好。但是,我至今仍然没有见过一个SCL用得很好,同时有拥有很强的代码能力的人。同样是有所得必有所失,你平时习惯了去抄程序,必然少了很多自己构思程序的机会,从而影响代码能力的提高。
当然,我也不是完全反对去使用SCL,偶尔用一下也是可以的,例如在比赛中。但是,需要注意的是,一定要用自己整理的SCL。我见过有人拿着一本别人整理的SCL,虽然内容很齐整,但是我没见他用对过。因为这本SCL不是他整理的,他自己都不知道每个程序在使用的时候应该注意些什么,于是一用就错。
后记:其实代码能力这个话题让Comars来讲可能更适合一点,因为他更有心得。不过他现在忙于杀鸡 :)
FAQ ceshi 2008-04-16 22:33:17.0
整理了13个以前遇到的问题,如果想起什么新的问题的话,再慢慢更新。
(注: 这其中有很多问题和回答都是从别人那里记下来,或者根本就是别人整理的)
1. 就快要比赛了,我们队还存在很多问题,怎么办?
正视你们的优势和劣势,承认它们的存在。
借用yini的话,比赛就是一个“do more with less”的过程。你要清楚自己的more和less。无论自己是more还是less,我们就是要去do more。
2. 比赛前应该想什么?
有人说,比赛前应该完全不想比赛的事情,放松自己的心情。我觉得这并不是很妥当。
在我看来,比赛前就应该去想比赛本身,把全部精力放在比赛上。可是,这难道不会影响心态吗?我认为不会。所有影响比赛心态的事都不属于比赛本身,例如排名、胜负,都是比赛以外的事。
3. 比赛中,领先了怎么办?落后了怎么办?和对手咬得很紧怎么办?出现问题怎么办?
比赛中有很多种状态,领先、落后、平分秋色、稳定、混乱……但是,归根结底,这都是一些状态。
对于自己所处的状态,我们要以局外人的眼光来看待,这样才能作出理性的判断。
作为局内人,我们需要知道,已经发生的事不可改变,我们可以做的就是在剩下的时间中do more。
注意,do more不等于“拼命”,还是要理性地去分析自己究竟还能做多好。
4. 自己或者队友实力太弱,怎么办?
很多人都会钦佩实力强的人,鄙视实力弱的人。但是,最起码在一支队里,这样的事情不应该发生。
我们要清楚每个队员的强弱,用纯理性的眼光去看待这些问题。你可以为一个队员的不足而着急,但是决不可以为此而埋怨他/她(或许完全做到这一点是不可能的)。
实际上,无论是谁,放在队里一定是有用的。再不济,读题的事情总可以做,还可以模拟sample、出一些测试数据……不要认为这些事情是低级的。它们和想算法、敲题一样,都是对队里的贡献。你可以想想,有谁可以跳过读题,直接去想算法、敲程序的?
5. 如何面对自己的队友?
如果可以把一支队看成一个整体的话,那么为什么不把它比作一个人呢?这样一来,每个队员就相当于身体的一部分。似乎没有哪个人的左右手是会分彼此的。如果这样去想(注意,是要这样去想,而不是仅仅懂得这个道理),我觉得你已经不需要再讨论这个问题了。
6. 对手太强了,怎么办?
如果你完全不是他们的对手,那为什么又要称他们为“对手”呢?
前面也提到了,比赛就是一个“do more with less”的过程。即便你们是全场最差的队,即便你们根本没有实力去争取哪怕是一个倒数第二的名次,你们同样可以do more。
可能你99%会输掉这场比赛,但是请你正视这个概率,勇敢地去面对可能到来的失败。
. 我们的进步速度总是不如预期,怎么办?
没有关系。每个人的预期总会或多或少的带点理想的色彩,所以实际的效果一般来说总是不如预期的。有时,甚至会出现只有预期的1/3到1/2的情况。但是,只要你坚持不懈地去做,不动摇自己的信念,最后的成绩一定不会差。记住,你遇到过的困难,你的对手也会遇到的。