Почему неиспользуемый код следует удалить?

Ответ 1

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

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

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

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

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

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

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

Ответ 2

@suspectus проделал отличную работу по представлению причин для удаления кода; Я хотел бы обратиться к вашим отдельным пулям для хранения кода.

• Код уже написан, и усилия потрачены

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

• Код может быть протестирован в синтетической и реальной среде.

Извините, я не знаю, что вы подразумеваете под этим.

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

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

• Код может использоваться в будущем

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

• При удалении автор может чувствовать себя некомфортно

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

Ответ 3

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

Ответ 4

Код уже написан, и усилия потрачены

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

Код может быть протестирован в синтетической и реальной среде

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

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

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

Если код не организован хорошо, с другой стороны, он испортит статический анализ, рефакторинг и любые другие.

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

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

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

Код может использоваться в будущем

Если это так, вы найдете его в своей команде SCM по выбору.

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

При удалении автор может чувствовать себя некомфортно

Так?

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

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

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

Изменить: Я видел одну действительную причину оставить код с комментариями в источнике, и это очень конкретный случай: когда код написан в странной/неинтуитивной форме и чистый способ перезаписи не работает по-настоящему тонкой причине. Это также следует применять только после повторной попытки исправить проблему и каждый раз, когда попытка повторного введения того же дефекта. В таком случае вы должны добавить прокомментированный интуитивно понятный код в качестве комментария и объяснить, почему он не работает (так что будущие разработчики не будут повторять одно и то же изменение):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Ответ 5

• Страх. Это заставляет команду больше беспокоиться и производить меньше. Количество страха возрастает экспоненциально, когда вводится более мертвый код. "Мы не знаю, используется ли этот бит, поэтому мы не смеем удалить его или коснуться это ".

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

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

• Психическая нагрузка. Каждый раз, когда вам нужно думать о том, что или нужно ли что-то делать с мертвым кодом, требуется некоторые из ваших мозгов.
• Дикие гусиные погони. "Мне нужен пример как использовать Foobar. О, это в этих местах в кодовой базе. Больной проверьте первый хит и узнайте, где это находится в пользовательском интерфейсе. Хм... Не могу найти его нигде.
• Надутые отчеты (например, сколько строк кода, классов, подпрограмм, изменений). Искажает видимость проекта и решения о том, какие части кодовой базы должны быть обработаны, и оценки будущих проектов.
• Ослабленное доверие к кодовой базе. Это может привести к большему количеству времени, затрачиваемого на избыточные задачи, и это ломает поток использования кодовой базы. Разработчикам, возможно, придется очень тщательно проверять, что все, что они используют, будет работать так, как им кажется.

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

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

Ответ 6

Мертвый код загрязняет ваш код

Мертвый код уменьшает понятность и удобочитаемость.

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

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

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

Ответ 7

• Неиспользуемый код - это большее пространство для поиска как для вас, так и для всего остального, что обычно сканирует ваш код. Например, компилятор, IDE, поиск в файле, отладка, статический анализ, многое другое для просмотра, включение файла, извлечение из VCS и т.д. Это замедляет эти процессы и добавляет значительный шум.
• Неиспользуемый код не всегда мертвый код. Может выполняться при определенных обстоятельствах. Это может не только предложить вектор для ошибок и проблем с производительностью, но также может быть проблемой безопасности. Что касается производительности, это может выражаться неожиданными способами, такими как большие загрузки.
• Неиспользуемый код порождает неиспользуемый код. Если вы удалите вызов функции, а затем выполните поиск использования этой функции, чтобы узнать, нужна ли она вам по-прежнему, вы можете увидеть совпадение из предыдущего неиспользованного кода и предположить, что вы можете сохранить его. Чем больше неиспользуемого кода, тем больше прыжков, чтобы определить, не используется ли код.
• Неиспользуемый код по-прежнему часто требует поддержки. Допустим, A и B зависят от C. Из них B не используется. Вы изменяете C, а затем B не компилируете, потому что вы удалили элемент из структуры в C, который требуется B, теперь вы должны исправить B или активно удалить его из компиляции. Вы должны были просто удалить это.

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

В ответ на ваши очки...

• Код уже написан, а усилия потрачены

Но это часто необходимо поддерживать. Он также будет отображаться в таких вещах, как поиск в файле.

• Код может быть протестирован в синтаксической и реальной среде

Я не уверен, что вы подразумеваете под этим. Я думаю, что это так же, как последний. Вы имеете в виду, что код уже протестирован, и его очистка может потребовать повторного тестирования. Это стоимость, которая обычно стоит того, потому что она окупится в 90% случаев и во избежание ее очистки перед началом производства. Практически весь код имеет две итерации: заставьте его работать, сделайте его чистым. Причина в том, что нужно проверять дважды, потому что кто-то пропустил последний шаг. Если ваш код также слишком дорог, чтобы его можно было проверить, прочитайте diff, протестируйте (что, скорее всего, случится, если он запутается в большом количестве неиспользуемого кода), и т.д.

• Хорошо организованный (сгруппированный, отдельный пакет, слабо связанный и т.д.), Он не мешает вам в общем анализе кода или рефакторинге.

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

• Код может быть использован в будущем

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

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

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

• При удалении автору может быть неудобно

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

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

Ответ 8

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

Ответ 9

Я думаю, что у вас могут быть два случая:  - код приложения: если он не используется, возможно, он непроверен и не работает в течение времени, возможно, вы можете перейти в "внутренний репозиторий кода",  - Код API: если вы пишете библиотеку, тогда имейте в виду, что это лучший выбор для ее поддержки, но внутри вашего активного процесса разработки.

Ответ 10

Вы уверены, что код не используется?

Недостаточно проверить, что код все еще компилируется. В C++, если вы удалите "неиспользуемый" неявно определенный метод, такой как operator= вы не получите ошибку компилятора, класс просто тихо начнет использовать (потенциально неправильную) реализацию по умолчанию. В Java или С# код может быть использован через отражение. В объектно-ориентированных языках наследование может играть роль (теперь можно называть базовый класс). Почти на любом языке может быть использована другая перегруженная функция.

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

Агрессивно удалить неиспользуемый код

Вы платите за поддержание кода:

• Исправление неработающих сборок (время разработки). Недавно у нас была сложная цепочка изменений #include, вводящая новую перегрузку в неиспользуемый код, что приводило к головной боли разумного размера для каждого инженера в команде из десятков разработчиков.
• Ресурсы машин на тестах (при условии, что у вас есть самотестирование непрерывных сборок). Моя команда недавно проверила все наши самые медленные тесты, и многие из них были из-за неиспользуемого кода. Инженеры, выполняющие тесты локально или в рамках непрерывной интеграции, ждут тестов над неиспользуемым кодом.
• С точки зрения читабельности (время разработки снова). Ваши заголовочные файлы представляют API. Если они включают функции, которые никто не хотел бы использовать, но каждый должен читать, ваша кривая изучения кода будет намного сложнее.
• В поисках кода (время разработки снова). Вы бы убрали свой дом, свой жесткий диск или Google Drive? Чем больше вы выполняете поиск домена, тем важнее иметь релевантный контент, чтобы избежать ложных срабатываний (или вы используете более сложный поиск, такой как поисковая система в Интернете).

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

Ответ 11

Этому обсуждению уже несколько лет, но я просто наткнулся на него...

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

Ответ 12

Я думаю, что лучше удалить неиспользуемый код, если он уже удален, мы можем увидеть снова в истории svn/cvs, очень легко сравнить оба кода без потери производительности.