- Неиспользуемый код - это больше места для поиска, которое вы можете прочитать, и все, что обычно сканирует ваш код. Например, компилятор, IDE, поиск в файле, отладка, статический анализ, дополнительные сведения для просмотра, включение файлов, извлечение из VCS и т. Д. Это замедляет эти процессы и добавляет значительный шум.
- Неиспользуемый код - это не всегда мертвый код. Он может выполняться при определенных обстоятельствах. Это может не только предложить вектор ошибок и проблем с производительностью, но также может быть проблемой безопасности. Что касается производительности, это может проявляться неожиданным образом, например, при увеличении количества загрузок.
- Неиспользованный код порождает неиспользуемый код. Если вы удалите вызов функции, а затем выполните поиск вариантов использования этой функции, чтобы увидеть, нужна ли она еще, вы можете увидеть совпадение с предыдущим неиспользованным кодом и предположить, что вы можете его сохранить. Чем больше у вас неиспользуемого кода, тем больше переходов нужно для определения того, не используется ли код.
- Неиспользуемый код по-прежнему часто приходится поддерживать. Допустим, A и B зависят от C. Из них B не используется. Вы меняете C, а затем B не компилируете, потому что вы удалили член из структуры в C, который требовался B, теперь вам нужно исправить B или активно удалить его из компиляции. Вы должны были просто удалить его.
Этот список может показаться простым, но каждый из них проявляется сотнями различных способов, добавляя перетаскивание, которое действует на протяжении всего процесса разработки. Неэффективность часто может быть доказана или продемонстрирована прямым и математическим способом.
В ответ на ваши баллы ...
- Код уже написан, и усилия потрачены
Но часто его нужно поддерживать. Он также будет отображаться в таких вещах, как поиск в файле.
- Код может быть протестирован в синтетической и реальной среде
Я не уверен, что вы имеете в виду под этим. Думаю, он такой же, как и предыдущий. Вы имеете в виду, что код уже протестирован, и его очистка может означать, что он нуждается в повторном тестировании. Это затраты, которые обычно окупаются, потому что они окупаются в 90% случаев, и во избежание того, чтобы их нужно было очистить перед запуском в производство. Практически весь код состоит из двух итераций: пусть он работает, исправляется. Причина, по которой нужно тестировать дважды, заключается в том, что кто-то пропустил последний шаг. Если ваш код также слишком дорог для проверки, прочитайте diff, test (что, вероятно, будет, если он запутан с большим количеством неиспользуемого кода) и т.д., тогда это еще одна проблема.
- Если хорошо организована (сгруппированы, отдельные пакеты, слабо связаны и т. Д.), Это не мешает вам в целом анализировать код или рефакторинг.
Ваш код в любом случае должен быть таким, но это лишь в меру смягчает проблему. Самый странный аргумент - слышать, что что-то должно быть организовано, но нечисто. Это нормально - сохранять модульный код и сокращать зависимости, но вам также нужен код многократного использования, и если все ваши модули являются островками, скорее всего, вы не были СУХИМ. Вы также можете обнаружить, что делаете чрезмерную развязку, которая ничего не делает, кроме как смягчает проблему неиспользуемого беспорядочного кода.
- Код может быть использован в будущем
Многие люди переоценивают письменный код. Если он не используется сейчас, это мертвый груз, и в действительности, когда вы идете по этому пути, часто только часть неиспользуемого кода становится используемым кодом. По всей вероятности, неиспользованный код вряд ли будет пригодным для использования или использованным кодом. Код, который, скорее всего, будет использоваться повторно, - это уже используемый код, который что-то делает.
Что еще хуже, неиспользуемый код не имеет цели. Когда кто-то приходит и должен что-то изменить, что в конечном итоге влияет на неиспользуемый код, они будут в тупике, сидя там, пытаясь выяснить, что этот неиспользуемый код без цели должен делать.
Люди легко могут так себя чувствовать, когда начинают, поскольку код требует больших усилий. Однако если вы научитесь свободно владеть и привыкать к нему, то это будет похоже на езду на велосипеде. Вы обнаружите, что по мере того, как стоимость написания такого фрагмента кода резко падает, затраты на его содержание растут.
- При удалении автор может чувствовать себя неуютно
Это проблема автора. С одной стороны, эгоистично оставлять множество неиспользуемого кода для других. С другой стороны, если автор ставит свои чувства выше качества кода, ему, вероятно, не следует писать код. Вы идете по дороге с этим: вы не можете исправить их код, когда он сломан, потому что это обидит их чувства. Если кто-то привязан к коду просто потому, что он его, а не потому, что он хорош, это плохой знак. Автор должен быть доволен чисткой своего кода. Это как если бы кто-то вынул за вас ваш мусор и выбросил его в мусорное ведро.
Я был бы на седьмом небе от счастья, если бы кто-то сделал это за меня. Что может облегчить преодоление этих чувств, так это вместо того, чтобы ждать, пока кто-то другой сделает это, попробуйте сделать это сами. Продолжайте итеративно переписывать кусок кода, который вы сделали, чтобы он работал лучше, двигайтесь лаконично, с меньшим количеством лишних и более гибким, но с меньшим количеством кода каждый раз. Старайтесь не думать о количестве кода, а о том, как много вы можете достичь с помощью небольшого кода. Это измельчение для повышения уровня, и как только вы это сделаете, весь ваш код выйдет на хороший уровень, поэтому его не нужно будет выравнивать так часто.