Лично я за.
Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике.
Уже более года, как я изучаю XP и пробую применять его принципы на практике.
Со своей стороны приведу комментарии к нескольким принципам.
Подключение заказчика (On-site Customer). Программа — это инструмент для решения определенных задач. Но кто, как не заказчик может лучше знать их специфику. А посему, подключим заказчика к процессу разработки. Пусть он будет под рукой когда программисту понадобится консультация, ведь потерянное время это его деньги. Пусть он будет в курсе событий и перестанет задавать вопросы типа: когда мы будем это иметь? Пусть он примет участие в принятии решений и разделив ответственность перестанет обвинять во всем программиста.
Небольшие релизы (Small Releases). Когда мы будем это иметь? Любой программист знает как сложно ответить на этот вопрос более менее точно. Оценить время на разработку релиза в целом очень сложно. Но вот если взять и разбить большой релиз на несколько маленьких, а задачи на каждый релиз детализировать до весьма небольших и легко прогнозируемых задач, то вполне можно не оплошаться с датой выхода релиза. В XP релиз состоит из 70-80 Итераций (Iteration), каждая из которых занимает 1-3 недели. Итерация реализует какую-то одну Историю Пользователя (User Story), которая является ни чем иным, как описанием некоей функции системы с точки зрения пользователя.
Не усложняйте проект (Simple Design). Зачем тратить время впустую, зачем делать то, что может никогда не понадобиться. Гораздо лучше оставить возможность расширения. Как это выглядит на практике? На мой взгляд в ОО программировании, существует лишь один безболезненный способ предусмотреть расширяемость — это реализовать наращиваемые сущности в виде иерархии классов. Например, если мы предполагаем, что в будущем некий набор операций может расшириться, то мы должны реализовать операции в виде иерархии классов, если же нет, то тогда можно использовать и стандартные типы или классы. В случае расширения все что нам надо, это добавить соответствующий подкласс.
Системная метафора (Metaphor). Системная метафора — это концепция системы, это используемая терминология, это платформа для общения между людьми, принимающими участие в разработке. Если уровень взаимодействия между людьми высок (а использование XP это предполагает), то системная метафора вам необходима как воздух.
Программируем вдвоем (Pair Programming). В основе этого принципа лежит сила общения. Хотя самому мне лишь изредка приходится работать в таком режиме (пока я не в силах это изменить ), доложу вам те приемущества, которые смог заметить:
— программист работает по 6 часов в день, и когда почти все это время он просиживает в одиночестве за компьтером — это утомляет, по-моему вдвоем гораздо веселей;
— взаимообучаемость;
— взаимозаменяемость;
— нет места халявщикам;
— и, как не странно, все это в итоге реально увеличивает производительность.
Начинай с тестов (Test-first Design). Тестирование — это не просто тестирование! Тест — это проект того кода, который мы собираемся написать. Как код будет использоваться? Именно на этот вопрос дает ответ тест. Кроме того, тест еще и прекрасная документация, не пресловутая спецификация, а живая, на примерах.
Рефакторинг (Refactoring). Совершенству нет предела, но хорошие идеи приходят не всегда и не сразу. Поэтому мы просто пишем код который выполняет то, что нам нужно. Если мы видим, что код можно улучшить, мы улучшаем его. Это и есть рефакторинг. Мы не сидим и не ждем вдохновения от бога, а просто делаем то, что на текущий момент является наилучшим вариантом. Завтра нас осенит и мы сделаем рефакторинг. Но надо иметь в виду, что без тестов рефакторинг может превратиться в геморрой.
...
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 предлагает не проектировать всю систему целиком и в деталях сразу, а делать это постепенно, при этом начав реализацию как можно раньше.
Здравствуйте bkat, Вы писали:
B>Все же полезнее обсуждать конкретные вещи, не смешивая их вместе. B>Например, чем Pair Programming эффективнее review, которые планируются заранее и к которым нужно спецально готовиться?
Я вообще не могу себе представить первого в принципе, хотя подозреваю, что для извращенцев в этом что-то есть. Кодирование — процесс личный, можно даже сказать интимный ;) и никто посторонний не должен касаться его своими грязными, волосатыми лапами. Другое дело результат кодинга, его можно и нужно представлять посторонним, при этом желательно заранее подготовиться.
Т.е. code review — благо, pair programming — зло.
;)
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Может есть кто-нить, кто все-таки юзает XP?
Здравствуйте Lefay, Вы писали:
CS>>Жаль, но видимо я здесь один, кто использует XP.
L>Нет, брат по разуму, ты не одинок!
Совсем не одинок. То что в XP называется умным буржуйским словом "рефакторинг" я начал использовать ещё до того как этот термин появился вместе с самой XP, ну прям мой стиль, панимаишь :) Наколбасишь, бывает, кода побольше, главное чтобы заработало, а потом раскладываешь его по полочкам.
Поэтому и к самой XP я отношусь как к обобщению положительного реального опыта программистской братии, не желающей тупо следовать не оправдавшим себя подходам к проектированию и разработки ПО, которые были предложены теоретиками и людьми никогда не писавшими программ сложнее hello-world.
Вот из этих позиций я и исхожу. При этом мне не нравится, что XP представляется как панацею от всех бед. Нифига она не панацея. Я могу привести примеры, с которыми я сталкиваюсь каждый день, где XP работать не будет, и где необходимо чёткое предварительное планирование и глубокий анализ на самых ранних этапах разработки, где ни о каких "Шашки наголо и вперёд" не может быть даже и речи.
Кроме того нам уже понадавали столько понацей, что это даже не смешно. Были революционные CASE-средства, от которых в реальной жизни прижились только ER диаграммы, как наиболее удобный способ документирования структуры БД. Был и есть UML, который тоже годится по большому счёту лишь на ранних этапах проектирования в качестве общих картинок, которые можно пообсуждать на митингах, и которые затем идут в мусорку, т.к. времени хватает только на что-то одно, либо на картинки, либо на кодирование. Пару лет назад об XML все орали так, как-будто он может заменить и изменить сразу всё, и HTML, и сам Интернет, и кодирование, и проектирование, стоит только его применить и всё сразу в мире станет лучше.
:super:
Не стало и не станет. И XP тоже никогда не будет панацеей, т.к. панацеи нет.
Используй XP на здоровье, и я тоже буду использовать из него какие-то части. Это очень здорово, что есть такая штука и есть её апологеты, которые пишут книжки, обобщают опыт и рассказывают нам как оно всё круто.
Только всегда нужно понимать одну простую вещь — ни XP, ни что-то ещё не могут решить всех проблем. Всё нужно использовать в меру. Здесь немножко XP, там лучше CASE, тут хорошо бы картинки порисовать, это задача лучше будет решаться, если будут приниматься коммандирские, если хотите волюнтаристские решения. Всё зависит от конкретной ситуации.
Вот такие пироги.
Если нам не помогут, то мы тоже никого не пощадим.
Как я уже говорил, целью, с которой я открыл данную тему, было обсуждение практических аспектов использования XP. В итоге же, получилась довольно рьяная дискуссия о полезности XP как таковой. Видимо, я не верно выбрал название :(, полагая, что противников XP практически не окажется, и мы сможем быстро перейти собственно к практическим аспектам. Но, несмотря на то, что нам так и не удалось прийти к общему знаменателю, надеюсь, что кто-нибудь что-нибудь да извлек из нашего общения (лично я получил не плохой урок уважения к чужим мнениям, сохранив при этом свое :) ).
Кстати, сегодня наткнулся на сайт XP по-русски :up: — там обсуждение ведется в нужном мне, практическом ключе. Всех, кому это интересно, приглашаю по-учавствовать (с разрешения авторов сайта, конечно же) !
2paul_shmakov
Спасибо за участие! Ваш пост развеял последние сомнения на счет окончания этой дискуссии.
Здравствуйте ChainSmoker, Вы писали:
CS>Лично я за. CS>Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике.
Я человек по жизни спокойный, чтобы меня из себя вывести нужно очень постараться... Этой ветке это удалось. (хорошее начало ;)
В любом другом месте я бы и внимания не обратил, но когда в форуме RSDN (уважаемым мной) обсуждается серьезная методология людьми, которые прочитали о ней максимум одну-две рекламные статьи — это, простите уж меня, ламерство называется!
Куча голословных утверждений вроде "в xp ХХХХ сделать нельзя", "xp не подходит для ХХХХ", "практика xp ХХХХХ — зло" и т.п. Причем с обоснованиями, по которым видно, что человек про XP знает только то, что XP — это Extreme Programming, а не WinXP или Athlon XP.
Прочитайте хоть что-нибудь для начала. А то не хорошо это выглядит, честное слово.
К тому же читать не обязательно именно про XP. "Гибких" (agile) методологий много различных. Все они похожи. И все к этому приходят, а не только Кент Бек. Просто XP сейчас самая модная методология.
2 ChainSmoker:
Отдельное спасибо за то, что затронули тему. Надеюсь, что через некоторое время здесь можно будет более конструктивную дискуссию прочитать, пусть и критикующую xp, но по делу.
Здравствуйте bkat, Вы писали:
B>Здравствуйте ChainSmoker, Вы писали:
B>Лично я ничего против разумного использования такого подхода не имею. B>Но очередной раз убеждаюсь, что для продвижения товара, технологии, идеологии и пр... B>название — это самое главное. B>В случае с "eXtreme Programming" — это очень хорошо видно. B>На мой взгляд все эти рекомендации очень полезны, но по сути — ничего нового. B>Зато слово "eXtreme" очень притягательно. B>Оно и понятно. Всем нам хочется чего-то "экстремального"
Могу поспорить: я тоже не большой сторонник использования слишком формализованных принципов, поскольку лишний формализм очень мешает, но
в случае именно XP могу сказать, что он вовсе не формализует, а структурирует те принципы разработки софта, которые известны всем и давно. Польза в такой структуризации принципов неоценима, поскольку каждый разработчик команды видит конкретную задачу, процесс ее реализации и знает у кого что надо спросить.
Несомненно каждый может ввести поправку в зависимости от специфики проекта и организации. В любом случае истина рождается при столкновении двух мнений
Взойти на гору можно разными путями, но само восхождение остается неизменным.
Думаю не имеет смысла продолжать в этом среде "религиозную войну", что хочет,
имеет достаточно информации чтобы разобраться что такое
XP и с чем его едят. А если кто не хочет — это его проблемы:)
А для тех кто не просто стучит по клавиатуре, а пытается как-то осмыслить происходящее
рекомендую прочитать статью Joel Spolsky The Joel Test: 12 Steps to Better Code http://www.joelonsoftware.com/articles/fog0000000043.html
Желающие могут заняться выяснением какие практики XP следуют из теста Joel и наоборот.
Или не следуют.
В чистом виде XP плохо применяется при написании
1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
2. библиотек (нет заказчика)
3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
В реальной жизни на проектах, которые не сами в себе, 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 предлагает не проектировать всю систему целиком и в деталях сразу, а делать это постепенно, при этом начав реализацию как можно раньше.
Здесь я с тобой полностью согласен, но для этого надо заставить разработчиков писать код, в котором стоимость изменений от объема кода растет не экспонециально, а линейно.
В целом, есть фундаментальные принципы, следуя которым можно успешнее
выполнять проекты. XP, процесс от Rational, SEI SW CMM, ISO — разные
взгляды (view) на одни и те же фундаментальные принципы.
Кому-то проще понять и применять эти принципы следуя XP,
кому-то — штудируя отчеты от SEI.
Это, наверное, основная причина, почему XP, Rational и пр... — не конкуренты.
А то что, кто-то на чем-то больше денег сделает — это уже вторично.
Ладно, это уже демогогия...
Все же полезнее обсуждать конкретные вещи, не смешивая их вместе.
Например, чем Pair Programming эффективнее review, которые планируются заранее
и к которым нужно спецально готовиться?
Здравствуйте bkat, Вы писали:
B>>>Например, чем Pair Programming эффективнее review, которые планируются заранее и к которым нужно спецально готовиться?
CS>>Ну, хотя бы тем, что склоняет делать сразу все "на бело", вырабатывать свой стиль, учась друг у друга.
B>Приведу некоторые свои аргументы против Pair Programming: B>1) Поскольку народ заранее не готовится, то реальные проблемы скорей всего будут пропущены. B>2) Нет свежего взгляда на код. Пара всегда имееет дело только с тем, с чем работает сама. B>3) Велик риск, что более авторитетный просто будет давить своим авторитетом на менее авторитетного. B> Я это испытал на собственной шкуре. Причем был и в роли ведущего и в роли ведомого. B>4) Ответственность каждого размывается. B>5) В ходе Pair Programming народ все же концентрируется на написании кода, B> а не на поиске проблем в коде. Code Review как раз направлено на поиск проблем и только. B> Аргументы, что в парном программировании ошибки допускаются реже — не серьезны.
6) При разных взглядах на проблему и примерно одинаковом уровне подготовки существует вероятность того, что эта пара просто не сумеет договориться. Ну типа как в басне Крылова.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте ChainSmoker, Вы писали:
CS>>Лично я за.
IT>Лично я не вижу ни одного против IT>А если сюда добавить правильную организацию внутри команды (тыпа MSF), то получится полная идилия
Если бы еще были конторы в которых все это практикуется...
Здравствуйте ChainSmoker, Вы писали:
CS>Лично я за. CS>Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике. CS>Уже более года, как я изучаю XP и пробую применять его принципы на практике. CS>Со своей стороны приведу комментарии к нескольким принципам.
CS>Подключение заказчика (On-site Customer). Программа — это инструмент для решения определенных задач. Но кто, как не заказчик может лучше знать их специфику. А посему, подключим заказчика к процессу разработки. Пусть он будет под рукой когда программисту понадобится консультация, ведь потерянное время это его деньги. Пусть он будет в курсе событий и перестанет задавать вопросы типа: когда мы будем это иметь? Пусть он примет участие в принятии решений и разделив ответственность перестанет обвинять во всем программиста.
CS>Небольшие релизы (Small Releases). Когда мы будем это иметь? Любой программист знает как сложно ответить на этот вопрос более менее точно. Оценить время на разработку релиза в целом очень сложно. Но вот если взять и разбить большой релиз на несколько маленьких, а задачи на каждый релиз детализировать до весьма небольших и легко прогнозируемых задач, то вполне можно не оплошаться с датой выхода релиза. В XP релиз состоит из 70-80 Итераций (Iteration), каждая из которых занимает 1-3 недели. Итерация реализует какую-то одну Историю Пользователя (User Story), которая является ни чем иным, как описанием некоей функции системы с точки зрения пользователя.
CS>Не усложняйте проект (Simple Design). Зачем тратить время впустую, зачем делать то, что может никогда не понадобиться. Гораздо лучше оставить возможность расширения. Как это выглядит на практике? На мой взгляд в ОО программировании, существует лишь один безболезненный способ предусмотреть расширяемость — это реализовать наращиваемые сущности в виде иерархии классов. Например, если мы предполагаем, что в будущем некий набор операций может расшириться, то мы должны реализовать операции в виде иерархии классов, если же нет, то тогда можно использовать и стандартные типы или классы. В случае расширения все что нам надо, это добавить соответствующий подкласс.
CS>Системная метафора (Metaphor). Системная метафора — это концепция системы, это используемая терминология, это платформа для общения между людьми, принимающими участие в разработке. Если уровень взаимодействия между людьми высок (а использование XP это предполагает), то системная метафора вам необходима как воздух.
CS>Программируем вдвоем (Pair Programming). В основе этого принципа лежит сила общения. Хотя самому мне лишь изредка приходится работать в таком режиме (пока я не в силах это изменить ), доложу вам те приемущества, которые смог заметить: CS>- программист работает по 6 часов в день, и когда почти все это время он просиживает в одиночестве за компьтером — это утомляет, по-моему вдвоем гораздо веселей; CS>- взаимообучаемость; CS>- взаимозаменяемость; CS>- нет места халявщикам; CS>- и, как не странно, все это в итоге реально увеличивает производительность.
CS>Начинай с тестов (Test-first Design). Тестирование — это не просто тестирование! Тест — это проект того кода, который мы собираемся написать. Как код будет использоваться? Именно на этот вопрос дает ответ тест. Кроме того, тест еще и прекрасная документация, не пресловутая спецификация, а живая, на примерах.
CS>Рефакторинг (Refactoring). Совершенству нет предела, но хорошие идеи приходят не всегда и не сразу. Поэтому мы просто пишем код который выполняет то, что нам нужно. Если мы видим, что код можно улучшить, мы улучшаем его. Это и есть рефакторинг. Мы не сидим и не ждем вдохновения от бога, а просто делаем то, что на текущий момент является наилучшим вариантом. Завтра нас осенит и мы сделаем рефакторинг. Но надо иметь в виду, что без тестов рефакторинг может превратиться в геморрой.
Я конечно прошу прощения за свою необразованность, но что такое eXtreme Programming и где можно про него почитать?
Лично я ничего против разумного использования такого подхода не имею.
Но очередной раз убеждаюсь, что для продвижения товара, технологии, идеологии и пр...
название — это самое главное.
В случае с "eXtreme Programming" — это очень хорошо видно.
На мой взгляд все эти рекомендации очень полезны, но по сути — ничего нового.
Зато слово "eXtreme" очень притягательно.
Оно и понятно. Всем нам хочется чего-то "экстремального"
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте ChainSmoker, Вы писали:
DG>В целом я за, но есть несколько моментов.
DG>В чистом виде XP плохо применяется при написании DG>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP) DG>2. библиотек (нет заказчика) DG>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
Поддерживаю эти мысли.
Добавлю ещё, что в XP практически невозможно получить что-то фундаментальное и относительно-устойчивое (фреймворк, библиотеку компонентов) -- заказчиков нет.
DG>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
В этом я тоже согласен с вами.
XP -- техника, порождённая "низами", "верхи", как всегда, не хотят. Вот бы совместить приятное с полезным -- здорово бы было! :user:
Здравствуйте psc71, Вы писали:
P>Я конечно прошу прощения за свою необразованность, но что такое eXtreme Programming и где можно про него почитать?
Если коротко. XP — это методология программирования, состоящая из набора практик (слово практика выбрано не случайно, оно отражает практическую направленность принципов XP). Практики XP охватывают как процессы проектирования и кодирования программ, так и организацию процесса разработки в целом.
Насчет почитать. Русских ресурсов я не встречал, а из англоязычных могу отметить два следующих. http://www.extremeprogramming.org/ — здесь можно ознакомиться с приниципами XP. http://www.objectmentor.com/ — ну а здесь масса статей ведущих специалистов на тему XP и вообще о программировании.
Здравствуйте bkat, Вы писали:
B>Лично я ничего против разумного использования такого подхода не имею. B>Но очередной раз убеждаюсь, что для продвижения товара, технологии, идеологии и пр... B>название — это самое главное. B>В случае с "eXtreme Programming" — это очень хорошо видно. B>На мой взгляд все эти рекомендации очень полезны, но по сути — ничего нового. B>Зато слово "eXtreme" очень притягательно. B>Оно и понятно. Всем нам хочется чего-то "экстремального" ;)
Отчасти вы правы, в наше время, чтобы на что-то обратили внимание, надо это "продвигать".
Но боюсь, что хотя элементы "продвижения" наблюдаются и с XP, название это скорее отражает суть, чем является рекламным трюком.
XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
Кроме того, XP носит скорее эволюционный характер, чем революционный. Т.е. хотя есть кое-что полностью новое, многое адаптировано из уже существующего. Но главное — это акцентирование внимания на экстремальности сегодняшних условий.
Здравствуйте DarkGray, Вы писали:
DG>В целом я за, но есть несколько моментов.
DG>В чистом виде XP плохо применяется при написании DG>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
Согласен, что изменение интерфейсов наиболее затруднено. Но чем это припятcтвует применению XP?
DG>2. библиотек (нет заказчика)
Ну кто-то же будет их использовать. А значит будет если не заказчик-покупатель, то хотя бы заказчик-пользователь.
DG>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
Ну тут уж ничего не сделаешь — с pair programming придется расстаться. Но ведь остальное вполне применимо.
DG>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
Честно сказать, не вижу никакой связи между XP и техникой "программирования снизу" (или "сверху").
У XP свой акцент, это акцент не на "низ" или "верх", а на требования заказчика (не надо делать ничего кроме того, что надо заказчику). А в контексте требований заказчика, вы уже сами можете решать, как вам программировать, "снизу" и/или "сверху".
Из ваших постов у меня сложилось впечатление, что никто из вас особо не использовал XP на практике, а кто-то может и вообще плохо понимает что-это такое. И хотя я, в принципе, не вижу ничего против просветительской и агитаторской работы, но цель моя была иной — поделиться опытом.
Здравствуйте ChainSmoker, Вы писали:
CS>Здравствуйте bkat, Вы писали:
CS>XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
Изменение требований на проекте не имеет ничего общего с экстремальностью.
Это обычная практика и с этим просто нужно уметь жить.
Те команды, которые с этим не справляются, как правило имеют очень большие проблемы.
На мой взгляд, управление требованиями — это ключевой момент во всей разработке.
Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
Здравствуйте ChainSmoker, Вы писали:
CS>Здравствуйте DarkGray, Вы писали:
DG>>В целом я за, но есть несколько моментов.
DG>>В чистом виде XP плохо применяется при написании DG>>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
CS>Согласен, что изменение интерфейсов наиболее затруднено. Но чем это припятcтвует применению XP?
Тем что XP говорит, давайте сначала сделаем это по простому, а как я зделаю, это просто, если у меня уже жестко прошит интерфейс.
DG>>2. библиотек (нет заказчика)
CS>Ну кто-то же будет их использовать. А значит будет если не заказчик-покупатель, то хотя бы заказчик-пользователь.
Но на этапе разработки, такого заказчика нет.
Вот возьмем класс CString, какой у него должен быть набор методов, как он должен быть устроен, насколько просто его надо реализовать и т.д. Даже наличие пары пользователей никак нам не поможет в реализации этого класса.
DG>>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
CS>Ну тут уж ничего не сделаешь — с pair programming придется расстаться.
Не только, тот же Кент Бек — делает очень большой акцент на то, что команда должна очень много общаться, и при говорит, что при отсутствии общения многие приемы из XP, начинают развалится... А какое может быть общение по e-mail-у.
CS>Но ведь остальное вполне применимо.
Я не говорю, что все не применимо, я говорю, что XP надо применять с оглядкой,
тот же тестинг, рефакторинг, "небольшие релизы" — я приветствую и использую,
"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
"подключить заказчика" — это хорошо, но на практике обычно сложно получается реализовать,
"системная метафора" — я скорее придерживаюсь подхода, что программа должна быть просто последовательна, а метафора — это уже вторично (так я видел жутко неудобные программы, использующие метафоры, так и удобные программы, которые не используют какие-либо метафоры, хотя, "программа под windows" — это уже метафора, а "консольная программа под unix" — это уже другая метафора.
"программирование в парах" — трудно реализуема на практике, т.к. добиться того, чтобы обоим людям было интересно(и продуктивно) работать в паре — очень сложно, т.к. равных людей не бывает, и в паре, обычно, более "активный"(умный, волевой) задавливает второго, которому остается только кивать гивой и иногда вставлять фразу: "а ты здесь забыл поставить точку с запятой"
DG>>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
CS>Честно сказать, не вижу никакой связи между XP и техникой "программирования снизу" (или "сверху"). CS>У XP свой акцент, это акцент не на "низ" или "верх", а на требования заказчика (не надо делать ничего кроме того, что надо заказчику). А в контексте требований заказчика, вы уже сами можете решать, как вам программировать, "снизу" и/или "сверху".
Программирование сверху, предполагает, что у нас есть жесткий (более и менее) каркас, который мы заполняем, а XP (в чистом виде) — говорит, что не надо ни какого каркаса, ни надо ничего проектировать, а давайте сделаем первую версию, как можно проще (как у нас получится), потом еще что-нибудь добавим, а дальше, куда кривая вылезет, поэтому XP(опять же в чистом виде) очень плохо уживается с этапом проектирования.
Здравствуйте bkat, Вы писали:
B>Изменение требований на проекте не имеет ничего общего с экстремальностью. B>Это обычная практика и с этим просто нужно уметь жить. B>Те команды, которые с этим не справляются, как правило имеют очень большие проблемы. B>На мой взгляд, управление требованиями — это ключевой момент во всей разработке. B>Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
Но XP заявляет, что если следовать тем правилам, которые заложены в XP, то с проблемой изменения требований, команда столкнется в намного меньшей степени или не столкнется (именно, как с проблемой) вообще.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте bkat, Вы писали:
B>>Изменение требований на проекте не имеет ничего общего с экстремальностью. B>>Это обычная практика и с этим просто нужно уметь жить. B>>Те команды, которые с этим не справляются, как правило имеют очень большие проблемы. B>>На мой взгляд, управление требованиями — это ключевой момент во всей разработке. B>>Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
DG>Но XP заявляет, что если следовать тем правилам, которые заложены в XP, то с проблемой изменения требований, команда столкнется в намного меньшей степени или не столкнется (именно, как с проблемой) вообще.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте bkat, Вы писали:
B>>А можно озвучить ключевые идеи этих правил?
DG>Дык, все те же самые.
DG>Подключение заказчика DG>Небольшие релизы DG>Не усложняйте проект DG>Системная метафора DG>Тестинг DG>Рефакторинг
Это не совсем правила. Это общие рекомендации.
Возмем, например, "Подключение заказчика".
Как вы его будете подключать? Как конкретно он будет участвовать на проекте?
Чтобы ответить на эти вопросы, нужны уже конкретные правила(процедуры),
которым следует команда разработчиков.
Самое сложное как раз выработать эти правила,
чтобы они действительно вели к реальному участию заказчика.
Можно очень активно общаться с заказчиком, и все же забыть о "мелочи",
которую он очень просил реализовать.
К чему я веду?
К тому, что XP и другие подобные методологии худо-бедно описывают цели,
но как к ним идти — это очень большой вопрос.
Вопрос к знатокам XP.
Имеются ли рекомендации по тому, как оценивать команду разработчиков,
на соответствие XP. Грубо говоря, хотелось бы почитать о методиках,
которые бы выдавали нечто типа:
— Команда Х выполняет требования XP на 100%;
— Команда Х выполняет требования XP на 50%;
Здравствуйте bkat, Вы писали:
B>Вопрос к знатокам XP. B>Имеются ли рекомендации по тому, как оценивать команду разработчиков, B>на соответствие XP. Грубо говоря, хотелось бы почитать о методиках, B>которые бы выдавали нечто типа: B>- Команда Х выполняет требования XP на 100%; B>- Команда Х выполняет требования XP на 50%;
Вот такого как раз нет, потому что я опять же напоминаю, что XP(в чистом виде) тоже не панацея, и ее надо комбинировать с другими типами разработки, а вот эта комбинация и есть субъективное дело команды.
Здравствуйте 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. Ведь если все и так хорошо, то зачем, вообще, что-то менять?
...
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 невозможна. Надо сначала всё спроектировать, а потом уж за компьютер браться.
...
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", в том, чтобы люди были бдительными, и следили за своим процессом разработки и улучшали его, а не надеялись, что дядя Кент обо всем позаботился за них.
...
DG>Но вот берем "окно" из windows-а. Если это был бы "замкнутый" объект, то его можно было бы копировать, передавать между процессами, создавать свои объекты окна и т.д. DG>Реализация всех этих вещей далеко не проста, но дальнейшее использование — было бы просто сказка, так как не надо было бы задумываться, в каких областях "окно", как полноценный объект не доделано.
Это именно была бы сказка — невозможно реализовать все "потенциально" возможные операции над объектом. А вот почему "окно из windows" не замкнутый объект, мне не понятно. Вполне может быть замкнутым, но только на определенном наборе операций.
...
CS>>Бывают и губительны, бывают и бесполезны. CS>>Но без метафоры никуда не денешься — ведь гораздо удобнее говорить "папки" размещаются на "рабочем столе", чем нечто вроде "хрямзели" располагаются на "хрюмзеле" :).
DG>IMHO, без разницы, главное чтобы эти "хрямзели" и "хрюмзели" — хорошо "лежали" на языке. Так для меня намногое понятнее и менее путанные термины — "директория" и "десктоп", чем "папка" и "рабочий стол", при это мне не интересно, как эти слова переводятся на русский и что еще означают на английском.
"Директория" и "десктоп" — тоже метофоры, только на английском. А вот "хрямзели" и "хрюмзели" не метафоры — им нет аналога в реальном мире.
DG>>>А язык общения лучше строить самим из понятных обоим сторонам кирпичиков, главное чтобы такой язык был последовательным.
CS>>Что значит последовательный? Как определить, последовательный или нет?
DG>Это значит, что если из A следует B, то это должно быть всегда. DG>Второе определение, от обратного, чем меньше исключений, тем язык последовательнее.
Ладно, я понял. Просто я бы сказал по-другому: язык должен быть очевидным и непротиворечивым. Хотя по-сути одно и то же.
CS>>>>Что такое каркас программы? По-моему это и есть "системная метафора"!
DG>>>Не совсем, "каркас программы" говорит, что у нас есть такие-то классы, у них есть такие-то методы, они вот так взаимодействуют между собой,
CS>>Ну, это уже не каркас, а готовая программа!
DG>Далеко нет!!! Если бы все обстояло так, как ты говоришь, то программисты давно бы вымерли и остались бы одни рисовальщики UML ;) DG>
Ну, тогда, программисты — готовтесь к смерти! :))
Вон, Mishka.NET сообщил в своем посте: "Rational пропагандирует идею автоматизации программирования, утверждают, что некоторые их клиенты снизили количество ручного написания кода на 90%. А это серьёзно. Потому у нас сейчас наметился переход к подобной же системе."
Так глядишь, через пару лет одни "рисовальщики диаграмм" останутся :). А ведь все к тому и идет...
DG>>>Здесь я с тобой полностью согласен, но для этого надо заставить разработчиков писать код, в котором стоимость изменений от объема кода растет не экспонециально, а линейно.
CS>>Ну, не обязательно заставлять, может они сами захотят!
DG>Для того чтобы человек что-нибудь захотел, его надо на это замотивировать, а как замотивировать программиста, которому положен оклад в месяц (без разницы, что он там понаписал), чтобы он писал код на будущее.
Уверен, есть люди, которых не надо заставлять.
Меня, например, никто не заставлял. Если бы я сидел и ждал, пока меня заставят, и халявил бы при каждой возможности — это означало бы, что моя работа мне не нравиться. А работа — это ~60% жизни! Так что же, большую часть жизни заниматься тем что не нравится. А за качественную работу всегда можно требовать достойную плату.
DG>Второе "подводный" камень, это то, что правило "писать код с возможностью уменьшения дальнейших изменений" сильно противоречит правилу "писать как можно проще". Часто при написании новый фичи проще сделать Copy+Paste, но дальнейшее изменение(сопровождение) такого кода превращается в сущий ад...
А здесь и рефактиринг тут как тут :). Это одна из его основных обязанностей — избавление от повторяемого кода. Сначала можно и copy+paste, а затем, когда тест пройден, делаем рефакторинг. В данном случае, это, как-правило, вынос повторяемого кода в отдельный метод.
Здравствуйте bkat, Вы писали:
B>Все же полезнее обсуждать конкретные вещи, не смешивая их вместе. B>Например, чем Pair Programming эффективнее review, которые планируются заранее B>и к которым нужно спецально готовиться?
Ну, хотя бы тем, что склоняет делать сразу все "на бело", вырабатывать свой стиль, учась друг у друга.
Здравствуйте IT, Вы писали:
B>>Все же полезнее обсуждать конкретные вещи, не смешивая их вместе. B>>Например, чем Pair Programming эффективнее review, которые планируются заранее и к которым нужно спецально готовиться?
IT>Я вообще не могу себе представить первого в принципе, хотя подозреваю, что для извращенцев в этом что-то есть. Кодирование — процесс личный, можно даже сказать интимный и никто посторонний не должен касаться его своими грязными, волосатыми лапами. Другое дело результат кодинга, его можно и нужно представлять посторонним, при этом желательно заранее подготовиться.
Здравствуйте ChainSmoker, Вы писали:
CS>Здравствуйте bkat, Вы писали:
B>>Все же полезнее обсуждать конкретные вещи, не смешивая их вместе. B>>Например, чем Pair Programming эффективнее review, которые планируются заранее B>>и к которым нужно спецально готовиться?
CS>Ну, хотя бы тем, что склоняет делать сразу все "на бело", вырабатывать свой стиль, учась друг у друга.
Приведу некоторые свои аргументы против Pair Programming:
1) Поскольку народ заранее не готовится, то реальные проблемы скорей всего будут пропущены.
2) Нет свежего взгляда на код. Пара всегда имееет дело только с тем, с чем работает сама.
3) Велик риск, что более авторитетный просто будет давить своим авторитетом на менее авторитетного.
Я это испытал на собственной шкуре. Причем был и в роли ведущего и в роли ведомого.
4) Ответственность каждого размывается.
5) В ходе Pair Programming народ все же концентрируется на написании кода,
а не на поиске проблем в коде. Code Review как раз направлено на поиск проблем и только.
Аргументы, что в парном программировании ошибки допускаются реже — не серьезны.
Здравствуйте IT,
IT> При разных взглядах на проблему и примерно одинаковом уровне подготовки существует вероятность того, что эта пара просто не сумеет договориться. Ну типа как в басне Крылова.
А я б вообще убил ламера А если профи сядет за комп, то я просто отойду в уголок, чтоб не мешать, да книжки лучше почитаю.
IT>6) При разных взглядах на проблему и примерно одинаковом уровне подготовки существует вероятность того, что эта пара просто не сумеет договориться. Ну типа как в басне Крылова.
Ну это общая проблема, которая имеет отношение не только к парному программированию.
Re[11]: XP - за и против
От:
Аноним
Дата:
05.07.02 13:47
Оценка:
Здравствуйте IT, Вы писали:
IT>6) При разных взглядах на проблему и примерно одинаковом уровне подготовки существует вероятность того, что эта пара просто не сумеет договориться. Ну типа как в басне Крылова.
IT, это лучший случай (когда не договориться). Обычно в таких ситуациях происходит переход к пункту 3). В худшем случае находится компромис, появляются две интерпретации кода, оба разработчика страдают. И вообще, идеальная пара создается примерно с той же вероятностью, что и идеальный брак (из тех, что рождаются на небесах).
Здравствуйте George_Seryakov, Вы писали:
CS>>Кстати, сегодня наткнулся на сайт XP по-русски — там обсуждение
GS>А хороший сайтик-то... Особенно мне понравилось про рефакторинг — очень внятно.
GS>2IT: а не стоит ли поглядывать на этих парней, имея в виду предложить им вовремя affilation/дисковое пространство/хостинг/убежище/whatever?
Да вроде как они пока не страдают:
Мы — это российское отделение компании Sales Explosion, Inc. Мы применяем экстремальное программирование в своей работе, пытаемся осознать как оно мапируется на российский менталитет. Мы хотели бы общаться и обмениваться опытом с другими XP командами.
но в случае чего...
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
GS>>2IT: а не стоит ли поглядывать на этих парней, имея в виду предложить им вовремя affilation/дисковое пространство/хостинг/убежище/whatever?
IT>Да вроде как они пока не страдают:
На войне ситуация меняется с каждой минутой.
IT>Мы — это российское отделение компании Sales Explosion, Inc. Мы применяем экстремальное программирование в своей работе, пытаемся осознать как оно мапируется на российский менталитет. Мы хотели бы общаться и обмениваться опытом с другими XP командами.
Ну, первый вопрос это размер этого "Мы", второй — сила его сцепления с фирмой, третий — сила сцепления фирмы Sales Explosion с бизнесом (они там, что-ли, SAP-у конкуренцию делают...), четвертый — сила сцепления российского отделения с нероссийским.
IT>но в случае чего...
Форумы ему предложи захостить, они у него не совсем.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте ChainSmoker, Вы писали:
DG>В целом я за, но есть несколько моментов.
DG>В чистом виде XP плохо применяется при написании DG>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
Но зато это дает расширяемость, а интерфейс между модулями надо строить на иерархии классов, чтоб можно было расширять систему (small releases) DG>2. библиотек (нет заказчика)
заказчиком в данном случае выступает лидер проекта, или программист,
который ответственнен за выполнение истории по создании библиотеки DG>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
Тут конечно можно согласиться, но как-же ICQ, почта и т.д.
DG>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
Взойти на гору можно разными путями, но само восхождение остается неизменным.
Re[2]: Может есть кто-нить, кто все-таки юзает XP?
Здравствуйте ChainSmoker, Вы писали:
CS>2All.
CS>Из ваших постов у меня сложилось впечатление, что никто из вас особо не использовал XP на практике, а кто-то может и вообще плохо понимает что-это такое. И хотя я, в принципе, не вижу ничего против просветительской и агитаторской работы, но цель моя была иной — поделиться опытом.
CS>Жаль, но видимо я здесь один, кто использует XP.
Нет, брат по разуму, ты не одинок!
Взойти на гору можно разными путями, но само восхождение остается неизменным.
Здравствуйте paul_shmakov, Вы писали:
PS>2 ChainSmoker: PS>Отдельное спасибо за то, что затронули тему. Надеюсь, что через некоторое время здесь можно будет более конструктивную дискуссию прочитать, пусть и критикующую xp, но по делу.
А я вот не понимаю проблемы. Первопроходцам и должно быть тяжело, т.к. аборигены всегда и везде съедают первых миссионеров. Ну подумаешь, вас тоже тут немного покусали. Это совсем не значит, что мы плохие. Просто пока не доросли
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте ChainSmoker, Вы писали:
CS>Лично я за. CS>Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике. CS>Уже более года, как я изучаю XP и пробую применять его принципы на практике.
я тоже пытаюсь применять xp на практике. только вот меня в нем смущает все что связано с взаимодействиеми с заказчиками. насколько реально на практике выполняется требование on-site customer? и насколько тяжело заставить заказчика генерировать функциональные тесты ?
Здравствуйте ChainSmoker, Вы писали:
CS>Кстати, сегодня наткнулся на сайт XP по-русски — там обсуждение ведется в нужном мне, практическом ключе. Всех, кому это интересно, приглашаю по-учавствовать (с разрешения авторов сайта, конечно же) !
Здравствуйте ChainSmoker, Вы писали:
CS>Лично я за.
А лично я — монописуально .
Если тебя хотя бы раз в жизни прижмет большой проект, и ты на свою голову еще и окажешься его руководителем, то все эти "фичи" XP осваиваются самостоятельно. И не только они.
Наверное, раз теперь на элементы вполне нормального стиля программирования навешивают такое название, старая терминология уже не режет слух.
PS. Как знал, что на RSDN найдеться такой топик
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
В нашем небольшом отделе всего два программиста (включая меня — VC), причем другой программирует на Delphi. Уж какое тут парное программирование, проблема как бы код склеить...
), доложу вам те приемущества, которые смог заметить:
Если нам не помогут, то мы тоже никого не пощадим.
!
А если профи сядет за комп, то я просто отойду в уголок, чтоб не мешать, да книжки лучше почитаю.
— там обсуждение 
