2014年5月29日下午7点19， 跟google约定的面试在5天以后进行， 这个时间心心念念都是各种面经各种网上经历各种coding interview exposed啥的 = = 但我在开始临阵磨枪前专门抽时间看了几本所谓内功修行指南， 这本是其中之一。
就个人经历来说， 我觉得无论大陆还是北美（BTW 大家总觉得印度软件厉害， 其实印度的计算机科班教育更不堪， 很多印度人在印度的大学读完计算机本科都没动手写过一行代码， 我就不说了）， 计算机科班训练中比较缺乏而日后参加工作又非常重要， 体现程序员区分度的一个是code pattern， 包括implementation pattern（http://book.douban.com/subject/2042269/）、 design pattern （http://book.douban.com/subject/2866799/） 和architecture这些， 另一个就是code quality。 其实按我本科的教育， 从大一到大三， 一路学习了模拟电子， 数字逻辑， 计算机组成原理， 编译原理， 操作系统， 高级语言程序设计这些， 我感觉要全部学好其实可以从提炼硅开始， 慢慢做三极管， 拼数字逻辑模块， 打造计算机并自己写编译器操作系统啥的， 但学习的时候老师只是专注地教各自分散的内容， 没有人来告诉你如何把这些融在一起， 如何用对这些知识的了解来提高自己代码的质量， 使科班出身的人写的代码区别于其他人写的。 毕竟， 大部分计算机学院出来的人都是写代码的， 没哪个真去搞电路板吧， 工作中涉及到编译器处理细节的也是那些在各种编译器厂商工作的小众。 没错的， 学过的所有东西都要服务于我们正在做的事情， 在这点上我喜欢CMU计算机学院前任院长的作风， 他写那本讲解计算机系统的书 （http://book.douban.com/subject/1896753/） 直接点明了是为程序员服务的， 材料组织和拣选都围绕着能提高代码质量这个主题。
貌似扯远了， 转回来， 为什么在应该大量练习编程解决算法题的时候来这个？ 或者为什么我这么强调这个？ 因为在目前这家公司被低质量的 legacy code折磨得够呛。 即便是北美的院校教育出来的， 写代码大概也就这样， 只要你的代码work就ok， 各种公司面试的时候也是看你能不能写出一个函数解决某个问题， 然后看你数学功底如何啥的。 注意， 虽然没有明说代码质量不重要， 也许各大公司也挺看重代码质量的， 但是他们没明说， 那他们这样的评判标准其实带有一种价值观的导向性。 这么说其实并不想把指针从一个极端拨向另一个极端， 比如号召同志们都注重代码质量， 对于算法效率的研究就可以不用那么抓紧， 只是想说对于代码质量， 虽然各种面试可能不那么看重， 也不能为你谋到跨国大公司里的好职位， 帮你找到好妹纸， 但要从原来不那么重视的地位提到一定的高度， 从一开始就把它变成一种习惯， 内化在自己的每一行code中。 别看这本书通篇在讲一些接地气的东西， 仿佛计算机系大一刚学c/c++的孩子们的扩展读物那样， 要知道这本书的作者本人是一个算法很 厉害的家伙， 搞计算机图形学的谁搞过谁知道。 只是， 一栋大楼你建再好， 远远看去很不错， 但这些细节不搞好，搬进去这里漏水那里没电是小事， 突然地基哪里不对， 就像作者讲的， 一个assert不对可以终止掉你整个系统 = =
所以看重代码质量的很少， 截止目前为止我认识的， 知道字符串比较用comparewith 而不是equals的， 知道克服大脑思维把常量写左边的， 只有一个人， 就是现在团队的auto-testing 的lead， linkedin上他称自己是software craftsman = = 很多人对此的误区就是要代码质量就得放弃进度， 要赶进度就得牺牲一些代码质量。 他们得出这样的结论是基于这样的观察， 比如你看变量的命名， 不care代码质量我遇到函数还是变量随便给它个名儿， 我爱叫啥名叫啥名， 那要遵循代码质量最好全队先一起开会商量个naming convention， 然后每次我起名字还得去查那个命名规定， 然后写出来的名字也许会比较长比较怪， 又让我每次都重复去type； 再比如你看那个设计模式， 好端端的干嘛抽一个接口出来， 干嘛能放这里的代码我要放那里， 然后用一种很奇怪的方式组装起来， 感觉整个code base像在做瑜伽还是易筋经， 就整个人还是好的但一定要摆一个无比怪异的pose在那里， 然后我还得专门停下来好好捉摸捉摸什么情况下应该摆什么pose， 那对于规模小一些的项目很有可能那些形式的代码要比真正的function code还多， 然后要trace回去也麻烦， 动辄就好几个类一起改， 我就习惯想到啥写啥一个函数洋洋洒洒几百行一蹴而就， 像在QQ上跟暧昧对象聊天吹牛一样无比直接真诚都不带拐弯抹角的…… 以上所有这些都是真的， 但我还是要说代码质量跟开发进度之间并不存在冲突， 恰恰相反， 是互相促进互相得益的。 这大概只有在巨型 legacy code base 上工作过， 并且经历长期迭代改进， 经历重构的人才能体会。 就是懂的自然懂， 不需要我解释； 不懂的就不懂， 我解释也没用(苦笑) 所以好的代码质量如何帮助项目进度我就不细讲了~ 然而我估计来找类似这样的书的读者， 更甚至来看到这篇书评的基本都对此感同身受的了~
其实在很久很久以前， 不确定是不是还在读大学的时候， 我就读过这本书的草稿， 那时候大概一百多页， 半天读完就已经留下很深的印象了。 应该说， 所有用C/C++写过比较大规模的code base的人读完都会很有共鸣吧 ~ 不过草稿相对就比较简陋， 或者说集中。 篇幅主要在论述日常工作中最容易出事的那部分， 对我是很有教义的。 几年以后看到装订成册， 再拿来读， 感觉多了很多正式的事情需要有的那些， 就内容编排， 举例讲解什么的都更系统也更版式化了。 你们知道我的意思吧~ 这让我想到读本科的时候用的那些正式出版发行的课本儿， 就布尔代数就有六门课在讲， 给人感觉就是就我能讲布尔代数， 或者你们这帮人整个本科期间只学我这门课我不讲布尔代数你们就不懂， 我得对你们知识体系的完备负责等等 （苦笑）
截止目前位置看过的帮助提高内功的书， 这是一本， 另外一本是系统程序员成长计划（http://book.douban.com/subject/4722708/）， 还有一本程序员修炼之道（http://book.douban.com/subject/1152111/）。 这只是入门， 比如很多更深入的东西在本书中都指明超出讨论范围， 并提供了相应的参考材料。 一抬头， 天已经黑了 正是路漫漫呐……