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

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.131.68.5 ※ 编辑: mpk 来自: 220.131.68.5 (08/21 15:10)