Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте bkat, Вы писали:
B>>Вопрос к знатокам XP. B>>Имеются ли рекомендации по тому, как оценивать команду разработчиков, B>>на соответствие XP. Грубо говоря, хотелось бы почитать о методиках, B>>которые бы выдавали нечто типа: B>>- Команда Х выполняет требования XP на 100%; B>>- Команда Х выполняет требования XP на 50%;
DG>Вот такого как раз нет, потому что я опять же напоминаю, что XP(в чистом виде) тоже не панацея, и ее надо комбинировать с другими типами разработки, а вот эта комбинация и есть субъективное дело команды.
Есть у меня подозрения, что если XP комбинировать с другими методологиями,
то от XP ничего не останется (ну разве только Pair Programming).
Т.е. я для себя рассматриваю XP, как популяризацию других методологий.
В этом и есть ценность XP (а может наоборот вред?).
Здравствуйте bkat, Вы писали:
B>Есть у меня подозрения, что если XP комбинировать с другими методологиями, B>то от XP ничего не останется (ну разве только Pair Programming).
Все тот же Кент Бек рекомендует (особенно на начальных этапах) использовать только часть рекомендаций XP, при этом, конечно, предупреждая, что при таком обращение с XP может получится ничего хорошего.
B>Т.е. я для себя рассматриваю XP, как популяризацию других методологий. B>В этом и есть ценность XP (а может наоборот вред?).
В XP открытым текстом во введение написано, что они используют обычные методики, но доведенные до экстремальной степени,
т.к. если тестировать — хорошо, то давайте — тестировать все и как можно чаще,
если укороченный срок разработки — хорошо, то давайте сократим его до нескольких месяцев/недель
и т.д.
Здравствуйте bkat, Вы писали:
CS>>XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
B>Изменение требований на проекте не имеет ничего общего с экстремальностью.
Имеет, в том смысле, что экстремальность — это возможная степень таких изменений.
B>Это обычная практика и с этим просто нужно уметь жить. B>Те команды, которые с этим не справляются, как правило имеют очень большие проблемы. B>На мой взгляд, управление требованиями — это ключевой момент во всей разработке. B>Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
Ну, я полагаю, как раз подобные проблемы и явились одними из причин возникновения XP. Кроме того, именно для проблемных проектов и есть смысл внедрять XP. Ведь если все и так хорошо, то зачем, вообще, что-то менять?
...
DG>Тем что XP говорит, давайте сначала сделаем это по простому, а как я зделаю, это просто, если у меня уже жестко прошит интерфейс.
Умение решать сложные проблемы с помощью простых решений — вот, на мой взгляд, признак гениальности в любой области (ведь все гениальное — просто). Причем простота характеризует не суть явления, а его форму, то как явление воспринмается нами. Если отбросить очевидные решения (а именно отсутствие очевидных решений делает проблему проблемой) и погрузиться в самую суть проблемы, изучить ее на самом фундаментальном уровне, то обязательно появятся оригинальные и простые ее решения. Вот так я думаю.
Что же касается конкретной проблемы с "жестко прошитым интерфейсом", использование которого приводит к ненужному усложнению кода, могу порекоммендовать следующее. Создать "прослойку", это может быть класс, модуль, компонент или что-то еще, которая бы, используя вызовы исходного интерфейса, реализовывала новый, упрощенный (более высоко уровневый, более специализированный) его вариант. Специально для решения подобного рода проблем существует ряд шаблонов проектирования (design patterns) — facade, proxy, stairway to heaven.
...
DG>Вот возьмем класс CString, какой у него должен быть набор методов, как он должен быть устроен, насколько просто его надо реализовать и т.д. Даже наличие пары пользователей никак нам не поможет в реализации этого класса.
Сам по себе класс CString никому не нужен. Но вместе с MFC (я так понял он оттуда), пожалуй пригодится. Поэтому и рассматривать его надо в контексте MFC. А из этого следует, что, во-первых, нам нужны пользователи не класса, а всей среды в целом. И, во-вторых, интерфейс класса CString будет определяться нуждами всей среды. Но каково назначение этой среды, и какое место в нем занимает класс CString? Подобный анализ достоин ученой степени, а может и чего похуже :))!
...
DG>Не только, тот же Кент Бек — делает очень большой акцент на то, что команда должна очень много общаться, и при говорит, что при отсутствии общения многие приемы из XP, начинают развалится... А какое может быть общение по e-mail-у.
Не вижу ничего плохого в общении по "мылу". Даже есть свои плюсы — вырабатывается более четкое мышление. Кроме того есть еще и телефон!
...
DG>Я не говорю, что все не применимо, я говорю, что XP надо применять с оглядкой, DG>тот же тестинг, рефакторинг, "небольшие релизы" — я приветствую и использую, DG>"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
А еще лучше и простыми, и замкнутыми!
DG>"подключить заказчика" — это хорошо, но на практике обычно сложно получается реализовать,
Проблема в том, что если не удастся, то программисту придется самому стать специалистом в предметной области задачи. Конечно, если продуктом является некая среда разработки (framework или набор библиотек), то программист, будучи программистом, уже является таким специалистом. Но в случае прикладных задач, по-моему, все же проще запросить специалиста.
DG>"системная метафора" — я скорее придерживаюсь подхода, что программа должна быть просто последовательна, а метафора — это уже вторично (так я видел жутко неудобные программы, использующие метафоры, так и удобные программы, которые не используют какие-либо метафоры, хотя, "программа под windows" — это уже метафора, а "консольная программа под unix" — это уже другая метафора.
Ну, не думаю что "программа под windows" это метафора. Метафора подразумевает аналогию. Если я использую метафору "рабочий стол", то я могу делать с ним то же, что и настоящим столом. Предполагается, что работать с метафорой проще, поскольку человек использует знания о реальном объекте. Но на самом деле, вся компьтерная терминология, лишь кажется метафорической, тогда как является скорее идиоматической. Насколько поможет мне знание о реальном рабочем столе в работе с "рабочим столом" в windows? Да, по-моему, вообще не поможет. Но вот если я уже изучил как работает пользовательский интерфейс в windows... то тогда, простая и знакомая терминология весьма и весьма удобная штука.
А "Системная метафора" XP является скорее языком, на котором общаются разработчики с заказчиками и пользователи с программой. А как можно общаться "последовательно" без языка?
DG>"программирование в парах" — трудно реализуема на практике, т.к. добиться того, чтобы обоим людям было интересно(и продуктивно) работать в паре — очень сложно, т.к. равных людей не бывает, и в паре, обычно, более "активный"(умный, волевой) задавливает второго, которому остается только кивать гивой и иногда вставлять фразу: "а ты здесь забыл поставить точку с запятой"
Проблемы, конечно же, есть. Но не смотря на это ведь работает же! По-моему, у программистов работающих в одиночестве, просто отрафируется способность к деловому общению, а эту способность надо развивать и поддерживать.
...
DG>Программирование сверху, предполагает, что у нас есть жесткий (более и менее) каркас, который мы заполняем, а XP (в чистом виде) — говорит, что не надо ни какого каркаса, ни надо ничего проектировать, а давайте сделаем первую версию, как можно проще (как у нас получится), потом еще что-нибудь добавим, а дальше, куда кривая вылезет, поэтому XP(опять же в чистом виде) очень плохо уживается с этапом проектирования.
Что такое каркас программы? По-моему это и есть "системная метафора"!
А разве XP плохо уживается с проектированием? Просто XP предлагает не проектировать всю систему целиком и в деталях сразу, а делать это постепенно, при этом начав реализацию как можно раньше.
...
B>Это не совсем правила. Это общие рекомендации. B>Возмем, например, "Подключение заказчика". B>Как вы его будете подключать? Как конкретно он будет участвовать на проекте? B>Чтобы ответить на эти вопросы, нужны уже конкретные правила(процедуры), B>которым следует команда разработчиков. B>Самое сложное как раз выработать эти правила, B>чтобы они действительно вели к реальному участию заказчика. B>Можно очень активно общаться с заказчиком, и все же забыть о "мелочи", B>которую он очень просил реализовать.
B>К чему я веду? B>К тому, что XP и другие подобные методологии худо-бедно описывают цели, B>но как к ним идти — это очень большой вопрос.
Я бы сказал так: XP выдает общие рекомендации, следование которым будет гарантировать ряд приемуществ.
B>Вопрос к знатокам XP. B>Имеются ли рекомендации по тому, как оценивать команду разработчиков, B>на соответствие XP. Грубо говоря, хотелось бы почитать о методиках, B>которые бы выдавали нечто типа: B>- Команда Х выполняет требования XP на 100%; B>- Команда Х выполняет требования XP на 50%;
А зачем это нужно?
Одно из правил XP гласит: Если XP не работает, то исправь его сам (Fix XP when it breaks).
Благодаря этому правилу очень сложно выявить процент использования XP :)).
Здравствуйте ChainSmoker,
CS>XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
Вот прямо как у нас ситуация только есть пара проблем: документации мы не пишем вообще — времени нет, парное программирование не принято — ресурсов не хватает, рефакторинг не делаем — нет времени, денег и желания, с заказчиками не общаемся — кто б нам такое позволил, тесты не пишем — нет времени, зато есть отдельная организация, которая нашо барахло тестирует. Вот это — реалии жизни и изменить что-то не получиться, поскольку пока что фирма зарабатывает деньги и менеджеры не видят надобности в изменении бизнес-процессов.
CS>Кроме того, XP носит скорее эволюционный характер, чем революционный. Т.е. хотя есть кое-что полностью новое, многое адаптировано из уже существующего. Но главное — это акцентирование внимания на экстремальности сегодняшних условий.
Вот тут неделю назад был в Дублине на призентации от фирмы Rational. И оказывается они знают что такое XP, а ещё они на него внимания не обращают, поскольку как показывает их практика, существуют и другие более эффективные методики.
Здравствуйте ChainSmoker,
DG>>2. библиотек (нет заказчика)
CS>Ну кто-то же будет их использовать. А значит будет если не заказчик-покупатель, то хотя бы заказчик-пользователь.
Реализайия framework, например, по технологии XP невозможна. Надо сначала всё спроектировать, а потом уж за компьютер браться.
DG>>Тем что XP говорит, давайте сначала сделаем это по простому, а как я зделаю, это просто, если у меня уже жестко прошит интерфейс.
CS>Умение решать сложные проблемы с помощью простых решений — вот, на мой взгляд, признак гениальности в любой области (ведь все гениальное — просто). Причем простота характеризует не суть явления, а его форму, то как явление воспринмается нами. Если отбросить очевидные решения (а именно отсутствие очевидных решений делает проблему проблемой) и погрузиться в самую суть проблемы, изучить ее на самом фундаментальном уровне, то обязательно появятся оригинальные и простые ее решения. Вот так я думаю.
CS>Что же касается конкретной проблемы с "жестко прошитым интерфейсом", использование которого приводит к ненужному усложнению кода, могу порекоммендовать следующее. Создать "прослойку", это может быть класс, модуль, компонент или что-то еще, которая бы, используя вызовы исходного интерфейса, реализовывала новый, упрощенный (более высоко уровневый, более специализированный) его вариант. Специально для решения подобного рода проблем существует ряд шаблонов проектирования (design patterns) — facade, proxy, stairway to heaven.
CS>...
DG>>Вот возьмем класс CString, какой у него должен быть набор методов, как он должен быть устроен, насколько просто его надо реализовать и т.д. Даже наличие пары пользователей никак нам не поможет в реализации этого класса.
CS>Сам по себе класс CString никому не нужен. Но вместе с MFC (я так понял он оттуда), пожалуй пригодится. Поэтому и рассматривать его надо в контексте MFC.
Я имел ввиду абстрактный класс строки, который есть в любом языке программирования, в любой библиотеке...
CS>А из этого следует, что, во-первых, нам нужны пользователи не класса, а всей среды в целом. И, во-вторых, интерфейс класса CString будет определяться нуждами всей среды. Но каково назначение этой среды, и какое место в нем занимает класс CString? Подобный анализ достоин ученой степени, а может и чего похуже !
Так вот и вопрос, как с применением XP писать такие классы?
DG>>Не только, тот же Кент Бек — делает очень большой акцент на то, что команда должна очень много общаться, и при говорит, что при отсутствии общения многие приемы из XP, начинают развалится... А какое может быть общение по e-mail-у.
CS>Не вижу ничего плохого в общении по "мылу". Даже есть свои плюсы — вырабатывается более четкое мышление. Кроме того есть еще и телефон!
Плохо, в том, что e-mail — это очень медленный и трудозатратный способ общения.
Телефон — тоже не выход, дорого, не возможно (по крайней мере в России) делать конференции (одновременное общение нескольких участников)
DG>>Я не говорю, что все не применимо, я говорю, что XP надо применять с оглядкой, DG>>тот же тестинг, рефакторинг, "небольшие релизы" — я приветствую и использую, DG>>"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
CS>А еще лучше и простыми, и замкнутыми!
Часто, это взаимоисключающие вещи.
DG>>"подключить заказчика" — это хорошо, но на практике обычно сложно получается реализовать,
CS>Проблема в том, что если не удастся, то программисту придется самому стать специалистом в предметной области задачи. Конечно, если продуктом является некая среда разработки (framework или набор библиотек), то программист, будучи программистом, уже является таким специалистом. Но в случае прикладных задач, по-моему, все же проще запросить специалиста.
DG>>"системная метафора" — я скорее придерживаюсь подхода, что программа должна быть просто последовательна, а метафора — это уже вторично (так я видел жутко неудобные программы, использующие метафоры, так и удобные программы, которые не используют какие-либо метафоры, хотя, "программа под windows" — это уже метафора, а "консольная программа под unix" — это уже другая метафора.
CS>Ну, не думаю что "программа под windows" это метафора. Метафора подразумевает аналогию. Если я использую метафору "рабочий стол", то я могу делать с ним то же, что и настоящим столом. Предполагается, что работать с метафорой проще, поскольку человек использует знания о реальном объекте. Но на самом деле, вся компьтерная терминология, лишь кажется метафорической, тогда как является скорее идиоматической. Насколько поможет мне знание о реальном рабочем столе в работе с "рабочим столом" в windows? Да, по-моему, вообще не поможет. Но вот если я уже изучил как работает пользовательский интерфейс в windows... то тогда, простая и знакомая терминология весьма и весьма удобная штука.
CS>А "Системная метафора" XP является скорее языком, на котором общаются разработчики с заказчиками и пользователи с программой. А как можно общаться "последовательно" без языка?
Аналогии, часто бывают губительны, т.к. каждый по своему проецирует оригинал на аналогию.
А язык общения лучше строить самим из понятных обоим сторонам кирпичиков, главное чтобы такой язык был последовательным.
DG>>"программирование в парах" — трудно реализуема на практике, т.к. добиться того, чтобы обоим людям было интересно(и продуктивно) работать в паре — очень сложно, т.к. равных людей не бывает, и в паре, обычно, более "активный"(умный, волевой) задавливает второго, которому остается только кивать гивой и иногда вставлять фразу: "а ты здесь забыл поставить точку с запятой"
CS>Проблемы, конечно же, есть. Но не смотря на это ведь работает же! По-моему, у программистов работающих в одиночестве, просто отрафируется способность к деловому общению, а эту способность надо развивать и поддерживать.
DG>>Программирование сверху, предполагает, что у нас есть жесткий (более и менее) каркас, который мы заполняем, а XP (в чистом виде) — говорит, что не надо ни какого каркаса, ни надо ничего проектировать, а давайте сделаем первую версию, как можно проще (как у нас получится), потом еще что-нибудь добавим, а дальше, куда кривая вылезет, поэтому XP(опять же в чистом виде) очень плохо уживается с этапом проектирования.
CS>Что такое каркас программы? По-моему это и есть "системная метафора"!
Не совсем, "каркас программы" говорит, что у нас есть такие-то классы, у них есть такие-то методы, они вот так взаимодействуют между собой,
CS>А разве XP плохо уживается с проектированием?
Если подходит творчески (не в лоб) — то хорошо.
CS> Просто XP предлагает не проектировать всю систему целиком и в деталях сразу, а делать это постепенно, при этом начав реализацию как можно раньше.
Здесь я с тобой полностью согласен, но для этого надо заставить разработчиков писать код, в котором стоимость изменений от объема кода растет не экспонециально, а линейно.
...
M.NET>Вот прямо как у нас ситуация только есть пара проблем: документации мы не пишем вообще — времени нет, парное программирование не принято — ресурсов не хватает, рефакторинг не делаем — нет времени, денег и желания, с заказчиками не общаемся — кто б нам такое позволил, тесты не пишем — нет времени, зато есть отдельная организация, которая нашо барахло тестирует. Вот это — реалии жизни и изменить что-то не получиться, поскольку пока что фирма зарабатывает деньги и менеджеры не видят надобности в изменении бизнес-процессов.
Одно из основных приемуществ XP — это учет, экономия времени. А у вас по каждому пункту, "нет времени", да "времени нет". Может как раз пора переходить на XP ? Ведь главное не то, зарабатываем мы деньги или нет, а то можно ли зарабатывать больше!
...
M.NET>Вот тут неделю назад был в Дублине на призентации от фирмы Rational. И оказывается они знают что такое XP, а ещё они на него внимания не обращают, поскольку как показывает их практика, существуют и другие более эффективные методики.
XP явный конкурент Rational, а на западе критиковать конурентов не принято (анти-реклама — лучшая реклама ), на них просто не обращают внимания!
А вот насчет более эффетивных методик хотелось бы узнать по-подробнее, ведь XP не панацея все-таки!
Здравствуйте ChainSmoker,
CS>Одно из основных приемуществ XP — это учет, экономия времени. А у вас по каждому пункту, "нет времени", да "времени нет". Может как раз пора переходить на XP ? Ведь главное не то, зарабатываем мы деньги или нет, а то можно ли зарабатывать больше!
Знаешь поговорку "Лучше синица в руках, чем утка под кроватью"?
CS>XP явный конкурент Rational, а на западе критиковать конурентов не принято (анти-реклама — лучшая реклама ), на них просто не обращают внимания!
Какой конкурент? Смеёшься что ли? Rational вообще-то очень даже уважаемая компания с огромным оборотом, а вот XP — это методика, которую выработала некая группа, скорее всего та же самая что поддерживает идею открытых проектов. И то и другое вызывет сомнения, когда дело доходит до зарабатывания денег.
CS>А вот насчет более эффетивных методик хотелось бы узнать по-подробнее, ведь XP не панацея все-таки!
Rational пропагандирует идею автоматизации программирования, утверждают, что некоторые их клиенты снизили количество ручного написания кода на 90%. А это серьёзно. Потому у нас сейчас наметился переход к подобной же системе.
CS>XP явный конкурент Rational, а на западе критиковать конурентов не принято (анти-реклама — лучшая реклама ), на них просто не обращают внимания!
XP не конкурент Rational. У каждого просто своя ниша.
Прошу прощения за сравнение, но разве ВАЗ конкурент Мерседесу? А наоборот?
Ну разве что с большой натяжкой.
Чем ответственнее и серьезнее проект, тем меньше шансов у XP.
Т.е. конечно, благодаря правилу "Fix XP when it breaks",
которое тобой же и было упомянуто, под XP можно натянуть все что угодно,
но тогда смысла в этом особого нет.
Методика, которая не имеет устойчивых основ, по сути бесполезна.
...
CS>>Сам по себе класс CString никому не нужен. Но вместе с MFC (я так понял он оттуда), пожалуй пригодится. Поэтому и рассматривать его надо в контексте MFC.
DG>Я имел ввиду абстрактный класс строки, который есть в любом языке программирования, в любой библиотеке...
Определение интерфейса, и тем более реализации, для класса, без рассмотрения среды его использования, слишком абстрактная задача. Абстрактная в том смысле, что потребует изучения всех возможных вариантов реализаций всех возможных сред. Тут и Эйнштейн, будь он программистом, сел бы в лужу :)
CS>>А из этого следует, что, во-первых, нам нужны пользователи не класса, а всей среды в целом. И, во-вторых, интерфейс класса CString будет определяться нуждами всей среды. Но каково назначение этой среды, и какое место в нем занимает класс CString? Подобный анализ достоин ученой степени, а может и чего похуже :))!
DG>Так вот и вопрос, как с применением XP писать такие классы?
Рекомендации XP распространяются на подобные задачи в виде общего подхода — сначала пишем тесты, не делаем ничего лишнего, следуем принятым стандартам кода и т.д. А определение интерфейса и его реализации — это на личное усмотрение программиста.
...
DG>>>"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
CS>>А еще лучше и простыми, и замкнутыми!
DG>Часто, это взаимоисключающие вещи.
Чем же они могут взаимоисключаться? Лично я ничего не вижу.
...
CS>>А "Системная метафора" XP является скорее языком, на котором общаются разработчики с заказчиками и пользователи с программой. А как можно общаться "последовательно" без языка?
DG>Аналогии, часто бывают губительны, т.к. каждый по своему проецирует оригинал на аналогию.
Бывают и губительны, бывают и бесполезны. Но без метафоры никуда не денешься — ведь гораздо удобнее говорить "папки" размещаются на "рабочем столе", чем нечто вроде "хрямзели" располагаются на "хрюмзеле" :).
DG>А язык общения лучше строить самим из понятных обоим сторонам кирпичиков, главное чтобы такой язык был последовательным.
Что значит последовательный? Как определить, последовательный или нет?
...
CS>>Что такое каркас программы? По-моему это и есть "системная метафора"!
DG>Не совсем, "каркас программы" говорит, что у нас есть такие-то классы, у них есть такие-то методы, они вот так взаимодействуют между собой,
Ну, это уже не каркас, а готовая программа!
...
CS>> Просто XP предлагает не проектировать всю систему целиком и в деталях сразу, а делать это постепенно, при этом начав реализацию как можно раньше.
DG>Здесь я с тобой полностью согласен, но для этого надо заставить разработчиков писать код, в котором стоимость изменений от объема кода растет не экспонециально, а линейно.
Ну, не обязательно заставлять, может они сами захотят!
Здравствуйте ChainSmoker, Вы писали:
DG>>Так вот и вопрос, как с применением XP писать такие классы?
CS>Рекомендации XP распространяются на подобные задачи в виде общего подхода — сначала пишем тесты, не делаем ничего лишнего, следуем принятым стандартам кода и т.д. А определение интерфейса и его реализации — это на личное усмотрение программиста.
CS>...
DG>>>>"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
CS>>>А еще лучше и простыми, и замкнутыми!
DG>>Часто, это взаимоисключающие вещи.
CS>Чем же они могут взаимоисключаться? Лично я ничего не вижу.
Но вот берем "окно" из windows-а. Если это был бы "замкнутый" объект, то его можно было бы копировать, передавать между процессами, создавать свои объекты окна и т.д.
Реализация всех этих вещей далеко не проста, но дальнейшее использование — было бы просто сказка, так как не надо было бы задумываться, в каких областях "окно", как полноценный объект не доделано.
CS>>>А "Системная метафора" XP является скорее языком, на котором общаются разработчики с заказчиками и пользователи с программой. А как можно общаться "последовательно" без языка?
DG>>Аналогии, часто бывают губительны, т.к. каждый по своему проецирует оригинал на аналогию.
CS>Бывают и губительны, бывают и бесполезны. CS>Но без метафоры никуда не денешься — ведь гораздо удобнее говорить "папки" размещаются на "рабочем столе", чем нечто вроде "хрямзели" располагаются на "хрюмзеле" :).
IMHO, без разницы, главное чтобы эти "хрямзели" и "хрюмзели" — хорошо "лежали" на языке. Так для меня намногое понятнее и менее путанные термины — "директория" и "десктоп", чем "папка" и "рабочий стол", при это мне не интересно, как эти слова переводятся на русский и что еще означают на английском.
DG>>А язык общения лучше строить самим из понятных обоим сторонам кирпичиков, главное чтобы такой язык был последовательным.
CS>Что значит последовательный? Как определить, последовательный или нет?
Это значит, что если из A следует B, то это должно быть всегда.
Второе определение, от обратного, чем меньше исключений, тем язык последовательнее.
CS>>>Что такое каркас программы? По-моему это и есть "системная метафора"!
DG>>Не совсем, "каркас программы" говорит, что у нас есть такие-то классы, у них есть такие-то методы, они вот так взаимодействуют между собой,
CS>Ну, это уже не каркас, а готовая программа!
Далеко нет!!! Если бы все обстояло так, как ты говоришь, то программисты давно бы вымерли и остались бы одни рисовальщики UML ;)
DG>>Здесь я с тобой полностью согласен, но для этого надо заставить разработчиков писать код, в котором стоимость изменений от объема кода растет не экспонециально, а линейно.
CS>Ну, не обязательно заставлять, может они сами захотят!
Для того чтобы человек что-нибудь захотел, его надо на это замотивировать, а как замотивировать программиста, которому положен оклад в месяц (без разницы, что он там понаписал), чтобы он писал код на будущее.
Второе "подводный" камень, это то, что правило "писать код с возможностью уменьшения дальнейших изменений" сильно противоречит правилу "писать как можно проще". Часто при написании новый фичи проще сделать Copy+Paste, но дальнейшее изменение(сопровождение) такого кода превращается в сущий ад...
...
CS>>Одно из основных приемуществ XP — это учет, экономия времени. А у вас по каждому пункту, "нет времени", да "времени нет". Может как раз пора переходить на XP :) ? Ведь главное не то, зарабатываем мы деньги или нет, а то можно ли зарабатывать больше!
M.NET>Знаешь поговорку "Лучше синица в руках, чем утка под кроватью"?
Ты это скажи финансистам. Не одна компания разлетелась в пух и прах только потому, что где-то что-то оказалось дешевле на пару центов.
CS>>XP явный конкурент Rational, а на западе критиковать конурентов не принято (анти-реклама — лучшая реклама :) ), на них просто не обращают внимания!
M.NET>Какой конкурент? Смеёшься что ли? Rational вообще-то очень даже уважаемая компания с огромным оборотом, а вот XP — это методика, которую выработала некая группа, скорее всего та же самая что поддерживает идею открытых проектов. И то и другое вызывет сомнения, когда дело доходит до зарабатывания денег.
Ну, большой оборот это еще не аргумент — XP проект не коммерческий, это не более (но и не менее), чем опыт одних программистов, изложенный в виде набора практик, для других программистов.
А что касается группы поддержки :), то вот одна из них — ObjectMentor, Inc. Кстати, не имеет никакого отношения к "халявным" проектам, и основана одним из ведущих спецов в области ОО программирования, Робертом Мартином.
CS>>А вот насчет более эффетивных методик хотелось бы узнать по-подробнее, ведь XP не панацея все-таки! M.NET>Rational пропагандирует идею автоматизации программирования, утверждают, что некоторые их клиенты снизили количество ручного написания кода на 90%. А это серьёзно. Потому у нас сейчас наметился переход к подобной же системе.
В чем же большая эффективность? Ведь все равно надо указывать какие будут классы и методы, атрибуты и взаимосвязи. Конечно, приемущества есть, но вот превосходят ли они те, которые дает XP, это вопрос!
Здравствуйте Mishka.NET, Вы писали:
CS>>Почему проектирование и XP несовместимы, хоть убей, но понять не могу!
M.NET>Поправь, если я не прав — по XP сначала пишем код, потом через рефакторинг получаем дизайн?
Очень большой вопрос. Процесс разработки — это стержень XP. На него "нанизаны" все его практики.
Но если коротко, то сначала проект, затем тест, код, и наконец рефакторинг. И так по кругу, начиная опять с проектирования, каждый раз когда, что-то собираемся писать, мы расширяем проект. Например, мы знаем, что у нас будет подсистема печати, но проектировать ее мы будем только когда дойдет время до ее реализации.
Здравствуйте bkat, Вы писали:
CS>>XP явный конкурент Rational, а на западе критиковать конурентов не принято (анти-реклама — лучшая реклама ), на них просто не обращают внимания!
B>XP не конкурент Rational. У каждого просто своя ниша. B>Прошу прощения за сравнение, но разве ВАЗ конкурент Мерседесу? А наоборот? B>Ну разве что с большой натяжкой.
Если есть выбор, то я предпочту мерседес .
А возможность выбора между XP (бесплатный), и Rational, по-моему, есть у всех.
B>Чем ответственнее и серьезнее проект, тем меньше шансов у XP. B>Т.е. конечно, благодаря правилу "Fix XP when it breaks", B>которое тобой же и было упомянуто, под XP можно натянуть все что угодно, B>но тогда смысла в этом особого нет. B>Методика, которая не имеет устойчивых основ, по сути бесполезна.
Каждая практика в XP, рассматривается с точки зрения ее полезности. А вы уж сами решайте нужно оно вам или нет. Вот полезность пресловутого правила "fix XP when it breaks", в том, чтобы люди были бдительными, и следили за своим процессом разработки и улучшали его, а не надеялись, что дядя Кент обо всем позаботился за них.
В целом, есть фундаментальные принципы, следуя которым можно успешнее
выполнять проекты. XP, процесс от Rational, SEI SW CMM, ISO — разные
взгляды (view) на одни и те же фундаментальные принципы.
Кому-то проще понять и применять эти принципы следуя XP,
кому-то — штудируя отчеты от SEI.
Это, наверное, основная причина, почему XP, Rational и пр... — не конкуренты.
А то что, кто-то на чем-то больше денег сделает — это уже вторично.
Ладно, это уже демогогия...
Все же полезнее обсуждать конкретные вещи, не смешивая их вместе.
Например, чем Pair Programming эффективнее review, которые планируются заранее
и к которым нужно спецально готовиться?
Здравствуйте bkat, Вы писали:
B>Все же полезнее обсуждать конкретные вещи, не смешивая их вместе. B>Например, чем Pair Programming эффективнее review, которые планируются заранее и к которым нужно спецально готовиться?
Я вообще не могу себе представить первого в принципе, хотя подозреваю, что для извращенцев в этом что-то есть. Кодирование — процесс личный, можно даже сказать интимный ;) и никто посторонний не должен касаться его своими грязными, волосатыми лапами. Другое дело результат кодинга, его можно и нужно представлять посторонним, при этом желательно заранее подготовиться.
Т.е. code review — благо, pair programming — зло.
;)
Если нам не помогут, то мы тоже никого не пощадим.
!
? Ведь главное не то, зарабатываем мы деньги или нет, а то можно ли зарабатывать больше!
Если нам не помогут, то мы тоже никого не пощадим.
