[討論] Clean Code vs Efficiency已刪文

看板Soft_Job作者 (git)時間8年前 (2016/05/25 08:25), 8年前編輯推噓22(22推 0噓 46→)
留言68則, 34人參與, 最新討論串1/2 (看更多)
最近上班在思考這問題 假如今天有個 O(log n) 的方法可以寫出一個東西 但是程式碼無法簡化 以後維護的人應該也會很痛苦 因為不直觀 另一個就是程式碼非常簡潔 但就一定是O(n) 甚至 O(n^2) 不知道大家會傾向於哪種? 我個人是比較喜歡clean code 因為過一陣字自己回來維護也比較快上手 但是感覺在學校學這麼多 就是要能寫出效率較好的程式碼 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 66.76.81.5 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1464135945.A.0E8.html
→
05/25 08:30, , 1F
模組化加詳細演算法文件，讓後人決定要不要改。
05/25 08:30, 1F
→
05/25 08:31, , 2F
我覺得跟 clean 衝突的通常是開發時間而不是執行效率
05/25 08:31, 2F
推
05/25 08:38, , 3F
O(log n), 然後職責拆分出去，替他寫足單
05/25 08:38, 3F
→
05/25 08:38, , 4F
元測試
05/25 08:38, 4F
推
05/25 08:58, , 5F
如果是 critical 的 operation 當然是用 O(log n)
05/25 08:58, 5F
→
05/25 08:59, , 6F
現實情況是,clean跟不是clean的效率差通常只是O(log n）與
05/25 08:59, 6F
→
05/25 08:59, , 7F
O(log n)+C的差而已
05/25 08:59, 7F
→
05/25 09:00, , 8F
差到級數不一樣的時候，連演算法都不同了，來討論clean不
05/25 09:00, 8F
→
05/25 09:00, , 9F
clean的根本沒有意義
05/25 09:00, 9F
應該這麼說 為了解決一個問題 有兩種演算法可以用 一個是O(n)以上的演算法 很直觀 一種是O(log n) 但是是很特殊的演算法 所以一般人第一眼看不出來在幹嘛 ※ 編輯: gitignore (66.76.81.5), 05/25/2016 09:07:07
→
05/25 09:14, , 10F
如果很頻繁使用到就用比較快的寫法，然後寫說明文件
05/25 09:14, 10F
→
05/25 09:16, , 11F
想都不想...一定選 logn 的, 個人習慣
05/25 09:16, 11F
→
05/25 09:20, , 12F
如果是指像iteration vs. recursion這種情況的話
05/25 09:20, 12F
→
05/25 09:20, , 13F
我會寫明這是某種recursion演算法的iteration版本
05/25 09:20, 13F
→
05/25 09:21, , 14F
程式只要讓人看的懂在做什麼就好，不用看的懂那個演算法的
05/25 09:21, 14F
→
05/25 09:21, , 15F
之後要維護的人，應該自己要有能力去確認.
05/25 09:21, 15F
→
05/25 09:21, , 16F
原理，標記好是用哪個演算法要知道原理的自己去讀書
05/25 09:21, 16F
→
05/25 09:29, , 17F
假議題, 要用哪種演算法要用文件說明, 不是讓人看 code
05/25 09:29, 17F
→
05/25 09:29, , 18F
自己理解的 = =a
05/25 09:29, 18F
→
05/25 09:34, , 19F
我還是覺得這跟 clean code 無關
05/25 09:34, 19F
推
05/25 09:45, , 20F
用efficency的解法然後寫doc阿
05/25 09:45, 20F
→
05/25 09:45, , 21F
*efficiency
05/25 09:45, 21F
推
05/25 10:03, , 22F
演算法不是用code來理解的 你要先profile瓶頸
05/25 10:03, 22F
→
05/25 10:03, , 23F
如果不是瓶頸你用效率差但是容易懂的根本無關緊要
05/25 10:03, 23F
→
05/25 10:04, , 24F
瓶頸的地方就是用比較好的演算法加上文件
05/25 10:04, 24F
推
05/25 10:15, , 25F
第一個想到的是temmplate programming 編譯出錯的訊息
05/25 10:15, 25F
→
05/25 10:16, , 26F
難以言喻 有些語法錯誤甚至要執行才會出現
05/25 10:16, 26F
→
05/25 10:18, , 27F
附上文件的連結啊，有時候使用到特殊的公式，都直接附 url
05/25 10:18, 27F
→
05/25 10:18, , 28F
我覺得程式的重點是後續維護,再來才是效能
05/25 10:18, 28F
→
05/25 10:40, , 29F
看 n 多少啊 XD
05/25 10:40, 29F
推
05/25 11:13, , 30F
data多大？效能不好的點老闆接受度？
05/25 11:13, 30F
→
05/25 11:33, , 31F
這跟clean code 無關+1
05/25 11:33, 31F
推
05/25 11:51, , 32F
看n多大，nˋ真的很大那就是效能優先然後好好寫文件註解
05/25 11:51, 32F
推
05/25 12:17, , 33F
一樓正解，單元拆好你高興實作兩套也沒問題
05/25 12:17, 33F
推
05/25 12:20, , 34F
case by case，該怎麼決定要靠經驗
05/25 12:20, 34F
推
05/25 13:31, , 35F
O(log n)也可以clean code啊
05/25 13:31, 35F
推
05/25 13:35, , 36F
沒有必要極端化啊，捨棄部分效能換取可讀性，或反之。
05/25 13:35, 36F
→
05/25 13:35, , 37F
個人覺得這問題是類比的，不是數位的非零即一
05/25 13:35, 37F
推
05/25 13:38, , 38F
突然發現log n到n交界點似乎是有點非零即一XD
05/25 13:38, 38F
推
05/25 14:50, , 39F
看n多大+1
05/25 14:50, 39F
推
05/25 17:30, , 40F
這個問題就像問你選擇愛情還是麵包
05/25 17:30, 40F
推
05/25 20:57, , 41F
真正效率瓶頸不在code 在人 開發效率才是重點
05/25 20:57, 41F
→
05/25 20:57, , 42F
選哪個? 選存在的那個
05/25 20:57, 42F
→
05/25 20:57, , 43F
還沒寫出來的東西就是不存在
05/25 20:57, 43F
推
05/25 21:57, , 44F
會跟時間複雜度放在天秤上取捨的一般是記憶體用量,而不
05/25 21:57, 44F
→
05/25 21:57, , 45F
是clean和重構執行的難易度 因為要影響到維護難度的層
05/25 21:57, 45F
→
05/25 21:57, , 46F
次是整個軟體的結構大小 而單個演算法通常是不會寫到這
05/25 21:57, 46F
→
05/25 21:57, , 47F
麼大量的結構去支持他運作的 如果有 那我會去買人家的l
05/25 21:57, 47F
→
05/25 21:57, , 48F
ibrary來用(X)
05/25 21:57, 48F
推
05/25 22:22, , 49F
跟clean code 無關+1.
05/25 22:22, 49F
→
05/26 01:51, , 50F
這問題可以很明確的，好比如果程式有 99% 的時間耗在
05/26 01:51, 50F
→
05/26 01:52, , 51F
其他部份，只有 1% 時間耗在你的演算法，這時候你把它
05/26 01:52, 51F
→
05/26 01:52, , 52F
從 O(n) 寫到變 O(log n) 拿不到顯著的好處。
05/26 01:52, 52F
→
05/26 01:55, , 53F
很多時候問題會是出在軟體開發速度和維護性上。
05/26 01:55, 53F
→
05/26 04:25, , 54F
如果最多只有500筆資料要處理，你寫成O(n^5)都沒有關係...
05/26 04:25, 54F
→
05/26 09:11, , 55F
看N多大+1
05/26 09:11, 55F
推
05/26 09:44, , 56F
演算法跟clean code應該無關，還是指程式執行時間？
05/26 09:44, 56F
推
05/27 20:56, , 57F
一定是O(logn) clean code 是誤導用的
05/27 20:56, 57F
→
05/27 20:57, , 58F
好效率的code 看不懂的人是他自己的問題 理解力不足
05/27 20:57, 58F
→
05/27 20:58, , 59F
現在這時代最需要的是有效率可以最正確達成效果的
05/27 20:58, 59F
→
05/27 21:00, , 60F
現在最需要的是不管怎麼混亂的code 都能夠用極快速度理解的
05/27 21:00, 60F
→
05/27 21:00, , 61F
能力這才是對的
05/27 21:00, 61F
推
05/27 21:04, , 62F
不能期待每個地方的法則都是要維持code看起來漂亮
05/27 21:04, 62F
→
05/27 21:06, , 63F
有些地方要的是極快速 但是不看圖無法理解的做法
05/27 21:06, 63F
推
05/28 12:07, , 64F
binomial heap跟Fibonacci heap寫起來都
05/28 12:07, 64F
→
05/28 12:07, , 65F
很複雜 相對於隔壁的binary heap......
05/28 12:07, 65F
推
05/28 12:54, , 66F
CleanCode != easyCode成人寫文章不能還在this is a boo
05/28 12:54, 66F
→
06/13 14:36, , 67F
兩個都寫 把不用的那一個註解掉 但是留著
06/13 14:36, 67F
→
06/13 14:37, , 68F
以後維護彈性多了 選擇題比申論題好寫多了
06/13 14:37, 68F
‣ 更多 gitignore 的文章
文章代碼(AID): #1NHF493e (Soft_Job)
‣ 更多 gitignore 的文章
文章代碼(AID): #1NHF493e (Soft_Job)