{转载} 我们真的会写程序么？
pongba
我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
现在的大学里面教 计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课 程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于 《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此 道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序 真的能用么？
大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文 学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说 呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。 还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读 的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似 的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所 成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强 调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了； 读得多了，就知道"啊哈，原来如此"。
可是反过来看看我们的程序员们是怎么培养出来的呢？基本上就是读完了字典，就去写《史记》，荒谬绝伦。至少成批的量产教育肯定如此。仔细想来大学的教育甚至连一门《代码阅读与欣赏》的课程都没有，何谈编程艺术。仔细想想我身边的朋友，但凡是在码代码 方面有点心得的，无不是私下里读了，写了，改了大量的代码。看来文学写作的经验还是符合人类学习的规律的，而编程学习也要符合这一规律。
我 深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的 书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
cat street
我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
现在的大学里面教计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序真的能用么？
大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了；读得多了，就知道"啊哈，原来如此"。
可是反过来看看我们的程序员们是怎么培养出来的呢？基本上就是读完了字典，就去写《史记》，荒谬绝伦。至少成批的量产教育肯定如此。仔细想来大学的教育甚至连一门《代码阅读与欣赏》的课程都没有，何谈编程艺术。仔细想想我身边的朋友，但凡是在码代码方面有点心得的，无不是私下里读了，写了，改了大量的代码。看来文学写作的经验还是符合人类学习的规律的，而编程学习也要符合这一规律。
我深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
@@
Zoom.Quiet
> 我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY
> 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
>
--
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
LiAndy
--
------Crazy in Silence. Silence in Crazy.------
facebook : Li Andy
Twitter : http://twitter.com/liandy
Googol Lee
只是这些程序太短小了，就像小学课本里的《秋天来了》一样，仅仅描述了很具体的一个东西。而这，并不是真正的程序。
真正需要开的是类似优秀程序赏析，大型程序架构分析之类的课吧
Kenny Yuan
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
redsea
但是对于个体, 特别是已经意识到这个问题的个体来说, 只要他还是上进, 其实问题在自身.
团队开发里面的东西, 个人学习不容易, 起码个人编程的东西, 大把资源, 个人学习是很容易的, 就只能怨自己.
On 9月11日, 下午6时11分, LiAndy <netclos...@gmail.com> wrote:
> 恩................感受良多，受益匪浅。
> 环境是个大问题啊.......
> 多谢各位前辈指教.......
> 向各位有过激烈争吵的朋友以至产生了误解的朋友，深深地道歉（太多了，不能一一列举，否则噪音太大，又有误解）。
LiAndy
莫华枫
观察之后，我觉得这两个人都存在各自的问题。先说B，他的问题不仅仅在于编程方面，他对于一般事物的认识也同样显得粗糙，浅薄。他做事往往丢失目标。他的资质不算很差，够得上平均水平。这种情况我觉得不是天生的。很可能从小缺乏思维锻炼，从小读书到大，却也只是被动地学了各种该他学的东西。至于如何学习，如何思考，他没有学会，也没有人教他。
A则灵巧得多，往往会主动地找到一些解决方案。但是，他始终还是无法完全独立地处理开发中遇到的问题。A身上体现了众多程序员中的另一种问题。他们缺乏全面的技术视野。他们有的凭着资质，有的凭着经验，具备了完成某项工作的能力。但是他们往往只会在既有的，熟悉的技术和方法范围内解决问题。因为他们只了解这些。作为程序员，不可能一开始就了解各种领域的技术。很多程序员往往沦落为井底之蛙。他们不知道还有更多的技术，更多的方法可以帮助他们更好地解决问题。久而久之，便养成了习惯，甚至主动地排斥其他领域的东西。这些人主要还是缺乏引导，没有人一开始就告诉他们，这个世界上还有很多其他的东西，可以为他们提供帮助。至少也应该鼓励他们探索新的领域，并且让他们知道如何去寻找新的东西。
对这些情况，我觉得教育有不可推卸的责任。对于B没有促使他学会学习的技能。对于A没有能够培养他们的好奇心和探索精神。正因为如此，我们在如此众多的it从业者中，却很难挑出足够多的优秀程序员。
李鹏果
我的身边有两个新手，其中一个之前做过一阵子js，用过jquery。另一个纯粹菜鸟，在一个什么业余学校里有一年多的培训。前者（简称A)很会做东西，给个思路，基本上就能做下去了，几个项目头头都喜欢同他合作。后者（简称B）不太行，始终抓不住要领，要命的是他自认为抓住了要领了。
观察之后，我觉得这两个人都存在各自的问题。先说B，他的问题不仅仅在于编程方面，他对于一般事物的认识也同样显得粗糙，浅薄。他做事往往丢失目标。他的资质不算很差，够得上平均水平。这种情况我觉得不是天生的。很可能从小缺乏思维锻炼，从小读书到大，却也只是被动地学了各种该他学的东西。至于如何学习，如何思考，他没有学会，也没有人教他。
A则灵巧得多，往往会主动地找到一些解决方案。但是，他始终还是无法完全独立地处理开发中遇到的问题。A身上体现了众多程序员中的另一种问题。他们缺乏全面的技术视野。他们有的凭着资质，有的凭着经验，具备了完成某项工作的能力。但是他们往往只会在既有的，熟悉的技术和方法范围内解决问题。因为他们只了解这些。作为程序员，不可能一开始就了解各种领域的技术。很多程序员往往沦落为井底之蛙。他们不知道还有更多的技术，更多的方法可以帮助他们更好地解决问题。久而久之，便养成了习惯，甚至主动地排斥其他领域的东西。这些人主要还是缺乏引导，没有人一开始就告诉他们，这个世界上还有很多其他的东西，可以为他们提供帮助。至少也应该鼓励他们探索新的领域，并且让他们知道如何去寻找新的东西。
对这些情况，我觉得教育有不可推卸的责任。对于B没有促使他学会学习的技能。对于A没有能够培养他们的好奇心和探索精神。正因为如此，我们在如此众多的it从业者中，却很难挑出足够多的优秀程序员。
王宁
pongba
我的身边有两个新手，其中一个之前做过一阵子js，用过jquery。另一个纯粹菜鸟，在一个什么业余学校里有一年多的培训。前者（简称A)很会做东西，给个思路，基本上就能做下去了，几个项目头头都喜欢同他合作。后者（简称B）不太行，始终抓不住要领，要命的是他自认为抓住了要领了。
观察之后，我觉得这两个人都存在各自的问题。先说B，他的问题不仅仅在于编程方面，他对于一般事物的认识也同样显得粗糙，浅薄。他做事往往丢失目标。他的资质不算很差，够得上平均水平。这种情况我觉得不是天生的。很可能从小缺乏思维锻炼，从小读书到大，却也只是被动地学了各种该他学的东西。至于如何学习，如何思考，他没有学会，也没有人教他。
A则灵巧得多，往往会主动地找到一些解决方案。但是，他始终还是无法完全独立地处理开发中遇到的问题。A身上体现了众多程序员中的另一种问题。他们缺乏全面的技术视野。他们有的凭着资质，有的凭着经验，具备了完成某项工作的能力。但是他们往往只会在既有的，熟悉的技术和方法范围内解决问题。因为他们只了解这些。作为程序员，不可能一开始就了解各种领域的技术。很多程序员往往沦落为井底之蛙。他们不知道还有更多的技术，更多的方法可以帮助他们更好地解决问题。久而久之，便养成了习惯，甚至主动地排斥其他领域的东西。这些人主要还是缺乏引导，没有人一开始就告诉他们，这个世界上还有很多其他的东西，可以为他们提供帮助。至少也应该鼓励他们探索新的领域，并且让他们知道如何去寻找新的东西。
这两段分析得真好！
Kenny Yuan
LiAndy
莫华枫
曾经有一个小孩在我家寄宿了一周。这个孩子钢琴考出了六级，但是居然分不清贝多芬和施特劳斯。或许他弹的是钢琴，不是音乐。
James liu
--
regards
j.L
Jiahua Huang
> 另外一个故事，表明学校教育只是问题的冰山一角。
> 曾经有一个小孩在我家寄宿了一周。这个孩子钢琴考出了六级，但是居然分不清贝多芬和施特劳斯。或许他弹的是钢琴，不是音乐。
>
是这样没错，
可还是有一些大师，小时候是也被逼着学的技巧，
很久以后懂得了音乐，却成为了大师。
只是对教育来说，太得不偿失了
katkat lim
redsea
我自己的也没有多强的软件工程能力, 只是会需求, 设计, 分派工作, 做好自己的编码测试, 盯住别人的进度和质量, 其他我都不会了.
redsea
我又没有标榜我会是一个好老师, 我的意见是学生在校学编程容易, 而不是学开发 or 学软工容易, 你为什么问我这个问题呢 ?
Jiahua Huang
> 如果一个人一直在重复发明轮子，也一样学不会写程序。
>
如果让普通学生去学 "C 语言"，考计算机证之类，
实在不如拿个周蟒 <http://code.google.com/p/zhpy/wiki/ByteOfZhpy> 给他/她玩
redsea
看现成的代码, 可以知道什么样的代码好, 但是什么样的代码不好, 为什么不好, 没有过切身体验, 说不定有时不小心还写出来了.
写过 n 多代码, 好和不好自己有过切身的感受, 效果更佳.
Kyle M. Lee
LiAndy
莫华枫
学音乐也有童子功，幼年时的音乐氛围和教育对于一个人的音乐表达力有很重要的作用。国内的很多演奏家拥有一流的技巧，但是演奏的音乐永远是别人的。程序员也是如此。（当然童子功就谈不上了，就算开蒙吧）。
nemo
大学那会开始接触比较大的PC应用程序，学会分析，了解程序除了语言以外的东西，觉得好像自己其实不会写程序。
工作到现在，从事嵌入式开发，好吧，觉得有点入门了。
在我目前的理解里，程序包含太庞大的概念了，程序，又不只是程序。
hayate
Mingxi Wu
这个比喻很好。我觉得大学教育最应该交给我们的是兴趣，创造力和解决问题的科学方法。
现在照本宣科的教育，对于兴趣和创造力的培养太有限了。
我在读代码时经常感概的，除了作者优美的代码外，就是 为什么他会想到写这个，他写这个程序的创意来自哪里。
我最佩服的是第一个发明轮子的人，这个人不但是技术了然于胸，而且他还能发现问题，并且活用已有知识来解决问题，这才是所谓的创新。
在兴趣的激发下，人迸发出的激情和创造力是无限的，而程序本身，只是解决问题的手段， 并不是最终的目的。
Jiahua Huang
> 这是两个问题。弹钢琴学技巧是必须的，但是只有技巧是不会理解音乐的。
> 据我所知，几乎所有的大师在学习基本技术和技巧的同时，都有着很全面的音乐熏陶。
但是这些功利性考钢琴的人，不太可能有啥音乐熏陶环境
莫华枫
我有个朋友喜欢上了唱歌。参加社区合唱队，了解歌唱的方法等等，不亦乐乎。他有一个观念，唱高音的，才是最厉害的。在他的思想中，唱不了高音，才会去唱中音和低音。他甚至认为上音声乐很差，因为至今没有培养出一个好的男高音。很多人有这种观点，所以会热炒维塔斯的所谓"海豚音"，或者找来个农民要跟帕瓦罗蒂比音高。
但是，从专业的角度来讲（呵呵，我也是听来的，只不过是从专业人士那里:)），高中低音的划分是根据个人条件来的（主要是生理条件）。而且，并非越高越难唱。一般人，经过正确的训练，可以使自己的最高音提高那么一两度。但是，声乐，特别是美声，强调的不是音高，而是声音通道（不是气管，究竟是什么也不十分明白，我理解成频谱的宽度，或者频谱的模式，或者共鸣的模式）。所唱的任何音高，都应该保持在一个通道里。如果没有保持住，那就是唱砸了。另一方面，并非高音难唱。相反低音更难唱。世界上高音好的一抓一大把，但低音唱的好的是凤毛麟角。（从物理学角度来看，要达到相同的分贝数，低音需要比高音消耗更多的能量）。
然而，这仅仅是演唱层面。对于更深层次的问题，则有更多的误解。我的那个朋友最崇拜帕瓦罗蒂，认为他是最好的男高音。但是我觉得，如果从演唱角度来讲，这毋庸置疑。帕瓦罗蒂的条件好，音色富有金属光泽。但是，如果从音乐表演的角度，也就是用歌唱来演绎角色，表达人物内心，他却不是最好的。而这却是更高层次，更具难度的事。我曾经把卡鲁索唱的"穿上戏装"（《丑角》）和帕瓦罗蒂的版本放在一起听。会发现，卡鲁索的表演（已经不仅仅是演唱了）极具表现力，即使听不懂意大利文的歌词，也被其歌声所感染，为他的命运而感到哀伤。而帕瓦罗蒂的演唱（这回是演唱了），虽然华丽，但却不应该是一个悲伤的丑角所发出的声音，而更像《弄臣》里的公爵。
我的朋友和其他一些爱好者，实际上并未深入地了解歌唱的艺术。他们错误地想要学唱，想要高音。实际上他们只对唱感兴趣，而不是音乐。作为普通人，更多地听，更多地了解音乐，才是在力所能及的范围内更好地提升自我修养和情趣的方式。
回到我们的it行业。很多程序员与我的这位朋友有着异曲同工的问题。只注重技术的外在形象，它的宣传，或者它的出身。往往陷入一些看起来很炫很酷，但实际上像软木塞那样漂在水面上的技术圈套。
ms在sql2005中推出了一个叫做"bi"的东西，可以用来生成数据统计网页，可以看到统计图片。我身边很多人津津乐道于此。但实际上，最后试用下来，这个东西实际上就是基于report service的一个报表网页生成模块。起初用起来是非常容易的。但是，对于一些稍微复杂的分析和展示，根本无法使用，只能回到手工编码的形式。这是因为ms并未提供一个开放的报表网页构造平台，而是提供了一个自认为可以解决客户问题的封闭的工具。
其实，要做到这样一个报表平台，并不困难。所需的技术都是现成的，根本无需重新发明轮子。对于文字、表格类的报表展示，html直接可以做到。对于那些图形化的展示，可以使用svg，这种几年前w3c就已推出的标准（除了ie以外，各大浏览器都直接支持）。数据从数据库中提出，以xml的形式组织，然后通过xslt或者xquery转换成html或者svg。非常灵活、简单、方便。数据展示的形式、格式、结构、配色等等，完全由style sheet或者xquery脚本，以及相关的css等控制。这些文档可以进一步做成模板，供快速开发常用报表使用。而那些非常规的，复杂的报表，则可以直接手工编写脚本，实现输出。
很多程序员把复杂和专有等同于先进。实际上，真正先进的，是那些简单、基础，并且抽象的东西。这样的技术可以在程序员灵活的双手中不断地组合变化，形成各种各样美妙的应用。
造成这些问题的真正原因，是他们对事物缺乏全面的了解。两种原因促使了这种情况。有的是得到了错误的信息。一些大企业为了经济利益，采用赋予感官刺激的宣传忽悠程序员，特别是新手。缺乏经验程序员们往往认为大厂商拥有雄厚的技术力量，推出的肯定都是最好的。或许工业企业是如此，但软件行业并非完全这样。特别是那些新兴的开源社群，拥有巨大的技术能量。
另一些则是主观的原因，只求知道，而不求知道更多。这种情况前面已经说到过了。
一个程序员要想成熟，必须跨过这道门槛。不能迷信，用自己的眼睛看、自己的头脑分析和思考。要看得多，看得广。了解了足够多的知识，才有的比较，才知道什么是最好的。
Googol Lee
老莫能推荐个讲xslt的书么？一直听说过这东西，但是没机会用到，想系统的学一下。
Jiahua Huang
> 老莫能推荐个讲xslt的书么？一直听说过这东西，但是没机会用到，想系统的学一下。
>
http://www.w3.org/Style/XSL/
http://www.w3.org/TR/xslt20/
http://www.w3.org/TR/xslt20req
caijimin
枝大叶、得过且过、固步自封，往往在生活中也是如此，写程序时精益求精、不断总结和反思、好奇心和求知欲强，做别的事情往往也是如此，也更容易成功
除了我们的教育应该负很大的责任，自我的意识和努力更为重要，佛学常说“点化”“顿悟”，在我看来，自己能顿悟当然好，别人的点化也很关键，就怕怎么点
化都无法顿悟。
thoriod
编程只是编程罢了。。。你要说方法。。。以及别的什么，我觉得其实只是个人的思维问题，你拿编程当编程，它自然就是编程，不会是实现方法的步骤。
个人讨厌程序员A，更讨厌程序员B。
前不久组里年纪大点的兄弟对我说，别对组里那2个年轻点的发脾气，人家也只是混日子。（年轻是指年纪偏小，虽然我是我组年纪最小的85生人）
做人没有规划，做事浑浑噩噩，期待别人给自己指路，被项目逼着赶进度，这样的生活，混着，你舒服吗。
LiAndy
shanks
一细看才知道是将程序员"养成"的！
文章两个观点混淆了：程序员到底是大量实践练出来的，还是大量阅读读出来的？
文章后面就变成了是"读出来"的观点（不知道我有没有理解错）
我个人比较中庸，认为理论学习、实践、和代码阅读都很重要（本科的时候觉得那些理论是废的），原因是代码阅读
在没有理论支持的情况下是盲人摸象，你根本无法知道人家为什么这样写，你又怎么用上这些你不理解的东西呢？
理论知识能在很多地方解答这个"为什么"。
实践就不说了，相信大家都能理解。
所以对于这个问题我的结论是，"大量"阅读代码事倍功半，小本版迭代才是王道，学点理论，在少量代码阅读中
印证，如此循环。当然可以"大量理论"然后再"大量代码"，不过我没见过有人一天是48小时的，所以，也不知道
有谁在智力和我一样平平的情况下能什么都"大量"的。
另外，拿编程和艺术的类比，要开代码欣赏课？！笑话，我从小学中学到大学，都有艺术欣赏课，但是这些课程除了让我
没有忘记音乐和"画画"这两个名词外，对我艺术水平似乎帮助不大。倒是小学的"画画课"让我知道只要三条弧线一个圆圈
就能画一张人脸。艺术欣赏能告诉你的就是艺术欣赏，你记得的音乐家里面有几个是"乐评家"？
当然，我对现行的教育问题确实很多，例如，只能教技术，没有教思想（惨一点的连技术都没有），在比如专业选人而不是
人选专业。只是我想回到最初的问题上"怎样的程序员才算会写程序呢？"或者扯远一点"什么计算机教育才算好的计算机教育呢？"
On 9月11日, 下午5时43分, pongba <pon...@gmail.com> wrote:
> 我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY
> 其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
>
> 文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
>
> via:http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
>
> 为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
>
> 现在的大学里面教
> 计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课
> 程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于
> 《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此
> 道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序
> 真的能用么？
>
> 大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文
> 学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说
> 呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。
> 还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读
> 的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似
> 的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所
> 成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强
> 调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了；
> 读得多了，就知道"啊哈，原来如此"。
>
LiAndy
Lian Cheng
老师的话……在当前这种功利的环境下，能这么纯粹地互相探讨的恐怕真是不多啊……反倒是学校里的技术社区对学生的影响更加积极和有效。
LiAndy
shanks
不好意思，你这话我确实没怎么看懂。我想知道老师交流足够是指"什么问题"上的交流足够？如果足够了能有什么好处？我们还是在说写程序的事吗？
^_^
另外，学生之间的交流又是指交流什么问题？
> 此言论再次说明，除了学生间要好好探讨如何交流、进行有效率的交流，达到一种所谓的【思维共振（共振，在物理上，有个概念，这个字【振】肯定写错了）】外，老师-间的交流也是不可缺少的，正所谓【上梁不正下梁歪】（不过，话说丑点，老师们在一起【思维共振】的时候，基本上都是社会意义的，而不是像学生们的那么具有单一性-）。
>
> 2008/9/12 shanks <yeahq....@gmail.com>
>
>
>
>
> > 文章是有点"铁屋呐喊"的味道，不过标题起错了，乍看这标题我还以为是讲"怎样才算是好程序员"的标准的，后来
> > 一细看才知道是将程序员"养成"的！
>
> > 文章两个观点混淆了：程序员到底是大量实践练出来的，还是大量阅读读出来的？
> > 文章后面就变成了是"读出来"的观点（不知道我有没有理解错）
>
> > 我个人比较中庸，认为理论学习、实践、和代码阅读都很重要（本科的时候觉得那些理论是废的），原因是代码阅读
> > 在没有理论支持的情况下是盲人摸象，你根本无法知道人家为什么这样写，你又怎么用上这些你不理解的东西呢？
> > 理论知识能在很多地方解答这个"为什么"。
> > 实践就不说了，相信大家都能理解。
> > 所以对于这个问题我的结论是，"大量"阅读代码事倍功半，小本版迭代才是王道，学点理论，在少量代码阅读中
> > 印证，如此循环。当然可以"大量理论"然后再"大量代码"，不过我没见过有人一天是48小时的，所以，也不知道
> > 有谁在智力和我一样平平的情况下能什么都"大量"的。
>
> > 另外，拿编程和艺术的类比，要开代码欣赏课？！笑话，我从小学中学到大学，都有艺术欣赏课，但是这些课程除了让我
> > 没有忘记音乐和"画画"这两个名词外，对我艺术水平似乎帮助不大。倒是小学的"画画课"让我知道只要三条弧线一个圆圈
> > 就能画一张人脸。艺术欣赏能告诉你的就是艺术欣赏，你记得的音乐家里面有几个是"乐评家"？
>
> > 当然，我对现行的教育问题确实很多，例如，只能教技术，没有教思想（惨一点的连技术都没有），在比如专业选人而不是
> > 人选专业。只是我想回到最初的问题上"怎样的程序员才算会写程序呢？"或者扯远一点"什么计算机教育才算好的计算机教育呢？"
>
> > On 9月11日, 下午5时43分, pongba <pon...@gmail.com> wrote:
> > > 我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY
>
> > > 其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
>
> > > 文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
>
> > > via:
> >http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
>
> > > 为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
>
> > > 现在的大学里面教
> > > 计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课
> > > 程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于
> > > 《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此
> > > 道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序
> > > 真的能用么？
>
> > > 大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文
> > > 学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说
> > > 呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。
> > > 还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读
> > > 的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似
> > > 的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所
> > > 成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强
> > > 调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了；
> > > 读得多了，就知道"啊哈，原来如此"。
>
>
> > > 我
> > 深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的
> > > 书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
>
> > > --
> > > 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> > > TopLanguagehttp://groups.google.com/group/pongba
>
> --
> ------Crazy in Silence. Silence in Crazy.------
> facebook : Li Andy
>
> - 显示引用的文字 -
LiAndy
总之一句话：不想被人把握命运，就要努力创造命运，但命运只与【德才兼备】有共识。
莫华枫
音色主要取决于泛音的模型。一般来讲泛音越多，而且是偶次倍泛音越多，音色越暖，奇次倍越多，音色越尖。这个不是量化，没有做过双盲对比，呵呵。
老莫能推荐个讲xslt的书么？一直听说过这东西，但是没机会用到，想系统的学一下。
yh
On 9月12日, 下午7时25分, LiAndy <netclos...@gmail.com> wrote:
> 呵呵，又可以和人小握一下手了。
> 这种环境，如果不拿一些策略出来，我们的下一代'程序员'们又要受到欺压，都不知道自己一辈子在干些什么？
> 当然，老师们的一些社会意义，也不是完全错误的，这是人之根本，没有错的，可学生们就未必知道。可如果学生们知道了，又在一定几率上不会好好学习，这就真伤脑筋啊、头大啦。
>
>
> 2008/9/12 Lian Cheng <rhythm.m...@gmail.com>
>
>
> > 呵呵，这段话我算是看懂了 :-)
> > 确实不错。学生，以及从学生转变过来的工程师之间进行沟通和交流的时候往往主题很纯粹，就是针对某个技术方向或者某个技术难题，大家靠事实和数据说话（这点在学生时期能做到的可能还不太多，但至少我周围的工程师之间还是很重事实和数据的）。
>
>
> > 2008/9/12 LiAndy <netclos...@gmail.com>
> > shanks ：
>
> >> 此言论再次说明，除了学生间要好好探讨如何交流、进行有效率的交流，达到一种所谓的【思维共振（共振，在物理上，有个概念，这个字【振】肯定写错了）】外，老师间的交流也是不可缺少的，正所谓【上梁不正下梁歪】（不过，话说丑点，老师们在一起【思维共振】的时候，基本上都是社会意义的，而不是像学生们的那么具有单一性）。
>
> >> 文章是有点"铁屋呐喊"的味道，不过标题起错了，乍看这标题我还以为是讲"怎样才算是好程序员"的标准的，后来
> >>> 一细看才知道是将程序员"养成"的！
>
> >>> 文章两个观点混淆了：程序员到底是大量实践练出来的，还是大量阅读读出来的？
> >>> 文章后面就变成了是"读出来"的观点（不知道我有没有理解错）
>
> >>> 我个人比较中庸，认为理论学习、实践、和代码阅读都很重要（本科的时候觉得那些理论是废的），原因是代码阅读
> >>> 在没有理论支持的情况下是盲人摸象，你根本无法知道人家为什么这样写，你又怎么用上这些你不理解的东西呢？
> >>> 理论知识能在很多地方解答这个"为什么"。
> >>> 实践就不说了，相信大家都能理解。
> >>> 所以对于这个问题我的结论是，"大量"阅读代码事倍功半，小本版迭代才是王道，学点理论，在少量代码阅读中
> >>> 印证，如此循环。当然可以"大量理论"然后再"大量代码"，不过我没见过有人一天是48小时的，所以，也不知道
> >>> 有谁在智力和我一样平平的情况下能什么都"大量"的。
>
> >>> 另外，拿编程和艺术的类比，要开代码欣赏课？！笑话，我从小学中学到大学，都有艺术欣赏课，但是这些课程除了让我
> >>> 没有忘记音乐和"画画"这两个名词外，对我艺术水平似乎帮助不大。倒是小学的"画画课"让我知道只要三条弧线一个圆圈
> >>> 就能画一张人脸。艺术欣赏能告诉你的就是艺术欣赏，你记得的音乐家里面有几个是"乐评家"？
>
> >>> 当然，我对现行的教育问题确实很多，例如，只能教技术，没有教思想（惨一点的连技术都没有），在比如专业选人而不是
> >>> 人选专业。只是我想回到最初的问题上"怎样的程序员才算会写程序呢？"或者扯远一点"什么计算机教育才算好的计算机教育呢？"
>
> >>> On 9月11日, 下午5时43分, pongba <pon...@gmail.com> wrote:
> >>> > 我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的
> >>> DRY
>
> >>> 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写-代码，写出来的代码无论是可读还是可维护性都很差。
>
> >>> > 其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
>
> >>> > 文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
>
> >>> > via:
mars
我发现他们跨越那个“门槛”是那样的艰难，那样的无助，而心态上又觉得自己是大学生，天之骄子，应该什么都会才是。其实这篇文字就是和一个新人谈话后所
写的。这个行业知识的更新速度太快，新进入者很容易迷茫，不像原来那种被硬件条件限制学习只有“华山一路”。
文章有些片面，忽略了其他的许多方面，比如实践，比如方法。话又说回来了，这些东西，这些教育学习的方式，应该遵循人类上千年的文明经验，可以说，
在“学习实践”这个问题上，人类文明有着最成熟的解决方案，至少比其他任何方法论都成熟。我最要指出和批判的是很多程序员的“修真之道”不符合这一规
律，他们在痛苦的路上愈加艰难的跋涉着。
关于兴趣
我小的时候看了一本《什么是数学：对思想和方法的基本研究》作者: （美）R ・柯朗 / （美）H·罗宾
http://www.douban.com/subject/1320282/?i=0
从此就爱上了数学
关于方法
我在大学的时候觉得最好的一本教材（个人观点） 《现代控制系统(第8版)》 作者: （美）多尔夫 / （美）毕晓
http://www.douban.com/subject/1509604/?i=50
整个教材对比一下我们的理论教学，就会发现人家的高明之处。整本书的习题构造了一个磁盘驱动器的控制系统，真是理论联系实际的典范啊。
关于悟性
我最怀念的时光，可能就是我在号称南半球最大的图书馆Fisher静静的读完馆藏的每一本Scheme书籍。聆听大师的教诲，深深的感到自己是多么无知
和渺小。想想所有的小说里的高僧，似乎都是得到了真传才牛逼的，靠悟性也都是悟所谓的“秘籍”。现代科学的名家名人更是如此，95%以上的牛逼人师父也
是顶顶牛逼的人。悟性是要有，但也要有名师。比如全真七子，有名师，没悟性，但也能在一流高手里面混，但成不了超一流选手。有悟性，没名师的，我实在想
不起来有提及谁，大家帮我想想。牛逼的主角都是符合“悟性+名师”的公式的。
pongba 写道：
> �Ҿ���ܽ�û����е���ģ���Ȼ����ȶ���ɾ����ڳ�ѧ��ӡ���������ǵõ���һ��ʼҲ������ͷд���룬д��4�Ĵ������ţ���� DRY
> ԭ��֪�#�����˵����淶�ˣ������ˣ��ع��ˣ�����ˡ�ֻ��˵ʵ����һ�繦�ܣ������ڲ������ҳ�һ�š������ڣ����кܶ�ѧϰ��̵ľ�û��������ǻ���д���룬д��4�Ĵ��������ǿɶ{��ǿ�ά���Զ��ܲ
>
> ��ʵ˵�����ǣ����������ɣ��Լ���ͷʵ��4�ܽ�һЩ�����֪ʶ������վ��ǰ�˵ļ���ϣ�������һ����ʵ��4��������ӡ��������Ч�ķ�����
>
> ���»�û����������Ȩ�������Ķc����۵㵹����ȷ�ġ���u�ǰ�˷����ϱ��Ӿ������N���ӻ��ܽ��4�ľ��飬�������˷�Щ����
>
> via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
>
> Ϊʲô���Ƕ���Ϊ�������д���ǻ���ģ�����Ϊ����Ա�Ϳ��Բ��q��˵Ĵ�������Լ�д���룿
>
> ���ڵĴ�ѧ�����
> �����һ�ſνС�C���ԡ���������ѧ�������ܻ�д�����߾���ڹ�����������4һЩ����ݽṹ�������㷨��������ʽ���ԡ���������ԭ�?֮��Ŀ�
> �̡���ò���ϵͳ�������㷺���ͼӵ��ϡ���������ԭ�?�����������ϵ������������һ�������ʱ�����ǾͲ��䡶TCP/IPԭ�?֮��Ŀγ̡�����
> ��������̡����ֹ�ƨ��ͨ�Ŀγ̣�ֻ����ʦ��4��ѧ��ͬʱ��4�Ի��Լ��ģ�����˵�ⲻ��һ��ѧ�ʣ�����˵���ڻ���̫�����ܾ��ڴ˵#�����������ڴ�
> �5�����ǡǡû��̫��������˵���ʦ��������������������ôһλ����������������4�ĸ��֡�����ѧ����ô�࣬�����Ļ�д����ô���ֻ���˵����д�ij���
> �������ô��
>
> ������˻��dz��ϱ������������ô�õģ����Ǿ��ú���Ƚ����Ƶ���ѧ������֮��ȡ������ʦ��֮����ѧ���������̱���
> ѧ��Ʒ����ʦ�ɳ�֮·���ƾ�����֮�á����ǻᷢ�ֳ���֮·�������Ǵ�ѧ����;�����������̽��ij���֮·�������Ǽ�ǧ��4�ľ������ì�ܵġ���ô˵
> �أ���������һ��������γ�Ϊһ����ѧ����������һ��˵����Ϊһ�����ıʵ��ˡ������Ҫ��һ��һ��ѧ�𣬵�Ȼ��(�֣��ʣ��䰡��һЩ�dz����Ҫ�ء�
> ����ƴ���˳����д��һϵ�й淶������һ����ѧ����Щ�淶��һ����д��Ѫɫ������ô������Ц������ָ��һ���˰��ֵ�ͨ��һ�����д��ʷ�ǡ�����ʹ���
> ���ǡ������ֵ䡷Ҳ���С�Ҳͬ����ָ��ѧ��ƴ��ͻ�˵�й�Ҫ��Ȼ�����Ļ���ѧ�㲥��ѧ֮��Ķ�Ҫ���Ŵ��ˡ��κ�һ����ѧϰ���ĵĹ�̶�������
> �ģ�ѧһ���֪ʶ����һЩ�ܿ������飬����дһд����һ�ģ���ѧһЩ�淶�Ե�֪ʶ���ǵȵȣ��ٴ� �Ķc��Լ����ϵ�д���ϵĸġ������4����һ������
> �ɾ͵�����ī��������һ��һ���߹�4�ġ�������"��������?�±�������"��˵�����ɼ��Ķ���ѧϰ���ĵ�����ĵIJ��֡��������Ǵӹ��Խ�����Ľ�ѧ��ǿ
> ����ѧϰ���˵���Ʒ��������Ҳ��ȫ�=�ͨ�е�һ������uĶ��ˣ�Ʒζ����ȥ�ˣ��uö��ˣ���ʶ�Ͷ��ˣ���֪����ν"��˼����#�˭�������"�ľ����ˣ�
> �uö��ˣ���֪��"������ԭ4���"��
>
> ���Ƿ���4�������ǵij���Ա������ô�����4���أ����Ͼ��Ƕ������ֵ䣬��ȥд��ʷ�ǡ���������ס����ٳ���� �����϶���ˡ���ϸ��4��ѧ�Ľ�������lһ�š������Ķ������͡��Ŀγ̶�û�У���̸���������ϸ��������ߵ����ѣ��������������
> �����е��ĵõģ�����˽������ˣ�д�ˣ����˴� �Ĵ��롣��4��ѧд��ľ��黹�Ƿ������ѧϰ�Ĺ��ɵģ�����ѧϰҲҪ�����һ���ɡ�
>
> �� �������ţ�ͨ��� �Ķ�����Դ���ܹ����ֳ���Ա�����Ĵ���˵�ṹ�滮�����?�����Ŀ���ʧ�ߣ��쳣�Ĵ��?�㣬�����淶�ȵȡ���Ȼ���е�
> ���ﶼ���ܽ�����ڱ�̵�һ�У������Ķ�Ҳ���ܣ������������֮ѡ��һ��ѧϰ��ʽ�Ļ�����ô�һ�ѡ������Ķc���Ϊ�������ӽ�"һ��"�ķ�����
>
> --
> ���(pongba)|C++������
LiAndy
egmkang wang
我先声明,我本菜鸟,绝非牛人.有什么不对的,直接拍砖就是.
我是一个学生,还没毕业.暑假在一公司实习.也有一点自己的看法.
中国的老师教你语法,教你识字,还是可以的.但是教你抽象,教你写史记,貌似我长这么大没见过几个吧?
可是编程偏偏是一个实践性东西,语法不会可以Google,抽象不会,思想不会,是Google不到的. 软件工程,看名字就知道是实践性相当强的东西,可在中国(外国不知),有几个老师真正接触过工业级别的工程????
我觉得,要是能在编程初期,接触一些失败的软件工程,那将是非常有意义的事. 记得大二的时候买了bob大叔的敏捷软件开发,看了,完全不知道在说些什么. 这个暑假出来假装实习,老板让写一个程序,给了一个VB的样例让我"学习". 我当时一看就晕了. 3个代码文件,2个文件代码都是2K+的.也别说什么抽象了,就是过程化的用VB,也至少得把不同功能的东西分割开来吧??? 郁闷了,就给老板说:我自己写,我不想看他的代码. 因为是实习,老板也同意了.随后,我就自己写代码.中间"历尽艰辛".
忽然间想起了敏捷,又翻开bob大叔的书,看了起来. 哎,那滋味道不出来的. 可惜,我比较愚笨,那本书到现在也就只能读懂前两部分,后面的完全不懂..............
中间阅读过一次别人的源码,是"梅花雪"写的MzTreeView.不晓得有人看过么? 大约05年左右写出来.那个代码一眼望去,感觉都是不一样的. 要是天天看这样的人写的代码,就是傻子,看四年,也会写代码了.
我觉得实践,思考还是比较重要的. 当然我一个菜鸟在这里指手画脚的感觉..........我还是打完收工吧...o(∩_∩)o...
我在cnblogs上面被拍砖,说,大四还没掌握OO,有一点说不过去. 我想在这里问一问, 众老鸟都是在什么时候认为自己真正掌握OO的呢?
redsea
JS/HTML 端, 用 Jquery, 似乎不怎么 OO.
web 后端, 用 django, 它自己可能 OO, 但是我们的代码, 多数是显示东西, 少数是输入编辑, 没有什么业务逻辑, 也不必用
OO. ORM 的部分, 在用到复杂查询的时候, 甚至就是完全不用的, 直接用 SQL.
高性能 web 端, 是 nginx module, 这个自己都不 OO 了.
中间的通信计算程序, 是数据分析处理, 也不必 OO, 只是底层的通信库是 OO 的.
linux kernel module, 也不 OO.
所以, 并非无 OO 不可.
LiAndy
莫华枫
张沈鹏
名可名,非恒名.
"道可道，非恒道"的含义有两层，
一、没有绝对真理，事物是不断发展变化的，因此现在认为是真理的以后不一定还是真理。
二、真理是语言难以穷尽的，认为真确的真理描述都难以完整描述真理。
Patrick He
系，我想在程序设计的实践当中，一个人只能说自己是否掌握了其中的基本知识；
更进一步的，是否会按照面向对象方法的原则展开程序设计的分析、设计、实现、
测试工作；更高级的，是否会在面对一个问题时，是否会熟练地利用面向对象的方
法提出一个解决方案。对于这些知识、经验、技巧，一个程序员的熟悉程度，在完
全不会到“真正掌握”之间还存在很大一段距离吧。况且在程序设计的工作中，会随
着经验的增长、知识的积累，会不断更新自己对面向对象方法的理解和认知。而软
件开发的方法，也不是只有面向对象一种范式；面向对象程序设计，也不是唯一的
专业基础知识。不知所指的“大四还没掌握OO，有一点说不过去”的说法，本身就不
太说得过去吧。
egmkang wang wrote:
> 我在cnblogs上面被拍砖,说,大四还没掌握OO,有一点说不过去. 我想在
> 这里问一问, 众老鸟都是在什么时候认为自己真正掌握OO的呢?
LiAndy
pongba
我在cnblogs上面被拍砖,说,大四还没掌握OO,有一点说不过去. 我想在这里问一问, 众老鸟都是在什么时候认为自己真正掌握OO的呢?
我到现在都不知道什么是OO。
我只知道信息封装、解耦合、多态。
OO只是一个名词，而且还是一个很大的名词，所谓很大就是它的定义没有一个单一而内聚的核心，违反了单一职责原理，一个概念含有的正交的东西太多就容易令人迷惑，每个人摸着一部分都觉得抓到了根本。
而实际上，你就别管OO是什么，转而去问，OO解决的是什么问题，人们常说的OO作为一个工具箱，里面到底有哪几种装备，它们在什么时候使用。把名词踢到一边，才能知道事物的本质是什么，否则容易被慌花了眼。
--
刘未鹏(pongba)|C++的罗浮宫
egmkang wang
我比较喜欢老板给我明确的功能,明确的最开始的输入或者是数据格式,比较明确的输出等.思路我会自己想,实现我会自己实现.可能程序最终封装的会有一点问题,但是我绝对试图去封装了,只是有时候不会解耦合,程序的某一些部分对其他的依赖太多.
我最郁闷的就是就是需求不明确,还有就是跟在别人屁股后面收拾烂摊子.....
老板那次让实现一棵树型的菜单. 按照我的理解,树,不就是至少一个的节点么. 根结点没有父节点,其他的都有就OK了.
结果写到最后,我都实现了我自己的理解的树.QA那边测试说不行,我一看直接傻眼,传进去了三个根结点........
我知道我跟老板都有问题,但是我不知道谁的问题多一点. 可能我跟他沟通还是不够吧?
我的身边有两个新手，其中一个之前做过一阵子js，用过jquery。另一个纯粹菜鸟，在一个什么业余学校里有一年多的培训。前者（简称A)很会做东西，给个思路，基本上就能做下去了，几个项目头头都喜欢同他合作。后者（简称B）不太行，始终抓不住要领，要命的是他自认为抓住了要领了。
观察之后，我觉得这两个人都存在各自的问题。先说B，他的问题不仅仅在于编程方面，他对于一般事物的认识也同样显得粗糙，浅薄。他做事往往丢失目标。他的资质不算很差，够得上平均水平。这种情况我觉得不是天生的。很可能从小缺乏思维锻炼，从小读书到大，却也只是被动地学了各种该他学的东西。至于如何学习，如何思考，他没有学会，也没有人教他。
A则灵巧得多，往往会主动地找到一些解决方案。但是，他始终还是无法完全独立地处理开发中遇到的问题。A身上体现了众多程序员中的另一种问题。他们缺乏全面的技术视野。他们有的凭着资质，有的凭着经验，具备了完成某项工作的能力。但是他们往往只会在既有的，熟悉的技术和方法范围内解决问题。因为他们只了解这些。作为程序员，不可能一开始就了解各种领域的技术。很多程序员往往沦落为井底之蛙。他们不知道还有更多的技术，更多的方法可以帮助他们更好地解决问题。久而久之，便养成了习惯，甚至主动地排斥其他领域的东西。这些人主要还是缺乏引导，没有人一开始就告诉他们，这个世界上还有很多其他的东西，可以为他们提供帮助。至少也应该鼓励他们探索新的领域，并且让他们知道如何去寻找新的东西。
对这些情况，我觉得教育有不可推卸的责任。对于B没有促使他学会学习的技能。对于A没有能够培养他们的好奇心和探索精神。正因为如此，我们在如此众多的it从业者中，却很难挑出足够多的优秀程序员。2008/9/11 pongba <pon...@gmail.com>
我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
现在的大学里面教 计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课 程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于 《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此 道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序 真的能用么？
大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文 学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说 呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。 还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读 的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似 的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所 成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强 调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了； 读得多了，就知道"啊哈，原来如此"。
可是反过来看看我们的程序员们是怎么培养出来的呢？基本上就是读完了字典，就去写《史记》，荒谬绝伦。至少成批的量产教育肯定如此。仔细想来大学的教育甚至连一门《代码阅读与欣赏》的课程都没有，何谈编程艺术。仔细想想我身边的朋友，但凡是在码代码 方面有点心得的，无不是私下里读了，写了，改了大量的代码。看来文学写作的经验还是符合人类学习的规律的，而编程学习也要符合这一规律。
我 深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的 书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
Christian
那个《史记》的类比很煽情，但不太靠谱。没几个公司敢让刚毕业的学生参与大项目的核心部分，他们还没有写《史记》的资格。该碰的钉子是必须得碰的，这谁都免不了。
我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
现在的大学里面教 计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课 程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于 《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此 道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序 真的能用么？
大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文 学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说 呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。 还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读 的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似 的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所 成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强 调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了； 读得多了，就知道"啊哈，原来如此"。
可是反过来看看我们的程序员们是怎么培养出来的呢？基本上就是读完了字典，就去写《史记》，荒谬绝伦。至少成批的量产教育肯定如此。仔细想来大学的教育甚至连一门《代码阅读与欣赏》的课程都没有，何谈编程艺术。仔细想想我身边的朋友，但凡是在码代码 方面有点心得的，无不是私下里读了，写了，改了大量的代码。看来文学写作的经验还是符合人类学习的规律的，而编程学习也要符合这一规律。
我 深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的 书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
--
曹禹
我觉得，仅仅开一个学期的代码鉴赏课，未必是一个根本的解决方案，关键还在于学生自己是否有参与的积极性（我见过很多不喜欢编程的计算机系学生）。明白基本的一些设计原则，还需要大量的阅读和实践，作为工程类的学科（如果只是以培养程序员为目标），经验是非常重要的，没有亲自参与几个比较大的project，设计编码能力恐怕很难提高一个层次。应用软件的开发始u终是以实用为第一准则的，纸上谈兵流于形式反而会让学生眼高手低，而在实际工作中栽大跟头。另一个问题是，学校的老师可能学术能力不错但自身未必有很丰富的编码经验，不妨将这种课程设置为选修课，由经验比较丰富的程序员或者架构师来主讲，只是执行起来恐怕未必容易。
thoriod
其实编程也罢，做人也罢，我们只是讨论程序员。
相信来看这个已经说明读者对编程还有兴趣，回复的人应该也都是对编程有无法言语的感情吧。
冷静下来想想，其实什么行业都有热爱而参与的人，也有为生计而参与的人，并没有对错。
说说我自己，在公司的团队建设很是失败，团队缺乏交流，团队内知识缺乏共享，团队弥漫"混日子"的气氛，我也即将离职（原因很是复杂）。
做人做事其实也得注意方法和态度，我这样的态度很不适合，这段时间成长不少。
这次的失败来的很是时候，新公司也需要我去建立团队，这次经验很好。也懂了一个道理，带动别人的积极心应该先肯定他。无论是程序员A也好，程序员B也
好，我想会自我反省，对自己的作品有荣誉感，能成长的程序员才是好程序员吧。
感谢这里的所有人。
On 9月12日, 下午3时44分, LiAndy <netclos...@gmail.com> wrote:
> thoriod ：
> 你好激动啊，其实大家都是好心，把每个人的观点说出来，从不同观点来体现科学（本质是理性），凡事有利有弊，理性的人总能从中找到一丝丝关系。
>
> 收获颇多啊......难道你不认为？
>
>
>
>
>
> > 上面的都是骗子。。。骗子。。。。骗子。。。骗子。
> > 编程只是编程罢了。。。你要说方法。。。以及别的什么，我觉得其实只是个人的思维问题，你拿编程当编程，它自然就是编程，不会是实现方法的步骤。
> > 个人讨厌程序员A，更讨厌程序员B。
>
> > 前不久组里年纪大点的兄弟对我说，别对组里那2个年轻点的发脾气，人家也只是混日子。（年轻是指年纪偏小，虽然我是我组年纪最小的85生人）
>
> > 做人没有规划，做事浑浑噩噩，期待别人给自己指路，被项目逼着赶进度，这样的生活，混着，你舒服吗。
>
> > On 9月11日, 下午10时57分, LiAndy <netclos...@gmail.com> wrote:
> > > 我的目的无他：
> > > 1、要把中国的IT骗子踢出局，免误新手；
> > > 2、创造良好环境：挖掘高手、提携新手；
> > > 3、发现中国式编程法则（思维不一样，所擅长的领域真的也不一样的）；
>
> > > 所以，很愤怒。请大家见谅。
>
> > > 2008/9/11 redsea <red...@gmail.com>
>
> > > > 我同意.
>
> > > > 看现成的代码, 可以知道什么样的代码好, 但是什么样的代码不好, 为什么不好, 没有过切身体验, 说不定有时不小心还写出来了.
>
> > > > 写过 n 多代码, 好和不好自己有过切身的感受, 效果更佳.
>
> > > > On Sep 11, 8:41 pm, "王宁" <nwang1...@gmail.com> wrote:
> > > > > 我也想瞎扯两句。
> > > > > 过去（现在？）国人常常讲"悟性"，只要够努力，熟读诗书万卷，自然就会写文章了。其中的方法，却很少有人像Polya的How To Solve
>
> > > > > 想提高，最好的办法应该是跟高手合作，或者Code Review。许多大公司里都是用这样的方法培养新人，效果很好，也为Software
> > > > > Craftsmanship和许多敏捷方法所倡导。今天学校的问题，恐怕是高手太少，合作更稀罕。
>
> > > --
> > > ------Crazy in Silence. Silence in Crazy.------
> > > facebook : Li Andy
> > > Twitter :http://twitter.com/liandy
>
> --
> ------Crazy in Silence. Silence in Crazy.------
> facebook : Li Andy
tony.jiao
基础也有不同的偏重,可以根据自己的兴趣或者目前从事的开发方向拓展开来.罗列出不同的基础分层,然后根据兴趣,和愿望在保证最大化提高实际工作能力的前提下,来补充知识.看到一个帖子说,基础是补不完的.我很是赞同.(前端时间就陷入补基础的困境(什么编译原理,后端优化,数据结构,算法分析,操作系统,计算机组成,等待那个,不一而足),完全没有考虑如何来提高自己的实际工作能力.现在明了了
:))
2008/9/16 thoriod <tho...@gmail.com>:
darkness
题，矫罔不可过正。重复别人做的事情可以让你更明白别人为啥那样设计，明白其中隐藏的深意。从学习锻炼的角度出发的，我鼓励重复发明轮子，只要你有兴
趣，那就去自己做个吧。
On 9月11日, 下午10时26分, "katkat lim" <limkat...@gmail.com> wrote:
> 如果一个人一直在重复发明轮子，也一样学不会写程序。
>
> 2008/9/11 Jiahua Huang <jhuangjia...@gmail.com>
Jun Yang
我觉得总结得还是有道理的（虽然大部分类比都可删除，但便于初学者印象深刻嘛）。记得当年一开始也是闷着头写代码，写出来的代码臭不可闻，基本的 DRY 原则都不知道，更不用说编码规范了，测试了，重构了，设计了。只能说实现了一坨功能，代码内部则是乱成一团。而现在，还有很多学习编程的觉得会了语法就是会了写代码，写出来的代码无论是可读还是可维护性都很差。
其实说到底就是，与其闭门造成，自己从头实践来总结一些经验和知识，不如站在前人的肩膀上，并辅以一定的实践来加深理解和印象，是最有效的方法。
文章基本没有正面论述，权当休闲阅读，但观点倒是正确的。多读点前人废了老鼻子劲碰掉了N鼻子灰总结出来的经验，可以少浪费些生命。
via: http://shrimphouse.spaces.live.com/Blog/cns!EBCC39981FB42087!612.entry
为什么我们都认为不读书就写书是荒谬的，而认为程序员就可以不读别人的代码就能自己写代码？
现在的大学里面教计算机，开一门课叫《C语言》，盼望着学了这个就能会写程序，或者觉得内功不够，就再来一些《数据结构》，《算法》，《形式语言》，《编译原理》之类的课程。觉得不够系统，不够广泛，就加点料《计算机组成原理》，《计算机体系》。发现这是一个网络的时代，于是就补充《TCP/IP原理》之类的课程。至于《软件工程》这种狗屁不通的课程，只是老师用来误导学生，同时用来迷惑自己的，不是说这不是一门学问，而是说国内还不太有人能精于此道，而就在少数精于此道的人中恰恰没有太多教书育人的老师。倘若你真的是遇见了这么一位，那真是你三生修来的福分。可是学了这么多，大家真的会写程序么？抑或是说我们写的程序真的能用么？
大多数人还是承认编程是门艺术。那么好的，我们就用和它比较相似的文学艺术与之相比。程序大师比之若文学巨匠，程序犹比文学作品，大师成长之路好似巨匠苦修之旅。我们会发现程序之路，至少是大学里面和绝大多数人正在探索的程序之路是与我们几千年来的经验积累矛盾的。怎么说呢？让我想像一个人是如何成为一个文学巨匠，或者退一万步说，成为一个有文笔的人。这个人要从一点一滴学起，当然包括字，词，句啊等一些非常基本的要素。还有拼音，笔顺，书写等一系列规范。可是一个人学了这些规范就一定能写出《血色浪漫》么，开玩笑！不能指望一个人把字典通读一遍就能写《史记》，即使你读的是《康熙字典》也不行。也同样不能指望学了拼音就会说中国话，要不然语言文化大学和广播大学之类的都要关门大吉了。任何一个人学习语文的过程都是相似的，学一点基础知识，读一些能看懂的书，试着写一写，改一改，再学一些规范性的知识如修辞等等，再大量阅读，自己不断的写不断的改。古往今来，哪一个有所成就的文人墨客无不是这一步一步走过来的。所以有"读书破万卷，下笔如有神"的说法。可见阅读是学习语文的最核心的部分。所以我们从古自今的语文教学都强调了学习他人的作品，相信这也是全世界通行的一个做法。读的多了，品味就上去了；读得多了，见识就多了，就知道所谓"文思如尿崩，谁与我争锋"的境界了；读得多了，就知道"啊哈，原来如此"。
可是反过来看看我们的程序员们是怎么培养出来的呢？基本上就是读完了字典，就去写《史记》，荒谬绝伦。至少成批的量产教育肯定如此。仔细想来大学的教育甚至连一门《代码阅读与欣赏》的课程都没有，何谈编程艺术。仔细想想我身边的朋友，但凡是在码代码方面有点心得的，无不是私下里读了，写了，改了大量的代码。看来文学写作的经验还是符合人类学习的规律的，而编程学习也要符合这一规律。
我深深相信，通过大量阅读优秀源码能够解决大部分程序员常犯的错误，比说结构规划不合理，并发的控制失策，异常的处理不足，代码风格不规范等等。当然所有的书里都不能教你关于编程的一切，代码阅读也不能，但是如果让我之选择一种学习方式的话，那么我会选择代码阅读，因为这个是最接近"一切"的方法。
dianausdu
Chen Zhengguang
xxmplus
还是挺符合大家的论题把
2008/9/25 Chen Zhengguang <cerr...@gmail.com>:
--
Any complex technology which doesn't come with documentation must be the best
available.
Chen Zhengguang
darkness
我想首文是在反对闭门造车, 不去阅读借鉴业内已有的优秀代码. 我同意他的质疑, 但不同意将编程和文学创作做类比, 来作为自己的观点的证据.
On 9月25日, 上午11时25分, "Chen Zhengguang" <cerror...@gmail.com> wrote:
> 锻炼是可以的，但是总是锻炼就不太好了。就像在学校里可以以学习为目的做大量前人已经解决的问题，但是在工作中还是尽量使用别人的成果比较好，因为自己再做一遍，会造成资源的浪费。毕竟别人只关注结果的。
> 我理解"从学习锻炼的角度"应该这样，但是貌似大家讨论的并不是"学习锻炼"……
别人的库,工具,包能有效的提高自身研发能力. ( 但可以提高对工具,库,包的使用能力,说白了,就是用熟悉了. 但正如主题揭示的那样: 我们关
注的是研发能力. ) 所以工作中尽量使用别人的成果或许可以让你不失业, 但不会有效提高你的研发能力. 如果你赞同我说的, 那么你是否想去做点什
么?
On 9月25日, 上午11时28分, xxmplus <xxmp...@gmail.com> wrote:
> 当年侯捷网站上有两句这样的话：练从难处练，用从易处用。
>
> 还是挺符合大家的论题把
>
>
>
> > 锻炼是可以的，但是总是锻炼就不太好了。就像在学校里可以以学习为目的做大量前人已经解决的问题，但是在工作中还是尽量使用别人的成果比较好，因为自己再做一遍，会造成资源的浪费。毕竟别人只关注结果的。
> > 我理解"从学习锻炼的角度"应该这样，但是貌似大家讨论的并不是"学习锻炼"……
>
arenas 0
LiAndy
--
------Crazy in Silence. Silence in Crazy.------
facebook : Li Andy
clever101
pongba
其实我个人倒觉得重复发明轮子也是锻炼能力的一种途径， 我不知道为啥国内业内总有种排斥重复发明轮子的倾向，可能是因为国内业内工程师有"相轻"得问
题，矫罔不可过正。重复别人做的事情可以让你更明白别人为啥那样设计，明白其中隐藏的深意。从学习锻炼的角度出发的，我鼓励重复发明轮子，只要你有兴
趣，那就去自己做个吧。
从学习的目的来说，我也建议自己发明发明轮子，弄清轮子是怎么造出来的。
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://twitter.com/pongba
Delicious
http://delicious.com/pongba
Douban
http://www.douban.com/people/pongba/