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

P>>Мертвый код сначаоа нужно идентифицировать. Чаще всего он просто выглядт, как живой код.
G>Давайте считать что мертвый код уже был идентифицирован, ибо если нет, то о чем разговор?

Ага, давайте считать, что проблемы нет, а строчки сами будут говорить надо ли их удалять.

G>Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.

Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает.

P>>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать.
G>Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать.

Вы в слова играете. У каждого своё видение, что именно относится к задаче. Например, один меняет метод, и все точки вызова проверит и поправит. А другой решит,что такая чистка к его задаче не относится, и даже тикет не создаст.

G>Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно.

Это общие слова.

P>>Одна единственная задача это только краткосрочная перспектива.
G>Это именно краткосрочная.

О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.

P>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое...
G>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.

В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.

P>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования.
G>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.

Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?