作者geroge0820 (可.....可恶)
看板Soft_Job
标题[请益] 关於clean code书籍选择
时间Sat Jun 16 16:56:45 2018
小弟工作资历尚浅 前一阵子才转职
目前是用ASP.NET MVC进行网页开发
因为自己还蛮菜的 想加强能力
不知道大家都怎麽选clean code的书
目前在网路上看到 clean code又是C#实作的是这一本
无瑕的程式码 敏捷完整篇：物件导向原则、设计模式与C#实践
想请问版上的各位 有没有甚麽建议
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.251.34.192
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1529139413.A.C37.html
1F：推 qqkerk: 这位大叔的书都不错，但只要不要全部当成真理就好了，实06/16 17:39
2F：→ qqkerk: 务上还是得因地制宜QAQ06/16 17:39
你讲完 害我有点不知道要不要买了
3F：→ fukinhot: 都大同小异吧 重点是要看完06/16 17:49
4F：推 landlord: agile 3p > clean code > clean architecture, clean c06/16 18:14
5F：→ landlord: oder可以随时看06/16 18:14
agile 3p 不知道是哪一本
6F：推 TitanEric: 不是Java吗 原来有C#？06/16 18:23
有啊 今年才看到有C#的
7F：嘘 THEWORLDS: THINK IN C 先看 CLEAN CODE不要去看 你无法理解的06/16 18:28
8F：推 prag222: 厅前同事在嘴 之前也有看了一下 可惜只看部分1/3不到06/16 19:34
9F：→ prag222: 看了clean code批评别人的code不好喔06/16 19:35
10F：→ prag222: 看过THINING IN PATTERNS觉得还是IN JAVA经典06/16 19:36
in Java 有看到电子书 可以省一笔了!!
11F：推 nashyuuki: Clean coder 根本就是作者自传06/16 20:01
12F：→ testPtt: 注解详细一点还是比较好06/16 20:41
13F：推 owlran: 注解写详细点好？为什麽不是直接把function name写好一点06/16 23:09
14F：→ sextitanic: function name 很难把计算或取资料的逻辑写上去啊06/16 23:14
15F：→ csieflyman: 我觉得直接看Martin Fowler 的Refactoring 那本再看 G06/16 23:45
16F：→ csieflyman: of Design Pattern 比较实际有用06/16 23:45
gof 这本 和大话设计模式 哪一本比较适合
※ 编辑: geroge0820 (111.251.20.191), 06/17/2018 00:16:22
17F：推 readonly: 写够多 dirty code 了吗？06/17 00:04
开会的时候 被靠盃了 呜呜
18F：推 banqhsia: 精通设计模式->无瑕的程式码->重构:改善既有程式的设计06/17 00:07
19F：→ banqhsia: 这边提供给您进修三部曲参考，最後一部请搭配出气娃娃06/17 00:08
我不小心看成充气娃娃..
20F：→ banqhsia: 作使用06/17 00:08
21F：推 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
22F：→ csieflyman: 设计模式的书先从难的挑来看 看不懂就换简单的 看完06/17 00:24
23F：→ csieflyman: 後再回头看难的 如果还是看不懂 就去看 refactoring t06/17 00:24
24F：→ csieflyman: o patterns 这本书06/17 00:24
25F：推 naoomi: 设计模式挑简单的看阿，看影片更好,直接看gof等从入门到06/17 01:07
26F：→ naoomi: 放弃06/17 01:07
从简单的开始 的确是好上手
但是也没到放弃这麽夸张啦
27F：嘘 KernelChen: 只有think in c++吧 我找不到think in c06/17 02:51
原来是真的没有
※ 编辑: geroge0820 (111.251.20.191), 06/17/2018 03:53:38
28F：推 dannypsnl: Allie 3p应该就是你文章提到的那本 06/17 04:34
29F：推 fayhong: 设计模式请找原典来读，clean code 建议你至少独自完成几 06/17 08:14
30F：推 fayhong: 设计模式请找原典来读，clean code 建议你至少独自完成几 06/17 08:20
31F：→ fayhong: 个系统，或有一定经验再来读，敏捷的书，读不如行得出来 06/17 08:20
32F：→ fayhong: ，你可以读，但在台湾大多数的软体公司，就要有革命或另 06/17 08:20
33F：→ fayhong: 谋高就的准备。 06/17 08:20
34F：→ testPtt: 其实不用刻意去读设计模式 多看看别人写法模仿就好 06/17 10:54
35F：推 Argos: 设计模式原典不太推 经验不足看深入浅出那本比较好 06/17 13:22
36F：→ Argos: clean code可以看但要看仔细 其实大叔在书中都有声明 那些 06/17 13:23
37F：→ Argos: 技巧要因地制宜 并不是一种法律要来规范大家 06/17 13:24
38F：→ Argos: 但你很容易忘记他提醒要因地制宜的部份 变成clean code警察 06/17 13:24
39F：→ Argos: 还是建议 设计模式 敏捷开发 请都当成「工具」 不是教条 06/17 13:25
40F：→ Argos: 学会「在什麽时候该用什麽样的工具」 比学会使用工具更重要 06/17 13:26
41F：推 Masakiad: 等你看到觉得clean code + design pattern 结合起来应 06/17 16:38
42F：→ Masakiad: 用写出像文章一样的code就成功了 06/17 16:38
43F：推 prag222: 我直接看深入浅出 原版整个ZZ 06/17 19:38
44F：→ testPtt: 我觉得面对大量的abstract跟binding不需要注解算蛮厉害的 06/17 22:18
45F：→ Masakiad: abstract & binding不好懂加入注解多半更难懂欸。 06/18 00:20
46F：→ testPtt: 我认为现在热门的framework都有注解 有反例吗? 06/18 08:59
47F：→ cha122977: API有注解不奇怪啊 没expose的部份还是没注解居多 06/19 00:47
48F：→ cha122977: 注解写多不一定是好事 因为注解也是要维护的 06/19 00:48
49F：→ cha122977: 所以才会说能免则免 06/19 00:48
50F：推 mepowerlmay: 会跑就好 06/19 01:09
51F：→ alog: 通常code写到不用注解是最好的 要加的话 就楼上的举例来说 f 06/19 09:10
52F：→ alog: ramework 这东西是内部多人协作跟外部贡献者要来经营的 通常 06/19 09:10
53F：→ alog: 是会写的很清楚 06/19 09:10
54F：→ alog: 不然还是要看专案、团队、是否有特殊几个状况需要特别交代 06/19 09:11
55F：→ alog: 的理由来决定要不要写 06/19 09:11
56F：→ leolarrel: 我最常遇到的就是注解没人要更新,一堆错误,有注解跟没 06/19 13:22
57F：→ leolarrel: 有注解依样 06/19 13:22
58F：→ testPtt: 不维护注解是写的人不好不能归咎於加注解不好 06/19 20:42
59F：→ testPtt: 我遇到这种的都是赶时程的case 重用性很差 程式越堆越肥 06/19 20:44
60F：→ leolarrel: 不过既然要花成本维护注解,为何不花同样的成本花在维护 06/21 10:52
61F：→ leolarrel: 易读程式码呢? 06/21 10:52
62F：→ testPtt: 有时候想说明整段程式码的原因跟注意事项 下次看较好回忆 06/21 13:12
63F：→ testPtt: 如果只有程式码很容易误用或是不用 不然就要去看内容 06/21 13:15
64F：→ testPtt: 可以想想api都没提供说明要你自己追code这样有比较快? 06/21 13:17
65F：推 Ghamu: 注解没维护是人的问题 这种观念不对 因为注解本身不会被执 06/22 00:21
66F：→ Ghamu: 行 没人在乎 特别赶的时候没人会看注解 function class 写 06/22 00:21
67F：→ Ghamu: 得好很短 更是不会有人看注解 06/22 00:21
68F：→ Ghamu: 但注解还是必要的 有时候靠命名 拆解还是无法全盘托出你的 06/22 00:24
69F：→ Ghamu: 意图 但我都会抱着些罪恶感去写注解 觉得自己架构不够好 命 06/22 00:24
70F：→ Ghamu: 名词穷 而不是认为写注解 维护注解是理所当然的事 06/22 00:24
71F：→ testPtt: 举个画表格的例子 一堆DrawLine方法不去注解会很惨 06/22 09:49
72F：→ testPtt: 下次就要座标慢慢看 如果我注解描述在表格哪个地方 06/22 09:51
73F：→ testPtt: 这样找起来就快很多 然後它要维护 不维护更惨 06/22 09:52
74F：→ Ghamu: 我是写app 不太懂表表格表达是啥 但如果是我或许会是drawXX 06/22 10:17
75F：→ Ghamu: Xtable() function 里面有drawSchemaRow() drawSchemaColum 06/22 10:17
76F：→ Ghamu: n() 再loop data list call drawContentRow() 06/22 10:17
77F：→ Ghamu: 也或许XXXTable本身就是一个class 反正以这样来看注解就不 06/22 10:20
78F：→ Ghamu: 太需要了吧？ 06/22 10:20
79F：→ testPtt: 就是要印报表要画很多线 而且还不是一行一笔资料 06/22 10:35
80F：→ testPtt: 而是公司减少纸张政策有空间就塞的高度课制化报表 06/22 10:38
81F：→ Ghamu: 嗯... 不管如何都可以吧？ 总有同一种类的表单 不可能表单 06/22 13:19
82F：→ Ghamu: 里东西类型都完全不一样吧？ 是说有点太细节了 我想必要 06/22 13:19
83F：→ Ghamu: 注解不可免 但大多数情况 你写注解就输了 代表架构杂乱 fu 06/22 13:19
84F：→ Ghamu: nction class 太肥 命名无法传达意图 只好靠注解补强设计者 06/22 13:19
85F：→ Ghamu: 的意图 06/22 13:19
86F：→ testPtt: 这个例子是刚好正在做 当然这有很多用拖拉的商业套件 06/22 16:07
87F：→ testPtt: 不过要钱 所以只好慢慢数座标 每条线都自己打code 06/22 16:09
88F：→ testPtt: 顺序也要算好 虽然随便放也不影响结果 06/22 16:14