Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
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>Мою мысль можно сформулировать более общо: реальный код реальных проектов код не бывает идеальным. Можно пробовать приближаться к идеальному состоянию, но чем ближе, тем дороже. И на каком-то этапе чистоты обязательно возникает вопрос о целесообразности дальнейших улучшений. В любом хорошем деле главное — вовремя остановиться. И это относится к любым критериям оценки качества кода. Количество мёртвого кода — всего лишь один из таких критериев.
Я так понял, что в этой теме вопрос того, как именно был обнаружен мертвый код, вынесен за скобки. Ну обнаружен как-то и обнаружен. Теперь-то что делать?
Тут есть высказывания как за то, чтобы оставить. Так и высказывания за то, чтобы удалять.
Причем если мотивация предлагающих удалять понятна, то вот противоположная точка зрения мне лично и не понята, и не близка.
Ведь если мертвый код обнаружен и доказано, что он мертвый, то зачем его оставлять? Тем более, что в системе контроля версий его копия все равно будет.
Вопрос же зачем и как искать мертвый код, имхо, требует отдельной темы.
Здравствуйте, so5team, Вы писали:
S>Я так понял, что в этой теме вопрос того, как именно был обнаружен мертвый код, вынесен за скобки. Ну обнаружен как-то и обнаружен. Теперь-то что делать?
Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".
S>Тут есть высказывания как за то, чтобы оставить. Так и высказывания за то, чтобы удалять. S>Причем если мотивация предлагающих удалять понятна, то вот противоположная точка зрения мне лично и не понята, и не близка. S>Ведь если мертвый код обнаружен и доказано, что он мертвый, то зачем его оставлять? Тем более, что в системе контроля версий его копия все равно будет. S>Вопрос же зачем и как искать мертвый код, имхо, требует отдельной темы.
Нет, я вовсе не призываю спотыкаться о мусорный код и не вычищать его только потму, что "возможно, он когда-нибудь понадобится". Сам терпеть не могу работать в грязи.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".
Я вот не могу вспомнить когда с таким сталкивался. Напротив, в мой практике обыденность -- это когда мертвый код оставляют. Причем когда над проектом за время его жизни работают разные люди и когда любой разработчик может просто так взять и поменять код написанный другим разработчиком, то это вообще происходит само собой и никаких усилий не требует. Он (мертвый код в смысле) сам по себе образуется и никто не следит за тем мертв он уже или еще нет. Тут скорее нужны силы, время и желание, чтобы посмотреть и проверить что после твоих правок оказалось уже ненужным.
Здравствуйте, so5team, Вы писали:
S>Я вот не могу вспомнить когда с таким сталкивался. Напротив, в мой практике обыденность -- это когда мертвый код оставляют.
Ну, мне трудно это комментировать. Я сталкивался. И тут я бы ещё задавался вопросом — по какой причине оставляют. Причины могут быть разные. Помимо "а вдруг этот код когда-нибудь понадобится", могут быть ещё риски внесения изменений, ограничения по времени, просто лень и др.
S>Причем когда над проектом за время его жизни работают разные люди и когда любой разработчик может просто так взять и поменять код написанный другим разработчиком, то это вообще происходит само собой и никаких усилий не требует. Он (мертвый код в смысле) сам по себе образуется и никто не следит за тем мертв он уже или еще нет. Тут скорее нужны силы, время и желание, чтобы посмотреть и проверить что после твоих правок оказалось уже ненужным.
Ну я поделился подходом, который использую сам — по мере необходимости. Этот подход видится мне оптимальным с разных точек зрения — он и не позволяет мёртвому коду разрастаться до уродливых размеров, и в то же время минимизирует риски, связанные с внесением изменений, и затраты времени.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, SkyDance, Вы писали:
SD>В системе контроля версий пусть лежит
Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации? Я просто видел, как некоторые удаляют непригодившиеся/драфтовые имплементации, типа, а что такого, есть же контроль версий, пусть там полежит. Но ещё ни разу не видел, чтобы кто-то рылся в этой чёрной дыре, если только не в попытках понять, откуда берётся баг, и куда уехал код, он был ещё вчера.
Короче, вопрос типично шмыговский, дурацкая хвилософия. Никто не любит мёртвый код, настоящий вопрос в том, что именно считать мёртвым кодом.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>настоящий вопрос в том, что именно считать мёртвым кодом.
Разве это вопрос? Мертвый код -- это который нигде не используется и полное удаление которого не оказывает никакого влияния на работоспособность оставшегося кода.
Здравствуйте, so5team, Вы писали:
A>>настоящий вопрос в том, что именно считать мёртвым кодом. S>Мертвый код -- это который нигде не используется
Сепульки — см. сепуление. "Не используется" само по себе расплывчатое понятие, через него мёртвый код не определить.
У меня была задача: поддержать управлением устройством X 3. (Название вымышлено, устройство реально). Мои вумные коллеги одновременно: а) уволили индуса, который занимался поддержкой устройств, б) вычистили файлы с названием X 3, поскольку эту модель уже много лет не поставляли на рынок, и, соответственно, код уже не использовался, и даже из UI удалили все способы запуска, в) наняли меня, г) поручили мне задачу поддержать недавно вышедшее на рынок устройство X 4.
Я несколько месяцев с нуля пилил поддержку, за соответствующую сумму. Всех всё устроило. Мне даже подарили деревянную залупу памятную награду за то, что уложился в срок. А потом я стал смотреть в архивах, оказалось, что буквально заменой пары команд для X 3 можно было обойтись. Конечно же, моя версия код была лучше (как же иначе), но писать код второй раз? Несколько месяцев?
И это ещё у них гита не было на момент моего ухода. Страшно представить, что там началось с внедрением гита.
Управлять кодом, в частности, оценивать, какой код точно не пригодится, это творческая задача. Никакими метриками, инструментами, правилами она не решается. Каждый раз надо думОть.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>>>настоящий вопрос в том, что именно считать мёртвым кодом. S>>Мертвый код -- это который нигде не используется
A>Сепульки — см. сепуление. "Не используется" само по себе расплывчатое понятие, через него мёртвый код не определить.
Ну ничего себе. У вас код без удаленного фрагмента полностью и собирается, и линкуется. После чего работает и повторяет все требующуюся вам функциональность. Никакой расплывчатости.
A>Управлять кодом, в частности, оценивать, какой код точно не пригодится, это творческая задача. Никакими метриками, инструментами, правилами она не решается. Каждый раз надо думОть.
Ну так здесь вся тема посвящена вопросу что делать с мертвым кодом. Что такое мертвый код однозначно понятно.
А вот что с ним делать -- нет.
Как в вашей истории он мог бы пригодится даже оставаясь мертвым.
В куче других историй он не пригождается.
Держать в проекте десятки тысяч строк мертвого кода просто из соображений "а вдруг когда-нибудь кому-нибудь" такое себе мероприятие.
M>Во-вторых по моему опыту неиспользуемый код сам по себе поддержки не требует и ошибок не вносит.
Требует, конечно. Представь, у тебя есть библиотека нижнего уровня, которую нужно подправить. Внезапно, те 2 функции, что ты хочешь поменять, используются в 100500 мест. И банальный пятиминутный рефакторинг превращается в "задачу на 3 года". Но если начать копать, оказывается, что 100499 мест на самом деле мертвый код. Руки бы поотрывать тем, кто его оставил.
A>Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации?
Даже если там и есть какая-то черновая реализация, скорее всего, она ни для чего не пригодна. Но да, я вообще имею привычку проверять "а не делали ли мы это раньше", причем еще до начала работ над реализацией. В первую очередь чтоб ответить на вопрос, а надо ли эту задачу делать, и почему в прошлый раз решили не делать. Может, и в этот раз тоже делать не надо, по той же причине.
Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к т.н. мертвому коду в проекте?
S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
S>Ваше отношение?
он путает тех, кто недавно пришел на проект, добавляет ненужную сложность, всплывает в поиске и т.д.. Удалять его нахрен при первой возможности (кому надо будет его восстановить в будущем — пороется в git истории). Его наличие это признак говнокодистости проекта, и отсутствия адекватного кодревью в команде.
Здравствуйте, Shmj, Вы писали:
S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит.
И зря. Удалять. В анналах гита или чего там у вас он останется и какой историк анналов, если ему припрет, раскопает. А да, комменты к коммитам писать следует внятные.
SD>Требует, конечно. Представь, у тебя есть библиотека нижнего уровня, которую нужно подправить. Внезапно, те 2 функции, что ты хочешь поменять, используются в 100500 мест. И банальный пятиминутный рефакторинг превращается в "задачу на 3 года". Но если начать копать, оказывается, что 100499 мест на самом деле мертвый код. Руки бы поотрывать тем, кто его оставил.
В этой ситуации не нужно менять функции, которые могут использоваться в 100500 мест, а следует добавить новые.
Здравствуйте, Alekzander, Вы писали:
A>Ты сам-то, если тебе дадут задачу поддержать формат/девайс/протокол, первым делом полезешь в контроль версий посмотреть, нет ли там случайно непригодившейся/драфтовой имплементации? Я просто видел, как некоторые удаляют непригодившиеся/драфтовые имплементации, типа, а что такого, есть же контроль версий, пусть там полежит. Но ещё ни разу не видел, чтобы кто-то рылся в этой чёрной дыре, если только не в попытках понять, откуда берётся баг, и куда уехал код, он был ещё вчера.
S>Ну ничего себе. У вас код без удаленного фрагмента полностью и собирается, и линкуется. После чего работает и повторяет все требующуюся вам функциональность. Никакой расплывчатости.
Требуемая функциональность — это расплывчатое понятие.
Как в примере с поддержкой устройств X3/X4.
Бизнес/маркетинг может менять свои требования неоднократно.
Здравствуйте, 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, и конфиги для сборки и что-то ещё.
Мой ответ в том, что готовых ответов нет.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, SkyDance, Вы писали:
SD>Я искренне надеюсь, что мне никогда в жизни не придется работать с кодовой базой, где до меня работал человек с вашим мышлением.
Я в свою очередь приложу все усилия, чтоб мне не пришлось работать в одной команде с фанатами типа тебя, которые, вместо того, чтобы заниматься делом, занимаются чисткой ради чистки.
--
Справедливость выше закона. А человечность выше справедливости.
SD>Я искренне надеюсь, что мне никогда в жизни не придется работать с кодовой базой, где до меня работал человек с вашим мышлением.
При изменении имплементации библиотечной функции очень сложно гарантировать, что не сломается зависимый код (а он может быть в проекте, про который ты вообще не знаешь).
Иногда это приводит к форкам целых библиотек.
Не то, чтобы я был в восторге от такого дублирования, но иногда по-другому не обосновать отсутствие возможных негативных последствий изменения библиотечного кода.
S>Даже если разработка ведется без жесткой формализации, все равно есть список фич для очередного релиза + список фич существующей версии ПО, + набор тестов (тестов разных типов) для контроля качества и регрессий.
Список требований может поменяться (как правило в меньшую сторону) в ходе разработки.
Например нужно поддержать некую линейку устройств, про которую на начальном этапе мало известно.
В ходе исследования выясняется, что вообще технически можно поддержать и сколько это будет в человеко-часах. Формализуется ТЗ.
Потом в ходе разработки и тестирования часть некритичного функционала могут выкинуть (перенести на будущие релизы), причем чисто на уровне документации или UI и уже после code lock/freeze.
Вот так и получится "неиспользуемый" код.
S>Даже если разработка ведется по какой-нибудь версии аджайла (или что там сейчас модное и молодежное?), то все равно у вас есть зафиксированные цели на текущий спринт. Так что требуемая функциональность все равно находится под контролем. S>А если это не так, что какая же это разработка ПО, это бардак какой-то.
Ну в одном цикле разработки может быть запланирован переход с библиотеки A на B. А в следующем цикле — назад.
Я предпочитаю планировать на несколько циклов вперёд.
Циклы не обязательно короткие, т.е. не agile.
Здравствуйте, m2user, Вы писали:
M>Вот так и получится "неиспользуемый" код.
Поскипал ненужное растекание по древу, т.к. описанное вами не имеет отношения к тому, что вы же говорили ранее:
Требуемая функциональность — это расплывчатое понятие.
Оно нифига не расплывчатое, а будь оно таковым, то разработка была бы из категории "делаем хз что хз для чего хз к какому сроку".
И да, вопрос не в том, как образуется "мертвый код". Конкретно в данной ветке отметились персонажи, которые вообще не понимают что такое "мертвый код". Как раз из-за якобы расплывчатого понятия "требуемая функциональность".
Здравствуйте, m2user, Вы писали:
SD>>Требует, конечно. Представь, у тебя есть библиотека нижнего уровня, которую нужно подправить. Внезапно, те 2 функции, что ты хочешь поменять, используются в 100500 мест. И банальный пятиминутный рефакторинг превращается в "задачу на 3 года". Но если начать копать, оказывается, что 100499 мест на самом деле мертвый код. Руки бы поотрывать тем, кто его оставил.
M>В этой ситуации не нужно менять функции, которые могут использоваться в 100500 мест, а следует добавить новые.
"Индусы" в основном так и делают. Это работает для проектов, время жизни которых — несколько лет.
А вот если время жизни больше, то через несколько лет, когда приходит пушной зверек,
эти товарищи просто переходят на другую работу, а бедная компания начинает новый проект цифровой трансформации.
A>И это ещё у них гита не было на момент моего ухода. Страшно представить, что там началось с внедрением гита.
А какие есть варианты, что начнётся с внедрением гита? Премия и повышение внедрившему, путаница и куча безполезной работы всем остальным.
Здравствуйте, Osaka, Вы писали:
A>>И это ещё у них гита не было на момент моего ухода. Страшно представить, что там началось с внедрением гита. O>А какие есть варианты, что начнётся с внедрением гита? Премия и повышение внедрившему, путаница и куча безполезной работы всем остальным.
Ну, это зависит от привычек. Я имел в виду привычку хранить код в удалённых версиях, документы в Корзине и т.д. А сам по себе гит отличный инструмент.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
A>Что если ты увеличиваешь массу кода вдвое, то и сложность растёт вдвое. А это не так!
Конечно, не так — там квадрат. Сложность растет вчетверо
"Модульный код" если он в самом деле модульный, может быть расположен не в этом, а в другом проекте, поэтому выходит за рамки рассмотрения. Если его в самом деле никогда не придется трогать при рефакторинге основного проекта, тогда да, сложности немного добавляется. Но обычно реальность такова, что просто лежит код, который собирается, и возможно даже тестируется, но никто не знает, зачем оно там и что сломается, если его удалить. Поэтому и боятся удалять. Ну или сложно это.
A>Как управлять самими этими модулями — зависит от технической части. Это может быть и #ifdef, и конфиги для сборки и что-то ещё.
Ух, нет, это сразу же делает мертвый код по-настоящему мертвый. Если он под ifdef, и не запускается даже в CI, он очень быстро протухнет, и работать вовсе перестанет.
А вот это уже ваши фантазии. Удаление мертвого кода делается не "ради чистки", а для ускорения выката новых фич (из-за отсутствия необходимости поддерживать старый мусор). Как несложно заметить, писать с нуля прототипчики куда быстрее, чем добавлять пять строчек кода в кодовую базу с авгиевыми конюшнями 15 лет разработки.
S>И да, вопрос не в том, как образуется "мертвый код". Конкретно в данной ветке отметились персонажи, которые вообще не понимают что такое "мертвый код". Как раз из-за якобы расплывчатого понятия "требуемая функциональность".
В моем понимании мертвый код, это код, ставший таковым вследствии изменения требований к продукту (удаление фичей и т.п.).
По крайне мере так я понял топикстартера.
Но далее в теме появились другие дефиниции:
— это любой код, который не требуется для сборки проекта и соответстия текущему ТЗ.
— "код, который собирается, и возможно даже тестируется, но никто не знает, зачем оно там и что сломается, если его удалить. (sic!)"
Под второе и третье определение может попадать существенно больший пласт кода.
Здравствуйте, m2user, Вы писали:
S>>И да, вопрос не в том, как образуется "мертвый код". Конкретно в данной ветке отметились персонажи, которые вообще не понимают что такое "мертвый код". Как раз из-за якобы расплывчатого понятия "требуемая функциональность".
M>В моем понимании мертвый код, это код, ставший таковым вследствии изменения требований к продукту (удаление фичей и т.п.).
Это не есть хорошее определение, т.к. оно не описывает ситуаций с рефакторингом.
Например, пусть в приложении была функция, которая делала рекурсивный обход рабочего каталога и удаляла найденные tmp-файлы, оставшиеся от предыдущего запуска, назовем ее find_then_wipe_old_tmp_files. Со временем выяснилось, что она работает медленно, поэтому для эксперимента написали улучшенный вариант, find_then_wipe_old_tmp_files_fast, но старую функцию почему-то не удалили. В коде она есть, в работе программы участия не принимает, на требуемую от программы функциональность влияния не оказывает. Но при этом она является мертвым кодом.
M>- "код, который собирается, и возможно даже тестируется, но никто не знает, зачем оно там и что сломается, если его удалить. (sic!)"
А это не дефиниция вообще. Это другое (с), а именно -- как выясняется, что код мертвый. Ведь на функции find_then_wipe_old_tmp_files не написано, что она является мертвым кодом. Она лежит себе в какой-нибудь библиотеке util, для нее, возможно, какие-то актуальные тесты написаны. Мертвой она от этого быть не перестает, но для того, чтобы выяснить, что она мертвая, нужно провести некоторый анализ.
твоё несогласие — это мои фантазии? Я ведь здесь именно эту мысль выражал — что чистки ради чисток — дурная работа. И именно с этим ты не согласился.
В том сообщении, цитирую, написано вот что:
> Считаю, что поблемы лучше решать по мере их поступления. Вот когда этот код станет помехой для чего-нибудь, тогда можно и почистить. И не обязательно вычищать всё сразу до самых семечек, а по мере востребованности, опять же. Так КПД больше.
Мертвый код становится проблемой с самого начала. Помехой для рефакторинга, проблемой для CI (а значит, всех сотрудников, ждущих окончания тестов). Чистки делаются не ради чисток, а для того, чтобы не огребать проблем, и не терять контекст. Потому что если код, который умертвили, не вычищать, в будущем сразу же будут возникать вопросы — а почему его оставили? Видимо, там есть какие-то скрытые зависимости? А может, его и вовсе нельзя было вычистить, это критично важный кусок?
Поэтому я за то, чтобы удалять мертвый код пока еще помнишь контекст. А не когда уже забыл, и не знаешь даже, как протестировать. Так КПД выше.
R>Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".
Не знаю, как в других языках, но на C# тебе прям студия подствечивает метод или класс, который вообще нигде не используется.
Ну и code guards как правило на больших проектах настроены и не позволяют заливать разную ерунду.
Здравствуйте, m2user, Вы писали:
M>По-моему опыту, просто делаются форки библиотечного кода в тех проектах, где нужна измененная имплементация.
Зачем вам форк? Есть же просто semver, мейнтейните
— текущая мажорная версия — фичи, баги, секурити фиксы,
— предыдущая версия — баги
— пред-предыдущая — секурити фиксы
M>Старые проекты остаются на старой версии.
Здравствуйте, SkyDance, Вы писали:
SD>В том сообщении, цитирую, написано вот что:
> Считаю, что поблемы лучше решать по мере их поступления. Вот когда этот код станет помехой для чего-нибудь, тогда можно и почистить. И не обязательно вычищать всё сразу до самых семечек, а по мере востребованности, опять же. Так КПД больше.
SD>Мертвый код становится проблемой с самого начала.
Ключевое выделено. Если становится проблемой с самого начала, значит, и чистить нужно с самого начала. Это и будет чистить по мере необходимости. Ты со мной споришь, как-будто я где-то сказал, что мёртвый код это хорошо и его нужно беречь.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, m2user, Вы писали: M>- "код, который собирается, и возможно даже тестируется, но никто не знает, зачем оно там и что сломается, если его удалить. (sic!)"
В старых проектах именно такого кода может быть овердофига.
Те кто его проектировал и писал, уже давно уволились, ушли на пенсию, или вообще умерли, документация не обновлялась десятилетиями, так что никто уже не знает, зачем этот код нужен.
Говнокод часто не просто так появляется, а из боязни удалить что-то нужное, недостаточного видения и понимания общей картины.
IMHO, чем меньше кода, тем лучше. Вычищать ненужный код лучше сразу, пока он не разросся как плесень.
Насмотрелся на это дело, иногда бывает и правда как в анекдоте про
обрезание кончиков сосисок
Муж заметил, что жена перед варкой обрезает кончики у сосисок.
— Зачем ты так делаешь?
— Я не знаю, моя мама всегда так делает
Позвонили тёще.
— Так варила ещё моя бабушка.
Прабабушка встрепенулась, услышав разговор:
— А вы что, до сих пор варите в моей маленькой кастрюльке?
С другой стороны, для большинства проектов, живущих всего несколько лет, это вообще не актуально.
P>Зачем вам форк? Есть же просто semver, мейнтейните P>- текущая мажорная версия — фичи, баги, секурити фиксы, P>- предыдущая версия — баги P>- пред-предыдущая — секурити фиксы
Во-первых для этого у библиотеки должен быть выделенный мэйнтейнер (команда, ответственная за эту библиотеку).
Во-вторых разные компоненты станут зависеть от разной версии библиотеки — в одном процессе это будет проблемой.
(я рассуждаю в контексте разработки на C#).
M>>Старые проекты остаются на старой версии.
P>А внутри проекта что делать?
Если проблемная функция реализована и используется только внутри проекта, то гораздо проще понять, на что повлияют вносимые изменения, и уместно ли их делать в данный момент.
Т.е. скорее всего удастся обойтись без копии.
Здравствуйте, Enomay, Вы писали:
R>>Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".
E>Не знаю, как в других языках, но на C# тебе прям студия подствечивает метод или класс, который вообще нигде не используется. E>Ну и code guards как правило на больших проектах настроены и не позволяют заливать разную ерунду.
Студии, конечно, низкий поклон за то, что она облегчает работу программиста. Но даже у студии не всегда есть полная информация для того, чтобы правильно продетектить мёртвый код. Сборки могут подгружаться внешними приложениями при помощи LoadAssembly, классы и методы могут использоваться через рефлесию и т.п. Лично для меня главным критерием внесения изменений в код является степень пересечения данного кода, с той задачей, которую я в данный момент выполняю. Просто вот с точки зрения минимизации зависимостей по коду — у каждой задачи есть некоторый скоуп, по которому определяются все её зависимости. И я без супер-острой необходимости никогда не полезу за эту стену, пускай там хоть одичалые сношаются с белыми ходоками.
--
Справедливость выше закона. А человечность выше справедливости.
bnk>Говнокод часто не просто так появляется, а из боязни удалить что-то нужное, недостаточного видения и понимания общей картины. bnk>IMHO, чем меньше кода, тем лучше. Вычищать ненужный код лучше сразу, пока он не разросся как плесень.
bnk>С другой стороны, для большинства проектов, живущих всего несколько лет, это вообще не актуально.
Несколько лет это тоже немало. По-моему опыту за несколько лет во-первых можно разобраться с кодом, во-вторых происходит хотя бы один большой рефакторинг, в ходе которого "непонятный" код либо исчезает, либо изолируется (и документируется).
Здравствуйте, m2user, Вы писали:
bnk>>Говнокод часто не просто так появляется, а из боязни удалить что-то нужное, недостаточного видения и понимания общей картины. bnk>>IMHO, чем меньше кода, тем лучше. Вычищать ненужный код лучше сразу, пока он не разросся как плесень.
M>Вот в этом комменте верно отмечено про модульность — https://rsdn.org/forum/flame.comp/8871222?tree=tree
Да кто бы спорил, лучше быть богатым и здоровым, чем бедным и больным
bnk>>С другой стороны, для большинства проектов, живущих всего несколько лет, это вообще не актуально.
M>Несколько лет это тоже немало. По-моему опыту за несколько лет во-первых можно разобраться с кодом, во-вторых происходит хотя бы один большой рефакторинг, в ходе которого "непонятный" код либо исчезает, либо изолируется (и документируется).
Как большинство людей не доживают до проблем с раком, большинство проектов не доживают до стадии, когда мертвый код начинает вызывать проблемы
Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к т.н. мертвому коду в проекте? S>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
Здравствуйте, kov_serg, Вы писали:
S>>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
Вот по этому ненужный код должен удалять не джун, вестимо
