人们可能会比较自然地去关注一些出彩的地方，比如说某人一场比赛做了七八道题，或者最后几分钟对了一道题（特别是又拿到冠军的），并称之为英雄。我觉得，光做到这点，充其量叫做野人（比常人力气大一点）。要成为英雄，还必须用脑子。我认为，英雄善于以用自己的智慧和实力。面对实力弱于自己的对手时，要将对手玩弄于股掌之间，不给别人任何机会；面对实力相当或高于自己的对手时，要懂得迂回前进，争取最大的取胜希望。或者，借用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的情况。但是，只要你坚持不懈地去做，不动摇自己的信念，最后的成绩一定不会差。记住，你遇到过的困难，你的对手也会遇到的。
扫一扫
520
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
