小弟工作資歷尚淺 前一陣子才轉職
目前是用ASP.NET MVC進行網頁開發
因為自己還蠻菜的 想加強能力
不知道大家都怎麼選clean code的書
目前在網路上看到 clean code又是C#實作的是這一本
無瑕的程式碼 敏捷完整篇：物件導向原則、設計模式與C#實踐
想請問版上的各位 有沒有甚麼建議
作者:
qqkerk (江雨)
2018-06-16 17:39:00這位大叔的書都不錯，但只要不要全部當成真理就好了，實務上還是得因地制宜QAQ
作者:
fukinhot (抱歉粗口我怕熱)
2018-06-16 17:49:00都大同小異吧 重點是要看完
agile 3p > clean code > clean architecture, clean coder可以隨時看
THINK IN C 先看 CLEAN CODE不要去看 你無法理解的
作者:
prag222 (prag)
2018-06-16 19:34:00廳前同事在嘴 之前也有看了一下 可惜只看部分1/3不到看了clean code批評別人的code不好喔看過THINING IN PATTERNS覺得還是IN JAVA經典
作者:
testPtt (測試)
2018-06-16 20:41:00註解詳細一點還是比較好
作者:
owlran (owlran)
2018-06-16 23:09:00註解寫詳細點好？為什麼不是直接把function name寫好一點
作者: sextitanic 2018-06-16 23:14:00
function name 很難把計算或取資料的邏輯寫上去啊
我覺得直接看Martin Fowler 的Refactoring 那本再看 Gof Design Pattern 比較實際有用
精通設計模式->無瑕的程式碼->重構:改善既有程式的設計這邊提供給您進修三部曲參考，最後一部請搭配出氣娃娃作使用
作者:
tvbic 2018-06-17 00:13:00我覺得這一類的書，其實都大同小異
設計模式的書先從難的挑來看 看不懂就換簡單的 看完後再回頭看難的 如果還是看不懂 就去看 refactoring to patterns 這本書
作者:
naoomi (奈米)
2018-06-17 01:07:00設計模式挑簡單的看阿，看影片更好,直接看gof等從入門到放棄
只有think in c++吧 我找不到think in c
作者: dannypsnl (秦書) 2018-06-17 04:34:00
Allie 3p應該就是你文章提到的那本
作者:
fayhong (恰似飛鴻踏雪泥)
2018-06-17 08:14:00設計模式請找原典來讀，clean code 建議你至少獨自完成幾設計模式請找原典來讀，clean code 建議你至少獨自完成幾個系統，或有一定經驗再來讀，敏捷的書，讀不如行得出來，你可以讀，但在台灣大多數的軟體公司，就要有革命或另謀高就的準備。
作者:
testPtt (測試)
2018-06-17 10:54:00其實不用刻意去讀設計模式 多看看別人寫法模仿就好
作者:
Argos (Big doge is watching u)
2018-06-17 13:22:00設計模式原典不太推 經驗不足看深入淺出那本比較好clean code可以看但要看仔細 其實大叔在書中都有聲明 那些技巧要因地制宜 並不是一種法律要來規範大家但你很容易忘記他提醒要因地制宜的部份 變成clean code警察還是建議 設計模式 敏捷開發 請都當成「工具」 不是教條學會「在什麼時候該用什麼樣的工具」 比學會使用工具更重要
作者:
Masakiad (Masaki)
2018-06-17 16:38:00等你看到覺得clean code + design pattern 結合起來應用寫出像文章一樣的code就成功了
作者:
prag222 (prag)
2018-06-17 19:38:00我直接看深入淺出 原版整個ZZ
作者:
testPtt (測試)
2018-06-17 22:18:00我覺得面對大量的abstract跟binding不需要註解算蠻厲害的
作者:
Masakiad (Masaki)
2018-06-18 00:20:00abstract & binding不好懂加入註解多半更難懂欸。
作者:
testPtt (測試)
2018-06-18 08:59:00我認為現在熱門的framework都有註解 有反例嗎?
API有註解不奇怪啊 沒expose的部份還是沒註解居多註解寫多不一定是好事 因為註解也是要維護的所以才會說能免則免
作者:
alog (A肉哥)
2018-06-19 09:10:00通常code寫到不用註解是最好的 要加的話 就樓上的舉例來說 framework 這東西是內部多人協作跟外部貢獻者要來經營的 通常是會寫的很清楚不然還是要看專案、團隊、是否有特殊幾個狀況需要特別交代的理由來決定要不要寫
我最常遇到的就是註解沒人要更新,一堆錯誤,有註解跟沒有註解依樣
作者:
testPtt (測試)
2018-06-19 20:42:00不維護註解是寫的人不好不能歸咎於加註解不好我遇到這種的都是趕時程的case 重用性很差 程式越堆越肥
不過既然要花成本維護註解,為何不花同樣的成本花在維護易讀程式碼呢?
作者:
testPtt (測試)
2018-06-21 13:12:00有時候想說明整段程式碼的原因跟注意事項 下次看較好回憶如果只有程式碼很容易誤用或是不用 不然就要去看內容可以想想api都沒提供說明要你自己追code這樣有比較快?
作者:
Ghamu (貓丸)
2018-06-22 00:21:00註解沒維護是人的問題 這種觀念不對 因為註解本身不會被執行 沒人在乎 特別趕的時候沒人會看註解 function class 寫得好很短 更是不會有人看註解但註解還是必要的 有時候靠命名 拆解還是無法全盤托出你的意圖 但我都會抱著些罪惡感去寫註解 覺得自己架構不夠好 命名詞窮 而不是認為寫註解 維護註解是理所當然的事
作者:
testPtt (測試)
2018-06-22 09:49:00舉個畫表格的例子 一堆DrawLine方法不去註解會很慘下次就要座標慢慢看 如果我註解描述在表格哪個地方這樣找起來就快很多 然後它要維護 不維護更慘
作者:
Ghamu (貓丸)
2018-06-22 10:17:00我是寫app 不太懂表表格表達是啥 但如果是我或許會是drawXXXtable() function 裡面有drawSchemaRow() drawSchemaColumn() 再loop data list call drawContentRow()也或許XXXTable本身就是一個class 反正以這樣來看註解就不太需要了吧？
作者:
testPtt (測試)
2018-06-22 10:35:00就是要印報表要畫很多線 而且還不是一行一筆資料而是公司減少紙張政策有空間就塞的高度課製化報表
作者:
Ghamu (貓丸)
2018-06-22 13:19:00嗯... 不管如何都可以吧？ 總有同一種類的表單 不可能表單裡東西類型都完全不一樣吧？ 是說有點太細節了 我想必要註解不可免 但大多數情況 你寫註解就輸了 代表架構雜亂 function class 太肥 命名無法傳達意圖 只好靠註解補強設計者的意圖
作者:
testPtt (測試)
2018-06-22 16:07:00這個例子是剛好正在做 當然這有很多用拖拉的商業套件不過要錢 所以只好慢慢數座標 每條線都自己打code順序也要算好 雖然隨便放也不影響結果