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

PS> Ситуация: из команды уходит один из ключевых разработчиков. Что делать? Что делать с тем кодом, который он оставил? Только не говорите, что все разработчики всегда должны быть в курсе того, что делают другие. Никогда этого не получается.

Получается. В XP есть такая практика — Collective Code Ownership

PS> Да, начальник отдела должен быть в курсе. Но обычно он в курсе достаточно поверхостно, т.к. когда Вы ему приносите 150Кб кода, как результат выполнения задания, он вникает в особенности функционирования, а не архитектуру.
150Кб кода это знаешь ли не мало, это один человек за неделю не напишет (если конечно мы говорим о качественном коде) А если никто из начальства не понимате в архитектуре, то это тоже нехорошо.

PS> Вот здесь и помогают CASE-средства. Несколько простых, самых важных для понимания диаграмм, описание классов и их взаимосвязей, одинаковое форматирование исходного кода и т.п. — все это сильно упрощает взаимозаменяемость разработчиков.

Несколько простых диаграмм можно нарисовать на бумажке или в Visio. Одинаковое форматирование кода во всей индустрии для Java нормальное явление, достигается в некоторых средствах разработки нажатием пары клавиш.


PS> И не имеет значения, сколько человек в команде.
Сколько стоят CASE средства? Для одного человека его купить гораздо тяжелее чем на десятерых.

PS> Ну а если Вы разрабатываете систему не один, а с напарником. Как Вы будете обсуждать ее архитектуру? "Ну помнишь я тебе говорил про подсистемку, в которой транзакции на банковском счете осуществляются удаленным банковским терминалом? Так вот, пусть там будет не 10 классов, а 11. Да и одну из таблиц нужно убрать, заменив ее на три другие." Долго Вы сможете вести такую беседу, полностью вникая во все, что говорит Вам собеседник? А если вечерком еще 3 литра пива выпить, то на следующее утро все вспомните?

И на это есть практика XP — Pair Programming Кстати, сдается мне ты не один банковскую систему разрабатываешь Мои знакомые, которые делают банковское ПО тоже используют CASE, но в данном случае не очевидно, что речь идет о банковской системе.

PS> А если продавать, поддерживать пользователей, выпускать новые версии — одназначно — код нужно документировать!
В XP принято писать понятный код, достигая этого через Refactoring, а вот документацию в XP пишут не всегда

PS> Вы к этому в любом случае придете Так что лучше раньше, чем потом.
Я вот в свое время порисовал в Together, а теперь вот обхожусь