Re: [討論] Clean Code vs Efficiency

看板Soft_Job作者 ((const *))時間9年前 (2016/05/28 02:27), 9年前編輯推噓37(37推 0噓 198→)
留言235則, 9人參與, 最新討論串2/2 (看更多)
其實這要看你的抽象化程度 一般在閱讀程式的時候除非有必要，否則都不會追究到程式架構的最底端 我們都會在抽象化程度偏高的地方瀏覽，真的有需要才會再往下一層去檢視實作 如果你的程式會讓閱讀者想要看裡面的實作通常代表 1. 你的設計沒辦法交代清楚它到底確切在做什麼？需要什麼？使用時機？使用限制？… … 一些慣例(命名慣例，design patterns…)可以讓閱讀者一眼就取得這些隱含的資訊 2. 這個東西的功能太神奇了(程式行為超出預期)，超出一般人的預期 像是 qt 的 signal slot 機制就會讓第一次接觸的人摸不著頭腦 因為它用名稱來配對 signal slot 的做法不是標準的 c++ 語言可以做到的 3. 底層程式有蟲，要抓蟲啦 4. 你的 code 很漂亮，很能夠引人入勝，讓人家很想一直繼續往下看 XD 所以說，要是有一個好的設計 那麼閱讀者根本就不需要去看那些效率取向的，最佳化過後的難懂的實作 因為你的設計就已經提供給閱讀者他想要的所有資訊 根本不需要自己去閱讀實作慢慢推敲啊 以上是對於提升整個系統整體的可讀性，如果是要考慮實作本身的可讀性的話 那麼重點就會放在職責的切割和分配 最快最有效率的檢查方式就是看在同一個 block 內的 code 的抽象化程度是否差不多 要是上一行是系統頂層的操作，下一行又是底層的東西，看起來一定很痛苦吧 而且這樣把兩個不同階層的東西綁在一起就是在製造多餘的相依性 回到原 po 演算法取捨的問題，我會推 policy based design 它不但保留了程式的擴充性，又不損失效能，超美的 XD ※ 引述《gitignore (git)》之銘言： : 最近上班在思考這問題 : 假如今天有個 O(log n) 的方法可以寫出一個東西 : 但是程式碼無法簡化 以後維護的人應該也會很痛苦 : 因為不直觀 : 另一個就是程式碼非常簡潔 但就一定是O(n) 甚至 O(n^2) : 不知道大家會傾向於哪種? : 我個人是比較喜歡clean code 因為過一陣字自己回來維護也比較快上手 : 但是感覺在學校學這麼多 就是要能寫出效率較好的程式碼 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.217.64.252 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1464373625.A.CE0.html ※ 編輯: CoNsTaR (49.217.64.252), 05/28/2016 02:29:15
推
05/28 08:07, , 1F
觀念正確，腦袋清楚
05/28 08:07, 1F
→
05/28 08:09, , 2F
除非人家想要改Code，否則對於一個呼叫者來說
05/28 08:09, 2F
→
05/28 08:09, , 3F
根本懶得看細節
05/28 08:09, 3F
→
05/28 08:11, , 4F
人與人之間是合作整合的關係，各自負責不同的部分
05/28 08:11, 4F
→
05/28 08:12, , 5F
不是都做一樣的事，然後相互比較看誰強，這跟學校不同
05/28 08:12, 5F
→
05/28 08:13, , 6F
Code太髒，苦的是接手的人，或者是未來的自己
05/28 08:13, 6F
推
05/28 10:48, , 7F
不是每個人的心態都這麼健康的...
05/28 10:48, 7F
推
05/28 10:57, , 8F
聽不懂抽象化是什麼的比想像中的多...
05/28 10:57, 8F
→
05/28 11:29, , 9F
聽不懂又整天掛在嘴上講的可怕
05/28 11:29, 9F
推
05/28 13:25, , 10F
看別人的Code，起手勢不是「寫這麼爛都看不懂」
05/28 13:25, 10F
推
05/28 20:44, , 11F
請問policy based design的overloading的Template泛型
05/28 20:44, 11F
→
05/28 20:44, , 12F
最終runtime實現方式也是一堆case或if else在那比對？
05/28 20:44, 12F
→
05/28 20:45, , 13F
這樣效率會好嗎？不曉得我認知有沒有錯？
05/28 20:45, 13F
要是每種 policy 的組合都有可能在執行時期用到的話 就會像你說的 要選擇用哪個特化版勢必要一堆 if else switch 不過要是你能夠忍受整個程式除了 main 以外所有函數都是 function template 的話 把目前的組合當作 template parameter 就不必一直重複判斷 整個程式可以只出現一次 switch XD 不過這種需要"組合搭配"的 本來就不會選擇用 policy based 這種情況下多型會適合很多
推
05/28 21:41, , 14F
可是瑞凡 在接維護的人難免都會需要改程式
05/28 21:41, 14F
→
05/28 21:41, , 15F
這個時候就需要看程式碼
05/28 21:41, 15F
→
05/28 21:41, , 16F
你這篇的角度比較像是 api 使用者
05/28 21:41, 16F
其實我覺得會需要"改程式"(而非只改功能) 就是有太多不該有的相依性 也就是職責的切割和分配一定出了問題 例如用你想要 增加/刪除/替換 某功能當例子好了 1. 假設你想增加某功能 會發現找不到一個適合的坑把新功能加進去 因為另一個佔著同一個坑的程式片段還負責了其他事情 所以如果你也想佔這個坑 勢必得一併把這些"其他事情"也寫進你的東西裡 否則塞不進這 個坑 2. 假設你想移掉一個功能 結果你發現你需要往下一層看實作 那通常代表你想移掉的功能可能又順便做了一點點其他事情 (它可能負責提供介面也負責做事，這聽起來沒什麼大問題，但是如果你把它直接刪掉， 那少了這個介面，上下就兜不起來了，如果一開始就把介面分開寫，你就可以直接刪掉原 本的功能，然後提供一個什麼都不做的版本銜接介面，介面再銜接上下) 或者是它本來就光明正大的被包含在一個負責不只一件事情的東西裡 所以你沒辦法直接移除它 不是要去修改實作就是要自己再寫另一份取代原本的 3. 替換同刪掉 不過這都只是我自己的想法 因為我根本還沒有工作過 唯一的合作夥伴就是自己 所以也不知道外面業界到底生態如何(我還只有大一)所以這些還是看看就好 XDD ※ 編輯: CoNsTaR (163.18.32.152), 05/29/2016 08:14:01
推
05/29 09:04, , 17F
其實有時候只是老闆希望產生的結果從 a 改成 b
05/29 09:04, 17F
→
05/29 09:04, , 18F
而這個演算法剛好是產生結果的核心部分
05/29 09:04, 18F
→
05/29 09:04, , 19F
這樣不管怎麼抽離都會需要改程式碼
05/29 09:04, 19F
→
05/29 09:04, , 20F
所以程式的可讀性與文件才會這麼重要
05/29 09:04, 20F
→
05/29 09:04, , 21F
這也是為什麼我覺得你的說法比較接近 api 使用者
05/29 09:04, 21F
推
05/29 10:29, , 22F
kiwatami 你指的應該是BO(or DAL)使用者吧
05/29 10:29, 22F
推
05/29 10:32, , 23F
只要當初寫code的人體質很差，很容易就會維護到這種三四
05/29 10:32, 23F
→
05/29 10:32, , 24F
個功能都擠到一個function裡做
05/29 10:32, 24F
推
05/29 10:39, , 25F
但這些問題會一直累積到要改「機制」or「規則」的那個人
05/29 10:39, 25F
→
05/29 10:39, , 26F
身上
05/29 10:39, 26F
推
05/29 10:50, , 27F
不用在意業界生態如何，用對的方式寫code就好
05/29 10:50, 27F
推
05/29 10:57, , 28F
不要被「實務上」魔人牽著走；因為我認為「因為我不懂，
05/29 10:57, 28F
→
05/29 10:57, , 29F
所以不這樣做」不等於「實務上」
05/29 10:57, 29F
推
05/29 11:02, , 30F
情境大致上是這樣：「為什麼不畫Uml?」、「為什麼不用de
05/29 11:02, 30F
→
05/29 11:02, , 31F
legate?」、「為什麼function一次做五件事？」答案開頭
05/29 11:02, 31F
→
05/29 11:02, , 32F
都會是「實務上沒人這樣做...」
05/29 11:02, 32F
推
05/29 11:04, , 33F
最後一個問題改成「為什麼function做五件事不拆出來？」
05/29 11:04, 33F
推
05/29 11:10, , 34F
我指的 api 使用者其實就是一般開發者
05/29 11:10, 34F
→
05/29 11:10, , 35F
通常不需要管原始碼 只要負責呼叫 method 就好
05/29 11:10, 35F
→
05/29 11:10, , 36F
這樣才符合原 po 提到的 1234點
05/29 11:10, 36F
→
05/29 11:10, , 37F
接維護的人不太可能不需要讀原始碼
05/29 11:10, 37F
還有 159 則推文
還有 25 段內文
→
06/01 12:47, , 197F
他提倡較好讀較好改...沒有到不用讀不用改吧
06/01 12:47, 197F
※ 編輯: CoNsTaR (163.18.32.152), 06/01/2016 15:44:49 ※ 編輯: CoNsTaR (163.18.32.152), 06/01/2016 17:14:41 ※ 編輯: CoNsTaR (163.18.32.152), 06/01/2016 18:09:51
推
06/02 09:34, , 198F
原 po 第一段提到"程式為什麼讓人想看裡面的實作"
06/02 09:34, 198F
→
06/02 09:34, , 199F
沒有為什麼 要改就是要看 這4點只符合一般使用者
06/02 09:34, 199F
→
06/02 09:34, , 200F
並不符合一般接手程式的情況
06/02 09:34, 200F
→
06/02 09:35, , 201F
但之後原 po 又說其實要讀 只是範圍小了點
06/02 09:35, 201F
→
06/02 09:35, , 202F
這不是完全跟你前面幾次回覆要說的完全不同了嗎?
06/02 09:35, 202F
→
06/02 09:35, , 203F
之後原 po 又提到"要是演算法不合需求了 重寫就好"
06/02 09:35, 203F
→
06/02 09:35, , 204F
"也不需要看程式內的實作"
06/02 09:35, 204F
→
06/02 09:35, , 205F
"要表達程式資訊最棒的方法是使用慣例"
06/02 09:35, 205F
→
06/02 09:35, , 206F
"因為註解文件又累又醜"
06/02 09:35, 206F
→
06/02 09:35, , 207F
並不是炮你表達 而是以上這些觀念都是不對的
06/02 09:35, 207F
→
06/02 09:35, , 208F
原原 po 的問題不成立是因為該寫的地方不用考慮複雜度
06/02 09:35, 208F
→
06/02 09:35, , 209F
而不是你說的"只要架構夠好根本不需要讀"
06/02 09:35, 209F
→
06/02 09:35, , 210F
這不是表達的問題 這是你真的這樣認為才會這樣說
06/02 09:35, 210F
→
06/02 09:35, , 211F
因為你覺得這個開發模式太美妙 想推廣給大家
06/02 09:35, 211F
→
06/02 09:35, , 212F
但不得不承認的是很多情況並不是開發模式可以解決的
06/02 09:35, 212F
→
06/02 09:35, , 213F
但你又堅持可以 只是對方貫徹的不夠徹底
06/02 09:35, 213F
→
06/02 09:35, , 214F
你最後也說很多結論有適用與不適用的地方
06/02 09:35, 214F
→
06/02 09:35, , 215F
但我提出了不適用的地方 你卻一直反駁這其實適用
06/02 09:35, 215F
→
06/02 09:35, , 216F
無法接受這個事實的不就是你自己嗎?
06/02 09:35, 216F
→
06/02 09:35, , 217F
不是體質不夠好 就算體質再好你還是要讀
06/02 09:35, 217F
→
06/02 09:35, , 218F
這這是我一直想告訴你的 但你一直不接受
06/02 09:35, 218F
→
06/02 09:35, , 219F
最後你的回覆不就是我前面一直想說的嗎?
06/02 09:35, 219F
→
06/02 09:35, , 220F
但你又把我打成了你的方法無用論者
06/02 09:35, 220F
→
06/02 09:35, , 221F
明眼人都看得出來很聰明那段是在酸人寫 code 架構差
06/02 09:35, 221F
→
06/02 09:35, , 222F
又死腦筋不願改進
06/02 09:35, 222F
→
06/02 09:35, , 223F
我只是覺得這對討論一點幫助也沒有
06/02 09:35, 223F
→
06/02 09:35, , 224F
這不是誇張了點 這是誇大成效 你要做的不是描述各種眉
06/02 09:35, 224F
→
06/02 09:35, , 225F
角
06/02 09:35, 225F
→
06/02 09:35, , 226F
而是忠實傳述這個開發模式的優點與目的就好
06/02 09:35, 226F
→
06/02 09:35, , 227F
不用讀 不用改 不用註解與文件云云根本是多餘又錯誤的
06/02 09:35, 227F
→
06/02 09:35, , 228F
可以的話請你回頭看看我在14樓回你什麼
06/02 09:35, 228F
→
06/02 09:35, , 229F
是不是就是你說的某些不適用的情況？
06/02 09:35, 229F
→
06/02 09:35, , 230F
但結果呢？你不接受 才有了這一大篇最後都歪樓的討論
06/02 09:35, 230F
→
06/02 09:35, , 231F
但最後你又接受了... 卻又說我在鑽牛角尖
06/02 09:35, 231F
→
06/02 09:35, , 232F
但我要表達的就是你最後結論提到的
06/02 09:35, 232F
→
06/02 09:35, , 233F
有適用與不適用的情況 這點而已
06/02 09:35, 233F
→
06/02 09:35, , 234F
也是你一開始堅持絕對沒有的東西
06/02 09:35, 234F
→
06/02 22:12, , 235F
嗯…很好啊 戰鬥力滿分 繼續保持……
06/02 22:12, 235F
‣ 更多 CoNsTaR 的文章
文章代碼(AID): #1NI95vpW (Soft_Job)
‣ 更多 CoNsTaR 的文章
文章代碼(AID): #1NI95vpW (Soft_Job)