Должны ли программисты использовать декомпиляторы?

Question

Слышите, в последнее время я слушал радио-шоу Джеффа Этвуда и Джоэла Спольски, и они говорили о собачьей упряжке (процесс повторного использования вашего собственного кода, см. Блог Джеффа Этвуда post ). Поэтому мой вопрос заключается в том, должны ли программисты использовать декомпиляторы, чтобы увидеть, как этот код программиста реализован и работает, чтобы убедиться, что он не сломает ваш код. Или вы просто должны доверять программистам, кодирующим и адаптирующимся к нему, потому что использование декомпиляторов идет вразрез со всем, что мы, как программисты, когда-либо учили о сокрытии данных (ну, по крайней мере, программистами OO)?

Примечание: Я не был уверен, к каким тегам это приведет, поэтому не стесняйтесь пометить его.

Редактировать: Просто чтобы уточнить, я спрашивал о декомпиляторах в качестве крайней меры, скажем, вы не можете получить исходный код по какой-то причине. Извините, я должен был предоставить это в первоначальном вопросе.

Answer 1

Да, может быть полезно использовать выходные данные декомпилятора, но не для того, что вы предлагаете. Вывод компилятора не очень похож на то, что написал бы человек (кроме случаев, когда он это делает). Он не может сказать вам, почему код делает то, что делает, или что должна означать конкретная переменная. Это вряд ли стоит того, чтобы сделать это, если у вас уже нет источника.

Если у вас есть исходный код, есть много веских причин для использования декомпилятора в процессе разработки.

Чаще всего причинами использования выходных данных декомпилятора является лучшая оптимизация кода. Иногда при высоких настройках оптимизации компилятор просто ошибается. Это может быть почти невозможно разобрать в некоторых случаях, не сравнивая выходные данные компилятора на разных уровнях оптимизации.

В других случаях, пытаясь выжать наибольшую производительность из очень горячего пути кода, разработчик может попытаться упорядочить свой код несколькими различными способами и сравнить скомпилированные результаты. В крайнем случае, это может быть самый простой способ начать при реализации блока кода на языке ассемблера, дублируя выходные данные компилятора.

Answer 2

Dogfooding - это процесс использования кода, который вы пишете, не обязательно повторного использования кода.

Однако повторное использование кода, как правило, означает, что у вас есть источник, поэтому «повторное использование кода» в противном случае просто использует библиотеку, предоставленную кем-то другим.

Трудно получить правильную декомпиляцию, а вывод, как правило, очень сложен.

Answer 3

Краткий ответ на это ... Программируйте общедоступную и документированную спецификацию, а не реализацию. Полагаясь на специфику реализации и побочные эффекты, вы обожжетесь.

Декомпиляция - это не инструмент для правильного программирования, хотя, в крайнем случае, он может помочь вам понять проблему с чужим кодом, для которого у вас нет исходного кода.

Также остерегайтесь возможного юридического риска декомпиляции; во многих компаниях, выпускающих программное обеспечение, существуют положения, запрещающие декомпиляцию, которые могут привести к юридическим последствиям для вас и вашего работодателя.

Answer 4

Или вы просто должны доверять программистам, кодирующим и адаптирующимся к нему, потому что использование декомпиляторов идет вразрез со всем, что мы, программисты, когда-либо учили о сокрытии данных (ну, по крайней мере, программистам из ОО)?

Это совсем не так. Вы бы использовали декомпилятор не потому, что хотите обойти какие-либо абстракции, инкапсуляцию или отказ от принципов ОО, а потому, что вы хотите понять , почему код ведет себя так, как он лучше.

Иногда вам нужно использовать декомпилятор (или в мире Java, средство просмотра байт-кода), когда вы устраняете досадную ошибку в сторонней библиотеке, где выдается исключение без полезного сообщения об ошибке, без ведения журнала и т. Д.

Использование декомпилятора не имеет ничего общего с принципами ОО.

Answer 5

Должны ли программисты использовать декомпиляторы?

Используйте правильный инструмент для правильной работы. Декомпиляторы не часто дают результаты, которые легко понять, но иногда это то, что нужно.

если программисты используют декомпиляторы для увидеть, как этот код программистов реализовано и работает, чтобы убедиться не сломает ваш код.

Нет, если только вы не найдете проблему и не нуждаетесь в поддержке. Как правило, вы не используете его, если не доверяете ему, и если вам нужно его использовать, вы, даже если не доверяете ему, разрабатываете тесты, чтобы подтвердить функциональность и убедиться, что последующие обновления по-прежнему работают должным образом.

Не используйте функциональность, которую вы не тестируете, если только у вас нет очень хорошей поддержки или доверительных отношений.

-Adam

Answer 6

Я не уверен, что именно вы спрашиваете, что вы ожидаете от «декомпиляторов», или как это связано с Атвудом и Спольским, или каков вопрос. Если вы программируете на общедоступные интерфейсы, то зачем вам нужен исходный код стороннего кода, чтобы определить, «сломает» ли он ваш код? Вы могли бы более эффективно построить тесты, чтобы определить это. Кроме того, то, что скажет вам «декомпилятор», во многом зависит от языка / платформы, на которой написано программное обеспечение, будь то Java, .NET, C и так далее. Это не то же самое, что исходный источник для чтения, даже в случае сборок .NET. В любом случае, если вы беспокоитесь о том, что сторонний код не работает для вас, тогда вам действительно следует проводить типовые виды модульных тестов против кода, а не пытаться «декомпилировать» его. Что касается того, «должен ли», если ты имеешь в виду, «должен ли» каким-то иным способом, кроме того, что будет лучшим использованием твоего времени, тогда я не уверен, что ты имеешь в виду.

Answer 7

Вы должны использовать декомпилятор, если это инструмент, необходимый для выполнения работы. Однако я не думаю, что это правильное использование декомпилятора, чтобы понять, насколько хорошо был написан код, который декомпилируется. В зависимости от языка, который вы используете, декомпилированный код может сильно отличаться от кода, который был фактически написан. Если вы хотите увидеть настоящий код, посмотрите на открытый исходный код. Если вы хотите увидеть код какого-либо конкретного продукта, возможно, лучше попытаться получить доступ к реальному коду с помощью каких-либо законных средств.