Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

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

D>Прочитал книгу "Экстремальное программирование", :super: возник вопрос — кто-нибудь так работает? :xz: Поделитесь впечатлениями. И много ли контор в Москве где так работают?

Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

Daenur wrote:

> Прочитал книгу "Экстремальное программирование", возник вопрос -
> кто-нибудь так работает? Поделитесь впечатлениями. И много ли
> контор в Москве где так работают?
Это не в Москве, а в ионе, но у них тоже эту штуку внедряли. Об этом Стив
Виноски упоминал с статье:
http://www.osp.ru/os/2004/01/059.htm
--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

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

S> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

А что есть тогда "по-нормальному"???
Объясни чайникам, о гуру

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

А ещё было бы интересно узнать и не только про Москву (не только там ведь люди живут...)

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

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

S>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>А что есть тогда "по-нормальному"???

Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

К>Объясни чайникам, о гуру :shuffle:

Зачем язвить?

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

S>>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>>А что есть тогда "по-нормальному"???

S> Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

Жаль, но дело, наверное, не в XP, а, возможно, в низкой квалификации разработчиков/менеджмента и/или непонимании ими методологии. Или несоответствии XP поставленной задаче. Между заявлениями "мы проповедуем" и эффективным использованием — большая разница.

Здравствуйте, Аноним, Вы писали:

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

S>>>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>>>А что есть тогда "по-нормальному"???

S>> Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

А>Жаль, но дело, наверное, не в XP, а, возможно, в низкой квалификации разработчиков/менеджмента и/или непонимании ими методологии. Или несоответствии XP поставленной задаче. Между заявлениями "мы проповедуем" и эффективным использованием — большая разница.

Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

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



S> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

А что же такое ХР на самом деле?
Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно! Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

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

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



S>> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

G>А что же такое ХР на самом деле?

Ты у меня спрашиваешь? :) Я не эксперт... это у Брукса или у Бека надо стросить...

G>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!

Это, кстати, одно из немного, что мне нравится в XP. Классная идея в том случае, если правильно подобраны партнеры. Можно получать очень качественный код.

G>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

вот-вот... согласен. Это все дело для каких-то очень странных проектов.

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

S> вот-вот... согласен. Это все дело для каких-то очень странных проектов.
Мне в этом плане больше UP нравится. Там и отдельные элементы ХР имеют место, но в тоже время есть четкое планирование, написание кода и тестирование.

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

Ну вот например, Наумен. Правда, насколько я понимаю основной офис у них не в Москве, а в Екатеринбурге. Одно время, если я не ошибаюсь, здесь бывал человек оттуда, не знаю, правда, читает ли он этот ресурс сейчас.

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

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

G>А что же такое ХР на самом деле?
G>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!
Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)
G>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.
Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

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

H>Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)
+1 Согласен. Помнится мы еще на 2 курсе с соседом эту фишку просекли, когда делали лабы и курсачи в последний момент. На самых трудных участках программы сидели вдвоем и дергая друг у друга клаву писали. Хорошо получалось.

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

На конференции разработчиков компьютерных игр (КРИ-2004), прошедшей в эти выходные, выступал руководитель игровых проектов компании "Никита" (которая игры пишет). Доклад назывался как-то типа "XP и реальная жизнь: опыт применения в компании Никита". Ну вот он утверждал, что такие методики, как маленькие циклы разработки, постоянный рефакторинг, парное программирование (не в том смысле, что за одним компом сидят двое программеров, а в том, что задание даётся на двоих), написание unit test'ов -- используется в их компании.

Правда под конец он несколько дезавуировал свой доклад, сообщив, что всё это используется в коллективе из 4 программеров и 4 художников, -- на мой взгляд в такой маленькой компании можно вообще любые методики успешно применять. Непосредственные коммуникации в таком маленьком коллективе могут успешно решать поставленные задачи вопреки любым формальным методикам

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

H>Здравствуйте, Glоbus, Вы писали:

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

G>>А что же такое ХР на самом деле?
G>>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!
H>Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)

Ага. А если ни один из челов в паре не знает вопроса, тггда что? Вдвоем в мсдн-е рыться?

G>>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.
H>Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

Очень клево — и швец, и жнец и на дуде дудец. И действительно клево ТЗ нету, никакой анализ не проведен, ничего не знаем, но зато начали педалить, наверх рапортуем об успехах, причем вдвоем с напарником наперегонки.
Кстати у меня всегда возникал вопрос — а как распределяется ответсвенность за написанный такоим образом код? И как эти товарищи договоряться что и как писать, если архитектуры общей нету. Откуда они знают место своего куска во всем прожекте, если у них даже ТЗ нету, не говоря уже об общей схеме приложения?

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

S>Здравствуйте, Glоbus, Вы писали:

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



S>>> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

G>>А что же такое ХР на самом деле?

S> Ты у меня спрашиваешь? Я не эксперт... это у Брукса или у Бека надо стросить...

G>>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!

S> Это, кстати, одно из немного, что мне нравится в XP. Классная идея в том случае, если правильно подобраны партнеры. Можно получать очень качественный код.

А подбирать ты их как будешь.
А код можно получить а можно и не получить
А спросим потом с кого?

G>>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

S> вот-вот... согласен. Это все дело для каких-то очень странных проектов.

Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

G>Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

А с чего это вдруг такое пренебрежение к лабам и курсовикам? "Серьезность" начинается именно с них. Это первое. Второе — лично для меня "серьезные" проекты — давно в прошлом. От "серьезных" проектов я не получаю ничего, кроме рутины и зеленой тоски. Я уже не мальчик, чтобы работать запросто так, без фана. Фан в работе имеет для меня огромное значение.
Третье. Как говрится, "Если высказывание можно истолковать неправильлно, оно будет истолковано неправильно", Если же высказывание таково, что его просто невозможно истолковать неправильлно, оно, тем не менее, все равно будет истолковано неправильно.

Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

"Проект всегда готов к сдаче" означает не житие сегодняшним днем и не отсутствие планирования. Это означает то, что написано, а именно "Проект всегда готов к сдаче". Не мешало бы научиться просто читать то, что написано, без выдумывания отсебятины.

Где в XP сказано, что не надо никаких планов? Где сказано, что планирование — это плохо? Там сказано, что надо быть гибче. Если план не срабатывает (ну негодный план, не торкает — это бывает сплошь и рядом), то ну его на фиг, такой план, на как можно более раннем этапе.

Рефакторинг означает не то, что надо постоянно все переделывать, как это многие извращенно понимают. Это значит, что надо не стесняться переделывать, если что-то оказалось неудачными, даже если это стоит больших усилий всей группы. Такой подход позволяем сохранять уровень энтропии кода на приемлемом уровне и не загонять себя в угол все более и более кривеющего тулкита, чем очень часто страдает традиционный подход. Кто скажет, что его ни разу не тошнило от проделанной самим же работы, тот либо самодовольный болван, либо молодой еще.

Работа парами ставит целью не повышение "мгновенной" эффективности. Наоборот, зачаструю это медленее, больше ругани, и т.д. Тем более, платить надо двоим за ту же работу. Работа парами ставит собой две цели. Первое — наладить естественным образом коммуникации между людьми. Каждый станотся более-менее в курсе того, что делается за соседним столом. Code Review говорите? Совершенно бесполезная, скучная и искусственно насаждаемая байда. С какой стати я должен разбираться в чужом коде, если я не вовлечен в процесс соседа и у него все работает (до поры, до времени)? Вторая цель — процентов 80 всей работы — это рутина. Не знаю как вы, но я от рутины постепенно сдуваюсь. Работать вдвоем над рутиной — просто веселее. Это очень важно. И не надо кивать на то, что "работа есть работа", "за нее деньги платят", "у нас серьезный проект", "тебе налили — вот сиди и пей" (последнее — как естественное логическое продолжение). Работать должно быть весело и приятно — только в этом случае можно выдать что-то хорошее.

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

G>>Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

MS>А с чего это вдруг такое пренебрежение к лабам и курсовикам? "Серьезность" начинается именно с них. Это первое. Второе — лично для меня "серьезные" проекты — давно в прошлом. От "серьезных" проектов я не получаю ничего, кроме рутины и зеленой тоски. Я уже не мальчик, чтобы работать запросто так, без фана. Фан в работе имеет для меня огромное значение.
MS>Третье. Как говрится, "Если высказывание можно истолковать неправильлно, оно будет истолковано неправильно", Если же высказывание таково, что его просто невозможно истолковать неправильлно, оно, тем не менее, все равно будет истолковано неправильно.

Интересно, если "серьезные" прожекты в прошлом, то что же в настоящем. Чтобы не было разночтений давайте сразу определимся что суть "серьезный" проект а что "несерьезный". По моему субъективному мнению лабы и курсовики нельзя назвать "серьезными" прожектами, да и прожектами вообще потому что зачастую, с вероятностью 0.95, они все просто "слиты" — на то закрыли глаза, там замазали — вот и сдали, ну и славненько. В коммерческих пролектах это тоже встречается, но имеет гараздо меньший удельный вес — за реальные прожекты трахают по-настоящему все начиная с твоего непосредственного начальника, который видит что твой алгоритм работает недостаточно быстро, и заканчивая заказчиком в далеком городке на берегу мисисипи за то что кнопка лежит не так.

MS>Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

Уважаемый, а вот ответь мне, простому русскому человеку, контора в которой ты работаешь применяет хр на практике? Реально просто интересно.

MS>"Проект всегда готов к сдаче" означает не житие сегодняшним днем и не отсутствие планирования. Это означает то, что написано, а именно "Проект всегда готов к сдаче". Не мешало бы научиться просто читать то, что написано, без выдумывания отсебятины.

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

MS>Где в XP сказано, что не надо никаких планов? Где сказано, что планирование — это плохо? Там сказано, что надо быть гибче. Если план не срабатывает (ну негодный план, не торкает — это бывает сплошь и рядом), то ну его на фиг, такой план, на как можно более раннем этапе.

Нет, само собой разумеется что планирование в хр хоть какое-то но присутсвует, хотя бы та же разработка тестов. Однако товарищ в посте выше написал буквально следующее

Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

Эк удобно то. Сам себе и архитектор, и тестер, и программер. Интересно было бы посмотреть на архитектуру того приложения, которым он занимался. А теперь представим что у нас таких архитекторов скажем 6. И все они равноправны требовать принятия своего решения. В хорошей книженке брукса описывается построение группы разработчиков по принципы операционной бригады. Всегда есть человек во главе процесса. он один принимает решения и он за это отвечает. Все остальные товарищи могут либо ваще играть роль исполнителей либо иметь совещательный голос в зависимости от квалификации и своего проф уровня.


MS>Рефакторинг означает не то, что надо постоянно все переделывать, как это многие извращенно понимают. Это значит, что надо не стесняться переделывать, если что-то оказалось неудачными, даже если это стоит больших усилий всей группы. Такой подход позволяем сохранять уровень энтропии кода на приемлемом уровне и не загонять себя в угол все более и более кривеющего тулкита, чем очень часто страдает традиционный подход. Кто скажет, что его ни разу не тошнило от проделанной самим же работы, тот либо самодовольный болван, либо молодой еще.

А никто не говорит что рефакторинг это плохо. Но посуди сам, мой благородный друг, что лучше применять рефакторинг в исключительных случаях нежели использовать его как часть методологии. Именно таким подходом и можно загнать себя в угол, потому что переделывать код каждый божий день грабли отвалятся, как бы тебя не тошнило от него. Так что сначала думать надо, а потом делать.

MS>Работа парами ставит целью не повышение "мгновенной" эффективности. Наоборот, зачаструю это медленее, больше ругани, и т.д. Тем более, платить надо двоим за ту же работу. Работа парами ставит собой две цели. Первое — наладить естественным образом коммуникации между людьми. Каждый станотся более-менее в курсе того, что делается за соседним столом. Code Review говорите? Совершенно бесполезная, скучная и искусственно насаждаемая байда. С какой стати я должен разбираться в чужом коде, если я не вовлечен в процесс соседа и у него все работает (до поры, до времени)? Вторая цель — процентов 80 всей работы — это рутина. Не знаю как вы, но я от рутины постепенно сдуваюсь. Работать вдвоем над рутиной — просто веселее. Это очень важно. И не надо кивать на то, что "работа есть работа", "за нее деньги платят", "у нас серьезный проект", "тебе налили — вот сиди и пей" (последнее — как естественное логическое продолжение). Работать должно быть весело и приятно — только в этом случае можно выдать что-то хорошее.

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

G>Интересно, если "серьезные" прожекты в прошлом, то что же в настоящем. Чтобы не было разночтений давайте сразу определимся что суть "серьезный" проект а что "несерьезный". По моему субъективному мнению лабы и курсовики нельзя назвать "серьезными" прожектами, да и прожектами вообще потому что зачастую, с вероятностью 0.95, они все просто "слиты" — на то закрыли глаза, там замазали — вот и сдали, ну и славненько.

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

MS>>Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

G>Уважаемый, а вот ответь мне, простому русскому человеку, контора в которой ты работаешь применяет хр на практике? Реально просто интересно.

Нет, не применяем — в этом нет необходимости. Я, кстати, и не говорил, что являюсь апологетом XP Я говорил о том, что тяжело понять и принять такую философию. Опять-же, учимся читать то, что написано.

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

Это означает, что заказчик постоянно его видит и наблюдает за развитием. Все определяется целью — как правило, это именно "слить" проект и получить деньги — это гнилая цель. Хорошая цель — это попытаться удивить мир, начиная с того же заказчика. Для этого надо иметь амбиции, а это непросто.

G>Эк удобно то. Сам себе и архитектор, и тестер, и программер. Интересно было бы посмотреть на архитектуру того приложения, которым он занимался. А теперь представим что у нас таких архитекторов скажем 6. И все они равноправны требовать принятия своего решения. В хорошей книженке брукса описывается построение группы разработчиков по принципы операционной бригады. Всегда есть человек во главе процесса. он один принимает решения и он за это отвечает. Все остальные товарищи могут либо ваще играть роль исполнителей либо иметь совещательный голос в зависимости от квалификации и своего проф уровня.

Здесь все зависит от этого начальника-архитектора. А это нехорошо. Начальник завсегда может свою ответственность слить. Как показывает практика.

MS>>Рефакторинг означает не то, что надо постоянно все переделывать, как это многие извращенно понимают. Это значит, что надо не стесняться переделывать, если что-то оказалось неудачными, даже если это стоит больших усилий всей группы. Такой подход позволяем сохранять уровень энтропии кода на приемлемом уровне и не загонять себя в угол все более и более кривеющего тулкита, чем очень часто страдает традиционный подход. Кто скажет, что его ни разу не тошнило от проделанной самим же работы, тот либо самодовольный болван, либо молодой еще.

G>А никто не говорит что рефакторинг это плохо. Но посуди сам, мой благородный друг, что лучше применять рефакторинг в исключительных случаях нежели использовать его как часть методологии. Именно таким подходом и можно загнать себя в угол, потому что переделывать код каждый божий день грабли отвалятся, как бы тебя не тошнило от него. Так что сначала думать надо, а потом делать.

Для этого надо быть провидцем на практике. Я таких не встречал. Чтобы хорошо придумать, надо хорошенько повертеть в руках сначала. Попробовать так и сяк. Не стесняться выкинуть написанный код и сделать лучше.

G>Писанина вдвоем это мне кажется реально байда. По большому счету разработчику практически не надо знать что делается за соседним столом как ты говоришь, уважаемый. У него должен быть список жестких требований к его модулю, а как он будет реализован это его маленькие интимные секреты. И с помощью этих секретов он должен уложить результат своих деяний в прокрустово ложе этих самых требований. А вот составить список требований по каждому модулю, да так чтоб все модули потом состыковались, и чтобы все было просто красиво и быстро — вот это настоящее искуство, в этом и состоит красота программинга как деятельности, а не в том чтобы...

Так о том и речь! К сожалению, все, что люди понимают из XP — это

G>...побыстрее напедалить чтобы все было "в любой момент готово к сдаче".

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

А что "должен быть список жестких требований к его модулю" — это в коне неверно. Список требований должен быть. Список жестких требований — блажь и самодурство начальников-архитекторов. Может это мне так не везло, но вот пример очень яркий. Был у нас проект по довольно сложной обработке геномных данных. Объемы гигантские, алгоритмы хитрые. Ораклы всякие. Так называетый главный архитектор определил модули, интерфейсы, и прочее. Все очень красиво и прельстиво. Осталось все реализовать. И вот, под конец выясняется, что "прокрустово ложе" интерфеса само по себе диктует сложность алгоритма на уровне O(N^3), в то время как и O(N log N) — многовато. Изначально это не было очевидно, все было красиво и все радовались. Нам удалось доказать несостоятельность его дизайна только лишь продемонстрировав что даже с пустышками вся система просто затыкается на реальных объемах. И все равно сдали именно так, потому как "сроки и планы". Заказчики вежливо отказались, репутация группы была испорчена, зато все в срок и с хорошим, красивым дизайном.

Согласен, есть задачи, где изначально очевидно, что все получится, надо только все грамотно расписать. Мне они не интересны — это рутина и тоска изначально, хоть на уровне проектирования, хоть на уровне кодирования. Мне интересны задачи со значительным риском — получится/не получится. Мне надо "поиграться", прикинуть Х к Н, подумать как следут (думать для меня означает пробовать так и сяк, вертеть в руках). А здесь первичен именно алгоритм, а не дизайн. И секреты у меня не "маленькие интимные", а большие и удивительные

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


MS>Ну так я об этом и говорю! Отношение к работе, желание выпендиться, если угодно. "Сдали, ну и славненько" — этим как раз страдает большинство коммерческих контор. Какая там квача внутри, никого не касается. И начинается это именно с тех самых курсовиков. Любой проект надо воспринимать как серьезный, но работать над ним надо не серьезно, а если угодно, с азартом.

Ага, пионер всем ребятам пример! С задором надо!


MS>Нет, не применяем — в этом нет необходимости. Я, кстати, и не говорил, что являюсь апологетом XP Я говорил о том, что тяжело понять и принять такую философию. Опять-же, учимся читать то, что написано.

Не будь таким прямолиненйным. Ты сам проповедуешь гибкость, а тут взялся за буковедство. Ты смотри между строк что написано. вот попробуй сам попедалить в паре с кем-нибудь, пописать один и тот же модуль. И я готов спорить что через 2 дня вы готовы будете глотки друг другу грызть. И не надо юлить с фразами о непонимании и неприятии философских концепций хр. Нет там никаких концепций.


MS>Это означает, что заказчик постоянно его видит и наблюдает за развитием. Все определяется целью — как правило, это именно "слить" проект и получить деньги — это гнилая цель. Хорошая цель — это попытаться удивить мир, начиная с того же заказчика. Для этого надо иметь амбиции, а это непросто.

Я не верю что я это читаю! Удивить мир. Извини, старик, но ты мне представляешся юношей с гарящим взглядом, собирающимся завтра заткнуть за пояс микрософт с помощью написанной тобой программулины.


MS>Здесь все зависит от этого начальника-архитектора. А это нехорошо. Начальник завсегда может свою ответственность слить. Как показывает практика.

Как показывает практика гараздо проще управлять одним архитектором, чем десятью программерами, думающими что они архзитекторы и тулящими всякую лабуду.



MS>Для этого надо быть провидцем на практике. Я таких не встречал. Чтобы хорошо придумать, надо хорошенько повертеть в руках сначала. Попробовать так и сяк. Не стесняться выкинуть написанный код и сделать лучше.

А вот это и есть инженерная задача, этому в институтах учат и толстолобые книжки пишут — как придумать так чтоб все склеилось потом без проблем. А вертеть в руках должен слесарь.


MS>Так о том и речь! К сожалению, все, что люди понимают из XP — это

G>>...побыстрее напедалить чтобы все было "в любой момент готово к сдаче".

А что же такое хр скажите на милость.

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

Просвети нас, о великий!

MS>А что "должен быть список жестких требований к его модулю" — это в коне неверно. Список требований должен быть. Список жестких требований — блажь и самодурство начальников-архитекторов. Может это мне так не везло, но вот пример очень яркий. Был у нас проект по довольно сложной обработке геномных данных. Объемы гигантские, алгоритмы хитрые. Ораклы всякие. Так называетый главный архитектор определил модули, интерфейсы, и прочее. Все очень красиво и прельстиво. Осталось все реализовать. И вот, под конец выясняется, что "прокрустово ложе" интерфеса само по себе диктует сложность алгоритма на уровне O(N^3), в то время как и O(N log N) — многовато. Изначально это не было очевидно, все было красиво и все радовались. Нам удалось доказать несостоятельность его дизайна только лишь продемонстрировав что даже с пустышками вся система просто затыкается на реальных объемах. И все равно сдали именно так, потому как "сроки и планы". Заказчики вежливо отказались, репутация группы была испорчена, зато все в срок и с хорошим, красивым дизайном.



MS>Согласен, есть задачи, где изначально очевидно, что все получится, надо только все грамотно расписать. Мне они не интересны — это рутина и тоска изначально, хоть на уровне проектирования, хоть на уровне кодирования. Мне интересны задачи со значительным риском — получится/не получится. Мне надо "поиграться", прикинуть Х к Н, подумать как следут (думать для меня означает пробовать так и сяк, вертеть в руках). А здесь первичен именно алгоритм, а не дизайн. И секреты у меня не "маленькие интимные", а большие и удивительные

Падаю ниц! Да будут твои дни долги, как вечность, о средоточие счастья!

G>Не будь таким прямолиненйным. Ты сам проповедуешь гибкость, а тут взялся за буковедство. Ты смотри между строк что написано.

А что там написано?! Made in China?!

G>вот попробуй сам попедалить в паре с кем-нибудь, пописать один и тот же модуль. И я готов спорить что через 2 дня вы готовы будете глотки друг другу грызть. И не надо юлить с фразами о непонимании и неприятии философских концепций хр. Нет там никаких концепций.

Я так и делаю периодически. "Педалим" по-тихоньку. Более того, это чуть ли не единственный способ оперативно решить скучную и тяжелую часть задачи.

G>Я не верю что я это читаю! Удивить мир. Извини, старик, но ты мне представляешся юношей с гарящим взглядом, собирающимся завтра заткнуть за пояс микрософт с помощью написанной тобой программулины.

Не собираюсь я никого затыкать за пояс. У меня другое предназначение

G>Как показывает практика гараздо проще управлять одним архитектором, чем десятью программерами, думающими что они архзитекторы и тулящими всякую лабуду.

Кто бы спорил, разумеется проще. И гораздо комфортнее. Попробуй поуправляй группой Нобелевских лауреатов по физике

G>А вот это и есть инженерная задача, этому в институтах учат и толстолобые книжки пишут — как придумать так чтоб все склеилось потом без проблем. А вертеть в руках должен слесарь.

Я, кстати, люблю слесарить. И инженерить тоже. Какая разница — инженер, слесарь, менеджер. Как там в одном из мультов про Масяню — "чем попса отличается от непопсы? Попсовики любят деньги, а музыканты — музыку". Вот и вся разница, собственно. Вот, кстати, к слову о слесарях, радистах, академиках и прочих:
http://www.buran.ru/htm/memory.htm — очень увлекательно.

MS>>Так о том и речь! К сожалению, все, что люди понимают из XP — это

G>>>...побыстрее напедалить чтобы все было "в любой момент готово к сдаче".

G>А что же такое хр скажите на милость.

Технология разработки софта.

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

G>>Не будь таким прямолиненйным. Ты сам проповедуешь гибкость, а тут взялся за буковедство. Ты смотри между строк что написано.

MS>А что там написано?! Made in China?!

G>>вот попробуй сам попедалить в паре с кем-нибудь, пописать один и тот же модуль. И я готов спорить что через 2 дня вы готовы будете глотки друг другу грызть. И не надо юлить с фразами о непонимании и неприятии философских концепций хр. Нет там никаких концепций.

MS>Я так и делаю периодически. "Педалим" по-тихоньку. Более того, это чуть ли не единственный способ оперативно решить скучную и тяжелую часть задачи.

Периодически это значит ты подсаживаешся раз в две недели к корешу за соседний стол и вы вместе тулитесь в его код, потому что кому-то из вас че-то неопнятно. А ты попробуй с этим вот корешем именно пописАть за одним компом, и не периодически а недельки две-три.

G>>Я не верю что я это читаю! Удивить мир. Извини, старик, но ты мне представляешся юношей с гарящим взглядом, собирающимся завтра заткнуть за пояс микрософт с помощью написанной тобой программулины.

MS>Не собираюсь я никого затыкать за пояс. У меня другое предназначение

Клево! Слушай, как станешь знаменитым скажешь там что вот я вот так вот с тобой запросто на форуме базарил . А то мне не поверят, скажут что понты колочу

G>>Как показывает практика гараздо проще управлять одним архитектором, чем десятью программерами, думающими что они архзитекторы и тулящими всякую лабуду.

MS>Кто бы спорил, разумеется проще. И гораздо комфортнее. Попробуй поуправляй группой Нобелевских лауреатов по физике

Кстати, управлял это группой Опенгеймер, и между прочим единственный "ненобелевский лауреат". А управлял он ими потому что он был к этому пригоден. Есть управленцы, есть исполнители со светлыми головами — вот у них и была дифференциация. Но руководитель один и обязанности четко расписаны.

G>>А вот это и есть инженерная задача, этому в институтах учат и толстолобые книжки пишут — как придумать так чтоб все склеилось потом без проблем. А вертеть в руках должен слесарь.

MS>Я, кстати, люблю слесарить. И инженерить тоже. Какая разница — инженер, слесарь, менеджер. Как там в одном из мультов про Масяню — "чем попса отличается от непопсы? Попсовики любят деньги, а музыканты — музыку". Вот и вся разница, собственно. Вот, кстати, к слову о слесарях, радистах, академиках и прочих:
MS>http://www.buran.ru/htm/memory.htm — очень увлекательно.

MS>>>Так о том и речь! К сожалению, все, что люди понимают из XP — это

Я тоже много чего люблю — и кирпичь класть, и цемент месить, и бачок чинить. только в этих областях я любитель и поэтому не претендую на ведущие позиции. А вот хр как раз подразумевает, что кухарка будет управлять прожектом.

G>>>>...побыстрее напедалить чтобы все было "в любой момент готово к сдаче".

G>>А что же такое хр скажите на милость.

MS>Технология разработки софта.

А изюминка в чем? Не просветишь старого?

- Ну и поганый певец этот ваш Карузо! Шепелявит, гундосит, половину букв вообще глотает!
— А ты его слушал?
— Да нет, но мне Мойша напел!

Прчти книгу Кента Бека Экстремальное программирование

Автор(ы): Кент Бек

Эта книга об экстремальном программировании.
Экстремальное программирование, часто обозначаемое аббревиатурой «XP», — это упрощенная методика
организации производства для небольших и средних по размеру команд разработчиков,
занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся
требований. Данная книга предназначена для того, чтобы помочь вам определить,
оправдано ли применение XP в вашей ситуации или нет.

.Сейчас у тебя не правильно6е понимание XP.

MS>>Технология разработки софта.

G>А изюминка в чем? Не просветишь старого?

Это песня! Это поэта! Это крик души менеджера, который "" традиционные спецификации и технологии типа ISO9000, поскольку полностью в них разочаровался

На самом деле я тоже кое-что из этого применял на практике и весьма успешно. Самая лучшая идея — активнго включить заказчика в процесс. Надо только сделать это очень ненавязчиво и как-бы естественным путем. Это тоже непросто. Я сумел пару раз это сделать и оба раза было то что надо. Но, большое но! Я работал над проектами в одиночку.

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

G>Не будь таким прямолиненйным. Ты сам проповедуешь гибкость, а тут взялся за буковедство. Ты смотри между строк что написано. вот попробуй сам попедалить в паре с кем-нибудь, пописать один и тот же модуль. И я готов спорить что через 2 дня вы готовы будете глотки друг другу грызть. И не надо юлить с фразами о непонимании и неприятии философских концепций хр. Нет там никаких концепций.

Кныжку пачытай, даа? Если команда состоит исключительно из ***, считающих себя ***, то да, будут грызть. Отстреливаешь их, набираешь нормальных. Работа в паре — естественный процесс, который в нормальных группах часто возникает стихийно. Надо принять критическое или неочевидное решение — позвал другого, объяснил ему, либо он подсказал, либо сам, объясняя понял.

G>Я не верю что я это читаю! Удивить мир. Извини, старик, но ты мне представляешся юношей с гарящим взглядом, собирающимся завтра заткнуть за пояс микрософт с помощью написанной тобой программулины.
А иначе, как бы, и смысла нет... Иначе проще сидеть в кАнторе, лабать на 1С и ждать пятницы.

G>Как показывает практика гараздо проще управлять одним архитектором, чем десятью программерами, думающими что они архзитекторы и тулящими всякую лабуду.
Менеджер пконтролировать архитектора не может практически никогда. Все, что он может — дать ему ***лей если к моменту сдачи выясниться, что он наархитектурил. Но будет уже поздно...
Десять программеров контролируют друг друга. Для этого и парное программирование и общее владение кодом. Во-первых, ты не напишешь явную каку если рядом сидит камрад с бейсбольной битой, во-вторых, если кака все-таки проникла, то кто угодно может 1. ее исправить 2. найти и исправить того, кто ее написал.

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


INT>Кныжку пачытай, даа? Если команда состоит исключительно из ***, считающих себя ***, то да, будут грызть. Отстреливаешь их, набираешь нормальных. Работа в паре — естественный процесс, который в нормальных группах часто возникает стихийно. Надо принять критическое или неочевидное решение — позвал другого, объяснил ему, либо он подсказал, либо сам, объясняя понял.

Ага, то есть еще не каждый человек может в пареработать? Никтог не спорит что с командой звезд управится тяжелее, чем с "нормальными" (а кстати что ты имеешь в виду под этим? кто это такие нормальные?) И как ты можешь сам принять неочевидное решение? Оно же неочевидно.

INT>А иначе, как бы, и смысла нет... Иначе проще сидеть в кАнторе, лабать на 1С и ждать пятницы.

Смысл есть. Все-таки программирвоание — это инженерная деятельность и тут нужен прагматизм. На одном энтузиазизьме далеко не уедешь. Без здравого и холодного волчьего расчета любое начинание обречено. Почему так? Да потому что есть много объективных факторов, так или иначе влияющих на процесс разработки. То есть я не против энтузиастов. Но мне не нравится идея о пионерах, строящих коммунизм.

INT>Менеджер пконтролировать архитектора не может практически никогда. Все, что он может — дать ему ***лей если к моменту сдачи выясниться, что он наархитектурил. Но будет уже поздно...
INT>Десять программеров контролируют друг друга. Для этого и парное программирование и общее владение кодом. Во-первых, ты не напишешь явную каку если рядом сидит камрад с бейсбольной битой, во-вторых, если кака все-таки проникла, то кто угодно может 1. ее исправить 2. найти и исправить того, кто ее написал.

Никого 10 программеров не контролируют. Им крупно на все посрать, кроме самих себя. Вот ответь мне на такой вопрос. Есть у тебя некая система. в ней Н модулей. Всеми этими модулями владеют все. предположим модуль Х не работает? С кого спросить, кого заставить его доделывать? Мы то объективно с тобой, старичела, понимаем, что нельзя знать весь код проекта( это к пункту 1 ). То есть идея о том, что кадый программер знает всю систему — это фикция. Вот и ответь мне — как распределяется отвественность за работу если нет четкой иерархической структуры во ввереном тебе отделении. К пункту 2 — а если тот кто ее написал уволился. И че тогда? ДА, тот кт ос ним рядом сидел имеет представление о том, как работает модуль, но с вероятностью 0.9 он может быфть не согласен в некоторых (а то и в большенстве) аспектов его реализации. что тогда будет? А документации-то нету. Нет никакого нормального проектирования. что будем делать? Или ты утверждаешь что хр позволяет программить сразу на все 100 без ошибок?

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

G>Ага, то есть еще не каждый человек может в паре работать? Никтог не спорит что с командой звезд управится тяжелее, чем с "нормальными" (а кстати что ты имеешь в виду под этим? кто это такие нормальные?) И как ты можешь сам принять неочевидное решение? Оно же неочевидно.

Да, в паре могут работать только вменяемые программисты. Т.е. те, кто хотя-бы в принципе может работать с другими людьми.

G>Смысл есть. Все-таки программирвоание — это инженерная деятельность и тут нужен прагматизм. На одном энтузиазизьме далеко не уедешь. Без здравого и холодного волчьего расчета любое начинание обречено. Почему так? Да потому что есть много объективных факторов, так или иначе влияющих на процесс разработки. То есть я не против энтузиастов. Но мне не нравится идея о пионерах, строящих коммунизм.

Подумай над идеей пионеров, строящих карьеру. Которым интересно не отсиживать 8 часов и изображать деятельность, чтобы не уволили, а делать успешные проекты и учиться эффективно работать.

G>Никого 10 программеров не контролируют. Им крупно на все посрать, кроме самих себя.

Я уже говорил. Ключевые слова — вменяемость и отстрел. Либо они сами фиксят код и отстреливают невменяемых, либо получают про***ое время вместо ценного опыта, заваленный проект и массовый расстрел в конечном итоге.

G>Вот ответь мне на такой вопрос. Есть у тебя некая система. в ней Н модулей. Всеми этими модулями владеют все. предположим модуль Х не работает? С кого спросить, кого заставить его доделывать?
Мы то объективно с тобой, старичела, понимаем, что нельзя знать весь код проекта( это к пункту 1 ). То есть идея о том, что кадый программер знает всю систему — это фикция. Вот и ответь мне — как распределяется отвественность за работу если нет четкой иерархической структуры во ввереном тебе отделении. К пункту 2 — а если тот кто ее написал уволился. И че тогда? ДА, тот кт ос ним рядом сидел имеет представление о том, как работает модуль, но с вероятностью 0.9 он может быфть не согласен в некоторых (а то и в большенстве) аспектов его реализации. что тогда будет? А документации-то нету. Нет никакого нормального проектирования. что будем делать? Или ты утверждаешь что хр позволяет программить сразу на все 100 без ошибок?

Ну прочитай ты книжку. Разумеется, каждое изменеие в коде должно фиксироваться — кто, когда, что, почему. Знаешь такую штуку — CVS?
И весь код с которым ты имеешь дело знать нужно. Если про какой-то кусок кода неизвестно, что он должен делать — то это баг, и его надо исправлять. Если известно, что должен, но он делает не то, — баг, исправлять. Если внутри этого куска ничего нельзя пофиксить — предупреждение автору, переписывание, в крайнем случае — выкидывание и отстрел.

XP предполагает не то, что код сразу безошибочен. Он предполагает, что весь код сразу исправлябелен.

Кстати, старичелла пишется через два "л".

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


INT>Да, в паре могут работать только вменяемые программисты. Т.е. те, кто хотя-бы в принципе может работать с другими людьми.

Я могу руб за сто дать, что подавляющее большенство вменяемых программеров не захотят сидеть на одном компе и педалить один и тот же кусок кода с другим вменяемым программером. Просто потому что это противоречит здравому смыслу. Вменяемость тут ни при чем


INT>Подумай над идеей пионеров, строящих карьеру. Которым интересно не отсиживать 8 часов и изображать деятельность, чтобы не уволили, а делать успешные проекты и учиться эффективно работать.

Да я сам такой


INT>Я уже говорил. Ключевые слова — вменяемость и отстрел. Либо они сами фиксят код и отстреливают невменяемых, либо получают про***ое время вместо ценного опыта, заваленный проект и массовый расстрел в конечном итоге.

Старик, вот ради интереса, попробуй поработать год за одним компом с одним и тем же человеком. клянусь тебе, ты взвоешь. Даже при том что по отдельности вы оба "вменяемы". Но есть такая вещь, как усталость друг от друга. Всегда будут мелкие дрязги и несросты. А это накапливается и в конечном итоге выливается в то, что каждый тянет одеяло на себя. А для того чтобы этого не было надо предоставить каждому человекумаленькое, но свое собсвтенное, поле для деятельности. И насчет "вменяемости". вот как ты, беря человека на работу, измеришь эту самую "вменяемость"? А отсреливать, как ты говоришь — так ты затрахаешся народ набирать. А года чел приходит в уже идущий прожект ( скажем месяцев 10-12) сколько времени ему надо въехать в ВЕСЬ код? Прикинь, а, на досуге.


INT>Ну прочитай ты книжку. Разумеется, каждое изменеие в коде должно фиксироваться — кто, когда, что, почему. Знаешь такую штуку — CVS?
INT>И весь код с которым ты имеешь дело знать нужно. Если про какой-то кусок кода неизвестно, что он должен делать — то это баг, и его надо исправлять. Если известно, что должен, но он делает не то, — баг, исправлять. Если внутри этого куска ничего нельзя пофиксить — предупреждение автору, переписывание, в крайнем случае — выкидывание и отстрел.

А при чем тут CVS. И какое это имеет отношение к тому что програмер знает все о коде прожекта. А если про какой-то кусок кода не известно что он делает так это не баг — это нормальное состояние. Тебе, если ты его не пишешь а просто юзаешь, нужно об этом куске знать ровно столько сколько нужно для твоего куска, и не более того. Почему так — да потому что все знать невозможно. Крупно сомневаюсь, что програмеры из мс каждый знает всю винду и может все поправить. Вот ты стл юзаешь. А ты знаешь весь его код? И в состоянии поправить любой баг в нем, коли придется? Ваще с модулями которые ты не пишешь ты должен в идеале обращаться также как и со стандартными либами. то есть тебе нужен только интерфейс да приблизительное (подчеркиваю, приблизительное) представление о том, что этоткусок из себя представляет внутри. Подобный подход, по моемускромному мнению, влечет за собой следующее
1) хороший уровень абстаркции, так как ты рассматриваешь кусок не столько сквозь призму текущего рпоекта, сколько сквозь призму возможного будущего использования в будущих проектах. само собой не стоит класть производительность на алтарь универсальночти — все хорошо вмеру
2) вырабатывает привычку писать код, не надеясь на то, что если там будет бак то петя справа его поправит, а ориентируясь на создание законченного куска. Ты всю отвественность берешь на себя, полностью отвечаешь за свой кусок, но и не напрягаешся по чужим проблеммам.

INT>XP предполагает не то, что код сразу безошибочен. Он предполагает, что весь код сразу исправлябелен.

Любой код сразу исправлябелен — бери да исправляй.

INT>Кстати, старичелла пишется через два "л".

Правила форума почитай, брателллллла (заметь, нет точки в конце предложения и неприлично много л в слове — можешь еще один плюс в пользу моей безграмотности там у себя поставить)

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

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

RTFM. И относительно всего остального тоже. XP имеет смысл если брать его целиком.

G>Крупно сомневаюсь, что програмеры из мс каждый знает всю винду и может все поправить. Вот ты стл юзаешь. А ты знаешь весь его код? И в состоянии поправить любой баг в нем, коли придется?

Весь код не знаю. Но знаю, что он делает. И смогу пофиксить исходники если он это делает не так.

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

INT>Здравствуйте, Glоbus, Вы писали:

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

INT>RTFM. И относительно всего остального тоже. XP имеет смысл если брать его целиком.

Да хот ьцеликом хоть оп частям — хр это аномалия наздорового мозга. прожетк крупнее порносайта из 10 страничек завалится однозначно.

G>>Крупно сомневаюсь, что програмеры из мс каждый знает всю винду и может все поправить. Вот ты стл юзаешь. А ты знаешь весь его код? И в состоянии поправить любой баг в нем, коли придется?

INT>Весь код не знаю. Но знаю, что он делает. И смогу пофиксить исходники если он это делает не так.

Вот видишь как замечательно! То есть не надо "владеть" каждому программеру всем кодом. Просто достаточно чтобы тебе предоставили нужную функциональность. А пофиксить баги можно и изучив код в случае крайней необходимости, как ты сам и сказал выше. А если не надо чтобы каждый программер владел всем кодом, то зачем ему зазря напрчгаться — пусть владеет своим куском и хотябы удовлитворительно его документирует.

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


G>Никого 10 программеров не контролируют. Им крупно на все посрать, кроме самих себя. Вот ответь мне на такой вопрос. Есть у тебя некая система. в ней Н модулей. Всеми этими модулями владеют все. предположим модуль Х не работает?
XP это не только парное программирование и коллективное владение кодом .

есть еще постоянная интреграция и модульные тесты. поэтому не бывет не работающего или глючного кода — есть тесты котрые не срабатывают.
и есть ежедневная интергация всех модулей . сответсвенно если Вася Пупкин сломал модуль это выяснится
при поломке модульных тестов, а затем — или тот кто сломал чинит (определяем виновника через CVS), или откатывется назад.


G>С кого спросить, кого заставить его доделывать? Мы то объективно с тобой, старичела, понимаем, что нельзя знать весь код проекта( это к пункту 1 ). То есть идея о том, что кадый программер знает всю систему — это фикция. Вот и ответь мне — как распределяется отвественность за работу если нет
G>четкой иерархической структуры во ввереном тебе отделении. К пункту 2 — а если тот кто ее написал уволился. И че тогда? ДА, тот кт ос ним рядом сидел имеет представление о том, как работает модуль, но с вероятностью 0.9 он может быфть не согласен в некоторых (а то и в большенстве) аспектов его реализации. что тогда будет?
G>А документации-то нету.
Почему нету ? а те же тесты ? или вы свою документацию постоянно обновляете и синхронизируете с изменеиями?
и она всегда на 100% соответсвует коду?

Сколько себя помню из всех билиотек, исходников и тд — документация _без_ примеров мало помогала...
а вот при толковых примерах(тестах), порой и документация была не нужна...

вот изменил кто-то модуль и уволился — а документации нет. И чего делать?
А в XP его работу без теста не примут. и на функциональное тестирование не допустят.


G>Нет никакого нормального проектирования. что будем делать?
и проектирование там есть, только вместо Крутой Проги Для Диаграмм — ручка и бумага.
А смысл такой-же. Или на бумаге рисовать это ненормально?

G>Или ты утверждаешь что хр позволяет программить сразу на все 100 без ошибок?
Модульные тесты позволяют писать без ошибок. Если, конечно, сначала тесты писать а потом код.

в XP по-моему 11 ключевых практик, вы выдернули две и давай высмеивать, —
как в том анекдоте Re[15]: Ну и поганый певец этот ваш Карузо

Автор: basis
Дата: 27.02.04

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

D_T>Здравствуйте, Glоbus, Вы писали:


D_T>XP это не только парное программирование и коллективное владение кодом .
D_T>есть еще постоянная интреграция и модульные тесты. поэтому не бывет не работающего или глючного кода — есть тесты котрые не срабатывают.
D_T>и есть ежедневная интергация всех модулей . сответсвенно если Вася Пупкин сломал модуль это выяснится
D_T>при поломке модульных тестов, а затем — или тот кто сломал чинит (определяем виновника через CVS), или откатывется назад.

Ага. уже лучше. То есть все-таки вася пупкин за что-то отвечает. А когда их двое за компом — кто будет чинить? Кто из них че писал?


D_T>Почему нету ? а те же тесты ? или вы свою документацию постоянно обновляете и синхронизируете с изменеиями?
D_T>и она всегда на 100% соответсвует коду?

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

D_T>Сколько себя помню из всех билиотек, исходников и тд — документация _без_ примеров мало помогала...
D_T>а вот при толковых примерах(тестах), порой и документация была не нужна...

А кто ж спорит — я тоже за примеры.

D_T>вот изменил кто-то модуль и уволился — а документации нет. И чего делать?
D_T>А в XP его работу без теста не примут. и на функциональное тестирование не допустят.

А я так скажу. Вот написал модуль и по тестам не прогнал. И тоже уволился. Ты уважаемый постоянно исходишь из того что все процедуры хр выполняются а класичского проектирвоания нет. почему так. почему чел не может в cvs залить кусок с багом в таком глубоком месте, которое обнаружится только на "предельных режимах работы". То ест ьможно сказать что тесты вскроют этот просчет, но тесты невсеобъемлющи. Даже программулина уже средней сложности является автоматом с таким количеством (хотя и конечным) числом состоянийб что ВСЕ потестить удастся врядли.


D_T>и проектирование там есть, только вместо Крутой Проги Для Диаграмм — ручка и бумага.
D_T>А смысл такой-же. Или на бумаге рисовать это ненормально?

Не понял к чему ты это. Я ваще сам пользую и бумагу, и case-средства и я кажется нигде не говорил что проектирование на бумаге сакс а на компе рулез. И тем более мне вдвойне удивительно что ты видишь в этом какую-то разницу.

D_T>Модульные тесты позволяют писать без ошибок. Если, конечно, сначала тесты писать а потом код.

Вах! Ну зачем такую каку говорить. Если быть формалистом, т описать без ошибок нельзя. Даже бог при сотворении мира много ошибался, чтож говорить о человеке. Насколько я понял ты имеешь в виду что постоянная прогонка тестов позволяет выявить ошибки на ранних стадиях.
Да и ваще, че тут говорить.
Давай, старик, лучще возьмем аналогии из других инженерных отраслей (просто потмоу что програминг это точно такая же инжереная деятельность как и многие другие). Я вот например ни в одном проектном институте не видл 2-х инженеров за одной чертежной доской, и при этом чтобы они постоянно то, что начертили тестили тут же. В том изаключается ценность инженера как работника, что он работает головой, а не руками. Например когда разрабатывают самолеты, опытных моделей строят в ходе всех многолетних работ штук 5 — не более того. И этого количества вполне хватает чтобы все проверить и оттестить на завершающем этапе. То же самое влюбой другой отрасли — постройка тестовго экземпляра и его тестирование слишком дорогое удольствие, чтобы это можно было делать каждый день. Так вот, к чему все гутарится. А гутарится к тому, что хр в первую голову плох тем, что вырабатывает плохой подход. Он отучивает планироват ьсвои действия и думать. Ваще настоящий программер должен 75% времени сидет ьс бумажкой. сейчас же тенденция такова, что 90% времени — это тячаянный, временами бездумный педалинг, а потом отчаянное исправление багов. хр ставит такую ситуаху во главу угла что по сути неверно, как мне кажется

D_T>в XP по-моему 11 ключевых практик, вы выдернули две и давай высмеивать, —
D_T>как в том анекдоте Re[15]: Ну и поганый певец этот ваш Карузо

Автор: basis
Дата: 27.02.04

Ну давайте, сладкие мои, обратимся к первоисточнику.
здесь

Автор(ы): Кент Бек

Эта книга об экстремальном программировании.
Экстремальное программирование, часто обозначаемое аббревиатурой «XP», — это упрощенная методика
организации производства для небольших и средних по размеру команд разработчиков,
занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся
требований. Данная книга предназначена для того, чтобы помочь вам определить,
оправдано ли применение XP в вашей ситуации или нет.

Смотрим в конец страницы и видим там комментарии с обильным цитированием.
Читаем

Если проектирование — это хорошо, значит проектирование надо сделать составной частью повседневной работы каждого участника проекта

Да вы что? А вот у нас в роекте дизигнер есть — он тоже будет проектирвоанием заниматься? Или технический писатель?

Если пересмотр архитектуры, это хорошо, значит мы будем пересматривать архитектуру постоянно.

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

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

Интересно, как можно писать тесты для того, архитектура чего постоянно меняется? чтоже проверять ? Получается что 50% времени мы пишем тесты, потом мочим их и пишем заново. Очень эффективно.

Если общение между членами команды важно, используем программирование парами программистов. Общение делаем непрерывным!

Вот от этого я в атасе. А почему тройками не сажать? Или четверками. Тогда общение огого как повысится.

Если небольшие итерации это хорошо, необходимо сделать итерации очень маленькими — секунды, минуты, может быть, часы

Какие итерации. Что итерирукем?

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

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


G>

G>Если тестирование — это хорошо, каждый участник проекта будет заниматься тестированием постоянно, а кодирование начинать с написания тестов для тестирования будущего кода.

G>Интересно, как можно писать тесты для того, архитектура чего постоянно меняется? чтоже проверять ? Получается что 50% времени мы пишем тесты, потом мочим их и пишем заново. Очень эффективно.

Можно попробовать так:
.....
OrderData order = new OrderData(....);
orderDeployer.createOrder(order);
OrderData loadedOrder = orderDeployer.getOrder(order.getId());
assertEquals(order, loadedOrder);
.....
ИМНО этому тесту без разницы, какая архитектура находится за Facade.

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

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

AVM>Здравствуйте, Glоbus, Вы писали:


G>>

G>>Если тестирование — это хорошо, каждый участник проекта будет заниматься тестированием постоянно, а кодирование начинать с написания тестов для тестирования будущего кода.

G>>Интересно, как можно писать тесты для того, архитектура чего постоянно меняется? чтоже проверять ? Получается что 50% времени мы пишем тесты, потом мочим их и пишем заново. Очень эффективно.

AVM>Можно попробовать так:
AVM>.....
AVM>OrderData order = new OrderData(....);
AVM>orderDeployer.createOrder(order);
AVM>OrderData loadedOrder = orderDeployer.getOrder(order.getId());
AVM>assertEquals(order, loadedOrder);
AVM>.....
AVM>ИМНО этому тесту без разницы, какая архитектура находится за Facade.

AVM>Понятно, что любую идею можно довести до абсурда и начать менять интерфейсы подсистем каждый день, но:
AVM>- ни разу не слышал, чтобы в рамках XP рекомендовалось это делать;
AVM>- методологии методологиями, но здравый смысл они не должны отменять.

Во! Здравый смысл! Вот и я про это. Если каждый должен заениматься тестированием то как, дизигнер тоже тестить будет?

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

AVM>>Понятно, что любую идею можно довести до абсурда и начать менять интерфейсы подсистем каждый день, но:
AVM>>- ни разу не слышал, чтобы в рамках XP рекомендовалось это делать;
AVM>>- методологии методологиями, но здравый смысл они не должны отменять.

G>Во! Здравый смысл! Вот и я про это. Если каждый должен заениматься тестированием то как, дизигнер тоже тестить будет?

Давай вместе попробуем, с позиции здравого смысла, подумать как software designer может заниматся тестированием.

Вот здесь можно почитать краткую историю возникновения TQM (http://archive.expert.ru/oborud/01/09-01/data/tema2.htm).
Коротко идея такая, чтобы получить 100-процентное качество сложной системы, компонененты этой системы тоже должны иметь 100-процентное качество.
(Под 100-процентным качеством, имеется ввиду что какие то заданные параметры, лежат в пределах определенных допусков).
Соответственно, чтобы гарантировать качество ПО, надо стремится к качественному дизайну.

Далее есть стандарт ISO 9... (к сожалению не помню на вскидку номер, но не 9000) называется типа так "Характеристики качества программных систем". В этом стандарте описывается набор характеристик, которые используются для оценки качества ПО.
В нем можно посмотреть, какие из характеристик можно использовать для оценки качества дизайна системы.
Например, такая характеристика — простота использования фабрики классов для создания графических примитивов. Характеристика достаточно абстрактная, но тем не менее....
Как ее проверить, написать пару тройку Unit-тестов, для различных вариантов интерфейсов фабрики и собраться обсудить с коллегами, какой из вариантов более предпочтителен. (Тут же как "побочный" результат, сразу получается и пример использования фабрики).

Остается один момент- решить, кто должен писать эти тесты, IMHO software designer, как говорится сам напроектировал, сам и проверяй.

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


AVM>Давай вместе попробуем, с позиции здравого смысла, подумать как software designer может заниматся тестированием.

AVM>Вот здесь можно почитать краткую историю возникновения TQM (http://archive.expert.ru/oborud/01/09-01/data/tema2.htm).
AVM>Коротко идея такая, чтобы получить 100-процентное качество сложной системы, компонененты этой системы тоже должны иметь 100-процентное качество.
AVM>(Под 100-процентным качеством, имеется ввиду что какие то заданные параметры, лежат в пределах определенных допусков).
AVM>Соответственно, чтобы гарантировать качество ПО, надо стремится к качественному дизайну.

AVM>Далее есть стандарт ISO 9... (к сожалению не помню на вскидку номер, но не 9000) называется типа так "Характеристики качества программных систем". В этом стандарте описывается набор характеристик, которые используются для оценки качества ПО.
AVM>В нем можно посмотреть, какие из характеристик можно использовать для оценки качества дизайна системы.
AVM>Например, такая характеристика — простота использования фабрики классов для создания графических примитивов. Характеристика достаточно абстрактная, но тем не менее....
AVM>Как ее проверить, написать пару тройку Unit-тестов, для различных вариантов интерфейсов фабрики и собраться обсудить с коллегами, какой из вариантов более предпочтителен. (Тут же как "побочный" результат, сразу получается и пример использования фабрики).

AVM>Остается один момент- решить, кто должен писать эти тесты, IMHO software designer, как говорится сам напроектировал, сам и проверяй.

Брат ))) под словом дизигнер я понимал дизигнера, рисующего иконки и картинки )))) Софтваре дизигнер конечно же участвует в тестировании, тут и вопросов быть не может.

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

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


AVM>>Давай вместе попробуем, с позиции здравого смысла, подумать как software designer может заниматся тестированием.

AVM>>Вот здесь можно почитать краткую историю возникновения TQM (http://archive.expert.ru/oborud/01/09-01/data/tema2.htm).
AVM>>Коротко идея такая, чтобы получить 100-процентное качество сложной системы, компонененты этой системы тоже должны иметь 100-процентное качество.
AVM>>(Под 100-процентным качеством, имеется ввиду что какие то заданные параметры, лежат в пределах определенных допусков).
AVM>>Соответственно, чтобы гарантировать качество ПО, надо стремится к качественному дизайну.

AVM>>Далее есть стандарт ISO 9... (к сожалению не помню на вскидку номер, но не 9000) называется типа так "Характеристики качества программных систем". В этом стандарте описывается набор характеристик, которые используются для оценки качества ПО.
AVM>>В нем можно посмотреть, какие из характеристик можно использовать для оценки качества дизайна системы.
AVM>>Например, такая характеристика — простота использования фабрики классов для создания графических примитивов. Характеристика достаточно абстрактная, но тем не менее....
AVM>>Как ее проверить, написать пару тройку Unit-тестов, для различных вариантов интерфейсов фабрики и собраться обсудить с коллегами, какой из вариантов более предпочтителен. (Тут же как "побочный" результат, сразу получается и пример использования фабрики).

AVM>>Остается один момент- решить, кто должен писать эти тесты, IMHO software designer, как говорится сам напроектировал, сам и проверяй.

G>Брат ))) под словом дизигнер я понимал дизигнера, рисующего иконки и картинки )))) Софтваре дизигнер конечно же участвует в тестировании, тут и вопросов быть не может.

Ну а в чем проблемы то? Designer (UI-designer) делает несколько наборов иконок, картинок. Потом просит представителя заказчика оценить наколько эти иконки картинки понятны конечным пользователям, по результатам оценки принимается решение, какие оставить, какие доработать, какие вообще убрать и тд.
Понятно, что тут оценка может быть очень субъективная, но тем не менее она есть. Разве это нельзя назвать тестированием?

PS: Ни в одном материале о XP, я не встречал мыслей о том что designers должны писать unit — тесты. Каждый занимается своим делом.....

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


G>>Брат ))) под словом дизигнер я понимал дизигнера, рисующего иконки и картинки )))) Софтваре дизигнер конечно же участвует в тестировании, тут и вопросов быть не может.

AVM>Ну а в чем проблемы то? Designer (UI-designer) делает несколько наборов иконок, картинок. Потом просит представителя заказчика оценить наколько эти иконки картинки понятны конечным пользователям, по результатам оценки принимается решение, какие оставить, какие доработать, какие вообще убрать и тд.
AVM>Понятно, что тут оценка может быть очень субъективная, но тем не менее она есть. Разве это нельзя назвать тестированием?

Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?
И что значит твоя фраза применительно к понятию тестирования

AVM>Понятно, что тут оценка может быть очень субъективная, но тем не менее она есть.

Тестирование на то и тестирвоание, чтобы сравнить объективные ожидаемые результаты с тем, что есть. Если график функции sin(x) должен принимаеть значения в диапозоне [-1..1] то это объективная реальность, с которой надо считаться. И никакой субъективизм тут недопустим. Именно поэтому обсуждалово иконок это не тестирование и в этом пункте ты явно сказал невпопад. Просто не надо притягивать за уши вещи которые не нужны. Тестировать ПО должны:
1) программеры
2) тестеры
3) в некотором роде сам архитектор или (софтваре)дизигнер этого дела


AVM>PS: Ни в одном материале о XP, я не встречал мыслей о том что designers должны писать unit — тесты. Каждый занимается своим делом.....

Цитата отсюда

Автор(ы): Кент Бек

Эта книга об экстремальном программировании.
Экстремальное программирование, часто обозначаемое аббревиатурой «XP», — это упрощенная методика
организации производства для небольших и средних по размеру команд разработчиков,
занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся
требований. Данная книга предназначена для того, чтобы помочь вам определить,
оправдано ли применение XP в вашей ситуации или нет.

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

Как это понимать? Или нам еще нужны толкователи учения Самого Любимого и Простого Бека? Только я тебя прошу, христа ради, не говори мне что я неверно понял или еще чтото. Это техническая литература. Тут каждое слово имеет вес и я вижу то что вижу и ничего больше. Поэтому не будем заниматься толкованием пророчеств Великого Экстримала.

ЗЫ Кстати, честно, любопытно просто ( не то чтобы я хотел наехать, у нас ведь научная дискусия — если я там груб был ты уж прости ), вот ты отстаиваешь хр, а там где ты работаешь оно применяется во всей своей красоте, вы пишете в парах, вы ваши продукты постоянно готовы к сдаче, каждый из вас разбирается во всем коде прожекта?

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

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



G>>>Брат ))) под словом дизигнер я понимал дизигнера, рисующего иконки и картинки )))) Софтваре дизигнер конечно же участвует в тестировании, тут и вопросов быть не может.

AVM>>Ну а в чем проблемы то? Designer (UI-designer) делает несколько наборов иконок, картинок. Потом просит представителя заказчика оценить наколько эти иконки картинки понятны конечным пользователям, по результатам оценки принимается решение, какие оставить, какие доработать, какие вообще убрать и тд.
AVM>>Понятно, что тут оценка может быть очень субъективная, но тем не менее она есть. Разве это нельзя назвать тестированием?

G>Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?
G>И что значит твоя фраза применительно к понятию тестирования
Ну вы блин даете ! (c)

а если серьезно,
— установи требование, например, не менее 70% конечных пользователей должны безошибочно определить, что обозначает та или иная иконка.
— опиши процедуру, как будет происходить проверка "узнаваимости" иконок пользователями (разрешение монитора, глубина цвета, с какого расстояния и под каким углом смотрят на монитор, тип освещения в помещении и тд).
— задокументируй все это и обзови как хочешь, типа перетиралово и обсуждалово с клиентом иконок, я бы назвал это "Требования к usability ПО и методика их тестирования", смысл не меняется — мы установили какие то параметры и проверяем удовлетворяет ли наш продукт (иконки) этим параметрам.
Заметь, я не призываю делать это в каждом проекте. Это просто попытка поиллюстрировать, как можно тестировать элементы UI, в рамках методологии XP.

AVM>>Понятно, что тут оценка может быть очень субъективная, но тем не менее она есть.

G>Тестирование на то и тестирвоание, чтобы сравнить объективные ожидаемые результаты с тем, что есть. Если график функции sin(x) должен принимаеть значения в диапозоне [-1..1] то это объективная реальность, с которой надо считаться. И никакой субъективизм тут недопустим. Именно поэтому обсуждалово иконок это не тестирование и в этом пункте ты явно сказал невпопад. Просто не надо притягивать за уши вещи которые не нужны. Тестировать ПО должны:
G>1) программеры
G>2) тестеры
G>3) в некотором роде сам архитектор или (софтваре)дизигнер этого дела
Как ты считаешь, надо ли вообще тестировать usability ПО ? Если надо, то приведи плз набор метрик, которые позволят сказать что usability, например этого форума, лежит в диапазоне [0.5..689] ?
0.5 и 649 — значения метрик, которые ты предложишь.

AVM>>PS: Ни в одном материале о XP, я не встречал мыслей о том что designers должны писать unit — тесты. Каждый занимается своим делом.....

G>Цитата отсюда

Автор(ы): Кент Бек

Эта книга об экстремальном программировании.
Экстремальное программирование, часто обозначаемое аббревиатурой «XP», — это упрощенная методика
организации производства для небольших и средних по размеру команд разработчиков,
занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся
требований. Данная книга предназначена для того, чтобы помочь вам определить,
оправдано ли применение XP в вашей ситуации или нет.

G>

G>Если тестирование — это хорошо, каждый участник проекта будет заниматься тестированием постоянно, а кодирование начинать с написания тестов для тестирования будущего кода.

Если тебя интересует, что именно Бек (переводчики) вкладывал в эту цитату — напиши ему, его мыло должно быть в книге.

G>Как это понимать? Или нам еще нужны толкователи учения Самого Любимого и Простого Бека? Только я тебя прошу, христа ради, не говори мне что я неверно понял или еще чтото. Это техническая литература. Тут каждое слово имеет вес и я вижу то что вижу и ничего больше. Поэтому не будем заниматься толкованием пророчеств Великого Экстримала.

Вот тут предлагаю включить Здравый смысл. Если переформулировать вот так:

Если тестирование — это хорошо, каждый участник проекта будет заниматься тестированием, а разработку начинать с написания тестов (методик тестирования), проверяющих результат его работы.

Имеется в виду, что каждый участник команды, как минимум как то оценивает результаты СВОЕГО труда.

G>ЗЫ Кстати, честно, любопытно просто ( не то чтобы я хотел наехать, у нас ведь научная дискусия — если я там груб был ты уж прости ), вот ты отстаиваешь хр, а там где ты работаешь оно применяется во всей своей красоте, вы пишете в парах, вы ваши продукты постоянно готовы к сдаче, каждый из вас разбирается во всем коде прожекта?

Да ладно, ничего личного

По поводу XP — я не отстаиваю эту методологию, не защищаю ее, не молюсь на нее и тд, просто в ней есть много интересных идей, которые мы (ты и я) используем в своей работе каждый день.
Я просто предлагаю посмотреть на XP c различных сторон. Например, как UI-designer может использовать постулаты XP в своей работе.

По поводу использования мною XP — нет не используем, не по причине того что она очень плоха, или очень хороша для нас, просто у нас на фирме..... ну в общем не используем

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

А я думаю, что отдельные товарищи представляют себя эдакими всемогущими мудрыми старцами архитекторами, по велению перста которых твориться история. А XP выбивает у них почву из под ног

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


AVM>Да ладно, ничего личного

AVM>По поводу XP — я не отстаиваю эту методологию, не защищаю ее, не молюсь на нее и тд, просто в ней есть много интересных идей, которые мы (ты и я) используем в своей работе каждый день.
AVM>Я просто предлагаю посмотреть на XP c различных сторон. Например, как UI-designer может использовать постулаты XP в своей работе.

AVM>По поводу использования мною XP — нет не используем, не по причине того что она очень плоха, или очень хороша для нас, просто у нас на фирме..... ну в общем не используем

Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить) Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально. На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.

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

MS>На самом деле я тоже кое-что из этого применял на практике и весьма успешно. Самая лучшая идея — активнго включить заказчика в процесс. Надо только сделать это очень ненавязчиво и как-бы естественным путем. Это тоже непросто. Я сумел пару раз это сделать и оба раза было то что надо. Но, большое но! Я работал над проектами в одиночку.


Я прям себя узнаю. Сначала он самозабвенно планы рисует, что надо и что ему не надо просто в журнале прочел и в кино посмотрел, программированию учит, рассказывает что у них все не так как у других. А потом как-то так в русло сотрудничества переходит, он придумывает, я придумываю. Прикольно получается. Тут только такт нужен и не реагировать на наезды. Тогда через какое-то время все устаканивается.

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

G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить) Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально. На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.

А вы сейчас Unit-тесты используете ?
Представитель заказчика на ранних этапах участвует в проекте ?
Итерации какую длительность примерно имеют ?

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

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


AVM>>Да ладно, ничего личного

AVM>>По поводу XP — я не отстаиваю эту методологию, не защищаю ее, не молюсь на нее и тд, просто в ней есть много интересных идей, которые мы (ты и я) используем в своей работе каждый день.
AVM>>Я просто предлагаю посмотреть на XP c различных сторон. Например, как UI-designer может использовать постулаты XP в своей работе.

AVM>>По поводу использования мною XP — нет не используем, не по причине того что она очень плоха, или очень хороша для нас, просто у нас на фирме..... ну в общем не используем

G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно). ( Слава богу, у меня одно время был свой прожект , в котором я мог от этого отвалить)

Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!

G>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.

Потому что вы не использовали парное программирование.

G>На любые замечания о том что нехило бы документацию составить, очертить круг задач и определить, кто же за что отвечает, следовали ответы что это напрасная трата времени и педалить надо — типа цигель = бабло. Сейчас работаю в конторе, применяющей классичкеский подход к проектированию и разработке, которому меня учили еще в институте. Могу сказать что это небо и земля. Эффективность каждого члена команды при четко очерченых границах и поставленных тербованиях повышается в разы по сравнению с подходами из хр.

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

G>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно).

Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.

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

S>Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!

Насколько я знаю, апологеты ХР как раз утверждают, что практики ХР самоценны и в отрыве друг от друга и совсем необязательно использовать их все одновременно. Тем более очевидно, что внедрение всех практик одновременно сродни пожару по способности дезорганизовать рабочий процесс.

G>>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.

S>Потому что вы не использовали парное программирование.

Причём тут парное программирование? Речь ведь идёт о разных подходах к планированию и ведению проектной документации.

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

S>>Если вы не использовали хотя бы одну практику XP — вы не использовали XP совсем!

G>Насколько я знаю, апологеты ХР как раз утверждают, что практики ХР самоценны и в отрыве друг от друга и совсем необязательно использовать их все одновременно. Тем более очевидно, что внедрение всех практик одновременно сродни пожару по способности дезорганизовать рабочий процесс.

В том-то и дело что нет. Или все или это жалкое подобие XP с деорганизованностью и бардаком.

G>>>Могу тебе авторитетно заявить — полнейший бардак. Даже на проектах средней сложности чувствуется полное отсутвие генеральной линии партии, а замена документации тестами приводит к полнейшей неразберихе. После ухода чела, который вел какой-нибудь кусок, разгерстись в нем было практически нереально.

S>>Потому что вы не использовали парное программирование.

G>Причём тут парное программирование? Речь ведь идёт о разных подходах к планированию и ведению проектной документации.

К тому, что при парном программировании с частым сменом пар и коллективным владением кодом все участники проекта
успевают по работать со всем кодом. По меньшей мере, с одними участками кода работали как минимум два человека, так
что уход одного к катастрофе приводить не должен. Обе эти практики были нарушены в вышеописанном проекте.
Цитирую "После ухода чела, который вел какой-нибудь кусок..." В XP проекте нет чела, который ведет кусок кода.
Все отвечают за весь код. Цитирую еще раз "руководство которой применяло хр (за исключением программирования в парах" —
парного программирования не было.

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


G>Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?

Почитай книжку про UI Design http://www.uibook1.ru/ (она тама в пдф). там очень внятно рассказывается про дизайн и тестирование UI. И если ты считаешь что тестирование UI это только "обсуждение иконок с заказчиком" то ты глубоко ошибаешься.

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

FT>Здравствуйте, Glоbus, Вы писали:


G>>Нет, это не тестирование в том смысле в котором его понимаю я как программер. Тестирование — это процесс аналица работоспосбности чего-либо и выявления ошибок. А обсуждение иконок с заказчиком это перетиралово и обсуждалово с клиентом. Или ты реально не видешь разницы между тестирвоанием ПО и обсуждением иконок с заказчиком?

FT>Почитай книжку про UI Design http://www.uibook1.ru/ (она тама в пдф). там очень внятно рассказывается про дизайн и тестирование UI. И если ты считаешь что тестирование UI это только "обсуждение иконок с заказчиком" то ты глубоко ошибаешься.

Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?

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

INT>Здравствуйте, Glоbus, Вы писали:

G>>Вот. А я работал раньше в конторе, руководство которой применяло хр (за исключением программирования в парах, мать его так! — хотя пыталиьс одних товарищей посадить на одну машину — они просидели недели две, пока не оказалось что их кпд равно нулю при таких раскладах — не потому что они тупые, а потому что работать так невозможно).

INT>Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.

Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".

INT>Если уж совсем трудно — то можно писать одному, но при занесении кода в CVS кто-то должен посмотреть на код и согласиться в ним. И в CVS пишется, кто проверял это изменение и он также несет за него ответственность. В том числе, получает премиальные за количество добавленных с его участием фич

Кто-то это кто? Какой чин? Статский советник аль колежский асессор? И что значит количество добавленных с его участием фич? Каких фич? откуда взялись? Сам придумал или кто подсказал? И нужны ли они были? И не портят ли архитектуру?
То есть я лично усматриваю в том что ты пишешь старик явное тяготение к бардаку и работе "с наскоку" — подход, применяемый прыщавыми студентами при сдаче лабораторных.

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

G>Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?

Да. т.к. у нас руководитель дизайнерсой группы — человек имеющий большой опыт в промышленном дизайне и имеющий степерь по психологии. И я счиьаю что такой подходоправдан — т.к. у нас ни разу не возникало проблемм с заказчиком по поводу интерфейса продукта.

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


S>К тому, что при парном программировании с частым сменом пар и коллективным владением кодом все участники проекта
S>успевают по работать со всем кодом. По меньшей мере, с одними участками кода работали как минимум два человека, так
S>что уход одного к катастрофе приводить не должен. Обе эти практики были нарушены в вышеописанном проекте.
S>Цитирую "После ухода чела, который вел какой-нибудь кусок..." В XP проекте нет чела, который ведет кусок кода.
S>Все отвечают за весь код. Цитирую еще раз "руководство которой применяло хр (за исключением программирования в парах" —
S>парного программирования не было.

Дорогой ты мой человек! Вот давай откинемся на спинку стула и раслаблено проанализируем что нам сулит хр как стиль ведения прожекта, и что нам сулит классический подход
1) отсутсвие внятной документации, все что есть инкапсулируется в тестах. А через 4 года когда нужно будет поднять проект и разобратсья в нем в, дорогой товарищ, сможете по тестам описать мне архитектуру системы?
в тоже самое время классический подход ратует за чательное документирвоание на бумаге или где бы то ни было

2) программирвоание в парах и постоянная их ротация, с целью сделать каждого участника прожекта носителем абсолютного знания о нем. Но это же абсурдно — по своей природе человек не может знать и помнить всего — для того бумага и нужна. Более того — размывается ответсвенность и начинается тыкание пальцем — это он посоветовал, а этот кусок не я делал и тп
Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией. И фразы о том что составление документации слишком длительный и муторный процесс тоже суть полный бред. Если посомтреть внимательно на брукса и его человеко-месяц то явно видно что они там бумажками не брезговали. И системы они писали в сотню раз сложнее, чем каждый из здесь спорящих.

3) активное вовлечение заказчика в процесс разработки. Очень знакомая ситуаха. На моей предыдущей работе наш менеджмент одного вовлек в мой прожект и очень об этом пожалел. Во многих случаях заказчик может быть абсолютно некомпетентен, но на своем видении того или иного момента он будет ой как наставивать. И придется сделать так как он сказал, даже если это глупо — не все заказчиуки вменяемы, а денюжку он платит. Класический же подход предлагает разработку четкого списка требований к системе, включая возможные будущие изменения и дополнения, что позволяет реализовать всю систему максимально гибко. Хр же со своей постоянной готовностью прожекта к сдаче заставляет жить сегодняшним днем, что само по себе херово в любой инженерной деятельности.

Это только первое что в голову приходит. Я уж не говорю о фразах типа "каждый участник проекта чакствует в его тестировании" И чт омне мой дизайнер натестирует?
Так что пусть архитектуру придумывают архитекторы, дизигнеры рисуют иконки и всякую цветастую лабуду, а программеры пишут и тестирую свой — и только свой! — код.

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

FT>Здравствуйте, Glоbus, Вы писали:

G>>Юзабилити UI и дизигн UI в смысле иконок ЭТО разные вещи, об этмо я говорю. Или у вас в конторе дизайнеры рисуют интерфейс со всем контролами и тп?

FT>Да. т.к. у нас руководитель дизайнерсой группы — человек имеющий большой опыт в промышленном дизайне и имеющий степерь по психологии. И я счиьаю что такой подходоправдан — т.к. у нас ни разу не возникало проблемм с заказчиком по поводу интерфейса продукта.

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

ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.

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

G>ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.

Сорри з небольшой офтоп но все-таки. про пренебрежение к психологии как аналогию могу привести игры переведенные профессиональными программистами
если человек занимаетс зазработкой интерфейса(не только компуретного UI а вообще) то, хлтя-бы основы прикладной психологии знать надо т.к. UI должен дыть функционально удобным и _НРАВИТСЯ ПОЛЬЗОВАТЕЛЯМ_. Причем 2ое обычно важнее(как замеченно из моей практики).Особенно если это mass production.

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

FT>Здравствуйте, Glоbus, Вы писали:

G>>ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.

FT>Сорри з небольшой офтоп но все-таки. про пренебрежение к психологии как аналогию могу привести игры переведенные профессиональными программистами
FT>если человек занимаетс зазработкой интерфейса(не только компуретного UI а вообще) то, хлтя-бы основы прикладной психологии знать надо т.к. UI должен дыть функционально удобным и _НРАВИТСЯ ПОЛЬЗОВАТЕЛЯМ_. Причем 2ое обычно важнее(как замеченно из моей практики).Особенно если это mass production.

Нравится/не нравится, красиво/некрасиво — это вопрос вкуса. Тут психология не поможет никак.
Все дизигнеры с которыми я работал были технарями и без знаний психологии затыкали за пояс товарищей из художетсвенных вузов. Просто потмоу что как и в любой художетсвенной деятельности тут главное чутье. А его еще ни психология, ни что другео не формализовало еще. Да и ваще к психологии трудно отностистся как к науке. Там исключений больше чем правил.

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

INT>>Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.

G>Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".

простая логика подсказывает что "индусский" код как раз и пишут в одиночку и подольше стараются никому не показывать, бо в паре засмеют тут-же — после первой же строчки.

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

G>Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией.

хм, у меня явно другой опыт — никакая "бамажка" в плане пониманию программы и рядом не стоит с собственноручным опытом что-нить в эту программу добавить. Может с "бамажками" не везло

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

G>а программеры пишут и тестирую свой — и только свой! — код.

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

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

OE>Здравствуйте, Glоbus, Вы писали:

G>>Да и ваще — то что парное программирование способствует сохранению информаци о проекте и хорошему понимаю его частей участвниками — это фикция. ничто не заменит бамажки с хорошей документацией.

OE>хм, у меня явно другой опыт — никакая "бамажка" в плане пониманию программы и рядом не стоит с собственноручным опытом что-нить в эту программу добавить. Может с "бамажками" не везло

весьма вероятно

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

OE>Здравствуйте, Glоbus, Вы писали:

G>>а программеры пишут и тестирую свой — и только свой! — код.

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

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

OE>Здравствуйте, Glоbus, Вы писали:

INT>>>Кстати, в описании XP прямо сказано, что пары не должны быть постоянными. Хватаешь того, кто попался под руку — и понеслась.

G>>Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".

OE>простая логика подсказывает что "индусский" код как раз и пишут в одиночку и подольше стараются никому не показывать, бо в паре засмеют тут-же — после первой же строчки.

не поделишся с убогим своими простыми логичискими измышлениями? а то мне просто кажется что хр предназначен для контор яростно желающих заработать мульён не вкладывая бабла — то есть можно посадить двух товарищей на один комп и попытаться сделать прогу не создавая сколь-нибудь пристойной документации. А так как индия страна бедная то для них этот подход весьма приемлем, а теперь, когда еще и книжки по нему пишут, то ваще можно и не сомневаться в правильности организации работы.

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

G>>>Ага, клевый подход. То есть может где-нибудь в индии именно так и пишут, а потом русские товарищи спрашивают "покажите индусский код, мы посмеемся".

OE>>простая логика подсказывает что "индусский" код как раз и пишут в одиночку и подольше стараются никому не показывать, бо в паре засмеют тут-же — после первой же строчки.

G>не поделишся с убогим своими простыми логичискими измышлениями?

отчегож, могу еще раз — пока чел пишет код в одиночку он может наваять всего чего угодно в меру своего усердия и понимания и смеяться над этим "индусским" кодом ты будешь уже потом, постфактум. Если же он начнет лепить всякую фигню при работе в паре с тобой, ты его сразу тормознешь и укажешь ему на то, какая он редиска, а скорее всего он и сам постесняется так писать, зная что рядом кто-то постоянно на экран смотрит, таким образом "индусский" код в данном случае вообще не появится

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

давай не будем в валить в одну кучу "индусский" код, документацию и "заработать мульён не вкладывая бабла", про "индусский" код моя логика понятна?

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

OE>Здравствуйте, Glоbus, Вы писали:


OE>отчегож, могу еще раз — пока чел пишет код в одиночку он может наваять всего чего угодно в меру своего усердия и понимания и смеяться над этим "индусским" кодом ты будешь уже потом, постфактум. Если же он начнет лепить всякую фигню при работе в паре с тобой, ты его сразу тормознешь и укажешь ему на то, какая он редиска, а скорее всего он и сам постесняется так писать, зная что рядом кто-то постоянно на экран смотрит, таким образом "индусский" код в данном случае вообще не появится


OE>давай не будем в валить в одну кучу "индусский" код, документацию и "заработать мульён не вкладывая бабла", про "индусский" код моя логика понятна?

Не совсем понятен следующий момент — зачем мне сидет сложа руки и тулится в экран товарища и еще следить зха тем как он пишет? Это че, детский сад? Вопросами кадровой политики и проф пригодности должны заниматься товарищи манагеры на этапе приема на работу — тестовые задания и тп. Не хочу я контролировать чужой код, дай ему бог здоровья! Мне за это не платят и во многих случаях я не способен этого сделать хотя бы потмоу что мой уровень может не дотягивать до человека, которого я контролирую. То, что с моей точки зрения глупость, может оказхаться мегагибким и неочевидным решением. И пока я буду с ним спорить вместо того чтобы работать, цигель будет уходить вместе с денюжкой.
А насчет не валить в одну кучу индусский код документацию и мульён это ты зря. Безудержное желание заработать мульён поскорее приваодит к отсутсвию документации и как следствие индусскомцу коду.

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

G>ЗЫ Знаешь, вот реально опыт в промышленном дизигне производит впечатление, а вот степень по психологии нет. У меня просто как у васякого технаря легкое пренебрежение к гуманетарным товарищам. А к психологам особенно.

Не надо распространять свое личное мнение на всех "технарей".

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


L>Не надо распространять свое личное мнение на всех "технарей".

То есть любишь психологов?

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

Тебе сюда

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?


скоро не только в москве будет. потому что msdn сказала "будем": Improve the Design and Flexibility of Your Project with Extreme Programming Techniques

по моему на rsdn видел статью с тем же конклюжн