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>>Когда оставляют то что уже не используется (когда-то нужно было, а сейчас уже нет). Но никто не удаляет, т.к. вроде есть не просит. С годами может накопиться очень много такого хлама.
Вот по этому ненужный код должен удалять не джун, вестимо
Здравствуйте, m2user, Вы писали:
M>Во-вторых разные компоненты станут зависеть от разной версии библиотеки — в одном процессе это будет проблемой. M>(я рассуждаю в контексте разработки на C#).
Если вы разные версии одной либы держите, вам ничего не поможет
Команда мейнтейнеров библиотеки нужна именно решать ваши вопросы с переходом на одну версию
А вы хотите и команду такую, и сидеть на нескольких версиях.
Какой в этом смысл?
P>Если вы разные версии одной либы держите, вам ничего не поможет P>Команда мейнтейнеров библиотеки нужна именно решать ваши вопросы с переходом на одну версию P>А вы хотите и команду такую, и сидеть на нескольких версиях. P>Какой в этом смысл?
держим одну версию, чтобы не решать вышеупомянутую проблему, но при этом (в теории) обеспечена
полная обратная совместимость.
перевести весь зависимый от модифицируемый функции код на новую имплементацию невозможно, т.к. этот
код может быть либо полностью "заморожен", либо c неопределенным ближайшим окном для перевода.
Именно поэтому самый безопасный способ это добавление второй версии функции/класса. Либо (поэтапный)
отказ от зависимости на эту общую библиотеку.
