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>Несколько лет это тоже немало. По-моему опыту за несколько лет во-первых можно разобраться с кодом, во-вторых происходит хотя бы один большой рефакторинг, в ходе которого "непонятный" код либо исчезает, либо изолируется (и документируется).
Как большинство людей не доживают до проблем с раком, большинство проектов не доживают до стадии, когда мертвый код начинает вызывать проблемы
