masterminds of programming 翻译 (五) -CSDN博客

Using the Language

使用语言

How do you debug? Do you have any suggestion for C++ developers?

您是如何调试程序的？你对C++开发者有什么建议吗？

Bjarne: By introspection. I study the program for so long and poke at it more or less systematically for so long that I have sufficient understanding to provide an educated guess where the bug is. Testing is something else, and so is design to minimize errors. I intensely dislike debugging and will go a long way to avoid it. If I am the designer of a piece of software, I build it

around interfaces and invariants so that it is hard to get seriously bad code to compile and run incorrectly. Then, I try hard to make it testable.

通过反省。我研究程序很长时间了，我也或多或少系统德捣鼓它很长时间了，以至于我有足够的知识对错误的位置提出合理的猜测。测试是另外一回事，使错误最少的设计也是。我非常不喜欢调试程序所以会尽力避免它。如果我是软件中的一部分的设计者，我会用接口和不变式来构建它，这样很难出现严重的编译和运行错误。然后我会努力让它变的可测试。

Testing is the systematic search for errors. It is hard to systematically test badly structured systems, so I again recommend a clean structure of the code. Testing can be automated and is repeatable in a way that debugging is not. Having flocks of pigeons randomly peck at the screen to see if they can break a GUI-based application is no way to ensure quality systems.

测试是系统地搜寻错误的过程。很难系统地测试结构不好的系统，所以再一次我推荐干净的代码结构。调试做不到的自动化和可重复测试可以做到。用一群在屏幕上啄食的鸽子去检测它们是否能够使一款基于图形用户界面的应用程序崩溃不可能确保系统质量。

Advice? It is hard to give general advice because the best techniques often depend on what is feasible for a given system in a given development environment. However: identify key interfaces that can be systematically tested and write test scripts that exercise those. Automate as much as you can and run those automated tests often. And do keep regression tests and run them frequently. Make sure that every entry point into the system and every output can be systematically tested. Compose your system out of quality components: monolithic programs are unnecessarily hard to understand and test.

建议?很难给出一般性建议因为最好的技巧经常依赖对于给定开发环境以及给定系统哪些是可行的。尽管如此：识别关键的可被系统测试的接口以及写出测试脚本去完成上述测试工作。尽你所能的自动化并经常运行这些自动化测试。切实的保持回归测试的习惯并经常运行它们。确保系统的每个输入点和输出点都可以被系统地测试。使用质量过硬的组件去组织系统：庞大的程序会对理解和测试它造成没有必要的困难。

At what level is it necessary to improve the security of software?

在什么层次上需要提高软件安全性？

Bjarne: First of all: security is a systems issue. No localized or partial remedy will by itself succeed. Remember, even if all of your code was perfect, I could probably still gain access to your stored secrets if I could steal your computer or the storage device holding your backup. Secondly, security is a cost/benefit game: perfect security is probably beyond the reach for most of us, but I can probably protect my system sufficiently that “bad guys” will consider their time better spent trying to break into someone else’s system. Actually, I prefer not to keep important secrets online and leave serious security to the experts.

Bjarne: 首先：安全性是一个系统问题。没有局部或者部分补救措施可以成功。记住，即便你的所有代码都很完美，如果我偷了你的电脑或者存有你备份的硬盘，我仍然可以获得对你存储的秘密的访问。其次，安全性是一个性价比的游戏：绝对安全对你我来说很可能难以企及，但我可以将我系统保护的足够好到“坏人”会考虑最好还是对别人的系统下手。事实上，我不喜欢把重要的秘密存在网上，并且把事关重大的安全性问题留给那些专家。

But what about programming languages and programming techniques? There is a dangerous tendency to assume that every line of code has to be “secure” (whatever that means), even assuming that someone with bad intentions messes with some other part of the system. This is a most dangerous notion that leaves the code littered with unsystematic tests guarding against ill-formulated imagined threats. It also makes code ugly, large, and slow. “Ugly” leaves places for bugs to hide, “large” ensures incomplete testing, and “slow” encourages the use of shortcuts and dirty tricks that are among the most fertile sources of security holes.

但是关于编程语言和编程技巧呢？现在有一种假设每一行代码都应该是“安全的”（不论那意味着什么）的危险趋势，即使假定怀有不良企图的人会弄乱系统其它部分[1]。把代码留给以糟糕制定的假想威胁为目标的无系统性的测试是最危险的一种观点。它也使代码变的丑陋，冗长且缓慢。“丑陋”给错误以生存空间，“冗长”确保不能全部测试，而“缓慢”则将鼓励滋生安全漏洞的捷径及危险技巧的使用。

I think the only permanent solution to security problems is in a simple security model applied systematically by quality hardware and/or software to selected interfaces. There has to be a place behind a barrier where code can be written simply, elegantly, and efficiently without worrying about random pieces of code abusing random pieces of other code. Only then can we focus on correctness, quality, and serious performance. The idea that anyone can provide an untrusted callback, plug-in, overrider, whatever, is plain silly. We have to distinguish between code that defends against fraud, and code that simply is protected against accidents.

我认为唯一永久的安全问题解决方案是在将一个被质量过硬的硬件或且软件应用的简单的安全模型应用到一些挑选出来的接口中。在栅栏后面得有一片地方，代码可以被简单、优雅、高效的写出来而不需要担心哪块代码滥用了哪块代码。只有那时我们才能专注于程序的正确性、质量以及性能。任何人都可以提供一个不被信任的回调函数、插件以及覆盖者，无论什么，都是直白的愚蠢。我们得区分抵抗欺骗的代码和简单的以防止外发生为目标的代码。

I do not think that you can design a programming language that is completely secure and also useful for real-world systems. Obviously, that depends on the meaning of “secure” and “system.” You could possibly achieve security in a domain-specific language, but my main domain of interest is systems programming (in a very broad meaning of that term), including embedded systems programming. I do think that type safety can and will be improved over what is offered by C++, but that is only part of the problem: type safety does not equal security. People who write C++ using lots of unencapsulated arrays, casts, and unstructured new and delete operations are asking for trouble. They are stuck in an 80s style of programming. To use C++ well, you have to adopt a style that minimizes type safety violations and manage resources (including memory) in a simple and systematic way.

我不认为人们可以设计出一门完全安全且对现实世界的系统管用的编程语言。显然，这依赖于对“安全”和“系统”的定义。你可能可以在一个特定领域的语言中做到安全，但我主要关心的领域是系统编程（这个术语意义广泛），包括嵌入式系统编程。我确实相信类型的安全性可以依靠C++所提供的得到提高，但这只是其中一部分：类型的安全并不等于安全。写C++程序的人使用了许多没有封装的数组，类型转换以及没有结构化地new和delete操作，这是在找麻烦。他们固守80年代的编程风格。要好好的使用C++，你得接受使类型安全侵害最小化和用简单系统的方式进行资源管理（包括内存）的风格。