Ищете конкретный пример того, что не так с исправлениями обезьян?

Question

Я слышал много о и о том, как исправление обезьян настолько круто, или исправление обезьян - худшая вещь на земле. У меня есть идея, что это нехорошо, если вы пишете какой-то код, а затем кто-то другой меняет его функциональность, чтобы сделать что-то еще. Но я ищу конкретный пример ситуации, когда это действительно может повредить вам. Я имею в виду, я пишу код все время, а потом мои коллеги вносят в него изменения. Так чем же отличается патч обезьяны от этого? Что хуже всего может случиться ?

Answer 1

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

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

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

Answer 2

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

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

Что касается худшего, что может случиться, что может быть хуже, если в вашем приложении есть ошибка? Может ли кто-то умереть из-за того, что часть оборудования функционирует неправильно? Не могли бы вы испортить чей-то кредитный рейтинг, отправив неверный счет или слишком много списав с его счета?

Answer 3

Это зависит от среды, т. Е. Вы делитесь кодом с кем-либо еще. Рассмотрим, однако, что-то, что можно сделать, например, в Smalltalk: измените значение оператора +. Если я введу функцию +, которая, скажем, вычитает один аргумент из другого, все пойдет не так ярко и неожиданно.

Answer 4

Ну, это действительно зависит от того, что вы подразумеваете под ...

не хорошо, если ты пишешь какой-то код а потом кто-то другой меняет его функциональность, чтобы сделать что-то еще

Какие требования? И сейчас, и раньше. Если требования изменились, и результирующий набор кода должен измениться, это называется поддержанием или расширением. Редко я могу встретить кусок кода в реальном мире, где эффективна «Monkey Patching», хотя она также сильно зависит от того, кто написал код, как давно и т. Д. Слишком много переменных, чтобы дать действительно эффективный ответ , Короче говоря, если это то, что вам нужно сделать, чтобы дать своим клиентам то, что они хотят, когда они этого хотят, то это, вероятно, хорошее «ох, лучше сделайте это». Это все о вашей аудитории.