看书是为了提升你的综合素养，别只是惦记着你那几行破代码【直播精华#10】

自护意识:
《颈椎病康复指南》《程序员如何活的更久》《劳动法》。少看点专业书，多学点人生经验，技术不会带你走的更远

【回复】赞同，糊口的家伙事儿只是为了生活，挣钱就是为了谋生，国内就没有到年限不裁员的
ZeromaX訸:
up说的可以多读些计算机领域其他的书这点我认同，但感觉直接不建议读那些经典的代码书籍是不是也有失偏颇？ 个人感觉那种类型的书读个一两本还是值得的，起码给初学者了解清晰代码的方向（其实不一定是初学者，有些工作久的人自己不思考这方面的话代码可读性、可维护性也是很差）。个人感觉这些并不是说所有人工作了就一定能自然而然就能习得的，有本相对完善的书看看，指导一下思路还是挺好的。 至于视频里说的大意——那些书不是普适的解法，因此说就没必要读——那我感觉这本身就是那些书都会提到的一句话“没有银弹”，那些书的目的从来都不是作为一颗银弹解决所有编程代码规范的问题，而是给你一些思路。以它们为凭借，从此你可以自己去思考如何写更好的代码。 不过确实没必要读太多，这类书到最后其实就那些内容：重构、解耦、单元测试之类的，掌握以后就可以了

【回复】但凡普通人有老哥您那么理性，我们这些反clean code党也不至于能壮大。 你就把我们想象成鲁迅说的那个为了开窗户而呼吁拆屋顶的人吧。 我在直播里也提到过很多次（说得比较零散，所以没有切进来），我不是反对clean code里的所有观点。因为它的一些观点本身就是编程常识，是common sense，是学校里就应该教过的，不是它原创的。我反对的是它里面的一些原创观点，那些观点我是在《让编程再次伟大》系列的视频里有理有据地反驳过的。 我选择大声呼吁拆屋顶，就是因为太多小孩子选择全盘接受这些书的观点，不去用科学的方式判断里面那些是合理的哪些是不合理的。 至于最后有没有把屋顶拆了，我是无所谓的，只要让大家开始思考要不要开窗户，我觉得我的目的就达成了[doge]
【回复】是的，我自己带开发团队，带过的程序员也不少 了，按我 code review 的经历来看，事实上只有最多一半人是符合up主所说的“当你有一定工作经验以后，你的感觉其实很准的”。有一些人五年前和五年后写的代码毫无长进，根本不用谈可读性/可维护性/单元测试覆盖率等。如果你不指导，他永远不会意识到问题。然而这类人往往也不会去好好读 clean code 这类经典代码书籍……所以某种程度来说 up 说的也对，会读的人没必要读，有必要读的人根本不会读[doge]
【回复】回复 @原子能 :没事，还有我这种全盘反对的。为什么反对呢？因为我看的国外名校的课程中，捎带把这些东西都教了[doge]
等风来的风向仪:
书要泛读也要精读，要相信书里的观点，但也不要尽信书里的观点。 泛读的目的是了解尽可能多的观点，然后和自己的代码实践相印证，保留自己认可的，以及改进自己不足的。 clean code 要做，但是也要有自己的 clean code 规则才行。 总之，读书要多读，但也要记得带上脑子去批判的读。

【回复】总结就是：像人月神话中说的那样，没有银弹
明天什么不存在好不好:
我日常不怎么处理网络协议，我就好奇别人是怎么玩出花来的，还有操作系统，感觉不去深入了解也能处理问题，但心里还是有点疙瘩

【回复】回复 @XellinPP :冲，看来就是持久的学，想一时半会了解全面是不可能的
【回复】回复 @朋克李PunkLi :Java软件应用开发，我最多会用linux，会写脚本，会基本的操作，我想学的是更加核心的东西，例如早期的docker，通过linux的联合文件系统，就搞出了镜像系统，而且还能虚拟网络，分配资源，让我感觉自己会的一些皮毛啥也不是[笑哭]
【回复】操作系统我花了两三年时间已经扒得差不多了，确实有意思
COC-衣妄:
个人推荐推荐书籍: C： C Primer Plus, C和指针，C专家编程 C++：有专门的视频 基础四大件： 数据结构和算法：大话数据结构，剑指offer，刷题。 计算机网络：TCP/IP详解 操作系统：深入理解操作系统 设计模式：大话设计模式 应用与编程实践： Linux：鸟哥的Linux私房菜 或 Linux就该这么学 编译和调试工具材料：英语好的看GNU官方关于GCC和GDB的官方文档。中文版《debugging with gdb》,跟我一起写makefile Linux的环境编程：Unix环境高级编程 ，Linux高性能服务器编程，POSIX多线程程序设计

LAST7_7:
我的 edge 界面设置和 up 的一模一样，垂直标签栏太好用了

【回复】回复 @LAST7_7 :经历过IE工具栏时代的我，对屏幕的垂直空间格外重视 (ノ≧∇≦)ノ
随心一听-_:
写代码确实实操比较好，那如果是技术提高了想比较全面的了解底层呢，这种适合看书吗，像《深入理解java虚拟机》啥的，虽然可以看源码，但是源码太复杂可能会不知道先从什么地方看起比较好[笑哭]

【回复】回复 @随心一听-_ :这个取决于那本书好不好，说得够不够全面了。 我的个人习惯是，对于这种底层知识，我都是书+官方文档+各种介绍视频混搭着看，因为每个都有各自的优缺点，一起看就能互补。 比如你想深入了解JVM，那肯定要配上甲骨文的官方文档： https://docs.oracle.com/javase/specs/jvms/se21/html/index.html
【回复】别看源码了[笑哭]，浪费时间
【回复】回复 @原子能 :哦吼，能哥还没睡呀，了解，谢谢能哥[呲牙][呲牙]
我干过沉水贬:
clean code和什么整洁的架构，你看完会发现，和没看区别不大[妙啊]

【回复】回复 @寂夜无痕 :按照你说的，业务解耦设计模式什么的才是外功，扩展性效率什么这些是内功，你这不反了吗？
【回复】回复 @我干过沉水贬 :我所比喻的编程外功就是语言、技术框架和高性能、高可用的设计和运用，侧重技术侧，而内功就是指设计模式、业务解耦、扩展性等侧重思想的知识。从职业发展的角度讲，前者可能会成为技术专家，后者则可能会成为架构师（举个例子，内外功只是比喻，职业方向跟这个比喻也不是因果关系） 然后看我刚刚的举例你或许可以理解我的想法，你所指的看成功的框架是如何设计的是侧重技术侧，成功的框架能让我们实现更复杂的技术能力、用更好地技术架构帮助我们实现高可用、高性能或者高健壮性的技术能力；但它或许无法指导我们去实现能长期满足业务需要的代码。技术能力是稳定的，业务需求是长期膨胀增长的，如果你已经工作了想必能理解我想说的？ 我们公司并没有使用六边形架构，也没有完全依照书中理论上的设计原则，但是有大佬在尝试融会贯通作用在他的项目里，而我也只是参考借鉴其思想而已，让理论结合实践。这也是我们学习阅读的原因啊，学习这些整洁架构不是让实践去满足理论，而是让理论服务于实践。 而你最后所说的过度设计，自当避免，避免不开那也是人的问题而不是架构或思想本身的问题。看框架的架构也可能会出现过度设计，给一个管理后台做高并发架构、跟给一个简单项目上 DDD 一样属于过度设计。
【回复】回复 @寂夜无痕 :不知道你说的啥是内功啥是外功，也不知道你怎么用他书里写的那个什么六边形框架实践的，建议看看成功的框架是怎么开发设计的。但无论如何请记住，过度设计不如不设计[妙啊]
dotdot:
“静坐常思己过，闲谈莫论人非”，唉，还是做不到。 书该读还是不该读，建议从自身现阶段面临的问题入手, 我见过很多干过四五年编码工作的人，也早早读过一系列经典，但于其工作却毫无帮助或体现。 教育具有一定的滞后性，如果某一天突然顿悟出某个状况的解，说明了以前的某本书起到了作用。 如果一直没有这种顿悟感，也大可不必诽谤诋毁，因为你可能很幸运不用去处理那些令人头大的状况。

老布莱克OldBlack:
clean code 不看？你就是那种写了一堆屎山给别人的程序员吧

【回复】你说有没有一种可能，clean code就是制造屎山的功臣之一 [吃瓜][吃瓜]
木几工丂:
虽然看了很多乱七八糟的书，但我还就惦记着那几行破代码[笑哭] 看来提升无望

effective_斯利普斯利普:
哪有这么极端，看书是看别人的观点和经验，又不是说看了书就全部一模一样照抄。。。

MasonCode:
重构 clean code这些书都是我们公司出的，一直也被公司奉为经典，但我也觉得这些东西应该是个基础共识而应该过分强调，就仿佛在智能机的时代你给我介绍手机一个劲的再说这个手机能打电话能发短信，会让人非常无语。 但是这些书应该还是值得一看的，但是是对于有一定开发经验的，你在开发过程你会对代码有思考，但是不是每个人能够提纲挈领，这时候这样一本书帮你总结了99%的场景，你会看的很快，并且帮你梳理。

言西早xw:
确定描述的不是死读书的那一类人?然后一棍子打死?

黑屏:
蓦然回首，才发现懂得了许多道理，却依然过不好这一生[doge]