Здравствуйте 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, а теперь вот обхожусь

Здравствуйте paul_shmakovВ,

Однозначно присоединяюсь к Вашему мнению.

Я имел дело с проектами состоящими из 1, 2, 20+ человек. Во всех случаях нел\достаток документации (в особенности стандартной — Vision,Glossary,Use-cases,Class/Sequence diagrams) всегда обходился дорого. В первых двух случаях это означало просто переписывание приложения каждым новым человеком ответственным за него вместо апгрейда в новую версию.

ИМХО отсутствие упомянутых документов есть признак непрофессионализма (или home-grown кода который никто никогда не купит и сопровождать не будет)

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

ND>Я имел дело с проектами состоящими из 1, 2, 20+ человек. Во всех случаях нел\достаток документации (в особенности стандартной — Vision,Glossary,Use-cases,Class/Sequence diagrams) всегда обходился дорого. В первых двух случаях это означало просто переписывание приложения каждым новым человеком ответственным за него вместо апгрейда в новую версию.

В XP считается, что написание понятного кода и тестов более эффективное средство от выбрасывания сделанного ранее, чем тома документации. Соревноваться в разнообразии и объеме окументации не очень интересно, к тому же хорошую документацию очень мало кто умеет писать.

Здравствуйте Яков Сироткин, Вы писали:

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

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

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

Да, я в курсе техник и практик Extreme Programming. Но, мне кажется, Вы нажимаете на то, что XP — это некая новая анархия, полная свобода в сравнении с RUP, например.
Но ведь это не так! XP — это набор очень правильных, уже многократно выстраданных рекомендаций и техник. И, безусловно, они пойдут всем нам на пользу. Особенно для маленьких команд.

Collective Code Ownership — еще один из способов уменьшения сложности последствий вышеназванной проблемы. Но ни в коем случае эта техника не является полной панацеей.

ЯС>В XP принято писать понятный код, достигая этого через Refactoring, а вот документацию в XP пишут не всегда:)

Так это везде принято :) XP описывает, как этого проще и легче достичь. Ну а насчет документации — я с Вами не согласен.

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

Нет, Вы меня не совсем правильно поняли (а, скорее, я плохо объяснил). Речь идет о том, что в реальном проекте очень сложно абсолютно всем быть в курсе всех последных изменений проекта. Чтобы тщательно вникнуть в некую новую подсистему нужно времени не намного меньше, чем на ее проектирование.
Я это утверждаю по собственному опыту. Возможно, что он не показателен (руки у нас кривые). Да, мы примерно всегда были в курсе того, кто, что и даже как делает. Практический каждый разработчик представлял, как функционируют и как построены чужие подсистемы. Но этого мало для того, чтобы кинуть беглый взгляд на чужой код и, возможно что-то вспомнив, сразу выдать: "А, да эти данные рефрешатся по таймеру теми очень хитрыми колбэками с сервера". Обычно приходится потратить достаточно времени, чтобы разобраться, сказать, что тот, кто писал — полный идиот, потом посидеть еще и понять, как круто тут все сделано, и что и куда нужно добавить.

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

Так я и не утверждаю, что обязательно платить несколько тысяч за Rational Rose или Together. Каждая команда должна определиться с набором документов, диаграмм, соглашений. И для этого выбрать набор средств.

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

Да, такая проблема есть. Особенно для небольших фирм. Я вижу здесь выход в аренде CASE-средств (правда, я не уверен, что это разрешено лицензионными соглашениями производителей).

ЯС>И на это есть практика XP — Pair Programming

Ну правильно, у Pair Programming несколько задач (для тех, кто XP не интересовался: Pair Programming — это когда программисты всегда работают в паре, вместе сидят перед компьютером, вместе думают, один пишет, а второй из-за плеча смотрит и контролирует, обдумывает; потом меняются местами).
Первая — это более высокое качество разработки (две головы все же лучше одной), постоянный контроль.
Вторая — это как раз та проблема, на которую я нажимал — один ушел, зато второй всегда в курсе.

Да, XP — это очень хорошо, но это не полная анархия. Даже наоборот.

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

PS>Да, XP — это очень хорошо, но это не полная анархия. Даже наоборот.
Абсолютно согласен, XP очень жесткая система! Но тем не менее она не требует постоянного использования CASE.

Здравствуйте Яков Сироткин, Вы писали:

ЯС>В XP считается, что написание понятного кода и тестов более эффективное средство от выбрасывания сделанного ранее, чем тома документации. Соревноваться в разнообразии и объеме окументации не очень интересно, к тому же хорошую документацию очень мало кто умеет писать.

Да и не стоит писать тома документации. И уж точно не "двухметровые полки руководств по OS/360" Фредерика Брукса :) (Кстати, если кто еще не успел прочитать книгу Брукса "Мифический человеко-месяц", то очень советую все бросить и срочно прочитать. А потом каждые 2 года перечитывать. Ей хоть и 25 лет, а в программисткой жизни мало что изменилось. Огромное удовольствие гарантирую, если не понравится — я верну вам деньги :) ну это шутка, конечно. http://www.books.ru/shop/books/3626 ).

Для каждого проекта нужно установить некоторый обязательный перечень документов, схем, диаграмм, хелпов, которые должны сопровождать жизненный цикл. И не обязательно этот перечень окажется большим. Документация для программиста по объемам не сравнима с документацией для пользователей.

Важная задача для фирмы — максимально повысить взаимозаменяемость своих программистов. И XP, и документирование и т.п. — все в этом помогает.

Здравствуйте Яков Сироткин,:

ЯС>В XP считается, что написание понятного кода и тестов более эффективное средство от выбрасывания сделанного ранее, чем тома документации. Соревноваться в разнообразии и объеме окументации не очень интересно, к тому же хорошую документацию очень мало кто умеет писать.

Я сильно предпочитаю RUP всем agile методологиям. В отношении к ХР — по крайней мере я сторонник Мартина Фаулера а не Кента Бека (см например "Is design dead?").

С другой стороны я вполне согласен что ХР играет важную роль в пропагандировании идей рефакторинга/юнит тестов/... А уж если поглядеть кто ХР продвигает — это ж супербизоны , но для этого надо лет 15 пробыть в бизнесе.

Чтобы разобраться в новой предметной области может уйти 0.5-1 лет и только качественная документация может облегчить эту задачу.

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

ND>Я сильно предпочитаю RUP всем agile методологиям. В отношении к ХР — по крайней мере я сторонник Мартина Фаулера а не Кента Бека (см например "Is design dead?").
Ты будешь смеятся, мне тоже нравится Фаулер