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

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

G>>>С логикой что-то не так?
R>>Теперь понятно.
R>>

1. Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах.
   R>>
2. Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.

G>>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
R>>Аналогично: не знаю, но сомневаюсь.

G>В таком случае должно быть какое-то простое и понятное объяснение — каким образом и почему разработка у них хорошо масштабируется. Я на слово даже уважаемым людям не верю — без понимания сути и причин пользы от такой веры никакой нет. А раз так — зачем себе голову забивать религиозными по сути штуками. Бритва Оккама.

Объяснение у них, очевидно, такое.
1) regression-тестами все накрываем, тестами!
Действительно, при таком подходе у нас становится сложнее внести ошибку в софтину. Многие это понимают, и применяют автоматические тесты — ведь их применение соверешенно иррелевантно к процессу разработки и методологии, на самом деле. Только тесты — не панацея, количество тестов по мере увеличения покрытия растет экспоненциально. Обеспечить покрытие, при котором рефакторинг стал бы действительно безопасным, обеспечивая полную защиту от дурака — это начиная с некоторого момента слишком дорого обходится. Потому, мы применяли сочетание regression-тестирования с проверкой предусловий-постусловий и инвариантов в рантайме, а также специальные "тестовые режимы" при которых старый и новый код выполняются впараллель — так просто дешевле, это уменьшает требуемое тестовое покрытие.

При этом, тесты вас совершенно не гарантируют от внесения новых ошибок. Тесты ловят уже обнаруженные ошибки при повторном их появлении. Самые худшие и дорогие ошибки — ошибки дизайна и архитектурные. Лучшая гарантия от них — это предварительное проектирование. Тогда не будет появляться хрупкий код.

2) Есть способ делать рефакторинг так, чтобы он обходился дешево.
Описываю реальные, типовые ситуации рефакторинга в CQG, коду которого уже лет 17 и размером он в пару миллионов строк. Предваряя замечания — дай вам бог написать код, который не выкинут через 17 лет, и он будет актуален — в этом коде заложена великолепная архитектура и огромный запас "архитектурной прочности". Так вот, как врач говорю, пардон — как бывший руководитель группы разработки сервера. Рефакторинг представляет собой головную боль не тогда, когда надо механически класс на два побить, а когда вам сильносвязную подсистему с неизвестным или просто дико кривым дизайном надо привести к хорошо структурированной системе, которая была бы лишена целого класса известных проблем, плюс успешно, без потока дефектов, выдержала бы добавление известно новой функциональности. Причем, как правило, вы требования к системе в этом случае снимаете частично с описания проблем, частично проводя reverse engineering имеющегося кода. После reverse engineering вы будете долго думать, как вам изменить дизайн так, чтобы серия планируемых изменений прошла безболезненно, с одной стороны, и старая функциональность при этом легла хорошо — с другой (здесь нет никакого универсального метода "рефакторинга" — тут надо уметь прикладные кейсы в голове держать и представльять, как они на дизайн лягут). Возможна ситуация (в описываемом случае — почти наверняка), когда вы поменяете при этом границы подсистем и измените их интерфейсы (иначе новая функциональность может не лечь), вот тут ваши юнит-тесты написанные с таким трудом дружно и отвалятся. Всем скопом. И это типовая ситуацияпри развитии продукта — адаптации его к изменившимся требованиям. И рулить будет то, что я написал выше в пункте 1 — общесистемные regression tests, инварианты с условиями в коде, и "тестовые режимы" с включенным старым и новым кодом (так дешевле — не надо окружения под них готовить).

Так вот, у меня такое произойет в продукте которому 17 лет, а при agile подходе вы имеете неплохие шансы словить такое в течении первого-второго года разработки одного проекта. Или же, у вас неплохой шанс сильно раздуть базу кода на ровном месте — это уж я даю гарантию почти 100% для сложного проекта начиная с определенного объема. Суть в том, что не делая предварительного дизайна, вы пишете legacy code. Сразу. Right now. Да, он будет с тестами, но это still the same fuckin legacy code. А юнит-тесты вы по дороге потеряете, по сценарию описанному мной в п 2. Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .