为什么推荐Linux多线程服务端编程。 转自我的知乎。
2016-12-29
个人感受,这本书写的非常好,也非常用心。但悲观的说,如果一遍看不懂的话,主要是因为缺乏经验。而且,我也并不认为缺乏经验的同学会通过只看书看几次就能看懂。
我觉得技术书籍可能分为几个层次。最上层可能是哲学,中层可能是方法论,最下层是技术说明。比如,技术说明可能是,API 某某可以干什么?XX语言怎么用?这种书籍的阅读需要的经验偏低,可以直接阅读。
到了方法论这个级别,就会说,解决一个问题有很多方法。这些方法哪些是不靠谱的。哪些是常用的,哪些是最佳实践。
而这本书的出色的地方就是基本上是在方法论及以上这个级别来谈问题。这种级别的书,读起来并不再是作者说什么,读者接受什么的过程了。而是一个思辨,对抗,统一的思维过程了。
比如书中说(凭着记忆回忆,不一定完全一致),多线程直接用锁应该用什么锁?读到这里,把书盖上,问问自己,自己会用什么锁?可能有读写锁,有mutex,有spinlock。这些东西自己会怎么用?为什么这么用?
ok,自己想明白之后,再看陈硕的书里怎么写的。也许大多数想法和自己一样。也许差的很远。但,对比自己和陈硕的思考过程,就能知道他牛逼的地方。自己也就提升了。
所以,对于这种书里的问题,没有自己的思考和经验,很难看下去。
顺便多聊一下。明白自己缺乏经验不是坏事。因为时间对大家基本平等,早明白这一点就可以早提升经验。提升的方法有两点。一个是阅读和自己经验更接近的方法论书籍,另一个是实践,写一个自己认为足够困难的东西。另外经验也是分领域的。让我写vue之类的,我也没经验。
另外一点,方法论的书籍,如果还是按照普通说明性质的书籍读。记住了xxx有什么功能。其实感觉收益不是最大的。我也在自己刚学编程的半年后读head first 设计模式。读了几遍也不知道为啥。过几年后重读,发现几个小时左右就全明白了。不过,这类书籍早期看过也不是坏事,只是之后拿起来重读就好了。
还有一种书籍,或者文章。是哲学级别的。比如python的import this。这个其实更容易读懂,因为基本都是大实话。但是,也更难实践。就是很多人说的,道理我都懂,过不好一生一样。
跑的有点偏,总结起来。这本书是方法论和哲学层次的书,阅读这类书都有很大的经验门槛。如果读不懂,这很正常。不要觉得缺乏经验不好,可以先补充这方面的经验。
大概这样吧,顺便感谢作者贡献。