前言
无关的前言。六月时买的书，一直藏着没打算看。把深入理解 Android 卷III 翻完之后就决定把这本书翻了。
正文
作为一本指导类型的书，这本书讲了从变量名一直到多线程同步编程，系统设计，涵盖了各种细节到大观。
说结论，我个人并不是很喜欢这本书。相较于程序员修炼之道，这本书有大量主观的说法。
关于命名，我非常赞同作者的说法。在项目里我见过太多名字被起得莫名其妙的类，域名，方法。这些类根本让人无法搜索，只能通过入口去一层一层深入。这真的是一件让人很恼火的事。
作者也把匈牙利命名法批判了一番，这种前缀毫无意义。前缀跟后缀应该使用来表示 Context，而非用于标记这是一个变量或者其他。
关于方法，我赞同有些方法应该尽可能地短，函数名应该尽可能表达其含义。但我在书里所看到的是，不少是支离破碎的细节。确实，尽可能地提取了函数之后，逻辑上会更加清晰，但跳转逻辑太多也会让人恼火。我更习惯于在逻辑快变得复杂时，将这一部分单独提取出来。把每个 if 语句的判断逻辑都写成一个函数，我应该也没有这种重构的时间。
另外，作者偶尔也会自我矛盾。有时候他提取了小逻辑，有时候他又说这没必要。这其中并没有一个标准。
关于注释，「注释最多只是一种必须的恶」。因为你没法用你的函数名清楚地告诉调用者使用之后会发生什么事，所以你要说明。
作者提到的是否需要注释的部分，有些只能算是说说罢了。比如说，公共使用的 API 需要注释。你并没法保证你做的这个模块是否会成为公共模块，所以你到底要不要写注释呢？
关于糟糕的注释也是，修炼之道告诉你，你要署名，因为这代表是你所完成的，代表你对这份代码负责。这本书告诉你：署名？丢掉吧，版本控制系统会告诉你。但我个人倾向于修炼之道的做法。
「一组开发者应当认同同一种格式风格，每个成员都应该采用那种风格。」这句话真的是戳到了我的痛点，我在跟一群完全不在乎这种事的人共事着。连格式都不在乎，他们怎能写出让人愉快的代码？
书里关于异常处理的代码，确实是让我看到异常的另外一种处理方法。将内部抛出的各类异常包裹成自己的异常，使内部的代码尽可能地简洁，即 try 块中只有正常执行的代码。这种代码看起来真的蛮舒服的，值得一试。
这本书后半很大一部分的内容都是作者在教你怎么把一段看起来不怎么「优雅」的代码改成他想要的样子。书的最后更是贴了六十几页的代码来举一个完整的例子。
可是我在他改的过程中所看到很多是作者自己主观的想法。一个函数到底多短才可以？这真的不只是越短越好。hot point 的话，方法内联也是必须的。如果你知道一个函数会把大量调用，适当减少调用层次会帮你不少忙。另外，时间跟效率的平衡也是值得考虑的一件事。我真没空把函数拆得支离破碎，在保证「一定」整洁性的前提下，我得去干其他事。
书里提到的大量重构的内容，我觉得我大概怎么都做不了吧。Android 真不是一个希望你能给你的应用写测试的平台。
另外一件事
这是一部译著，这本书需要评论还有它的翻译。
我想，如果当初我是在实体书店翻过这本书的话，我是一定不会买的吧。这个翻译翻出来的文字读起来让人特别纠结，文诌诌的（比如把依赖翻成依恋），完全没有作者在某些地方表现出来的幽默感。最可怕的是，这个译者有些专业术语更是不可原谅地翻错了。explaining temporary variables - 解释临时变量模式？what？具有解释性的临时变量多正常。把 decorator 翻成油漆工？把 collection 翻成集群类？真怀疑译者到底有没有起码看过一本设计模式书籍或者Java入门书。
まとめ
如果要给这本书一个评分的吧，就像我在豆瓣上给的，原书4分，翻译2分。这个翻译太糟糕，列入黑名单。
在豆瓣上给的评价：
「4分给原作，翻译2分。整本书看起来极其费力。译者好像在追求着用语的与众不同，比如把依赖翻成依恋？译者的辞藻是不是用错地方了。看霍炬翻的重构我都没有这种感觉，人家是翻得是真有文采跟幽默感。这本书最糟糕的是把一些专业术语翻得莫名其妙，把装饰器翻成油漆工？集合类翻成集群类。任何一个看过设计模式跟Java入门书的人都不会这么翻。」