程序员应该使用反编译器吗？
听说最近我一直在听 Jeff Atwood 和 Joel Spolsky 的广播节目，他们一直在谈论dogfooding（重用自己代码的过程，请参阅 Jeff Atwood 的博客 帖子）。 所以我的问题是程序员是否应该使用反编译器来查看程序员的代码是如何实现和工作的，以确保它不会破坏您的代码。 或者你应该相信程序员会编码并适应它，因为使用反编译器违背了我们作为程序员所学到的有关隐藏数据的一切（至少是面向对象的程序员）？
注意：我不确定这将属于哪些标签，所以请随意重新标记它。
编辑：只是为了澄清我询问反编译器作为最后的手段，假设您由于某种原因无法获取源代码。 抱歉，我应该在原来的问题中提供这个。
Hear lately I've been listening to Jeff Atwood and Joel Spolsky's radio show and they have been talking about dogfooding (the process of reusing your own code, see Jeff Atwood's blog post). So my question is should programmers use decompilers to see how that programmers code is implemented and works, to make sure it won't break your code. Or should you just trust that programmers code and adapt to it because using decompilers go against everything we as programmers have ever learn about hiding data (well OO programmers at least)?
Note: I wasn't sure which tags this would go under so feel free to retag it.
Edit: Just to clarify I was asking about decompilers as a last resort, say you can't get the source code for some reason. Sorry, I should have supplied this in the original question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
是的，使用反编译器的输出可能很有用，但不适用于您的建议。 编译器的输出看起来不太像人类编写的内容（除非它确实如此）。它无法告诉您代码为何执行其操作，或者特定变量应该意味着什么。 除非您已经拥有源代码，否则不太值得这么麻烦。
如果您确实有源代码，那么就有很多充分的理由在您的开发过程中使用反编译器。
大多数情况下，使用反编译器输出的原因是为了更好地优化代码。 有时，使用高优化设置，编译器就会出错。 在某些情况下，如果不比较不同优化级别的编译器的输出，这几乎是不可能解决的。
其他时候，当试图从非常热的代码路径中榨取最大性能时，开发人员可以尝试以几种不同的方式排列代码并比较编译的结果。 作为最后的手段，这可能是通过复制编译器的输出来实现汇编语言代码块时最简单的开始方法。
Yes, It can be useful to use the output of a decompiler, but not for what you suggest. The output of a compiler doesn't ever look much like what a human would write (except when it does.) It can't tell you why the code does what it does, or what a particular variable should mean. It's unlikely to be worth the trouble to do this unless you already have the source.
If you do have the source, then there are lots of good reasons to use a decompiler in your development process.
Most often, the reasons for using the output of a decompiler is to better optimize code. Sometimes, with high optimization settings, a compiler will just get it wrong. This can be almost impossible to sort out in some cases without comparing the output of the compiler at different levels of optimization.
Other times, when trying to squeeze the most performance out of a very hot code path, a developer can try arranging their code in a few different ways and compare the compiled results. As a last resort, this may be the simplest way to start when implementing a code block in assembly language, by duplicating the compiler's output.
Dogfooding 是使用您编写的代码的过程，不一定是重复使用代码。
然而，代码重用通常意味着您拥有源代码，因此“代码重用”，否则它只是使用其他人提供的库。
反编译很难正确进行，而且输出通常也很难理解。
Dogfooding is the process of using the code that you write, not necessarily re-using code.
However, code re-use typically means you have the source, hence 'code-reuse' otherwise its just using a library supplied by someone else.
Decompiling is hard to get right, and the output is typically very hard to follow.
如果反编译器是完成工作所需的工具，则应该使用它。 但是，我不认为正确使用反编译器来了解正在反编译的代码的编写情况。 根据您使用的语言，反编译的代码可能与实际编写的代码有很大不同。 如果您想查看一些真实的代码，请查看开源代码。 如果您想查看某些特定产品的代码，最好尝试通过某种合法手段访问实际代码。
You should use a decompiler if it is the tool that's required to get the job done. However, I don't think it's the proper use of a decompiler to get an idea of how well the code which is being decompiled was written. Depending on the language you use, the decompiled code can be very different from the code which was actually written. If you want to see some real code, look at open source code. If you want to see the code of some particular product, it's probably better to try to get access to the actual code through some legal means.
我不确定你到底在问什么，你期望“反编译器”向你展示什么，或者这与阿特伍德和斯波尔斯基有什么关系，或者问题到底是什么。 如果您正在对公共接口进行编程，那么为什么需要查看第三方代码的原始来源以查看它是否会“破坏”您的代码？ 您可以更有效地构建测试来确定这一点。 同样，“反编译器”会告诉您什么很大程度上取决于软件编写的语言/平台，无论是 Java、.NET、C 等。 即使对于 .NET 程序集，这与读取原始源代码也是不同的。 无论如何，如果您担心第三方代码不适合您，那么您确实应该针对代码进行典型的单元测试，而不是尝试“反编译”它。 至于你是否“应该”，如果你的意思是你是否“应该”以其他方式而不是最好地利用你的时间，那么我不确定你的意思。
I'm not sure what exactly it is you are asking, what you expect "decompilers" to show you, or what this has to do with Atwood and Spolsky, or what the question is exactly. If you're programming to public interfaces then why would you need to see the original source of the the third party code to see if it will "break" your code? You could more effectively build tests to in order to determine this. As well, what the "decompiler" will tell you largely depends on the language/platform the software was written in, whether it is Java, .NET, C and so forth. It's not the same as having the original source to read, even in the case of .NET assemblies. Anyway, if you are worried about third party code not working for you then you should really be doing typical kinds of unit tests against the code rather than trying to "decompile" it. As far as whether you "should," if you mean whether you "should" in some other way other than what would be the best use of your time then I'm not sure what you mean.
使用正确的工具完成正确的工作。 反编译器通常不会产生易于理解的结果，但有时它们正是所需要的。
不，除非您发现问题并需要支持。 一般来说，如果您不信任它，您就不会使用它；如果您必须使用它，即使您不信任它，您也可以开发测试来证明其功能并验证以后的升级是否仍按预期工作。
不要使用未经测试的功能，除非您有很好的支持或信任关系。
-亚当
Use the right tool for the right job. Decompilers don't often produce results that are easy to understand, but sometimes they are what's needed.
No, not unless you find a problem and need support. In general you don't use it if you don't trust it, and if you have to use it you even when you don't trust it you develop tests to prove the functionality and verify that later upgrades still work as expected.
Don't use functionality you don't test, unless you have very good support or a relationship of trust.
-Adam
这根本不是真的。 您使用反编译器并不是因为您想要绕过任何类型的抽象、封装或击败 OO 原则，而是因为您想要理解为什么代码的行为方式会更好。
有时，当您对第 3 方库的恼人错误进行故障排除时，您需要使用反编译器（或者在 Java 世界中，字节码查看器），其中抛出异常，没有有用的错误消息，没有日志记录等。
使用反编译器与 OO 原则无关。
This is not true at all. You would use a decompiler not because you want to get around any sort of abstraction, encapsulation, or defeat OO principles, but because you want to understand why the code is behaving the way it is better.
Sometimes you need to use a decompiler (or in the Java world, a bytecode viewer) when you are troubleshooting an annoying bug with a 3rd party library where an exception is thrown with no useful error message, no logging, etc.
Use of a decompiler has nothing to do with OO principles.
对此的简短回答...针对公共和记录的规范进行编程，而不是针对实现进行编程。 依赖实施细节和副作用会让你很痛苦。
反编译不是帮助您正确编程的工具，尽管在紧要关头，它可能会帮助您理解您没有源代码的其他人的代码的问题。
另外，还要警惕反编译可能带来的法律风险； 许多软件公司都有禁止反编译条款，这可能会让您和您的雇主承担法律后果。
The short answer to this... Program to a public and documented specification, not to an implementation. Relying on implementation specifics and side-effects will burn you.
Decompilation is not a tool to help you program correctly, though it might, in a pinch, assist you in understanding a problem with someone else's code for which you don't have source.
Also, beware of the possible legal risk of decompiling; many software companies have no-decompile clauses which could expose you and your employer to legal consequences.