Здравствуйте, so5team, Вы писали:

S>Я так понял, что в этой теме вопрос того, как именно был обнаружен мертвый код, вынесен за скобки. Ну обнаружен как-то и обнаружен. Теперь-то что делать?

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

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

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

Здравствуйте, rg45, Вы писали:

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

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

Здравствуйте, so5team, Вы писали:

S>Я вот не могу вспомнить когда с таким сталкивался. Напротив, в мой практике обыденность -- это когда мертвый код оставляют.

Ну, мне трудно это комментировать. Я сталкивался. И тут я бы ещё задавался вопросом — по какой причине оставляют. Причины могут быть разные. Помимо "а вдруг этот код когда-нибудь понадобится", могут быть ещё риски внесения изменений, ограничения по времени, просто лень и др.

S>Причем когда над проектом за время его жизни работают разные люди и когда любой разработчик может просто так взять и поменять код написанный другим разработчиком, то это вообще происходит само собой и никаких усилий не требует. Он (мертвый код в смысле) сам по себе образуется и никто не следит за тем мертв он уже или еще нет. Тут скорее нужны силы, время и желание, чтобы посмотреть и проверить что после твоих правок оказалось уже ненужным.

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

Здравствуйте, SkyDance, Вы писали:

SD>В системе контроля версий пусть лежит

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

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

Здравствуйте, Alekzander, Вы писали:

A>настоящий вопрос в том, что именно считать мёртвым кодом.

Разве это вопрос? Мертвый код -- это который нигде не используется и полное удаление которого не оказывает никакого влияния на работоспособность оставшегося кода.

Здравствуйте, so5team, Вы писали:

A>>настоящий вопрос в том, что именно считать мёртвым кодом.
S>Мертвый код -- это который нигде не используется

Сепульки — см. сепуление. "Не используется" само по себе расплывчатое понятие, через него мёртвый код не определить.

У меня была задача: поддержать управлением устройством X 3. (Название вымышлено, устройство реально). Мои вумные коллеги одновременно: а) уволили индуса, который занимался поддержкой устройств, б) вычистили файлы с названием X 3, поскольку эту модель уже много лет не поставляли на рынок, и, соответственно, код уже не использовался, и даже из UI удалили все способы запуска, в) наняли меня, г) поручили мне задачу поддержать недавно вышедшее на рынок устройство X 4.

Я несколько месяцев с нуля пилил поддержку, за соответствующую сумму. Всех всё устроило. Мне даже подарили деревянную залупу памятную награду за то, что уложился в срок. А потом я стал смотреть в архивах, оказалось, что буквально заменой пары команд для X 3 можно было обойтись. Конечно же, моя версия код была лучше (как же иначе), но писать код второй раз? Несколько месяцев?

И это ещё у них гита не было на момент моего ухода. Страшно представить, что там началось с внедрением гита.

Управлять кодом, в частности, оценивать, какой код точно не пригодится, это творческая задача. Никакими метриками, инструментами, правилами она не решается. Каждый раз надо думОть.

Здравствуйте, Alekzander, Вы писали:

A>>>настоящий вопрос в том, что именно считать мёртвым кодом.
S>>Мертвый код -- это который нигде не используется

A>Сепульки — см. сепуление. "Не используется" само по себе расплывчатое понятие, через него мёртвый код не определить.

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

A>Управлять кодом, в частности, оценивать, какой код точно не пригодится, это творческая задача. Никакими метриками, инструментами, правилами она не решается. Каждый раз надо думОть.

Ну так здесь вся тема посвящена вопросу что делать с мертвым кодом. Что такое мертвый код однозначно понятно.
А вот что с ним делать -- нет.

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

Держать в проекте десятки тысяч строк мертвого кода просто из соображений "а вдруг когда-нибудь кому-нибудь" такое себе мероприятие.

M>Во-вторых по моему опыту неиспользуемый код сам по себе поддержки не требует и ошибок не вносит.

Требует, конечно. Представь, у тебя есть библиотека нижнего уровня, которую нужно подправить. Внезапно, те 2 функции, что ты хочешь поменять, используются в 100500 мест. И банальный пятиминутный рефакторинг превращается в "задачу на 3 года". Но если начать копать, оказывается, что 100499 мест на самом деле мертвый код. Руки бы поотрывать тем, кто его оставил.

R> А как искать?

В CHANGELOG, конечно. Не обязательно в файлике с таким названием, это может быть и "git log | grep ..."

A>Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации?

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

Здравствуйте, Shmj, Вы писали:

S>Как вы относитесь к т.н. мертвому коду в проекте?

Удаляю. Мертвый код это постоянные издержки на зависимости, компиляцию, поиск, итд

Здравствуйте, Shmj, Вы писали:

S>Как вы относитесь к т.н. мертвому коду в проекте?

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

S>Ваше отношение?

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

Здравствуйте, Shmj, Вы писали:

S>Ваше отношение?

Как по температуре тела отличить живого от мертвого?

Здравствуйте, Shmj, Вы писали:

S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит.
И зря. Удалять. В анналах гита или чего там у вас он останется и какой историк анналов, если ему припрет, раскопает. А да, комменты к коммитам писать следует внятные.

SD>Требует, конечно. Представь, у тебя есть библиотека нижнего уровня, которую нужно подправить. Внезапно, те 2 функции, что ты хочешь поменять, используются в 100500 мест. И банальный пятиминутный рефакторинг превращается в "задачу на 3 года". Но если начать копать, оказывается, что 100499 мест на самом деле мертвый код. Руки бы поотрывать тем, кто его оставил.

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

Здравствуйте, Alekzander, Вы писали:

A>Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации? Я просто видел, как некоторые удаляют непригодившиеся/драфтовые имплементации, типа, а что такого, есть же контроль версий, пусть там полежит. Но ещё ни разу не видел, чтобы кто-то рылся в этой чёрной дыре, если только не в попытках понять, откуда берётся баг, и куда уехал код, он был ещё вчера.

Я такое оставляю в коментах рядом с рабочим кодом

S>Ну ничего себе. У вас код без удаленного фрагмента полностью и собирается, и линкуется. После чего работает и повторяет все требующуюся вам функциональность. Никакой расплывчатости.

Требуемая функциональность — это расплывчатое понятие.
Как в примере с поддержкой устройств X3/X4.
Бизнес/маркетинг может менять свои требования неоднократно.

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

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

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

Здравствуйте, m2user, Вы писали:

S>>Ну ничего себе. У вас код без удаленного фрагмента полностью и собирается, и линкуется. После чего работает и повторяет все требующуюся вам функциональность. Никакой расплывчатости.

M>Требуемая функциональность — это расплывчатое понятие.

Афигеть! А это как?

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

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

Удаление полезного кода явным образом приведет к тому, что вы не пройдете ПСИ.
Тогда как удаление мертвого кода на наблюдаемой фунциональности ПО вообще не сказывается.

M>Как в примере с поддержкой устройств X3/X4.

Пример с поддержкой устройств X3/X4 вообще про другое. Там ПО удовлетворяло требованиям по функциональности как в версии с поддержкой X3 (и тогда код для X3 не был мертвым), так и в версии без поддержки X3 (и тогда код для X3 был мертвым с точки зрения обеспечения требовавшегося от ПО функционала).

И вопрос, имхо, лежал в плоскости передачи знаний о продукте от разработчиков к разработчикам.

M>Бизнес/маркетинг может менять свои требования неоднократно.

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

А если это не так, что какая же это разработка ПО, это бардак какой-то.

Здравствуйте, пффф, Вы писали:

A>>Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации? Я просто видел, как некоторые удаляют непригодившиеся/драфтовые имплементации, типа, а что такого, есть же контроль версий, пусть там полежит. Но ещё ни разу не видел, чтобы кто-то рылся в этой чёрной дыре, если только не в попытках понять, откуда берётся баг, и куда уехал код, он был ещё вчера.

П>Я такое оставляю в коментах рядом с рабочим кодом

Я в разных ситуациях делаю по-разному.

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

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

Такие вещи как поддержку форматов/девайсов/протоколов я в первую очередь стремлюсь модульно организовать. Вот эта формула выше ("E = mC^2 (errors = more * code ^ 2)"), она же тащит за собой одну аксиому, столь же важную, сколь и ошибочную: что код плоский. Что вся его масса примерно равномерна. Что если ты увеличиваешь массу кода вдвое, то и сложность растёт вдвое. А это не так! Если у тебя сохранение в каждый формат — отдельный модуль, который принимает на вход read-only интерфейс документа, и write-only сериализатор, то даже от очень значительного увеличения объёма такого модуля общая сложность проекта изменится мало, и уж точно — нелинейно. Тебе же не надо туда постоянно лазить при работе над проектными багофичами. А если ты такой модуль выкинешь, жизнь твоя не станет как по волшебству похожа на рахат-лукум. Так что, тут важно не то, что делать с таким модулем (как его хранить в анабиозе), а чтобы он вообще появился в структуре проекта и был правильно изолирован, а то клоунов хватает делать монолитный экспорт-импорт, или вешать его на обработчики или ещё что-нибудь в этом же роде.

Как управлять самими этими модулями — зависит от технической части. Это может быть и #ifdef, и конфиги для сборки и что-то ещё.

Мой ответ в том, что готовых ответов нет.