korvin:
Цитата D_KEY @ 01.09.20, 22:01 Ну потому что при нормальной декомпозиции размер системы не должен настолько сильно сказываться.
Как это не должен, когда должен: к юнит тестам добавляются интеграционные тесты, потом функциональные и системные.
Цитата D_KEY @ 01.09.20, 22:01 На самой ранней из возможных.
Самая ранняя из возможных — это хинты IDE от компилятора и анализатора.
Цитата D_KEY @ 01.09.20, 22:01 Я к тому, что на первый взгляд мне кажется, что TDD показывает проблемы системы.
Нет, не показывает. Что он показывает, так проблемы анализа и постановки задач и вместо нормального решения затыкает костылём (собой).
Цитата D_KEY @ 01.09.20, 22:01 А если его применять сначала, то…
…никогда не дойдёшь до реализации. Либо вместо тебя дойдут конкуренты по методу херак-херак и в продакшн, но это уже другая история.
Цитата D_KEY @ 01.09.20, 22:01 Начали использовать TDD, что помогло нам заметить проблемы.
Не помогло. Добавило новых.
Цитата D_KEY @ 01.09.20, 22:01 Корректность кода определяется не самим кодом, а тем, удовлетворяет ли он контрактам, которые от него хотят извне.
Контракт этого кода: сумма удвоенных нечётных целых чисел из списка. Именно это в нём и написано. Дальше что?
Цитата D_KEY @ 01.09.20, 22:01 Соответственно, поправили код
Зачем вы поправили код?
Цитата D_KEY @ 01.09.20, 22:01 найти и исправить все места, где этот код используется в соответствии с новым контрактом.
Это ещё с какого хера? Если у этих мест появились новые требования (новый контракт), пусть сами его использование и чинят. Моя задача, как реализатора контракта — реализовать его.
Цитата D_KEY @ 01.09.20, 22:01 И я думаю, что многих из этих проблем не было бы при использовании TDD со старта.
Что ж, удачи тебе. )
https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838081
