[轉錄] 整潔的代碼 VS 卓越的代碼

看板Soft_Job (軟體人)作者 (沉默是金。)時間14年前 (2011/08/10 09:24), 編輯推噓8(8029)
留言37則, 10人參與, 最新討論串1/1
原文 http://davybrion.com/blog/2011/07/clean-code-versus-great-code/ 譯文 http://www.jobbole.com/entry.php/1223 不過這篇文章中講的事情也是可以想一想。 某個角度上來講,特例 vs 架構的取捨也是很重要的。 -- 我:一半的日子讓你說,我聽你說你的所有______________________________________ ______________________________________一半的日子我想說,對你說過去的所有:我 _______________________________________________________ 在討論中妥善扮演兼具聆聽與分享的角色,是我們一生的課題。 _______________________________________________________ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 12.208.243.66

08/10 09:53, , 1F
wrong link ? http://0rz.tw/NVpnf
08/10 09:53, 1F
剛下班還在恍神 感謝更正:) ※ 編輯: TonyQ 來自: 12.208.243.66 (08/10 10:06)

08/10 13:01, , 2F
親身經歷: 第1手:架構良好,第2手:特例一堆,第3手(我):這啥?
08/10 13:01, 2F

08/10 13:18, , 3F
架構只有完成的當下好,下一個當下需要下一個架構。
08/10 13:18, 3F

08/10 13:19, , 4F
只有投注無數心血、千錘百鍊的架構,沒有不會更動的架構
08/10 13:19, 4F

08/10 13:38, , 5F
我想~特例也可以寫得很有架構...應該這麼說 在架構還沒出來
08/10 13:38, 5F

08/10 13:39, , 6F
之前 所有架構裡的東西也都只是一個個特例 所以才需要架
08/10 13:39, 6F

08/10 13:39, , 7F
購 來進行規範或是模組化的動作 來達到源碼的整齊與辨識率
08/10 13:39, 7F

08/10 13:40, , 8F
所以其實沒有取捨 是可以並行的 唯一的問題是客戶給不給
08/10 13:40, 8F

08/10 13:40, , 9F
這麼多時間XD
08/10 13:40, 9F

08/10 13:56, , 10F
我覺得可怕的是一昧的不爽開特例而把架構越開越generic...
08/10 13:56, 10F

08/10 13:57, , 11F
我覺得一個完全沒有特例的系統也是很可怕的極端...
08/10 13:57, 11F

08/10 13:57, , 12F
所有的零件都能重組的意思就是每個細節你都要很熟...
08/10 13:57, 12F

08/10 14:10, , 13F
要讓 code 保持『活』的狀態,才能支援各種改變
08/10 14:10, 13F

08/10 14:37, , 14F
所以架構在設計時就要考慮到擴充性了 像各家的CMS那樣QQ
08/10 14:37, 14F

08/10 16:05, , 15F
我覺得qty說的活指的是程式碼是會隨著需求而演化
08/10 16:05, 15F

08/10 16:06, , 16F
而不是完全不去修改他們吧?
08/10 16:06, 16F

08/10 16:06, , 17F
我覺得如果所有AP設計時就要考慮到類似CMS或Eclipse那種程度
08/10 16:06, 17F

08/10 16:06, , 18F
的擴充性,那成本會非常高,而且不是所有AP都值得這麼做。
08/10 16:06, 18F

08/10 16:26, , 19F
的確如此,甚至可以說大部分的都沒辦法做到這樣= =
08/10 16:26, 19F

08/10 16:26, , 20F
只是想不太到其他架構跟源碼都可優秀的例子 單純就可行性而
08/10 16:26, 20F

08/10 16:27, , 21F
言的前提才有辦法做到
08/10 16:27, 21F

08/10 16:27, , 22F
但是現實上跟可行性通常都是背道而馳啦XD
08/10 16:27, 22F

08/10 17:03, , 23F
問題就是客戶通常不會給太多時間才需要取捨呀..
08/10 17:03, 23F

08/10 17:32, , 24F
如果不抓時間重構,讓程式保持可變性,那往後的日子會越來
08/10 17:32, 24F

08/10 17:33, , 25F
越痛苦。而且活的相對是死的,程式太久沒去理他就會變成
08/10 17:33, 25F

08/10 17:33, , 26F
無法踏入的死亡之地。沒有人想去維護那不易改動的內容。
08/10 17:33, 26F

08/10 17:34, , 27F
有些時間花下去,是幫助掙取更多的時間。
08/10 17:34, 27F

08/10 17:39, , 28F
我曾經拿上面這段話和老闆談, 結果... T^T
08/10 17:39, 28F

08/10 17:55, , 29F
http://goo.gl/hW72N 尾巴難收的原因之一
08/10 17:55, 29F

08/10 22:00, , 30F
根據破窗理論,從有一個特例開始,特例會越來越多
08/10 22:00, 30F

08/11 00:14, , 31F
為了避免特例你的架構會整駝變成特例...
08/11 00:14, 31F

08/11 00:15, , 32F
同樣類型的特例超過兩個,就值得整理成架構。
08/11 00:15, 32F

08/11 00:15, , 33F
只有一個,那最好還是特例得好。
08/11 00:15, 33F

08/11 23:37, , 34F
目前遇到是的..老系統架構爆爛..當初搞爛架構的人升官了
08/11 23:37, 34F

08/11 23:38, , 35F
回頭來要求東要求西....
08/11 23:38, 35F

08/12 16:02, , 36F
對我來說,那個死就是熱寂,系統的功能已經被廢熱埋沒了
08/12 16:02, 36F

08/12 19:09, , 37F
以我自己的經驗,完全能夠架構化的東西本身也是個特例...
08/12 19:09, 37F
文章代碼(AID): #1EGTsysY (Soft_Job)
文章代碼(AID): #1EGTsysY (Soft_Job)