看过时的计算机书2

刚看完一本Programming in Prolog Using the ISO Standard，前面看得比较仔细，后面看得粗一点。总体感觉不错，只是有些地方稍嫌啰嗦。学Prolog这门语言，真的是处处要换个脑子，不是太习惯。粗粗看下来，感觉最关键的是递归和回溯（backtrack）两个要点。

看完了《快速软件开发》，不少观点感同身受，但是，很多东西自己无法改变，只能随其自然，去适应。

又开始看《修改代码的艺术》，书名原文是Working with Legacy Code，直译应该是《如何处理遗留代码》之类。译者刘未鹏，看过他写的《暗时间》，但没多少印象。看得出来，翻译态度还是比较认真的，对于译名多有斟酌，虽然处理方法未必合理。比如stub一词，译者加了注释，说保留英文，不译。这大概是受了侯捷的影响，因为他曾说过表达不好的概念干脆不译。既然是翻译，就不能不译——说到这里，感觉计算机书的翻译，往往是由技术人员做的。他们一般懂专业（也有一些根本不懂的），但缺乏翻译训练，结果翻出的东西佶屈聱牙，还不如直接看英文原版。而英语水平精湛的老先生们，又不懂计算机技术，无法翻译。技术人员中，英语相对较好的，又对翻译理论等一无所知，自说自话一套“理论”。（比如上面的“不译”一说，若此说成立，则梁实秋先生在译莎时，碰到双关之类难译之处是否也可“不译”，直接保留原文？）回到此书，另一个翻译上的问题是自创名词，如“测试用具”，“解依赖”。计算机技术不少名词，中文确实一下子难以找到合适的对应词，于是不少人就干脆用词典上该词条的第一个释义来直译，或是自己生造出一个名词。有些“约定俗成”，已为大家接受，比如“赋值”，不知道有哪本汉语词典收有该词？或许对于这个assignment，确实难以找到很好的译法，但有些名词，恐怕是因为中文根底薄弱，又缺乏翻译训练，才草草安个生造的称呼。

说了翻译，再说书的内容。既然说的是处理遗留代码，似乎很自然地想到首先要交代为什么要修改遗留代码，以及一般应遵循的原则。但这本书看了六分之一，却还只字未提，而是在大谈特谈如何“解依赖”，如何编写单元测试（unit testing，同样是一个不懂脑筋的译法）。固然有一定的启发价值，但原则不交代清楚，给人的错觉似乎是一拿到遗留代码，就要大动手术。我的理解是，对于企业程序来说，稳定性是最重要的，还有就是需求驱动。比如，性能调优，一般只有对关键业务影响大的部分才有意义。另外，固然重构代码，使代码更灵活，更便于修改原则上是好的，问题是往往无法预料改动会在什么地方。所以，有些地方，设计得很灵活，其实没多大意义，反而造成不必要的程序阅读和调试上的麻烦。极端地说，如果某个地方基本上不会有变动，则硬编码也未尝不可。总的来说，基本上能不改就不改，特别要注意避免“用个更好的架构来改写”的想法，结果要么是无谓劳动，吃力不讨好，要么是反而造成许多新的bug。

在这本书里，作者提到了使用mock对象来“解依赖”，编写单元测试。mock对象使用起来确实很方便，不过似乎感觉作者有点过于抬高单元测试的作用。很多问题只有在特定的数据下才会出现，而mock对象的使用，就往往会掩盖这些问题。而真要全面测试，恐怕很多情况下是难以做到的，只能让测试人员（QA）去做。

标签：翻译,看过,计算机,代码,单元测试,不译,遗留,mock
来源： https://www.cnblogs.com/badnumber/p/13580672.html