Здравствуйте, so5team, Вы писали:

S>Не уверен, что правильно вас понял, но вот как это бывает в моей практике:

S>- нужно добавить фичу X (или починить фичу Y);
S>- выясняется, что для этого нужно переделать класс C;
S>- сперва пытаемся определить, что поломается, если класс C изменить;
S>- находится функция F, в которой задействованы методы класса C, которые становятся жертвами изменений;
S>- пробуем разобраться где и как применяется F и...

S>В лучшем случае обнаруживаем, что она задействована только в unit-тестах для F. Но это если проект делается по-человечески.
S>А если делается так, как часто бывает, то просто нигде не используется. Тупо комментируешь ее и код успешно собирается и линкуется.

Я говорил

Автор: rg45
Дата: 19.12 02:47

, что вычищать старый код нужно по мере необходимости. Вот это пример сценария, когда такая необходимость назрела. Да, нам таки придется поискать, где и как применяется функция F, но при этом мы можем ответить на вопросы "зачем?" и "почему?" мы это делаем. А просто поиски ради поисков и чистка ради чистки — с моей точки зрения, этим можно заниматься, только если больше делать нечего.

Мою мысль можно сформулировать более общо: реальный код реальных проектов код не бывает идеальным. Можно пробовать приближаться к идеальному состоянию, но чем ближе, тем дороже. И на каком-то этапе чистоты обязательно возникает вопрос о целесообразности дальнейших улучшений. В любом хорошем деле главное — вовремя остановиться. И это относится к любым критериям оценки качества кода. Количество мёртвого кода — всего лишь один из таких критериев.