為什麼這篇無瑕的程式碼pdf鄉民發文收入到精華區：因為在無瑕的程式碼pdf這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者geroge0820 (可.....可惡)看板Soft_Job標題[請益] 關於clean co...
小弟工作資歷尚淺 前一陣子才轉職
目前是用ASP.NET MVC進行網頁開發
因為自己還蠻菜的 想加強能力
不知道大家都怎麼選clean code的書
目前在網路上看到 clean code又是C#實作的是這一本
無瑕的程式碼 敏捷完整篇：物件導向原則、設計模式與C#實踐
想請問版上的各位 有沒有甚麼建議
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.251.34.192
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1529139413.A.C37.html
推 qqkerk: 這位大叔的書都不錯，但只要不要全部當成真理就好了，實06/16 17:39
→ qqkerk: 務上還是得因地制宜QAQ06/16 17:39
你講完 害我有點不知道要不要買了→ fukinhot: 都大同小異吧 重點是要看完06/16 17:49
推 landlord: agile 3p > clean code > clean architecture, clean c06/16 18:14
→ landlord: oder可以隨時看06/16 18:14
agile 3p 不知道是哪一本推 TitanEric: 不是Java嗎 原來有C#？06/16 18:23
有啊 今年才看到有C#的噓 THEWORLDS: THINK IN C 先看 CLEAN CODE不要去看 你無法理解的06/16 18:28
推 prag222: 廳前同事在嘴 之前也有看了一下 可惜只看部分1/3不到06/16 19:34
→ prag222: 看了clean code批評別人的code不好喔06/16 19:35
→ prag222: 看過THINING IN PATTERNS覺得還是IN JAVA經典06/16 19:36
in Java 有看到電子書 可以省一筆了!!推 nashyuuki: Clean coder 根本就是作者自傳06/16 20:01
→ testPtt: 註解詳細一點還是比較好06/16 20:41
推 owlran: 註解寫詳細點好？為什麼不是直接把function name寫好一點06/16 23:09
→ sextitanic: function name 很難把計算或取資料的邏輯寫上去啊06/16 23:14
→ csieflyman: 我覺得直接看Martin Fowler 的Refactoring 那本再看 G06/16 23:45
→ csieflyman: of Design Pattern 比較實際有用06/16 23:45
gof 這本 和大話設計模式 哪一本比較適合※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 00:16:22
推 readonly: 寫夠多 dirty code 了嗎？06/17 00:04
開會的時候 被靠盃了 嗚嗚推 banqhsia: 精通設計模式->無瑕的程式碼->重構:改善既有程式的設計06/17 00:07
→ banqhsia: 這邊提供給您進修三部曲參考，最後一部請搭配出氣娃娃06/17 00:08
我不小心看成充氣娃娃..→ banqhsia: 作使用06/17 00:08
推 tvbic: 我覺得這一類的書，其實都大同小異06/17 00:13
就我所看到的部分 設計模式重複率很高※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 00:20:55
※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 00:23:13
→ csieflyman: 設計模式的書先從難的挑來看 看不懂就換簡單的 看完06/17 00:24
→ csieflyman: 後再回頭看難的 如果還是看不懂 就去看 refactoring t06/17 00:24
→ csieflyman: o patterns 這本書06/17 00:24
推 naoomi: 設計模式挑簡單的看阿，看影片更好,直接看gof等從入門到06/17 01:07
→ naoomi: 放棄06/17 01:07
從簡單的開始 的確是好上手但是也沒到放棄這麼誇張啦
噓 KernelChen: 只有think in c++吧 我找不到think in c06/17 02:51
原來是真的沒有※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 03:53:38
推 dannypsnl: Allie 3p應該就是你文章提到的那本 06/17 04:34
推 fayhong: 設計模式請找原典來讀，clean code 建議你至少獨自完成幾 06/17 08:14
推 fayhong: 設計模式請找原典來讀，clean code 建議你至少獨自完成幾 06/17 08:20
→ fayhong: 個系統，或有一定經驗再來讀，敏捷的書，讀不如行得出來 06/17 08:20
→ fayhong: ，你可以讀，但在台灣大多數的軟體公司，就要有革命或另 06/17 08:20
→ fayhong: 謀高就的準備。 06/17 08:20
→ testPtt: 其實不用刻意去讀設計模式 多看看別人寫法模仿就好 06/17 10:54
推 Argos: 設計模式原典不太推 經驗不足看深入淺出那本比較好 06/17 13:22
→ Argos: clean code可以看但要看仔細 其實大叔在書中都有聲明 那些 06/17 13:23
→ Argos: 技巧要因地制宜 並不是一種法律要來規範大家 06/17 13:24
→ Argos: 但你很容易忘記他提醒要因地制宜的部份 變成clean code警察 06/17 13:24
→ Argos: 還是建議 設計模式 敏捷開發 請都當成「工具」 不是教條 06/17 13:25
→ Argos: 學會「在什麼時候該用什麼樣的工具」 比學會使用工具更重要 06/17 13:26
推 Masakiad: 等你看到覺得clean code + design pattern 結合起來應 06/17 16:38
→ Masakiad: 用寫出像文章一樣的code就成功了 06/17 16:38
推 prag222: 我直接看深入淺出 原版整個ZZ 06/17 19:38
→ testPtt: 我覺得面對大量的abstract跟binding不需要註解算蠻厲害的 06/17 22:18
→ Masakiad: abstract & binding不好懂加入註解多半更難懂欸。 06/18 00:20
→ testPtt: 我認為現在熱門的framework都有註解 有反例嗎? 06/18 08:59
→ cha122977: API有註解不奇怪啊 沒expose的部份還是沒註解居多 06/19 00:47
→ cha122977: 註解寫多不一定是好事 因為註解也是要維護的 06/19 00:48
→ cha122977: 所以才會說能免則免 06/19 00:48
推 mepowerlmay: 會跑就好 06/19 01:09
→ alog: 通常code寫到不用註解是最好的 要加的話 就樓上的舉例來說 f 06/19 09:10
→ alog: ramework 這東西是內部多人協作跟外部貢獻者要來經營的 通常 06/19 09:10
→ alog: 是會寫的很清楚 06/19 09:10
→ alog: 不然還是要看專案、團隊、是否有特殊幾個狀況需要特別交代 06/19 09:11
→ alog: 的理由來決定要不要寫 06/19 09:11
→ leolarrel: 我最常遇到的就是註解沒人要更新,一堆錯誤,有註解跟沒 06/19 13:22
→ leolarrel: 有註解依樣 06/19 13:22
→ testPtt: 不維護註解是寫的人不好不能歸咎於加註解不好 06/19 20:42
→ testPtt: 我遇到這種的都是趕時程的case 重用性很差 程式越堆越肥 06/19 20:44
→ leolarrel: 不過既然要花成本維護註解,為何不花同樣的成本花在維護 06/21 10:52
→ leolarrel: 易讀程式碼呢? 06/21 10:52
→ testPtt: 有時候想說明整段程式碼的原因跟注意事項 下次看較好回憶 06/21 13:12
→ testPtt: 如果只有程式碼很容易誤用或是不用 不然就要去看內容 06/21 13:15
→ testPtt: 可以想想api都沒提供說明要你自己追code這樣有比較快? 06/21 13:17
推 Ghamu: 註解沒維護是人的問題 這種觀念不對 因為註解本身不會被執 06/22 00:21
→ Ghamu: 行 沒人在乎 特別趕的時候沒人會看註解 function class 寫 06/22 00:21
→ Ghamu: 得好很短 更是不會有人看註解 06/22 00:21
→ Ghamu: 但註解還是必要的 有時候靠命名 拆解還是無法全盤托出你的 06/22 00:24
→ Ghamu: 意圖 但我都會抱著些罪惡感去寫註解 覺得自己架構不夠好 命 06/22 00:24
→ Ghamu: 名詞窮 而不是認為寫註解 維護註解是理所當然的事 06/22 00:24
→ testPtt: 舉個畫表格的例子 一堆DrawLine方法不去註解會很慘 06/22 09:49
→ testPtt: 下次就要座標慢慢看 如果我註解描述在表格哪個地方 06/22 09:51
→ testPtt: 這樣找起來就快很多 然後它要維護 不維護更慘 06/22 09:52
→ Ghamu: 我是寫app 不太懂表表格表達是啥 但如果是我或許會是drawXX 06/22 10:17
→ Ghamu: Xtable() function 裡面有drawSchemaRow() drawSchemaColum 06/22 10:17
→ Ghamu: n() 再loop data list call drawContentRow() 06/22 10:17
→ Ghamu: 也或許XXXTable本身就是一個class 反正以這樣來看註解就不 06/22 10:20
→ Ghamu: 太需要了吧？ 06/22 10:20
→ testPtt: 就是要印報表要畫很多線 而且還不是一行一筆資料 06/22 10:35
→ testPtt: 而是公司減少紙張政策有空間就塞的高度課製化報表 06/22 10:38
→ Ghamu: 嗯... 不管如何都可以吧？ 總有同一種類的表單 不可能表單 06/22 13:19
→ Ghamu: 裡東西類型都完全不一樣吧？ 是說有點太細節了 我想必要 06/22 13:19
→ Ghamu: 註解不可免 但大多數情況 你寫註解就輸了 代表架構雜亂 fu 06/22 13:19
→ Ghamu: nction class 太肥 命名無法傳達意圖 只好靠註解補強設計者 06/22 13:19
→ Ghamu: 的意圖 06/22 13:19
→ testPtt: 這個例子是剛好正在做 當然這有很多用拖拉的商業套件 06/22 16:07
→ testPtt: 不過要錢 所以只好慢慢數座標 每條線都自己打code 06/22 16:09
→ testPtt: 順序也要算好 雖然隨便放也不影響結果 06/22 16:14