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

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

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


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


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

P>>>Одна единственная задача это только краткосрочная перспектива.
G>>Это именно краткосрочная.
P>О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.
И это хорошо. Требования часто меняются, будущее угадывать невозможно. Нет смысла ориентироваться на "долгосрочные" цели разрабатывая каждый блок функционала.


P>>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое...
G>>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.
P>В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.
У меня есть эпичный пример на этот счет.
Был такой один проектировщик. Он даже ен ИТшник был, а фин менеджер. Проектировал процесс согласования. Говорил что должно быть строго три согласующих, потому что так уже 7 лет в компании было. И буквально на следующий день, как выпустили процесс, согласующих стало 2.
Как бы красиво не называли, это все попытка угадать будущее. И чаще всего люди не угадывают. Поэтому единственный универсальный способ — написать сегодня настолько мало, чтобы завтра было не жалко выкинуть.
Как только вы начинаете проектировать наперед, то создаете кучу ограничений и потом сложнее отказаться от написанного, ибо работает когнитивная ошибка невозвратных затрат, да и просто обосновать зачем столько делали становится сложнее.


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

P>Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Зачем нужна обратная совместимость?
1) если добавляется необязательное поле, то старый код продолжает работать
2) если поле обязательное, то старый код в любом случае сломается
3) если происходят более значимые изменения, то просто создается новый метод (возможно с номером версии в сегменте пути, querystring или заголовке)

P>Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?
Если задача создать новый метод не поломав старый, то она решается целиком. А не так, что сначала создается новый, а потом чинится старый. Некоторые изменения в системах должны быть атомарны — это и будет одна задача для одного программиста.