Re: [請益] 程式該怎麼越寫越好呢

看板Programming作者 (小賴x)時間15年前 (2009/08/21 15:07), 編輯推噓1(1049)
留言50則, 3人參與, 最新討論串7/34 (看更多)
其實這個真的要考慮到很多方面 要看你的好是讓程式看起來很漂亮 還是要方便修改 比方說程式高手 或許別人需要花二三百行寫的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)

08/21 15:11, , 1F
長短與易維護與否並無一定關係. 我見過
08/21 15:11, 1F

08/21 15:11, , 2F
太多大量 copy and paste 改一點點的又
08/21 15:11, 2F

08/21 15:11, , 3F
臭又長的 code, 這些絕對是又長又難維
08/21 15:11, 3F

08/21 15:11, , 4F
護的垃圾...
08/21 15:11, 4F

08/21 15:12, , 5F
個人覺得高手才不會硬為少較少行數而用
08/21 15:12, 5F

08/21 15:13, , 6F
當然不是指又臭又長的垃圾
08/21 15:13, 6F

08/21 15:14, , 7F
晦澀的寫法, 為了短不惜寫得難明反而是
08/21 15:14, 7F

08/21 15:14, , 8F
新手常犯的錯誤
08/21 15:14, 8F

08/21 15:14, , 9F
比方說 這一行明明有兩個意思在裡面
08/21 15:14, 9F

08/21 15:15, , 10F
有些高手就會常以一行來解決
08/21 15:15, 10F

08/21 15:17, , 11F
你說這種情況反而是新手常犯比較多..
08/21 15:17, 11F

08/21 15:17, , 12F
至少依我工作一路來看, 寫得好的人, 常
08/21 15:17, 12F

08/21 15:18, , 13F
我就曾經解別人的bug 最後是把那行拆開來處理
08/21 15:18, 13F

08/21 15:18, , 14F
會為了易懂反而多寫東西, 程式短通常是
08/21 15:18, 14F

08/21 15:19, , 15F
那個bug的發生是因為 整個系統被改掉而產生
08/21 15:19, 15F

08/21 15:19, , 16F
因為整個流程想得清楚帶來的. 倒是有些
08/21 15:19, 16F

08/21 15:20, , 17F
如果當初兩個意思的事情 能分開來寫
08/21 15:20, 17F

08/21 15:20, , 18F
人寫得不思長進, 就會整天在省variable
08/21 15:20, 18F

08/21 15:21, , 19F
名稱幾個字, 或 { } 這類, 但程式流程
08/21 15:21, 19F

08/21 15:21, , 20F
就寫得左堆右砌沒有細心思考... :(
08/21 15:21, 20F

08/21 15:24, , 21F
其實我之前說: 維護一下爛 code 也能增
08/21 15:24, 21F

08/21 15:24, , 22F
進功力, 其實就是像 m 君那種情況, 當
08/21 15:24, 22F

08/21 15:24, , 23F
看過差的 code, 感受過它為維護者帶來
08/21 15:24, 23F

08/21 15:25, , 24F
的痛苦, 以後就會避免犯上前人的問題.
08/21 15:25, 24F

08/21 15:25, , 25F
去看一下國際C語言混亂代碼大賽的作品XD
08/21 15:25, 25F

08/21 15:25, , 26F
對我來說能清楚表達意思的就是好code
08/21 15:25, 26F

08/21 15:26, , 27F
好擴充 易懂 效率好XD
08/21 15:26, 27F

08/21 15:26, , 28F
好的code能讓人在精神不太好的時候 依然看得懂
08/21 15:26, 28F

08/21 15:27, , 29F
能在中間平衡 就看功力了
08/21 15:27, 29F

08/21 15:27, , 30F
除非有特殊需求 否則沒必要寫到沒人看懂
08/21 15:27, 30F

08/21 15:29, , 31F
其實那個不是讓人看不懂 而是只有本人看得懂
08/21 15:29, 31F

08/21 15:30, , 32F
就像是大師作品一樣 初學者一定看不懂
08/21 15:30, 32F

08/21 15:30, , 33F
同意 mpk 所言. 我一句寫程式(或要求別
08/21 15:30, 33F

08/21 15:30, , 34F
人) 最基本的就是 可讀性. 效率我反而
08/21 15:30, 34F

08/21 15:31, , 35F
所以我才說看需求阿
08/21 15:31, 35F

08/21 15:31, , 36F
看你寫的目的是什麼 功能是什麼
08/21 15:31, 36F

08/21 15:31, , 37F
山不轉路轉 CODE是人在寫
08/21 15:31, 37F

08/21 15:32, , 38F
不會那麼錙銖必較, 有時用一點心, 不要
08/21 15:32, 38F

08/21 15:33, , 39F
寫明顯是很笨的低效率 code, 就已經足
08/21 15:33, 39F

08/21 15:33, , 40F
夠了
08/21 15:33, 40F

08/21 15:33, , 41F
這沒有一定的準則 一切依需求
08/21 15:33, 41F

08/21 15:35, , 42F
我覺得無論什麼需求, 可讀性是不可能視
08/21 15:35, 42F

08/21 15:36, , 43F
若無賭的. 個人認為這些是寫程式的道德
08/21 15:36, 43F

08/21 15:36, , 44F
問題, 實在不能用需求胡混過去...
08/21 15:36, 44F

08/21 15:42, , 45F
國際C語言混亂代碼大賽裡面就沒啥可讀性
08/21 15:42, 45F

08/21 15:42, , 46F
還有用程式碼化圖的
08/21 15:42, 46F

08/21 15:44, , 47F
道德就言重了 有些是寫給自己爽的
08/21 15:44, 47F

08/21 16:12, , 48F
那個就是故意要寫得難明吧... 那很不同
08/21 16:12, 48F

08/21 16:12, , 49F
吧 XDD 我自己是寫爽也盡量寫得讓以後
08/21 16:12, 49F

08/21 16:13, , 50F
的自己也看得懂
08/21 16:13, 50F
文章代碼(AID): #1AZaV8sA (Programming)
討論串 (同標題文章)
文章代碼(AID): #1AZaV8sA (Programming)