Как вы безопасно удаляете фрагмент кода, который выглядит так, как будто он никогда не вводился?

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

На ум приходят две идеи.

  1. «Просто» использовать вывод, основанный на том, выглядит ли код, как он должен выполняться. Однако иногда это может быть сложной, трудоемкой работой, немного рискованной (ваша оценка подвержена ошибкам), поскольку нет существенного возврата бизнеса.

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

Есть ли какие-нибудь лучшие идеи или что-то вроде канонического подхода?

124 голоса | спросил Brad Thomas 7 MarpmTue, 07 Mar 2017 17:41:09 +03002017-03-07T17:41:09+03:0005 2017, 17:41:09

20 ответов


112

В моем идеальном мире фантазий, где у меня есть 100% -ное охват тестирования, я бы просто удалил его, запустил модульные тесты, и когда ни один тест не станет красным, я его совершу.

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

  • Награда: код в будущем будет легче поддерживать.
  • Риск: сломайте код в каком-то неясном краевом случае, о котором я не думал, вызывают инцидент, когда я меньше всего этого ожидаю, и виноваты в этом, потому что мне пришлось удовлетворять OCD с качеством кода и внести изменения без ценность бизнеса, воспринимаемая любому заинтересованному лицу, которое не является самим кодером.
ответил Philipp 7 MarpmTue, 07 Mar 2017 17:52:00 +03002017-03-07T17:52:00+03:0005 2017, 17:52:00
83

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

Многие ответы здесь имеют отличные решения для первой половины. Инструменты, такие как статические анализаторы, отлично подходят для идентификации мертвого кода. grep может быть вашим другом в некоторых случаях. Один необычный шаг, который я часто делаю, - попытаться определить, какова была первоначальная цель кода. Намного легче спорить: «X больше не является особенностью нашего продукта, а сегмент кода Y был разработан для поддержки функции X», чем сказать «Я не вижу никакой цели для сегмента кода Y» .â €

Вторая половина - это ключевой шаг, чтобы разбить любой тупик по поводу того, следует ли удалять код. Вам нужно понять, какие последствия имеют неправильный ответ. Если люди умрут, если вы ответите неправильно, обратите внимание! Может быть, это хорошее время, чтобы принять, что кодовый рывок развивается со временем, и вместо этого старайтесь не писать больше. Если люди не умрут, спросите себя, как простить ваших пользователей. Можете ли вы отправить им исправление, если сломаете что-то и поддерживаете отношения с клиентами? У вас есть Q & Команда, которая заплатила, чтобы найти такие проблемы? Эти вопросы необходимы для понимания того, насколько вы должны быть до того, как нажали клавишу удаления.

В комментариях, rmun отметил отличную формулировку концепции понимания первоначальной цели кода перед его удалением. Цитата теперь известна как Забор Честертона . Хотя он слишком велик для цитирования непосредственно в комментарии, я думаю, что он заслуживает того, чтобы его правильно цитировали здесь:

  

В вопросах реформирования вещей, в отличие от их деформирования, существует один простой и простой принцип; принцип, который, вероятно, будет называться парадоксом. В таком случае существует определенный институт или закон; скажем, ради простоты, забор или ворота, установленные по дороге. Более современный тип реформатора подходит к нему и говорит: «Я не вижу использования этого; давайте проясним это ». На что более разумный тип реформатора будет хорошо отвечать:« Если вы не будете использовать его, я, конечно, не дам вам убрать его. Уходите и подумайте. Затем, когда вы можете вернуться и сказать мне, что вы видите его использование, я могу позволить вам уничтожить его.

ответил Cort Ammon 7 MarpmTue, 07 Mar 2017 19:42:23 +03002017-03-07T19:42:23+03:0007 2017, 19:42:23
43

Я также склоняюсь к grep для имени функции /класса в коде, что может дать некоторые дополнительные преимущества, которые может не использовать анализатор кода, например, если имя упоминается в комментарии или в файл документации или сценарий, например. Я запускаю grep в файлах в исходном дереве и сохраняю результат в файле; обычно результат дает сжатую информацию: имя файла /путь, номер строки и строку, где встречается имя, что может дать ключ к тому, где функция /класс вызывается или упоминается без какого-либо семантического значения (в отличие от анализатора кода ) и независимо от расширений файлов. Определенно не окончательное решение, а хорошее дополнение к анализу.

ответил piwi 7 MarpmTue, 07 Mar 2017 19:15:52 +03002017-03-07T19:15:52+03:0007 2017, 19:15:52
30
  • Определите код, который выглядит мертвым (статический анализ и т. д.).
  • Добавить сообщение журнала для каждого вызова якобы мертвого кода. Это легко с функциями /методами; с статическими членами, такими как константы, это сложнее. Иногда вы можете просто пометить код как устаревший, и среда выполнения автоматически зарегистрирует сообщение. Оставьте код в противном случае.
    • Зарегистрировать сообщение, когда загружен мертвый модуль: большинство языков имеют возможность запускать статическую инициализацию во время загрузки, что может быть выполнено с помощью копий.
    • Убедитесь, что ваше сообщение журнала содержит разумную трассировку стека, чтобы вы поняли, что то, что вызвало якобы мертвый код.
  • Запустите измененный код через все тестовые пакеты. Ваши тестовые комплекты также должны проверяться на особые времена, например, через полночь, поворот на четверть, оборот в год и т. Д. Посмотрите на журналы, обновите свое понимание того, что мертво. Обратите внимание, что модульные тесты могут специально тестировать мертвый код, в то время как никакие другие модульные тесты и тесты интеграции не затрагивают его.
  • Запустите измененный код в процессе производства в течение нескольких недель. Убедитесь, что в течение этого периода выполняются все периодические процессы, например, однократные задания ETL cron за период.
  • Посмотрите на журналы. Все, что было зарегистрировано, фактически не мертво. Переходное замыкание графика вызова над остальным мертвым кодом также потенциально не мертво, даже если оно не было вызвано. Проанализируйте его. Возможно, некоторые ветви безопасно мертвы (например, работают с API уже исчезнувшей службы), а некоторые еще не созданы. Возможно, весь модуль /класс загружается только для константы, определенной в нем, и вы можете легко ее не использовать.
  • Все, что осталось, безопасно мертво и может быть удалено.
ответил 9000 7 MarpmTue, 07 Mar 2017 19:55:52 +03002017-03-07T19:55:52+03:0007 2017, 19:55:52
16

В дополнение к уже упомянутым ответам вы также можете итеративно удалить код в нескольких версиях.

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

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

ответил user3196468 8 MaramWed, 08 Mar 2017 06:05:11 +03002017-03-08T06:05:11+03:0006 2017, 06:05:11
7

Многие люди предполагают, что «безопасная» вещь заключается в том, чтобы оставить код, если вы не можете доказать, что он не используется.

Но код не является активом, это ответственность.

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

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

ответил Adrian McCarthy 9 MaramThu, 09 Mar 2017 01:56:19 +03002017-03-09T01:56:19+03:0001 2017, 01:56:19
6

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

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

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

Подробнее читайте здесь: https://martinfowler.com/articles/feature-toggles. HTML

ответил Sash 7 MarpmTue, 07 Mar 2017 19:10:49 +03002017-03-07T19:10:49+03:0007 2017, 19:10:49
6

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

Просто измените имя метода (например, измените DoSomething на DoSomethingX), а затем запустите сборку.

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

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

Если вы действительно обеспокоены его удалением, подумайте о сохранении кода, но отметив его ObsoleteAttribute (или эквивалент на вашем языке). Отпустите его так же, как для одной версии, затем удалите код после того, как в дикой природе не обнаружено проблем.

ответил John Wu 8 MaramWed, 08 Mar 2017 07:29:29 +03002017-03-08T07:29:29+03:0007 2017, 07:29:29
4
  • Я бы начал использовать анализатор кода, чтобы проверить, является ли это мертвым кодом.
  • Я бы начал проверять свои тесты и пытаться достичь кода. Если я не в состоянии достичь кода в тестовом примере, это может быть мертвый код.
  • Я бы удалил код и выбрал исключение. Для одной версии исключение активируется, а во втором выпуске исключение можно удалить. Чтобы быть в безопасности, поместите аварийный флаг (в Java, системное свойство), чтобы иметь возможность активировать исходный код, когда клиент замечает исключение. Таким образом, исключение можно отключить, а исходный код можно активировать в рабочей среде.
ответил Markus Lausberg 7 MarpmTue, 07 Mar 2017 17:54:14 +03002017-03-07T17:54:14+03:0005 2017, 17:54:14
3

Удаление недостижимого кода

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

К сожалению, не все языки статически типизированы, и не все статически типизированные языки являются принципиальными. Вещи, которые могут пойти не так, включают (1) отражение и (2) беспринципную перегрузку.

Если вы используете динамический язык или язык с достаточно сильным отражением, что кусок кода под пристальным наблюдением потенциально может быть доступен во время выполнения через отражение, тогда вы не можете полагаться на компилятор. Такие языки включают Python, Ruby или Java.

Если вы используете язык с беспринципной перегрузкой, то просто удаление перегрузки может просто переключить разрешение перегрузки на другое без перегрузки. Некоторые из таких языков позволяют запрограммировать предупреждение /ошибку времени компиляции, связанные с использованием кода, иначе вы не можете полагаться на компилятор. К таким языкам относятся Java (используйте @Deprecated) или C ++ (используйте [[deprecated]] или = delete).

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

Выполните следующий раздел ...


Удаление потенциально неиспользуемого кода

Скорее всего, код действительно ссылается, однако вы подозреваете , что на практике ветви кода, которые ссылаются на него, никогда не принимаются.

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

В прошлом я успешно использовал 3-фазный подход к удалению такого кода:

  1. В каждой ветви, предположительно НЕ принимаемой, запишите предупреждение.
  2. После одного цикла выкиньте исключение /верните ошибку при вводе определенного фрагмента кода.
  3. После следующего цикла удалите код.

Что такое цикл? Это цикл использования кода. Например, для финансовой заявки я ожидаю короткий месячный цикл (с выплатой зарплаты в конце месяца) и долгим годовым циклом. В этом случае вам нужно подождать не менее года, чтобы убедиться, что никакое предупреждение никогда не издавалось для инвентаря на конец года, может использовать пути кода, которые в противном случае никогда не использовались.

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

Советую поместить комментарий TODO с датой, сообщая, когда перейти к следующему шагу. И напоминание в вашем календаре.

ответил Matthieu M. 8 MarpmWed, 08 Mar 2017 13:28:02 +03002017-03-08T13:28:02+03:0001 2017, 13:28:02
2

Удаление кода из производства - это как уборка дома. В тот момент, когда вы выбросите объект с чердака, ваша жена убьет вас на следующий день, чтобы отбросить подарок третьего внука великой матери на родину от своего соседа, который умер в 1923 году.

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

Если вы не будете следовать этому подходу, вы, вероятно, будете убиты вашей женой. Если вы сохраните код (как и каждый подарок на память), то вы можете успокоить свою совесть в том, что закон Мура приходит на помощь, а стоимость дискового пространства, используемого кодом, который похож на «камень в моей обуви», уменьшает каждый год, и вы не рискуете стать центром многочисленных сплетен с водяным охлаждением и странным взглядом в коридорах.

PS: Прояснить в ответ на комментарий. Оригинальный вопрос: «Как вы безопасно удалить ..», конечно, в моем ответе подразумевается Version Control. Так же, как выкапывание мусора, чтобы найти ценное. Никакое тело с каким-либо смыслом не выбрасывает код и контроль версий, должно быть частью строгости каждого разработчика.

Проблема заключается в коде, который может быть лишним. Мы никогда не сможем узнать, какой фрагмент кода лишний, если мы не можем гарантировать, что 100% путей выполнения не доходят до него. И предполагается, что это достаточно большая часть программного обеспечения, что эта гарантия почти невозможна. И если я не прочитаю этот вопрос неправильно, единственный раз, когда весь этот поток разговоров имеет значение, касается случаев во время производства, где удаленный код может быть вызван, и, следовательно, у нас есть проблема времени выполнения /производства. Контроль версий не спасает никого из-за сбоев в работе, поэтому комментарий об «контроле версий» не имеет отношения к вопросу или моей исходной точке, т. Е. Должным образом осуждает за очень длительный временной интервал, если вам действительно нужно, t беспокоиться, потому что лишний код добавляет относительно небольшие затраты на раздувание дискового пространства.

IMHO, комментарий является излишним и является кандидатом на удаление.

ответил LMSingh 8 MaramWed, 08 Mar 2017 07:47:26 +03002017-03-08T07:47:26+03:0007 2017, 07:47:26
1

Возможно, компилятор делает замечает, что это просто не вызывает шума.

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

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

Если двоичные файлы разные ... тогда это неубедительно. Это может быть какое-то другое изменение. Некоторые компиляторы даже включают дату и время компиляции в двоичном формате (и, возможно, его можно настроить!)

ответил Emilio M Bumachar 8 MarpmWed, 08 Mar 2017 12:46:51 +03002017-03-08T12:46:51+03:0012 2017, 12:46:51
1

Недавно я столкнулся с этой конкретной ситуацией с помощью метода «deleteFoo». Нигде во всей кодовой базе не была найдена строка, отличная от объявления метода, но я мудро написал строку журнала в верхней части метода.

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

Оказывается, код использовался! Некоторые методы AJAX вызывают метод: delete, elem = Foo, который затем объединяется и вызывается с помощью call_user_func_array () .

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

ответил dotancohen 8 MarpmWed, 08 Mar 2017 13:03:20 +03002017-03-08T13:03:20+03:0001 2017, 13:03:20
0

Используйте grep или какие-либо инструменты, которые у вас есть в первую очередь, вы можете найти ссылки на код. (Не изначально моя инструкция /совет.)

Затем решите, хотите ли вы рискнуть удалить код, или если мое предложение может прийти к использованию:

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

Две проблемы:

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

  2. Трассировка вызывающего. На некоторых языках высокого уровня (например, на Python) вы можете легко получить трассировку. Но в скомпилированных языках вам нужно будет сохранить обратный адрес в журнале и заставить ядро ​​сбрасывать при выходе (точка 1).
    В C это должно быть довольно просто: используйте условный блок (например, #ifdef ... #endif), чтобы использовать его только тогда, когда вы знаете, что он будет работать (и протестировал его), и просто прочитайте обратный адрес из стека (может потребоваться или не требуется встроенный язык ассемблера).

Сохранение аргументов в файле журнала может быть или не быть полезным.

ответил Oskar Skog 7 MarpmTue, 07 Mar 2017 19:37:59 +03002017-03-07T19:37:59+03:0007 2017, 19:37:59
0

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

Если, с другой стороны, вы рефакторинг части кода, где вы не знаете , что он делает, не удалять его . Сначала понимайте это, а затем реорганизуйте его, если вы определите его как безопасный (и только если вы сможете определить, что рефакторинг будет правильным использованием вашего времени).

Теперь могут быть некоторые обстоятельства (я знаю, что сам столкнулся с этим), где код «мертвый» на самом деле не связан с чем-либо . Такие, как библиотеки кода, разработанные подрядчиком, которые никогда не были реализованы нигде, поскольку они стали устаревшими сразу после того, как приложение было доставлено (почему да, у меня есть конкретный пример, как вы узнали?).

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

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

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

ответил Zibbobz 9 MarpmThu, 09 Mar 2017 17:44:11 +03002017-03-09T17:44:11+03:0005 2017, 17:44:11
0

Мой подход, который я всегда считал промышленным стандартом в этом случае, странно не упоминался до сих пор:

Получите вторую пару глаз.

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

Я тоже видел подход к протоколированию - точнее, я видел код регистрации: еще более мертвый код, который оставался там в течение 10 лет. Подход к регистрации очень приличный, если вы говорите об удалении целых функций, но не в том случае, если вы просто удаляете небольшой кусок мертвого кода.

ответил Peter 11 MaramSat, 11 Mar 2017 02:59:57 +03002017-03-11T02:59:57+03:0002 2017, 02:59:57
0

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

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

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

В конечном счете, вы либо понимаете это, оставляете его в покое, либо рискните.

ответил jmoreno 11 MarpmSat, 11 Mar 2017 17:02:15 +03002017-03-11T17:02:15+03:0005 2017, 17:02:15
0

Если разработчик данного кода все еще доступен, просмотрите удаление кода с ним . Кроме того, читать комментарии в коде .

Вы получите правильное объяснение, почему этот код был добавлен и для какой функции он служит. Он может быть легко поддержан конкретным вариантом использования, или у вас даже может не хватить опыта, чтобы судить, действительно ли это не требуется. В крайнем случае можно удалить все бесплатные заявления из программы на C и не заметить что-то не так (может потребоваться несколько минут, чтобы исчерпать память).

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

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

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

ответил h22 11 MarpmSat, 11 Mar 2017 21:01:13 +03002017-03-11T21:01:13+03:0009 2017, 21:01:13
-1

Я полностью согласен с первым пунктом Маркуса Лаусберга: код обязательно должен анализироваться с помощью инструментов. Невозможно доверять этому умению мозги Ape !!

Большинство стандартных языков программирования могут использоваться в среде IDE и каждой IDE, которую стоит назвать, которая имеет «найти для всех обычаев» - это идеальный инструмент для такого рода ситуаций. (Например, Ctrl + Shift + G в Eclipse)

Конечно: инструменты статического анализатора не идеальны. Нужно помнить о более сложных ситуациях, когда решение о том, что рассматриваемый метод вызывается, происходит только во время выполнения и не раньше (вызовы через Reflection, вызовы «eval» -функций на языках сценариев и т. Д.).

ответил Johannes Hahn 7 MarpmTue, 07 Mar 2017 19:25:09 +03002017-03-07T19:25:09+03:0007 2017, 19:25:09
-1

Две возможности:

  1. У вас есть 99% + охват тестирования : удалите код и сделайте с ним.
  2. У вас нет заслуживающего доверия охвата теста: тогда ответ должен добавить предупреждение derecation . I.e., вы добавляете некоторый код в это место, что делает что-то разумное (зарегистрируйте предупреждение на какое-то легко видимое место, которое не конфликтует с повседневным использованием вашего приложения, например). Затем пусть он варится на несколько месяцев /лет. Если вы никогда не встречали его, замените усталость тем, что выдает исключение. Пусть это стоит некоторое время. Наконец, полностью удалите все.
ответил AnoE 9 MarpmThu, 09 Mar 2017 19:36:50 +03002017-03-09T19:36:50+03:0007 2017, 19:36:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132