5 ms·
If it's language that has byte-code like java or .net you might be able to decompile the production binary.
by ma2rten 7y ago
If it's language that has byte-code like java or .net you might be able to decompile the production binary.
- dllthomas 7y agoEven if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.
- ma2rten 7y agoLast time I checked x86 decompilers were not that useful. They were producing code that is not compilable, often completely failing on more complex, translating code compiler boilerplate into code. This was a while ago so maybe things improved since then.
- dllthomas 7y agoThe goal here is some window into "what changed". For that, we don't need "compilable", and boilerplate won't be an issue provided it's stable (by no means guaranteed, to be sure). If I had to bet at even odds, I'd bet against it being useful. But the win is potentially large and the effort isn't.
- avgDev 7y agoGood suggestion. I have decompiled the version in production. I will admit that reading it, is extremely frustrating as there are no objects and fields are named field1, field2, field3.
- Drdrdrq 7y agoStill, you can compile + decompile the code you have, and compare that to decompiled production app. This might allow you to apply any cganges back to the code. Btw, it's not a dev who lost the code, it's the company and inadequate development process. It should never have been the single dev's responsibility to make backups.
- avgDev 7y agoDefinitely did not mean to only blame the dev. The company knows that errors were made on both sides, hence why we are working on improving the process.