Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама. S>Ваше отношение?
Иногда надо оставить, чтобы знать, что так уже пробовали.
Причём именно там, потому что в другие источники никто не полезет искать.
Здравствуйте, Shmj, Вы писали:
S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
Если есть не просит то и пофиг, попросит там и решать.
Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к т.н. мертвому коду в проекте?
S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
S>Ваше отношение?
Самое плохое в мертвом коде не только то, что занимает место, но и тянет лишние устаревшие зависимости.
Один хлам ссылается на другой, тот на третий — глядишь и сотня модулей хлама в проект потянулась.
Или циклических ссылок между модулями.
И какая — нибудь библиотека метров на 20.
Обожаю удалять код. Поэтому моё отношение, наверное, очевидное — резать по-живому. Я периодически аналитиков терроризирую на предмет используемости функционала, чтобы поудалять его, если он уже не нужен.
Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к т.н. мертвому коду в проекте? S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама. S>Ваше отношение?
Считаю, что поблемы лучше решать по мере их поступления. Вот когда этот код станет помехой для чего-нибудь, тогда можно и почистить. И не обязательно вычищать всё сразу до самых семечек, а по мере востребованности, опять же. Так КПД больше.
--
Справедливость выше закона. А человечность выше справедливости.
Придерживаюсь мнения, что удалять просто ради того чтобы удалять (как некоторые тут пишут) это совершенно бесполезная и даже вредная деятельность.
Во-первых само по себе определение ненужного (неиспользуемого) кода расплывчато.
Вот сегодня он не используется, а завтра (через месяц/год) — будет. Для какой-нибудь библиотеки это вполне нормальное положение дел.
Во-вторых по моему опыту неиспользуемый код сам по себе поддержки не требует и ошибок не вносит.
Допускаю, что тут могут быть исключения, когда требуется обязательное покрытие автотестами или что-то в этом роде.
Но я с таким кодом не сталкивался. Хотя сталкивался с людьми, которые пытались утверждать (бездоказательно), обратное .
Для полноты ответа приведу ряд случаев когда неиспользуемый код мешает, и есть основания от него избавиться:
1) не проходит статический анализатор кода (после ужесточения обязательных правил и т.п.)
2) аудит кода выявил наличие потенциальных уязвимостей, исправление (либо обоснование безопасности) требует определенных трудозатрат
3) аудит кода выявил потенциальные проблемы в юридической плоскости (нарушение чъего-то копирайта)
В корпоративных проектах это сделать сложно, потому, что нужен тикет, который надо привязать к какой-то теме, тесты, отчетность. Со всей этой мутотенью это быстро становится никому не нужным. На совещании менеджеров за это не похвалят (а вот если поправить крутую багу, которую сам же год назад сделал, а потом целый год никто найти не мог — похвалят и вообще, будешь на хорошем счету).
Здравствуйте, m2user, Вы писали:
M>Придерживаюсь мнения, что удалять просто ради того чтобы удалять (как некоторые тут пишут) это совершенно бесполезная и даже вредная деятельность.
Назови эту деятельность мудрёным словом "рефакторинг", и она сразу обретет глубокий смысл.
S>Самое плохое в мертвом коде не только то, что занимает место, но и тянет лишние устаревшие зависимости. S>Один хлам ссылается на другой, тот на третий — глядишь и сотня модулей хлама в проект потянулась. S>Или циклических ссылок между модулями. S>И какая — нибудь библиотека метров на 20.
Ладно если так. Он же может в себе еще и бизнес-логику нести. Тоже устаревшую, да. Но когда разбираешься или не хочешь сломать старое, будешь и ее затрагивать. А это лишнее. Ну это помимо того, что будешь тратить время на ее осмысление. Да банально, какую-нибудь фичу не сможешь легко добавить, потому что она будет "ломать" неиспользуемую уже давно бизнес-логику.
Pzz>Назови эту деятельность мудрёным словом "рефакторинг", и она сразу обретет глубокий смысл.
При рефакторинге объём кода может уменьшится за счёт устранения дублирования или удаления "черновых" вариантов кода.
Но рабочий функционал (протестированные фичи) не выкидывается.
В этом на мой взгляд отличие.
Здравствуйте, bnk, Вы писали:
bnk>Удалять нахрен (YAGNI). Если понадобится, можно откопать в истории.
Речь же не о том, понадобится или нет. Просто мёртвый код, который точно никогда не понадобится, нужно же ещё найти. А как искать? В сторону проект, и не вернемся к нему до тех пор, пока всё не найдем и не вычистим, даже то, что никак не мешает?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
bnk>>Удалять нахрен (YAGNI). Если понадобится, можно откопать в истории.
R>Речь же не о том, понадобится или нет. Просто мёртвый код, который точно никогда не понадобится, нужно же ещё найти. А как искать? В сторону проект, и не вернемся к нему до тех пор, пока всё не найдем и не вычистим, даже то, что никак не мешает?
Не уверен, что правильно вас понял, но вот как это бывает в моей практике:
— нужно добавить фичу X (или починить фичу Y);
— выясняется, что для этого нужно переделать класс C;
— сперва пытаемся определить, что поломается, если класс C изменить;
— находится функция F, в которой задействованы методы класса C, которые становятся жертвами изменений;
— пробуем разобраться где и как применяется F и...
В лучшем случае обнаруживаем, что она задействована только в unit-тестах для F. Но это если проект делается по-человечески.
А если делается так, как часто бывает, то просто нигде не используется. Тупо комментируешь ее и код успешно собирается и линкуется.
Здравствуйте, so5team, Вы писали:
S>Не уверен, что правильно вас понял, но вот как это бывает в моей практике:
S>- нужно добавить фичу X (или починить фичу Y); S>- выясняется, что для этого нужно переделать класс C; S>- сперва пытаемся определить, что поломается, если класс C изменить; S>- находится функция F, в которой задействованы методы класса C, которые становятся жертвами изменений; S>- пробуем разобраться где и как применяется F и...
S>В лучшем случае обнаруживаем, что она задействована только в unit-тестах для F. Но это если проект делается по-человечески. S>А если делается так, как часто бывает, то просто нигде не используется. Тупо комментируешь ее и код успешно собирается и линкуется.
, что вычищать старый код нужно по мере необходимости. Вот это пример сценария, когда такая необходимость назрела. Да, нам таки придется поискать, где и как применяется функция F, но при этом мы можем ответить на вопросы "зачем?" и "почему?" мы это делаем. А просто поиски ради поисков и чистка ради чистки — с моей точки зрения, этим можно заниматься, только если больше делать нечего.
Мою мысль можно сформулировать более общо: реальный код реальных проектов код не бывает идеальным. Можно пробовать приближаться к идеальному состоянию, но чем ближе, тем дороже. И на каком-то этапе чистоты обязательно возникает вопрос о целесообразности дальнейших улучшений. В любом хорошем деле главное — вовремя остановиться. И это относится к любым критериям оценки качества кода. Количество мёртвого кода — всего лишь один из таких критериев.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, m2user, Вы писали:
M>При рефакторинге объём кода может уменьшится за счёт устранения дублирования или удаления "черновых" вариантов кода. M>Но рабочий функционал (протестированные фичи) не выкидывается. M>В этом на мой взгляд отличие.
Если этот код мёртвый, то он не является частью рабочего функционала. Через нормальные интерфейсы програмного модуля (процесса или библиотеки) до него не доберешься. Максимум, он доступен для юнит-тестов.
Здравствуйте, rg45, Вы писали:
R>Мою мысль можно сформулировать более общо: реальный код реальных проектов код не бывает идеальным. Можно пробовать приближаться к идеальному состоянию, но чем ближе, тем дороже. И на каком-то этапе чистоты обязательно возникает вопрос о целесообразности дальнейших улучшений. В любом хорошем деле главное — вовремя остановиться. И это относится к любым критериям оценки качества кода. Количество мёртвого кода — всего лишь один из таких критериев.
Я так понял, что в этой теме вопрос того, как именно был обнаружен мертвый код, вынесен за скобки. Ну обнаружен как-то и обнаружен. Теперь-то что делать?
Тут есть высказывания как за то, чтобы оставить. Так и высказывания за то, чтобы удалять.
Причем если мотивация предлагающих удалять понятна, то вот противоположная точка зрения мне лично и не понята, и не близка.
Ведь если мертвый код обнаружен и доказано, что он мертвый, то зачем его оставлять? Тем более, что в системе контроля версий его копия все равно будет.
Вопрос же зачем и как искать мертвый код, имхо, требует отдельной темы.
