Здравствуйте, 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!)"
Под второе и третье определение может попадать существенно больший пласт кода.
