最近聽到我一直在聽Jeff Atwood和Joel Spolsky的電臺節目，他們一直在談論dogfooding（重複使用自己的代碼的過程，請參閱Jeff Atwood的博客post）。所以我的問題是程序員應該使用反編譯器來查看程序員代碼是如何實現和工作的，以確保它不會破壞你的代碼。還是應該相信程序員編寫代碼並適應它，因爲使用反編譯器會違揹我們程序員所知道的隱藏數據的所有事情（至少是OO程序員）？程序員應該使用反編譯器嗎？
注意：我不確定哪些標籤會在這種情況下隨意重新標記。
編輯︰只是爲了澄清我是問反編譯器作爲最後的手段，說你不能得到源代碼出於某種原因。對不起，我應該在原始問題中提供這個。
是的，它可以使用反編譯的輸出是有用的，但不是給你什麼建議。編譯器的輸出看起來不像人類會寫什麼（除非是這樣）。它不能告訴你代碼爲什麼會這麼做，或者一個特定的變量應該是什麼意思。除非你已經有了源代碼，否則這樣做是不值得的。
如果確實有源代碼，那麼在您的開發過程中使用反編譯器有很多很好的理由。
大多數情況下，使用反編譯器輸出的原因是爲了更好地優化代碼。有時候，在優化設置很高的情況下，編譯器會錯誤的。在某些情況下，如果不在不同的優化級別比較編譯器的輸出，這幾乎是不可能的。其他時候，當試圖從非常熱門的代碼路徑中擠出最高性能時，開發人員可以嘗試以幾種不同方式安排其代碼，並比較編譯結果。作爲最後的手段，通過複製編譯器的輸出，這可能是以彙編語言實現代碼塊時最簡單的方法。
Dogfooding是使用您編寫的代碼的過程，不一定需要重新使用代碼。
但是，代碼重用通常意味着你有源代碼，因此'代碼重用'，否則它只是使用其他人提供的庫。
反編譯很難做到正確，輸出通常很難遵循。
如果它是完成工作所需的工具，則應該使用反編譯器。但是，我不認爲這是正確使用反編譯器來了解被編譯的代碼編寫得如何。根據您使用的語言，反編譯的代碼可能與實際編寫的代碼有很大不同。如果你想看到一些真實的代碼，看看開源代碼。如果您想查看某個特定產品的代碼，最好嘗試通過某種合法手段訪問實際代碼。
我不確定你問的是什麼，你期望「反編譯器」向你展示什麼，或者這與Atwood和Spolsky有什麼關係，或者問題是什麼。如果您正在編程公共接口，那麼爲什麼您需要查看第三方代碼的原始來源以查看它是否會「破壞」您的代碼？爲了確定這一點，你可以更有效地構建測試。而且，「反編譯器」會告訴你什麼主要取決於軟件編寫的語言/平臺，無論是Java，.NET，C等等。即使在.NET程序集的情況下，它也不像原始源代碼那樣讀取。無論如何，如果你擔心第三方代碼不適合你，那麼你應該對代碼進行典型的單元測試，而不是試圖「反編譯」它。至於你是否「應該」，如果你的意思是你是否「應該」用別的方式，而不是最好的方式來利用你的時間，那麼我不確定你的意思。
程序員應該使用反編譯器嗎？
使用合適的工具進行正確的工作。反編譯器通常不會產生易於理解的結果，但有時它們是需要的。
應該程序員使用反編譯器來 看到程序員的代碼是如何實現的 和作品，以確保它 不會破壞你的代碼。
不，除非你找到一個問題，需要支持。一般來說，如果你不信任它，就不會使用它，如果你不得不使用它，即使你不信任它，你也會開發測試來證明這些功能，並驗證以後的升級是否仍然按預期工作。
不要使用你不測試的功能，除非你有非常好的支持或信任關係。
- 亞當
或者你應該相信程序員編碼並適應它，因爲使用反編譯器會違揹我們程序員所知道的隱藏數據（至少是OO程序員）的一切嗎？
這根本不是真的。你會使用一個反編譯器，並不是因爲你想繞過任何抽象，封裝或打敗面向對象的原則，而是因爲你想要了解爲什麼代碼行爲更好。
有時你需要使用反編譯器（或在Java世界中，字節碼查看器），當你正在解決一個惱人的錯誤與第三方庫，其中沒有有用的錯誤消息，沒有記錄等引發的異常
使用反編譯器與OO原則無關。
對此的簡短回答...編程爲公開且有文檔的規範，而不是實現。依靠實施細節和副作用會燒你。
反編譯不是幫助您正確編程的工具，儘管它可能會在一個指尖中幫助您理解與其他源代碼無關的問題。
另外，請注意反彙編可能帶來的法律風險;許多軟件公司都沒有反編譯條款，可能會讓您和您的僱主承擔法律後果。
當然，如果你編寫庫代碼，那麼狗食*就是*使用你自己的API。 – 2009-02-19 06:26:25
沒錯，但是你不需要反編譯它。 – 2009-02-20 06:01:36