我觉得要多问人..看别人的code..不然都是自己闭门造车 我自己花了很久的时间闭门造车 其实很多时候用更方便的语法 应该说要多用别人的code..就会快很多 另外就是要写test. 最好是unit test 其实应该是test driven programming 为了一时方变求快 往往导致後面更长的时间在debug.. 只要写大一点点改code有错就可能花一两天来找 非常可怕 如果可以有人review 你的code那是进步最快的 ※ 引述《yoco315 (眠月)》之铭言： : ※ 引述《miniroom549 (takecoe)》之铭言： : : 程式该怎麽越写越好呢 : : 是否有程式高手可提供一下意见?? : 我不是高手，我懂一点点程式设计，但是我可以分享一点点经验。 : 程式设计是一门艺术， : 多写当然很重要，但是闭门造车狂写的话，除非是绝世天才，不然就掰了， : 多看大师等级的程式码绝对比自己死命写进步的快好几倍。 : 就像音乐跟绘画，多看多接触多欣赏别人的经典，绝对是好的。 : 但是看要看得懂，光看到程式码看不懂背後设计的精髓的话还是没用， : 要看懂那些东西你得先有基本的资料结构、演算法跟进阶的设计模式等功力， : 当然，除了理论以外，程式语言本身你也要熟捻。 : 所以以上基本教材先念熟，这是进入高阶殿堂的钥匙。 : 这些东西没有的话，想要进殿堂连门都没有。 : 然後去找网路上有些「xx源码解析」， : 里面都会找一些经典的程式码，然後解释背後的设计理念， : 看懂就是你的，这个时候你对软体的结构就开始有点概念了。 : 看不懂的话，你就去好一点的讨论版问， : 因为到这个程度，死大学生讨作业的烂版已经不能满足你问题的难度了。 : 高手不少，但是既然是高手，他们对无聊的问题就一点兴趣也没有， : 要把他们钓出来你的问题就要够好，他们遇到好的问题就会掏心掏肺， : 因为他们有些人很无聊，每天都在看板，但是很少发文，因为没的发挥， : 难得有机会发挥的话，他们就不会放过，所以你要看这个。 : http://catb.org/~esr/faqs/smart-questions.html : 当然阅读吸收很重要，但是还要多写， : 写没多久你就会发现开发环境很重要，选一个好的 IDE，绝对不要虐待自己。 : 选用的时候要多看多问多评估，因为这是你写程式的时候会一直接触的东西， : 程式设计师需要保持快乐，不快乐的程式设计师就是没有产能的程式设计师。 : 程式码累积一定程度之後你会发现程式码的整理也很重要， : 这个时候你可能会注意到有版本管理系统这种东西， : 当然，选用之前要多评估，烂的版本管理系统会让你大脑发烟。 : 也许有一天你需要回头用或是看自己的程式码， : 你会发现干他妈的写这个程式的人是他妈的猪吗！？为什麽我一行都看不懂！？ : 所以你需要写文件跟注解，请选一个好的文件系统。 : 文件也可以避免别人看着你的程式码骂你是他妈的猪。 : 而且懒惰是程式设计师的美德，如果你不想一直解释重复的问题， : 写好文件就是让你脱离当幼稚园老师的不二法门：「Read The Fucking Manual」 : 搞不好你在当学生的时候就可以作到以上全部， : 然後不管你工作了没有，你可能会开发大型软体， : 我是说大型软体，一个人写不出来的那种。 : 这个时候你会发现写软体就像是盖房子，需要工程方法， : 一堆程式设计师在一起没有统筹跟良好方法的话，是作不出好的大东西的， : 大东西可能做的出来，但是不好的大东西不叫做大程式，叫做大便， : 真的，因为你会看着那堆程式码整天直呼「shit!」 : 软体工程，不过他不是大型软体才需要， : 你最好在越过学徒阶段之後就要抱有软体工程的概念。 : 如果你有幸坚持到这一步， : 当别人问你是不是高手的时候， : 你也许就可以回答他说「我懂一点点程式设计」然後跟他分享你的经验了。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 128.125.87.33