伊莉討論區

標題: 怎麼樣可以判斷程式寫得好不好? [打印本頁]

作者: HANK_CHAN 時間: 2019-6-18 09:11 PM 標題: 怎麼樣可以判斷程式寫得好不好?

尤其對本程式菜雞來說，寫腳本會能用就是幸運了
不如繪圖那般可以看出大師或老手的差別

譬如說我一個程式只會用if或for來寫很多重複簡單的計算
是不是就很low ，還是有甚麼用了比較潮的招式之類的哈哈

大大可以解惑一下嗎? 感謝

作者: codewice 時間: 2019-6-18 11:52 PM

程式的優劣大致上會從正確性、效率、可讀性、可維護性去判斷品質。

正確性不用說，會出錯的程式就沒用了。我們無法確保總是 bug free，至少在某一個 function 之中，已知的測試條件都要能正確執行。

接著還會希望這段程式碼的效率不要太差，有些寫法一看就知道效率不好。既然程式碼需要被閱讀，那麼可讀性就很重要：是否能夠清楚地知道這段程式碼在做些什麼事情。通常可讀性好的程式碼，維護的難度也會稍微低一點。為了更容易維護，經常也會給程式碼加上一些抽象層。但是，抽象層也常常帶來效率的流失，所以在效率跟維護之間要抓一個平衡。

只會用 if / for 來寫程式，代表的是你對語言、工具或是框架、架構的掌握程度不夠，很難寫出優秀的程式碼。如果以寫作來比喻寫程式，並不是堆砌華麗的詞彙就能寫出好文章，但是字彙量如果只有國小的程度，要把文章寫好的難度是高了一些。

作者: kwj 時間: 2019-6-19 12:18 AM

本帖最後由 kwj 於 2019-6-19 12:22 AM 編輯

先糾正一個觀念，程式碼沒有什麼「寫法潮不潮」的問題，只有「容不容易看懂」、「執行效率快不快」或者「容不容易擴充」的問題。而在還沒有很熟練以前，比起執行效率或靈活性，建議應該優先考慮可讀性。

如果很多 if 和 for 指的是用了很多層巢狀的 if 和 for 的程式碼，那毫無疑問是不好的程式碼，但問題不在於寫法本身潮不潮，而是在於這種寫法絕對很難看懂。

而要「看」出好的程式碼，其實只要先嘗試去看看別人寫的程式碼，然後很快就會知道什麼是「不好的程式碼」了。如果覺得自己太弱看不懂別人的程式碼，那麼另一種選擇是～自己把程式碼寫好以後，過一個月再回來看它，看看自己看得懂多少、要花多少時間看懂。雖然說並沒有確切的指標，不過基本上一段好的一兩百行的程式碼，兩三分鐘內應該要能大致看懂。

作者: jackyo04 時間: 2019-6-20 10:21 AM

一切都是講究經驗，程式語言通常都是以可讀性為優先，自己寫的程式，自己要看得懂之外，別人也要可以輕鬆駕馭，至於會不會出錯，程式裡面的bug通常都是在規劃時沒規劃好，或設計時，自己看錯，或誤會行為才會些bug....這些通常發生在比較複雜的專案上

我以前也跟你差不多，會if else、switch case、for、while.....用基本的判斷方式、迴圈、陣列..寫出一個專案
然後在公司用這些東西用了快半年...之後經過一個前輩的教導後才開始去翻一些手冊精進自己...
雖然說用基本的判斷方式也不是不好，但往往會讓程式碼變得很長一大串，導致去看的時候還要花上許多時間..

作者: neqkwos1003 時間: 2019-6-20 07:35 PM

我記得資料結構這個學習是可以判斷程式效率的，像用 if或單純使用變數，都有一個指標可以告訴我們效率好不好，找找看吧！

作者: ddttdtxb 時間: 2019-6-20 09:31 PM

如果要學習讓程式寫得好一些… 是可以往設計模式與程式重構的方面去找資料來看。

不過呢，初期還是以程式能「作對事情」最為要緊，
若程式作的事和預期的不一樣，再漂亮的程式碼也只是垃圾。

以從事程式相關工作的經驗來說，有些時候無關乎「要不要寫漂亮的程式」，
而是不得不對現實低頭，面對那些欠了許多技術債，或背了許多歷史包衭的程式碼…
能看懂它們是在作些什麼… 就要花上不少力氣了，再來還要把它們改成需要的功能…

如果最後還有留下一絲力氣的話，再去思考所謂漂亮的程式吧！

改的時候就用"漂亮"的方式來寫？
別鬧了！那只會讓你在幾個星期後，在兩種(或更多)天差地遠的寫法中，更看不懂它們是在作什麼的。
大多數的人，是會忘記幾星期前就沒有接觸(維護)的程式。(通常是更短)

所以… 所謂漂亮的程式，其實就是「在幾星期後，能輕易看懂是在作啥的程式碼」…

作者: kentcat3030 時間: 2019-7-17 01:12 PM

本帖最後由 kentcat3030 於 2019-7-17 01:14 PM 編輯

判斷程式寫得好不好，很難定義．
現階段，我覺得，沒有任何人敢說自己寫出來的程式是完美的．
商用程式，就必須符合客戶需求，一切也如上面各位先進所言．
先符合需求，在慢慢改善其他，如效率、相容性....等等．

高手，尚無法寫出客戶需求，因為考慮仔細，還會考慮到將來的擴充性等等．．．
新手，用簡單的思考，繁瑣多餘的語法，目前，立即可達到客戶需求．
這時，誰寫的好？(客戶來評估的話)．

只要自己寫出來的，讓自己滿意，就是好！
自然而然，自己就會想要精進，改進，深入.....

上面各位先進有提到可讀性、維護性等問題．
我會建議，各個運作區塊前，Rem一段區塊解說．
至於條件，迴路等混和在一起的．
在每個條件後面，迴路後面，加上Rem甚麼語法的終點
例如：

// 判斷ＸＸＸＸ
if A>B then
　.....
　while
　　....
　　....
　loop //while
　case
　　....
　　....
　end //case
end //if A>B then

這樣的話，將來，不管是自己或是交給別人維護，會省下很多時間，也容易閱讀．

作者: stephenwei_lu 時間: 2019-7-18 09:44 AM

以個人觀點來說, 我昨天玩傳說, 有人罵我笨, 但是我覺得不差啊

以產品觀點來說, 我被人罵笨, 如果不爽擺爛, 那大家一起輸, 一起配合,取得默契, 那贏得機會較高

以個人觀點來說, 不用在乎好壞, 通常這個時候, 很多人會說, 多看別人的code

以產品觀點來說, 看一下資深寫的模組或者class ,你可以一邊引用,一邊看別人是怎麼寫的

作者: burtonway 時間: 2020-10-20 01:43 AM

個人覺得先模仿,然後再創新,剛開始學先複製別人的程式,學著修改,然後整合,最後熟練後才學著簡化,畢竟程式也是一種語言,用來溝通用的.

作者: din1002 時間: 2020-11-7 10:16 PM

不用太在意這個吧! 程式只要功能性達到就好其次才是效能最後才是寫法用了一些少用的funcation 去呈現code 反而讓後面的人維護困難

作者: klampard 時間: 2020-11-26 08:47 PM

每一個人對好的定義都不同,我對好的定義是其他人能不能看明白你的代碼, 然後在去tune效能

作者: jaw090101 時間: 2021-1-8 02:00 AM

我覺得要看你著重什麼吧!
軟體我覺得就穩定性/可讀性/佔用記憶體多寡
個人認為只要用的技巧很高，都不會具有什麼可讀性，穩定性有待商確...
就好像我主管寫程式很強，但是程式內Bug一堆，後面的人要解Bug看不懂也很難解...
簡單像是if /while/for/try .... 簡單的應用，但強在穩定性很高...
像是車用一些，是有限定語法，還有強制的規範，所以好不好，重點是在於你要寫的是什麼東西/用在那! 如果你寫了一個只有你自己看的懂自己能編，最後也只有自己能用，算的上好嗎?
我覺得現在已經是Team work的時代，寫只有自己能編的，唯一的好處就是留任度會高些...
但也要看是做什麼，如果工作沒有舉足輕重，那也是白搭...

作者: Ateach 時間: 2021-1-20 09:19 PM

先追求明確的邏輯吧
用自己的邏輯思維去寫就行了
程式邏輯寫的清楚
bug就少
不用追求可讀性
寫給同事看的介面才需要可讀性
內部實作你自己看的懂就夠了

作者: qwer8964 時間: 2021-2-25 01:58 PM

提示: 作者被禁止或刪除內容自動屏蔽

作者: he01204046 時間: 2021-12-30 09:41 PM

寫程式都是循序漸進的。

你要先知道怎麼寫，例如有哪些可以用的function

再來就是使用這些函數寫出符合功能可以運作的程式

最後才是進行程式的優化。

沒有人一開始就很會寫程式，一定是累積經驗後知道該怎麼寫才會有效率的。

作者: w12463 時間: 2022-8-22 07:13 PM

能讓你幾個月後回來看，馬上能搞懂且能繼續改寫的，都是好程式
最好註解與邏輯運用還能讓其他人易上手
不然那種高效率字數又少的程式，一旦要自己接手會...

作者: kelibox 時間: 2023-11-4 05:38 PM

寫程式先講求正常功能在講求效能。
人一開始先求寫出正常程式，之後累積經驗才知道如何寫會有效率。
模式設計與重構是為可讀性與維護性所做。

作者: zhangwayne 時間: 2024-8-30 10:50 PM

一個程式寫得好不好，從客觀的角度來看，個人覺得有幾點基本要求還是先滿足︰
1.符合需求︰程式最後的成品，一定要符合需求。
2.功能運作要正確︰程式的功能要能正常運行，而且結果輸出也要正確。
3.程式風格統一，而且有淺顯易懂的註解。
4.程式閱讀容易且架構清析易懂︰雖然程式最主要是給電腦看的，但後續的維護還是必須由人來維護，所以人要能容易看得懂還是很重要的。
5.有詳細的說明文件︰這條是建立大的系統程式上的，雖然程式只要架構清析好閱讀，很多東西都可以從程式碼獲得，但記得你永遠不會只有自己一個人開發，有一天總是會是團隊成員，所以有很多交流都是需要靠文件的，所以千萬別輕視文件的重要性。

個人覺得一個程式的好與壞首先必須先滿足以上五點，再來探討程式用什麼理念來規刜它的程式架構和整個資料流的處理，其實到這個階段，可以說哲學的理念已經佔比較大的重比了，所以這個可以說是有點主觀的判斷評論。

歡迎光臨伊莉討論區 (http://a04.eyny.com/)