Должен ли я удалять ненужный код?

Я работаю над базой кода среднего размера (100 тыс. строк), это все относительно недавний код (менее года) и имеет хороший охват тестирования.

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

Должен ли я удалить этот код, если я уверен, что он больше не нужен?

Причины для удаления:

  • Меньше кода, меньше ошибок
  • Меньше кода для других легче усваивать
  • Он все еще находится под контролем источника

Причины этого:

  • Может использоваться как ссылка
  • Может быть полезно когда-нибудь
  • Возможно, это было написано для «округления» функциональности для класса
115 голосов | спросил 4 revs, 3 users 91%
Simon Hutton
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

16 ответов


213

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
43

Все причины его снятия.

Причины этого:

  • Может использоваться как ссылка
  • Может быть полезно когда-нибудь
  • Возможно, это было написано для «округления» функциональности для класса

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
22

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
14

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

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

Мой подход: (1) если вы используете его один раз, сохраняйте то, что вам действительно нужно; (2) если вы используете его дважды, скопируйте и адаптируйте его во второй раз, когда вы его используете; (3) если вы используете его более двух раз, сделайте из него четко определенный, стабильный модуль и используйте этот модуль по мере необходимости.

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
11

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
8

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

Для бит, которые были трудно получить в первую очередь и, скорее всего, будут воскрешены, я бы сохранил их немного более «живыми», чем просто в управлении источниками. Люди не знают /не помнят, что они существуют, говоря «вы можете просто найти его в контроле источника», предполагая, что вы знаете /помните, что он есть! В таких случаях рассмотрите вопрос об отказе (с помощью «assert (false)» showstopper) или комментируя.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
3

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

Для интересных кодовых накопителей я использую ветвь archive в моих системах контроля версий.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
2

Одна из веских причин сохранить неиспользуемые методы: они могут использоваться для других ветвей /тегов!

Изучите все активные ветви и теги перед их удалением.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

Ничто не потребляет меньше времени, чем никакого кода.

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

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

Если ничего нет, никто не будет терять время с ним.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

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

Длинные комментарии старого кода отвлекают и делают сложную навигацию.

Привет

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

Следуйте этому простому алгоритму:

  1. Поддерживается ли он в SCM? Если да, перейдите к 3.
  2. Настройте SCM.
  3. Выбросьте материал .

Все ваши баллы в пользу удаления действительны.

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

Это называется «мертвым кодом» по какой-то причине. Пусть он умрет и успокоится.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
1

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

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

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

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
0

Он останется в контроле источника; он не должен оставаться в активной базе кода.

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

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43:50
0

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

Без сомнения, наличие неиспользуемого кода - плохой запах.

ОБНОВЛЕНИЕ: Я только заметил, что Эд Стауб дал очень похожий ответ.

ответил crasic 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 04:43:50 +0400 2011, 04:43: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