小弟工作资历尚浅 前一阵子才转职
目前是用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顺序也要算好 虽然随便放也不影响结果