PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (可.....可惡)時間7年前 (2018/06/16 16:56), 7年前編輯推噓16(18推 2噓 68→)
留言88則, 25人參與, 7年前最新討論串1/2 (看更多)
小弟工作資歷尚淺 前一陣子才轉職 目前是用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
推
06/16 17:39, 7年前 , 1F
這位大叔的書都不錯，但只要不要全部當成真理就好了，實
06/16 17:39, 1F
→
06/16 17:39, 7年前 , 2F
務上還是得因地制宜QAQ
06/16 17:39, 2F
你講完 害我有點不知道要不要買了
→
06/16 17:49, 7年前 , 3F
都大同小異吧 重點是要看完
06/16 17:49, 3F
推
06/16 18:14, 7年前 , 4F
agile 3p > clean code > clean architecture, clean c
06/16 18:14, 4F
→
06/16 18:14, 7年前 , 5F
oder可以隨時看
06/16 18:14, 5F
agile 3p 不知道是哪一本
推
06/16 18:23, 7年前 , 6F
不是Java嗎 原來有C#？
06/16 18:23, 6F
有啊 今年才看到有C#的
噓
06/16 18:28, 7年前 , 7F
THINK IN C 先看 CLEAN CODE不要去看 你無法理解的
06/16 18:28, 7F
推
06/16 19:34, 7年前 , 8F
廳前同事在嘴 之前也有看了一下 可惜只看部分1/3不到
06/16 19:34, 8F
→
06/16 19:35, 7年前 , 9F
看了clean code批評別人的code不好喔
06/16 19:35, 9F
→
06/16 19:36, 7年前 , 10F
看過THINING IN PATTERNS覺得還是IN JAVA經典
06/16 19:36, 10F
in Java 有看到電子書 可以省一筆了!!
推
06/16 20:01, 7年前 , 11F
Clean coder 根本就是作者自傳
06/16 20:01, 11F
→
06/16 20:41, 7年前 , 12F
註解詳細一點還是比較好
06/16 20:41, 12F
推
06/16 23:09, 7年前 , 13F
註解寫詳細點好？為什麼不是直接把function name寫好一點
06/16 23:09, 13F
→
06/16 23:14, 7年前 , 14F
function name 很難把計算或取資料的邏輯寫上去啊
06/16 23:14, 14F
→
06/16 23:45, 7年前 , 15F
我覺得直接看Martin Fowler 的Refactoring 那本再看 G
06/16 23:45, 15F
→
06/16 23:45, 7年前 , 16F
of Design Pattern 比較實際有用
06/16 23:45, 16F
gof 這本 和大話設計模式 哪一本比較適合 ※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 00:16:22
推
06/17 00:04, 7年前 , 17F
寫夠多 dirty code 了嗎？
06/17 00:04, 17F
開會的時候 被靠盃了 嗚嗚
推
06/17 00:07, 7年前 , 18F
精通設計模式->無瑕的程式碼->重構:改善既有程式的設計
06/17 00:07, 18F
→
06/17 00:08, 7年前 , 19F
這邊提供給您進修三部曲參考，最後一部請搭配出氣娃娃
06/17 00:08, 19F
我不小心看成充氣娃娃..
→
06/17 00:08, 7年前 , 20F
作使用
06/17 00:08, 20F
推
06/17 00:13, 7年前 , 21F
我覺得這一類的書，其實都大同小異
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
→
06/17 00:24, 7年前 , 22F
設計模式的書先從難的挑來看 看不懂就換簡單的 看完
06/17 00:24, 22F
→
06/17 00:24, 7年前 , 23F
後再回頭看難的 如果還是看不懂 就去看 refactoring t
06/17 00:24, 23F
→
06/17 00:24, 7年前 , 24F
o patterns 這本書
06/17 00:24, 24F
推
06/17 01:07, 7年前 , 25F
設計模式挑簡單的看阿，看影片更好,直接看gof等從入門到
06/17 01:07, 25F
→
06/17 01:07, 7年前 , 26F
放棄
06/17 01:07, 26F
從簡單的開始 的確是好上手 但是也沒到放棄這麼誇張啦
噓
06/17 02:51, 7年前 , 27F
只有think in c++吧 我找不到think in c
06/17 02:51, 27F
原來是真的沒有 ※ 編輯: geroge0820 (111.251.20.191), 06/17/2018 03:53:38
推
06/17 04:34, 7年前 , 28F
Allie 3p應該就是你文章提到的那本
06/17 04:34, 28F
推
06/17 08:14, 7年前 , 29F
設計模式請找原典來讀，clean code 建議你至少獨自完成幾
06/17 08:14, 29F
推
06/17 08:20, 7年前 , 30F
設計模式請找原典來讀，clean code 建議你至少獨自完成幾
06/17 08:20, 30F
→
06/17 08:20, 7年前 , 31F
個系統，或有一定經驗再來讀，敏捷的書，讀不如行得出來
06/17 08:20, 31F
→
06/17 08:20, 7年前 , 32F
，你可以讀，但在台灣大多數的軟體公司，就要有革命或另
06/17 08:20, 32F
→
06/17 08:20, 7年前 , 33F
謀高就的準備。
06/17 08:20, 33F
→
06/17 10:54, 7年前 , 34F
其實不用刻意去讀設計模式 多看看別人寫法模仿就好
06/17 10:54, 34F
推
06/17 13:22, 7年前 , 35F
設計模式原典不太推 經驗不足看深入淺出那本比較好
06/17 13:22, 35F
→
06/17 13:23, 7年前 , 36F
clean code可以看但要看仔細 其實大叔在書中都有聲明 那些
06/17 13:23, 36F
→
06/17 13:24, 7年前 , 37F
技巧要因地制宜 並不是一種法律要來規範大家
06/17 13:24, 37F
→
06/17 13:24, 7年前 , 38F
但你很容易忘記他提醒要因地制宜的部份 變成clean code警察
06/17 13:24, 38F
→
06/17 13:25, 7年前 , 39F
還是建議 設計模式 敏捷開發 請都當成「工具」 不是教條
06/17 13:25, 39F
→
06/17 13:26, 7年前 , 40F
學會「在什麼時候該用什麼樣的工具」 比學會使用工具更重要
06/17 13:26, 40F
推
06/17 16:38, 7年前 , 41F
等你看到覺得clean code + design pattern 結合起來應
06/17 16:38, 41F
→
06/17 16:38, 7年前 , 42F
用寫出像文章一樣的code就成功了
06/17 16:38, 42F
推
06/17 19:38, 7年前 , 43F
我直接看深入淺出 原版整個ZZ
06/17 19:38, 43F
→
06/17 22:18, 7年前 , 44F
我覺得面對大量的abstract跟binding不需要註解算蠻厲害的
06/17 22:18, 44F
→
06/18 00:20, 7年前 , 45F
abstract & binding不好懂加入註解多半更難懂欸。
06/18 00:20, 45F
→
06/18 08:59, 7年前 , 46F
我認為現在熱門的framework都有註解 有反例嗎?
06/18 08:59, 46F
→
06/19 00:47, 7年前 , 47F
API有註解不奇怪啊 沒expose的部份還是沒註解居多
06/19 00:47, 47F
→
06/19 00:48, 7年前 , 48F
註解寫多不一定是好事 因為註解也是要維護的
06/19 00:48, 48F
→
06/19 00:48, 7年前 , 49F
所以才會說能免則免
06/19 00:48, 49F
推
06/19 01:09, 7年前 , 50F
會跑就好
06/19 01:09, 50F
→
06/19 09:10, 7年前 , 51F
通常code寫到不用註解是最好的 要加的話 就樓上的舉例來說 f
06/19 09:10, 51F
→
06/19 09:10, 7年前 , 52F
ramework 這東西是內部多人協作跟外部貢獻者要來經營的 通常
06/19 09:10, 52F
→
06/19 09:10, 7年前 , 53F
是會寫的很清楚
06/19 09:10, 53F
→
06/19 09:11, 7年前 , 54F
不然還是要看專案、團隊、是否有特殊幾個狀況需要特別交代
06/19 09:11, 54F
→
06/19 09:11, 7年前 , 55F
的理由來決定要不要寫
06/19 09:11, 55F
→
06/19 13:22, 7年前 , 56F
我最常遇到的就是註解沒人要更新,一堆錯誤,有註解跟沒
06/19 13:22, 56F
→
06/19 13:22, 7年前 , 57F
有註解依樣
06/19 13:22, 57F
→
06/19 20:42, 7年前 , 58F
不維護註解是寫的人不好不能歸咎於加註解不好
06/19 20:42, 58F
→
06/19 20:44, 7年前 , 59F
我遇到這種的都是趕時程的case 重用性很差 程式越堆越肥
06/19 20:44, 59F
→
06/21 10:52, 7年前 , 60F
不過既然要花成本維護註解,為何不花同樣的成本花在維護
06/21 10:52, 60F
→
06/21 10:52, 7年前 , 61F
易讀程式碼呢?
06/21 10:52, 61F
→
06/21 13:12, 7年前 , 62F
有時候想說明整段程式碼的原因跟注意事項 下次看較好回憶
06/21 13:12, 62F
→
06/21 13:15, 7年前 , 63F
如果只有程式碼很容易誤用或是不用 不然就要去看內容
06/21 13:15, 63F
→
06/21 13:17, 7年前 , 64F
可以想想api都沒提供說明要你自己追code這樣有比較快?
06/21 13:17, 64F
推
06/22 00:21, 7年前 , 65F
註解沒維護是人的問題 這種觀念不對 因為註解本身不會被執
06/22 00:21, 65F
→
06/22 00:21, 7年前 , 66F
行 沒人在乎 特別趕的時候沒人會看註解 function class 寫
06/22 00:21, 66F
→
06/22 00:21, 7年前 , 67F
得好很短 更是不會有人看註解
06/22 00:21, 67F
→
06/22 00:24, 7年前 , 68F
但註解還是必要的 有時候靠命名 拆解還是無法全盤托出你的
06/22 00:24, 68F
→
06/22 00:24, 7年前 , 69F
意圖 但我都會抱著些罪惡感去寫註解 覺得自己架構不夠好 命
06/22 00:24, 69F
→
06/22 00:24, 7年前 , 70F
名詞窮 而不是認為寫註解 維護註解是理所當然的事
06/22 00:24, 70F
→
06/22 09:49, 7年前 , 71F
舉個畫表格的例子 一堆DrawLine方法不去註解會很慘
06/22 09:49, 71F
→
06/22 09:51, 7年前 , 72F
下次就要座標慢慢看 如果我註解描述在表格哪個地方
06/22 09:51, 72F
→
06/22 09:52, 7年前 , 73F
這樣找起來就快很多 然後它要維護 不維護更慘
06/22 09:52, 73F
→
06/22 10:17, 7年前 , 74F
我是寫app 不太懂表表格表達是啥 但如果是我或許會是drawXX
06/22 10:17, 74F
→
06/22 10:17, 7年前 , 75F
Xtable() function 裡面有drawSchemaRow() drawSchemaColum
06/22 10:17, 75F
→
06/22 10:17, 7年前 , 76F
n() 再loop data list call drawContentRow()
06/22 10:17, 76F
→
06/22 10:20, 7年前 , 77F
也或許XXXTable本身就是一個class 反正以這樣來看註解就不
06/22 10:20, 77F
→
06/22 10:20, 7年前 , 78F
太需要了吧？
06/22 10:20, 78F
→
06/22 10:35, 7年前 , 79F
就是要印報表要畫很多線 而且還不是一行一筆資料
06/22 10:35, 79F
→
06/22 10:38, 7年前 , 80F
而是公司減少紙張政策有空間就塞的高度課製化報表
06/22 10:38, 80F
→
06/22 13:19, 7年前 , 81F
嗯... 不管如何都可以吧？ 總有同一種類的表單 不可能表單
06/22 13:19, 81F
→
06/22 13:19, 7年前 , 82F
裡東西類型都完全不一樣吧？ 是說有點太細節了 我想必要
06/22 13:19, 82F
→
06/22 13:19, 7年前 , 83F
註解不可免 但大多數情況 你寫註解就輸了 代表架構雜亂 fu
06/22 13:19, 83F
→
06/22 13:19, 7年前 , 84F
nction class 太肥 命名無法傳達意圖 只好靠註解補強設計者
06/22 13:19, 84F
→
06/22 13:19, 7年前 , 85F
的意圖
06/22 13:19, 85F
→
06/22 16:07, 7年前 , 86F
這個例子是剛好正在做 當然這有很多用拖拉的商業套件
06/22 16:07, 86F
→
06/22 16:09, 7年前 , 87F
不過要錢 所以只好慢慢數座標 每條線都自己打code
06/22 16:09, 87F
→
06/22 16:14, 7年前 , 88F
順序也要算好 雖然隨便放也不影響結果
06/22 16:14, 88F
‣ 更多 geroge0820 的文章
文章代碼(AID): #1R9D3Lmt (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 2 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共2篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 geroge0820 的文章
文章代碼(AID): #1R9D3Lmt (Soft_Job)