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

[mpk (小賴x)]

其實這個真的要考慮到很多方面
要看你的好是讓程式看起來很漂亮
還是要方便修改
比方說程式高手 或許別人需要花二三百行寫的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)
→ adrianshum:長短與易維護與否並無一定關係. 我見過
→ adrianshum:太多大量 copy and paste 改一點點的又
→ adrianshum:臭又長的 code, 這些絕對是又長又難維
→ adrianshum:護的垃圾...
→ adrianshum:個人覺得高手才不會硬為少較少行數而用
→ mpk:當然不是指又臭又長的垃圾
→ adrianshum:晦澀的寫法, 為了短不惜寫得難明反而是
→ adrianshum:新手常犯的錯誤
→ mpk:比方說 這一行明明有兩個意思在裡面
→ mpk:有些高手就會常以一行來解決
→ adrianshum:你說這種情況反而是新手常犯比較多..
→ adrianshum:至少依我工作一路來看, 寫得好的人, 常
→ mpk:我就曾經解別人的bug 最後是把那行拆開來處理
→ adrianshum:會為了易懂反而多寫東西, 程式短通常是
→ mpk:那個bug的發生是因為 整個系統被改掉而產生
→ adrianshum:因為整個流程想得清楚帶來的. 倒是有些
→ mpk:如果當初兩個意思的事情 能分開來寫
→ adrianshum:人寫得不思長進, 就會整天在省variable
→ adrianshum:名稱幾個字, 或 { } 這類, 但程式流程
→ adrianshum:就寫得左堆右砌沒有細心思考... :(
→ adrianshum:其實我之前說: 維護一下爛 code 也能增
→ adrianshum:進功力, 其實就是像 m 君那種情況, 當
→ adrianshum:看過差的 code, 感受過它為維護者帶來
→ adrianshum:的痛苦, 以後就會避免犯上前人的問題.
→ kuninaka:去看一下國際C語言混亂代碼大賽的作品XD
→ mpk:對我來說能清楚表達意思的就是好code
→ kuninaka:好擴充 易懂 效率好XD
→ mpk:好的code能讓人在精神不太好的時候 依然看得懂
→ kuninaka:能在中間平衡  就看功力了
→ kuninaka:除非有特殊需求 否則沒必要寫到沒人看懂
→ mpk:其實那個不是讓人看不懂 而是只有本人看得懂
→ mpk:就像是大師作品一樣 初學者一定看不懂
推 adrianshum:同意 mpk 所言. 我一句寫程式(或要求別
→ adrianshum:人) 最基本的就是 可讀性. 效率我反而
→ kuninaka:所以我才說看需求阿
→ kuninaka:看你寫的目的是什麼 功能是什麼
→ kuninaka:山不轉路轉 CODE是人在寫
→ adrianshum:不會那麼錙銖必較, 有時用一點心, 不要
→ adrianshum:寫明顯是很笨的低效率 code, 就已經足
→ adrianshum:夠了
→ kuninaka:這沒有一定的準則 一切依需求
→ adrianshum:我覺得無論什麼需求, 可讀性是不可能視
→ adrianshum:若無賭的. 個人認為這些是寫程式的道德
→ adrianshum:問題, 實在不能用需求胡混過去...
→ kuninaka:國際C語言混亂代碼大賽裡面就沒啥可讀性
→ kuninaka:還有用程式碼化圖的
→ kuninaka:道德就言重了 有些是寫給自己爽的
→ adrianshum:那個就是故意要寫得難明吧... 那很不同
→ adrianshum:吧 XDD 我自己是寫爽也盡量寫得讓以後
→ adrianshum:的自己也看得懂