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

____>А процесс ТДД не понятно как распараллелить. Вот три стадии цикла ТДД:

__>1) написание теста, который заведомо не выполнится успешно (другие в ТДД не комильфо, потому что каждый новый тест должен предварять соотв. ему изменения в коде);
__>2) исправления в коде по принципу наименьшего сопротивления;
__>3) рефакторинг кода по результатам 2), если он нужен.

__>При выполнении п.2) каждого цикла, архиектура кода потенциально может измениться. И, даже если дизайн ООП системы не меняется в конкретном цикле, нужно делать рефакторинг или нет — зависит от результатов п.1) и п.2).
__>И не важно, на сколько малы изменения — суть зависимости это не меняет.
__>Т.о., мало того, что вполнение каждого последующего цикла зависит от результата предыдущего, стадии внутри цикла тоже зависят друг от друга.
Если рассматривать ситуацию сугубо теоретически — то да, любой новый код (даже безотносительно TDD) может поменять архитектуру всей системы и результаты работы остальных членов команды станут нерелевантными.
Но практика говорит, что 99% работы программистов — локальные и не влияют на другие части системы.
Касательно TDD — если каждый цикл TDD (или даже каждый десятый) приводит к изменению архитектуры системы — значит команду нужно разогнать и нанять нормальных опытных разработчиков.
Потому, что если они через TDD пытаются создать архитектуру сложной системы, не уделяя внимания системному проектированию, то навыки данной команды для данного проекта недостаточны.