Juven Xu

我是个喜欢读书的人，大学里买不起书就收集了好多电子书（盗版行为，不鼓励），工作后手头没那么拮据了，就买很多书，影印的、翻译的、国人原创的、二手的，还有一些直接从amazon.com购买的原版书，当然那个价格就相对贵很多了。到目前为止，书房一个大大的书架也已经塞了十之八九。这还不包括我在iPad上的不少阅读量。

虽然是计算机书，但大多都是随性而读，换句话说就是全凭兴趣，因而不够严肃专业，自然太深的积累是没有的，不过浅一些的心得还是可以说一说的。

首先是挑书，我在读书的同时慢慢锻炼了挑书的能力，因为读书最大的消费不是书价，而是时间，因此挑对书是至关重要的。我读书主要是看出版社，比如国外著名的有O’Reilly、Manning、Addison Wesley、Pragmatic Bookshelf等等，这些出版社的书大部分质量非常优秀，也包含了不少的经典，就算你不小心遇到本很水的，那几率也是非常地低。国内出版社和国外差距很大，但应该说一直在进步，我个人最喜欢的是东南大学出版社的O’Reilly影印系列，质量真是好得没话说，价格也公道。关于翻译，人民邮电图灵的质量应该是做得最好的了，特别是有阮一峰这样的译者，真是读者的福气。原创方面的话，应该说机械工业的华章和电子工业的博文视点强一点，经常会出现一些让人眼前一亮的书，其作者水平真不比老外差。

挑书还得看作者，不熟悉作者的话，那就去网店搜一下作者的名字，如果看到他有10本或者更多的著作或译作，三五年内完成，专业领域跨度又极大，那基本上这是个不负责任的家伙。计算机行业写作不是写玄幻小说，本身需要很厚的技术积累，很多专家都是积累三五年，然后再花一两年才能磨出一本好书的，因此高产的基本就无法保证质量。还有一个看作者的方法是看他有没有自己给书开辟一个网页，负责的作者会把自己的书看得很重，因此写完了也会持续收集反馈。

挑书当然也可以看网店的书评，什么China-Pub啊、当当啊、京东啊、卓越啊、豆瓣啊等等，但不是所有书评都是可以相信的，书拖书黑在这个年代就像火车站卖发票的贩子一样常见。我个人会关注那些购买了书后，写得较长的有理有据的书评。什么“好书，顶”，或者“垃圾、骗子”这样的评论其实等于什么都没说。看看amazon.com上的书评，好在哪里、不好在哪里，说得清清楚楚，那才是有意义的。

挑到了好书就开始享受咯！我会大概把书分为简单两类，其一是硬技术，例如一门语言ruby，一个技术lucene，不学就不会，学了就会。对这类书，会有两种阅读的驱动力，一是完全凭兴趣，例如前一阵子因为《黑客与画家》的缘故，想学学lisp了，那就找本lisp的书看看，又或者因为最近买了mac，就找本mac编程的书看看，等等。二是功利性阅读了，例如最近一个项目要用到lucene，那就找本lucene的书来啃，以应付工作。功利和兴趣还是结合起来的好，完全功利了就没有自己的想法，完全凭兴趣那也不太现实，毕竟还是要工作的。当然，如果工作的技术点就是你的兴趣，那再好不过。

除了硬技术类书籍，还有大量软技术的书籍。最好的例子就是《程序员修炼之道》，它没说某个特定的技术，但总结了大量闪光的思想，可能读到其中一条你会有豁然开朗的感觉，又或者你读的时候没在意，一段时间后在实际工作中遇到的问题让你想起书中的一些建议。出版社可能会将其归入“技术人文类”，但我觉得，所有那些看过一遍都要思考理解后才能慢慢感悟的书都属于“软技术”，例如《重构》也算，还有一些软件工程类的如敏捷开发等等。

我会夹杂着读硬技术书籍和软技术书籍，相对来说软技术书籍读起来会轻松一点，因为表面意思理解很容易，而硬技术，懂就是懂，不懂就是不懂，前后还有衔接，要求你硬记住，或者实际操作才能理解。但其实真正理解软技术更难，这些书往往需要你读过一遍之后，过一年再读，再过几年再读，才能理解作者的思想。当然读太多这类的书而忽于实践也不好，到最后只剩下空洞的理论。功利性的阅读往往只再硬技术上，但如果缺乏软技术的补充，往往会迷失，好比已经积累了很多内力但缺乏调理。

书读得多了，我渐渐有了点怪癖，例如追求原版书的印刷质量，有时候会不惜好几倍的价格买原版书。又或者一直盯着市场看有什么好书出来，有了就买，到最后都来不及读。还有就是能读英文就不读翻译，完全是盲目的。其实只要翻译够好，读起来也爽，还能节省时间。不过话说回来，作为一个程序员，读个至少十本八本的英文版还是有必要的，这点能力是必须的。

读书的时候做点笔记也大有帮助，给自己买本漂亮的笔记本，多少写写划划，电子版的话，很多软件如iPad平台上的，都支持做些笔记。这都帮助思考，而不是简单的字面意思都过掉了，以为读完了，其实理解甚少。

大概想到的就这么多了，最后给大家的建议是，只要是你认定的好书，读一遍肯定是不够的，一定要读个两到三遍！

本文已经首发于图灵社区，原文为《阅读计算机图书的一些心得》，如需转载，请务必附带本声明，谢谢。

Just finished the book “Building and Testing with Gradle” in this vacation, and here is my review.

First of all this book has a great Foreword by Ken Sipe, the CTO of Gradleware. I totally agree with him on

What I have discovered over the years as a software engineer is that in order to solve a problem best, I have to understand the model. The reason make wasn’t a great build tool for Java is that it didn’t have a way to express the model well. Ant gave us platform independence and a better vocabulary, but a weak model. Maven provided a stronger model, which is why so many people prefer it over Ant. The challenge for Maven is that it provided a “the one model to rule them all”. You’re able to express your build needs within that model and only that model.

Gradle fills the gap. Gradle provides a way of modeling a build system using a DSL with convention over configuration, yet allowing an enterprise to define its own model. It goes deeper than this, as explained in this introductory book by Matthew and Tim, but modeling by convention is truly a game changer for enterprise software development.

To simplify, Make has no build model, Ant has weak model, Maven has one (and only one) strong model, and Gradle allows you do define model. I’m not saying Gradle is better than Maven, actually I think in most cases, one strong model is better than allowing people define models. But the ‘model’ concept is the key to undertand the differences among those tools.

BTW, the title of this post if borrowed from Ken’s foreword .

This is one of the shortest technique book I’ve ever read, only 110 pages composed by 6 chapters:

1. Hello, Gradle!
2. Gradle Tasks
3. Ant and Gradle
4. Maven and Gradle
5. Testing with Gradle
6. Multiproject Builds

Just like any tool introduction book, the first chapter is for the very beginners. The ‘Gradle Tasks’ chapter is the most valuable part of this book, it does a good job explaining this key concept, and in a practical way. The third chapter is for Ant users the fourth is for Maven users, I belong to the latter. From the ‘Maven and Gradle’ chapter I can see the Gradle implementations of Maven concepts like coordinate, dependency, repository, and convention, but a bit disappointed on the missing of lifecycle. The ‘Testing with Gradle’ has little value, it’s just too basic. The last chapter is on multi-project builds, or sometimes we call this multi-module builds. Any real project is multi-moduled so I could not skip it. This chapters introduces 3 ways to organize your modules, one build file for each module, one master build file for all modules, and in a hybrid way which some modules have build file while somes don’t. This is interesting to me because Maven only gives me one choice. But, when I looked forward to see some advice on when to use which style, the authors told me to decide by myself .

Too short the book is so sometimes I have to refer to the official gradle user guide to understand something. The authors mentioned that there will be future volumes for Gradle plugin ecosystem and Java plugin, besides, I also hope there will be something on Gradle’s lifecycle, and more importantly, real world examples and best practices. This is the only published Gradle book and Gradle itself is only on version 1.0-milestone-3, so there is a lot of space to improve.

Thanks to Tim Berglund & Matthew McCullough for making this book out.