哦~~~~~~~~~
反对的总是有的,而且都会有很好的理由。——如果不是这样,人家也就不反对了。
哈哈。
1. 512字节是很少很少,但不要忘记,我们只计算“有效字节数”,那么,空格或者注释
一类是不算数的。况且,我们现在正在公开征集意见,看是否有必要增加字节数。——
否则,这个竞赛就成了“有闲/有钱人的游戏”了。
2. 国外的确有组织过此类的竞赛,好象比较有名的有两个,一个是4K程序设计大赛。另一
个是Waze程序设计大赛。——人家名字叫不叫这个我不记得。但大意是这样的:前者要求
程序的目标文件不大于4K;后者要求目标文件不大于64K,而且参加者必须是Waze组织成员,
如0Day。但是,我不会认为有人做过我们就不必要再做,人家能用这种方法来锻炼编程实力,
我们怎么就不可以?——我常说,一件没有坏处的事,不论它是否有好处,总之是可以干的
了。哈哈。
3. 我们公司有个程序员,现在是项目经理。他原本是做图形程序开发的,我看过它的一个工
具的代码,OHHHH,我当时差点没有昏倒。——它的代码做得就象方块,每一行几乎都一个样
子,似乎都在不断重复。但是,这些代码的运行效率居然比我见到的所有图形开发包都快!
所以,我绝对同意“一个真正优秀的方案可能代码很多,很精巧,也很复杂,但绝对在效率、速度上非
普通方案可比”、“大道深处又至简,一个非常出色的方案往往可以化复杂为简单,化腐朽为神奇,
达到代码即方案,代码即解释,恍恍乎游刃有余”和“最出色的代码不是代码本身,而是代码体现
出来的出神入化的思维和境界。到达这个境界,代码多少已经不再重要了”这样的观点。
4. 代码的规范性我深有体会。我们公司现在正在展开的也是一个叫“代码格式化规范”的动作。
但我要说的是一个小故事,我的一个组员总是在说我的代码他看不懂,这看不懂那也看不懂;而另
一个组员呢,将我一个写了两年的项目那个去看了一个多月,说懂了。前一个组员总是说我的代码
不“规范”,不“格式化”,用了太多的技巧,不用标准的写法;而后一个组员却什么也不说。两
个组员最大的不同是:前一个组员只有两年的编程经验,而后一个,有十年的编程经验。
如果,如果你用Delphi来写一个“操作系统级程序”,那么,你能用到的“标准的写法”可能没几
个,你可能必须用各种各样的技巧,各种各样离奇的思想。这不是一般人能够想到的做到的。
有兴趣的人可以去看看QString这个字符串处理单元,那绝对是不好读的代码,也绝对精炼,效率也
绝对高。但可能绝对“不标准”、“不规范”。
我并不是反对“代码格式化”,我只是说,我们在这里开展一个竞赛,重点并不是要去格式
化代码,我们的主旨是“写出好的思想”和“好的代码”。那些格式化中存在的各种各样的注释和
格式化用的空格,自然有工具去过滤掉它,你不必关心它们影响你的代码字节数。我考虑将代码字
节数增加到4K,最重要的一个原因也是不想限制大家的思路和对长的、有意义的变量的使用。
5. 这个竞赛的确是在“鼓励提高个人能力”,但绝对没有“忽视团队精神”的意思。哈哈。
我们一直忽略了这点,没有提出来说,算是我的工作失误。其实中国现在的“程序高手”很多,
但真正懂得“软件工作”和组织“团队开发”的人才之又少。事实上我现在也正在学这个,正
在带开发组,正在从最小的“团队”做起。——我自认还做得非常非常差。
印度培养出来的程序员象一个个标准大小的方块,任意多块放在任意位置都是有用的,但缺乏
灵魂;中国培养出来的程序员象一个个钉子,放哪里打都好用,灵气十足,能力十足,但一大
堆钉子放在一起,你的手碰都不敢碰一下。
但中国的程序员在国外却是极好的。因为人家懂得如何组织钉子开发,而不是只懂得如何将方
块“积木”在一起。
不要因为中国没有好的项目管理人员,就要求所有的程序员全变成方块,这是舍本而逐末的事。
6. 好的雕刻师必须先是好的木匠,艺人必须先是匠人。