其實這個真的要考慮到很多方面 要看你的好是讓程式看起來很漂亮 還是要方便修改 比方說程式高手 或許別人需要花二三百行寫的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)