[請益] 關於clean code書籍選擇

作者 geroge0820 (可.....可惡)

時間 2018-06-16 16:56:45

留言 88 ( 18推 2噓 68→ )

小弟工作資歷尚淺前一陣子才轉職目前是用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 1F

→ qqkerk 務上還是得因地制宜QAQ 06/16 17:39 2F

你講完害我有點不知道要不要買了

→ fukinhot 都大同小異吧重點是要看完 06/16 17:49 3F

推 landlord agile 3p > clean code > clean architecture, clean c 06/16 18:14 4F

→ landlord oder可以隨時看 06/16 18:14 5F

agile 3p 不知道是哪一本

推 TitanEric 不是Java嗎原來有C#？ 06/16 18:23 6F

有啊今年才看到有C#的

噓 THEWORLDS THINK IN C 先看 CLEAN CODE不要去看你無法理解的 06/16 18:28 7F

推 prag222 廳前同事在嘴之前也有看了一下可惜只看部分1/3不到 06/16 19:34 8F

→ prag222 看了clean code批評別人的code不好喔 06/16 19:35 9F

→ prag222 看過THINING IN PATTERNS覺得還是IN JAVA經典 06/16 19:36 10F

in Java 有看到電子書可以省一筆了!!

推 nashyuuki Clean coder 根本就是作者自傳 06/16 20:01 11F

→ testPtt 註解詳細一點還是比較好 06/16 20:41 12F

推 owlran 註解寫詳細點好？為什麼不是直接把function name寫好一點 06/16 23:09 13F

→ sextitanic function name 很難把計算或取資料的邏輯寫上去啊 06/16 23:14 14F

→ csieflyman 我覺得直接看Martin Fowler 的Refactoring 那本再看 G 06/16 23:45 15F

→ csieflyman of Design Pattern 比較實際有用 06/16 23:45 16F

gof 這本和大話設計模式哪一本比較適合

※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 00:16:22

推 readonly 寫夠多 dirty code 了嗎？ 06/17 00:04 17F

開會的時候被靠盃了嗚嗚

推 banqhsia 精通設計模式->無瑕的程式碼->重構:改善既有程式的設計 06/17 00:07 18F

→ banqhsia 這邊提供給您進修三部曲參考，最後一部請搭配出氣娃娃 06/17 00:08 19F

我不小心看成充氣娃娃..

→ banqhsia 作使用 06/17 00:08 20F

推 tvbic 我覺得這一類的書，其實都大同小異 06/17 00:13 21F

就我所看到的部分設計模式重複率很高

※ 編輯: 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 22F

→ csieflyman 後再回頭看難的如果還是看不懂就去看 refactoring t 06/17 00:24 23F

→ csieflyman o patterns 這本書 06/17 00:24 24F

推 naoomi 設計模式挑簡單的看阿，看影片更好,直接看gof等從入門到 06/17 01:07 25F

→ naoomi 放棄 06/17 01:07 26F

從簡單的開始的確是好上手但是也沒到放棄這麼誇張啦

噓 KernelChen 只有think in c++吧我找不到think in c 06/17 02:51 27F

原來是真的沒有

※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 03:53:38

推 dannypsnl Allie 3p應該就是你文章提到的那本 06/17 04:34 28F

推 fayhong 設計模式請找原典來讀，clean code 建議你至少獨自完成幾 06/17 08:14 29F

推 fayhong 設計模式請找原典來讀，clean code 建議你至少獨自完成幾 06/17 08:20 30F

→ fayhong 個系統，或有一定經驗再來讀，敏捷的書，讀不如行得出來 06/17 08:20 31F

→ fayhong ，你可以讀，但在台灣大多數的軟體公司，就要有革命或另 06/17 08:20 32F

→ fayhong 謀高就的準備。 06/17 08:20 33F

→ testPtt 其實不用刻意去讀設計模式多看看別人寫法模仿就好 06/17 10:54 34F

推 Argos 設計模式原典不太推經驗不足看深入淺出那本比較好 06/17 13:22 35F

→ Argos clean code可以看但要看仔細其實大叔在書中都有聲明那些 06/17 13:23 36F

→ Argos 技巧要因地制宜並不是一種法律要來規範大家 06/17 13:24 37F

→ Argos 但你很容易忘記他提醒要因地制宜的部份變成clean code警察 06/17 13:24 38F

→ Argos 還是建議設計模式敏捷開發請都當成「工具」不是教條 06/17 13:25 39F

→ Argos 學會「在什麼時候該用什麼樣的工具」比學會使用工具更重要 06/17 13:26 40F

推 Masakiad 等你看到覺得clean code + design pattern 結合起來應 06/17 16:38 41F

→ Masakiad 用寫出像文章一樣的code就成功了 06/17 16:38 42F

推 prag222 我直接看深入淺出原版整個ZZ 06/17 19:38 43F

→ testPtt 我覺得面對大量的abstract跟binding不需要註解算蠻厲害的 06/17 22:18 44F

→ Masakiad abstract & binding不好懂加入註解多半更難懂欸。 06/18 00:20 45F

→ testPtt 我認為現在熱門的framework都有註解有反例嗎? 06/18 08:59 46F

→ cha122977 API有註解不奇怪啊沒expose的部份還是沒註解居多 06/19 00:47 47F

→ cha122977 註解寫多不一定是好事因為註解也是要維護的 06/19 00:48 48F

→ cha122977 所以才會說能免則免 06/19 00:48 49F

推 mepowerlmay 會跑就好 06/19 01:09 50F

→ alog 通常code寫到不用註解是最好的要加的話就樓上的舉例來說 f 06/19 09:10 51F

→ alog ramework 這東西是內部多人協作跟外部貢獻者要來經營的通常 06/19 09:10 52F

→ alog 是會寫的很清楚 06/19 09:10 53F

→ alog 不然還是要看專案、團隊、是否有特殊幾個狀況需要特別交代 06/19 09:11 54F

→ alog 的理由來決定要不要寫 06/19 09:11 55F

→ leolarrel 我最常遇到的就是註解沒人要更新,一堆錯誤,有註解跟沒 06/19 13:22 56F

→ leolarrel 有註解依樣 06/19 13:22 57F

→ testPtt 不維護註解是寫的人不好不能歸咎於加註解不好 06/19 20:42 58F

→ testPtt 我遇到這種的都是趕時程的case 重用性很差程式越堆越肥 06/19 20:44 59F

→ leolarrel 不過既然要花成本維護註解,為何不花同樣的成本花在維護 06/21 10:52 60F

→ leolarrel 易讀程式碼呢? 06/21 10:52 61F

→ testPtt 有時候想說明整段程式碼的原因跟注意事項下次看較好回憶 06/21 13:12 62F

→ testPtt 如果只有程式碼很容易誤用或是不用不然就要去看內容 06/21 13:15 63F

→ testPtt 可以想想api都沒提供說明要你自己追code這樣有比較快? 06/21 13:17 64F

推 Ghamu 註解沒維護是人的問題這種觀念不對因為註解本身不會被執 06/22 00:21 65F

→ Ghamu 行沒人在乎特別趕的時候沒人會看註解 function class 寫 06/22 00:21 66F

→ Ghamu 得好很短更是不會有人看註解 06/22 00:21 67F

→ Ghamu 但註解還是必要的有時候靠命名拆解還是無法全盤托出你的 06/22 00:24 68F

→ Ghamu 意圖但我都會抱著些罪惡感去寫註解覺得自己架構不夠好命 06/22 00:24 69F

→ Ghamu 名詞窮而不是認為寫註解維護註解是理所當然的事 06/22 00:24 70F

→ testPtt 舉個畫表格的例子一堆DrawLine方法不去註解會很慘 06/22 09:49 71F

→ testPtt 下次就要座標慢慢看如果我註解描述在表格哪個地方 06/22 09:51 72F

→ testPtt 這樣找起來就快很多然後它要維護不維護更慘 06/22 09:52 73F

→ Ghamu 我是寫app 不太懂表表格表達是啥但如果是我或許會是drawXX 06/22 10:17 74F

→ Ghamu Xtable() function 裡面有drawSchemaRow() drawSchemaColum 06/22 10:17 75F

→ Ghamu n() 再loop data list call drawContentRow() 06/22 10:17 76F

→ Ghamu 也或許XXXTable本身就是一個class 反正以這樣來看註解就不 06/22 10:20 77F

→ Ghamu 太需要了吧？ 06/22 10:20 78F

→ testPtt 就是要印報表要畫很多線而且還不是一行一筆資料 06/22 10:35 79F

→ testPtt 而是公司減少紙張政策有空間就塞的高度課製化報表 06/22 10:38 80F

→ Ghamu 嗯... 不管如何都可以吧？總有同一種類的表單不可能表單 06/22 13:19 81F

→ Ghamu 裡東西類型都完全不一樣吧？是說有點太細節了我想必要 06/22 13:19 82F

→ Ghamu 註解不可免但大多數情況你寫註解就輸了代表架構雜亂 fu 06/22 13:19 83F

→ Ghamu nction class 太肥命名無法傳達意圖只好靠註解補強設計者 06/22 13:19 84F

→ Ghamu 的意圖 06/22 13:19 85F

→ testPtt 這個例子是剛好正在做當然這有很多用拖拉的商業套件 06/22 16:07 86F

→ testPtt 不過要錢所以只好慢慢數座標每條線都自己打code 06/22 16:09 87F

→ testPtt 順序也要算好雖然隨便放也不影響結果 06/22 16:14 88F

[請益] 關於clean code書籍選擇

留言

最新文章