Здравствуйте, 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, чем меньше кода, тем лучше. Вычищать ненужный код лучше сразу, пока он не разросся как плесень.
Насмотрелся на это дело, иногда бывает и правда как в анекдоте про
обрезание кончиков сосисок
Муж заметил, что жена перед варкой обрезает кончики у сосисок.
— Зачем ты так делаешь?
— Я не знаю, моя мама всегда так делает
Позвонили тёще.
— Так варила ещё моя бабушка.
Прабабушка встрепенулась, услышав разговор:
— А вы что, до сих пор варите в моей маленькой кастрюльке?
С другой стороны, для большинства проектов, живущих всего несколько лет, это вообще не актуально.
