“初读这本书的时候,我好几次想要笑出来,因为内容实在太‘土’了。请不要误会,这里的‘土’完全没有任何贬义,反而还有赞许的色彩,因为软件开发从来也离不开‘土办法’。”这是《思维整洁之道:编写与头脑合拍的卓越代码》(本书是Clean系列的新篇、Jolt大奖作者新作)一书的译者余晟老师在阅读本书时的感受~~
本书原著在亚马逊评分有4.5分!
为什么余晟老师在阅读本书时会有这样的感受呢?咱们往下看!
文/余晟
过去未去,未来已来
同意翻译这本书的时候,我正在自己的琴上练习《云宫迅音》。
对于“云宫迅音”这个名字,也许一般人不是很熟悉,但只要前奏响起,绝大多数人都会第一时间反应过来:啊,《西游记》。
没错,它就是广为人知的“86版”电视剧《西游记》中,给观众留下深刻印象的片头曲。
在很长的时间里,大家都不知道它的名字是“云宫迅音”,甚至作曲者许镜清老师也没有给它正经取个名字。大家印象深刻的是全曲开头电声乐器那特别的旋律,音乐响起,所有人都知道,神魔鬼怪的故事就要上演了。
如今,面对着《云宫迅音》的乐谱,我才发现,这首曲子并非那么简单。仔细分析,全曲涵盖了多个不同的主题,从猴王问世到大闹天宫,从天庭盛会到取经长路,磅礴大气又层次分明,还贯穿着不断升华的主线旋律。在这背后,从调式到节奏,从和声到配器,处处都体现出精妙的味道。
不必观看许老师的采访也可以想见,当年为了这首连名字都没有的片头曲,他一定绞尽了脑汁。最终,这首片头曲留下的影响力,轻松穿透了近40年的光阴。
过去的东西,未必会真的离我们而去,前提是,它是真的好东西。
恰好是在反复练习《云宫迅音》的时候,我收到了翻译这本书的邀请,再三考虑,我决定接下这个任务。
翻译图书,我的顾虑不少。
早年间,我翻译过几本书,也自恃“爱惜名声”,所以对于继续翻译书这回事,我是非常谨慎的,因为技术图书的翻译纯粹是个“费力不讨好”的活儿。
相信大家都知道,如果看完一本英文书的难度是1,那么陈述书中主要观点的难度大概是5,逐字逐句复述书中内容的难度大概是50。如果不但要逐字逐句复述,还必须考虑听者的理解能力,保证听者准确理解,难度还要翻上几番。如果再进一步,要准确还原作者的行文风格,让译文读者产生与原文读者相同的感受,那就难比登天了。
偏生翻译这回事又没有太多工具可以依赖,它有点儿像写代码时,沿着happy path一条道走到黑,既没有单元测试,也没有集成测试,大部分时候全凭手感。所以,译稿出错漏的概率可比代码出bug的概率要高多了。
更麻烦的是,许多读者的技术不错,英语也不错,是故能轻而易举地发现翻译中的错漏。在这个社交媒体流行的年代,任何错误都可能被人拿出来,发在网上四处讨论。换句话说,翻译技术图书这事,风险极大。
所以,该怎么办?还要不要翻译这本书呢?
《云宫迅音》给了我启发。我想,对许老师来说,“会不会流行”“不被人喜欢怎么办”之类的问题,一定不那么重要。相反,用心写好这首曲子,对得起自己,这才重要。
对我来说,阅读英文图书当然没有大的问题;但我仍然要承认,自己读中文书的速度远远超过读英文书。我相信,对许多同行来说,情况也是如此。所以,把这本书的内容以中文形式呈现给大家,会是一件有意义的事情。
加之,这又确实是本特殊的书,与我翻译过的、读过的许多书都不一样。初读这本书的时候,我好几次想要笑出来,因为内容实在太“土”了。
请不要误会,这里的“土”完全没有任何贬义,反而还有赞许的色彩,因为软件开发从来也离不开“土办法”。
我算是计算机专业毕业的,基础知识也不算不扎实,但仍然会犯下“修改防火墙(iptables)配置把自己锁死在外面”的错误。怎么杜绝这种风险,我绞尽脑汁也找不到答案。直到许多年后,朋友告诉我一个“土办法”:先准备一份“绝对没问题”的配置作为备份,再设定一个计划任务,每5分钟就自动载入备份配置,如此就能放心折腾,安全无虞。
这个“土办法”让我拍案叫绝,可是我从没有在教科书里看到过它。我由此想到,许多技术图书都是“阳春白雪”,而“下里巴人”往往不可或缺。那么,类似的经验有没有聚沙成塔、集腋成裘的机会呢?Mark的这本书,恰恰就是我想找的答案。
实际上,Mark也毫不隐瞒,在副标题里直接注明这本书讲的是软件工程中的heuristics。许多人把heuristics翻译为“启发式方法”,其实未必准确,因为它不一定能给人多少“启发”。严格说起来,heuristics指的是一种综合了经验、规则、直觉的试错方法,常用于解决复杂问题,目标不是保证找到最优解,而是在合理的时间内找到接近最优解的实用解决方案。
工作的年头长了,我越来越觉得,软件工程从来不是科学研究,不要求穷尽心力寻找最优解,而是要在合理的时间里找到实用的次优解。而这,恰恰就是“土办法”的价值所在。办法“土”无所谓,能解决问题就是好的。
当然,“土”也会带来疑惑。尤其是在ChatGPT已经诞生并且大肆流行的年代,大量“聪明”的工具涌现出来帮我们生成代码。既然手工写代码都已显得多余,那么手工写代码的各种“讲究”是否还有意义,似乎应该打上一个大大的问号。
但是我继而又发现,许多代码虽然可以自动生成,但最终还是要靠人来阅读、合并、构建的。而不管在中国还是在外国,不管是做哪种系统的开发,也不管从业人员的经验多寡,软件工程的许多问题都是共通的。
比如,与代码渐行渐远的文档;比如,大杂烩式的提交(commit)操作;又比如,含混潦草的提交说明(commit message)…… 所有这些,都会让你在与人合作的时候无比头痛,哪怕现成的代码库摆在眼前,也不过是《西游记》中的盘丝洞,看一眼就要倒吸一口凉气。
每当这种时候,我都想让当事人去读读这本书,好好补习基本功。
又比如,在多团队协作联调时,一个诡异的bug消耗了我们的大量时间,最后发现对接口的调用没有错,可惜接口的设计有误,调用某个接口之后,对象就处于异常状态。然而当我指出问题之后,合作团队的工程师轻描淡写地说:“噢,问题不大,你再调用某某接口,状态就会对了。”
那一刻,我恨不得直接把他从屏幕那面拽过来,指着这本书上的内容给他看:“从本质上讲,封装应该保证一个对象永远不会处于无效状态。”虽然他确实是一位资深工程师,但他无疑还应当补习这些基本常识。
当然,阅读这本书的过程,也不仅仅是强化已有常识的过程。实话实说,我也收获了很多新的知识。
比如“提交记录分析法”。在新接触已有代码库时,先对过往提交记录做个统计分析,画出提交的热点围栏图,就可以很清楚地知道大家的工作模式,哪些模块是当前的重点,bug主要集中在哪些模块—这个办法的确比自己闷头读代码快得多。
再比如“橡皮鸭法”。在面对问题一筹莫展时,找个橡皮鸭玩具,或者想象自己正对着橡皮鸭,尝试复述问题和自己的思路。“你看,现在我遇到了这个问题,它的现象是这样的……我尝试分析,第一步我做了……第二步我做了……那么接下来我大概应该……”。
看起来有点儿滑稽,但它真的帮我排除了不少疑难杂症。
Mark还告诉我,如果实在没有思路,也不要紧。一定要站起身来,离开计算机,四处走动走动,干点儿不相干的事情。切记不要沉迷在问题当中,而是把它交给“系统1”(也就是潜意识)去思考。经过一段时间的“发酵”,没准儿就能水到渠成。
看起来有点儿荒谬,但我真的很多次在骑自行车时体验了灵感爆发。
因此,“土”归“土”,我还是很高兴地读完了这本书,也愿意让更多人读到这本书。要知道,软件开发这回事,从来不是在理论、工具、框架的新世界里叱咤风云,也从来不能对留传下来的宝贵实践经验嗤之以鼻。
怎样提交代码,怎样写提交说明,怎样设计API来杜绝用户做你不想让他们做的事情,怎样迅速理解巨大的代码库,怎样找到排障的思路……经典的教科书完全不会涉及这些问题,在那些书中,写提交说明、提交代码、设计接口、定位故障……似乎这一切都会按部就班地自然发生。
然而在真实的开发中,我们又常常被这些“不起眼”的问题困住,消耗了太多的时间和精力。更可惜的是,如果没有人告诉开发人员怎么做才是对的,那么他可能根本意识不到,这类问题本不应该浪费如此多的时间和精力。
所以,阅读这本书,也暗合了Mark反复提起的那句话:“未来已来,只不过是参差而来。”
“未来已来”,让读者意识到旧问题,寻找到新答案,提升自己的技艺水准。至于“参差而来”,则意味着读者不必完全赞同Mark的每个观点—老实说,他的许多观点我看了也皱眉,比如他对ORM的反感,以及他对于计算机科学知识价值的低估,无论是根据理论认知还是实践经验,我都无法赞同他的这些观点。所以,建议大家因地制宜,放心拿走对自己有用、有启发的观点。
要补充的是,Mark的这本书,行文是非常轻松随意的,因此即便是相对严肃的话题,你也看不到一本正经的腔调。虽然中英文的表达方式有很大不同,但我仍然努力保持、还原英文原书那种轻松随意的风格,希望大家在收获知识的同时,也有良好的阅读体验相伴。
我衷心地希望,在未来的某个时刻,也许你早已忘记了作者和书名,可是一看到模糊潦草的提交说明,就能条件反射般地知道:嘿,这可不行!
——余晟
↑限时五折优惠↑
限时五折优惠,快快抢购吧!识别二维码或点击阅读原文链接
发布:刘恩惠
审核:陈歆懿
如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连