Экстремальное программирование

"как сделать хорошего програмиста на с из двух плохих программистов на васике". ИМХО редкостная лажа, порождённая нездоровым желанием исключить процесс разработки и свалить всё на быдлокодеров. Из-за межличностных трений и, главное, разного видения проблемы и путей решения, ничё хорошево не получицо, а если и получицо - будет совершенно неподдерживаемое.

Всё вышесказанное моё ИМХО, на практике не проверялось, а также я не знаю никого настолько отмороженного, кто согласился бы это проверить.

есть пара ссылок отсюда:

http://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0...

Использовал. Один раз написал систему контроля юзеров для одной бодяги, писал с жуткого похмелья. Это был экстрим. Потом по ней даже дипломную работу написали.

> что делать когда для нормальной работы класса требуется внешняя система, например это GUI и для его работы нужен человек

Засада. Хотя коммерческие пакеты для тестирования GUI существуют. На память приходит что-то типа AWTRobot или SwingRobot.

> как тестировать класс, который завязвн на GUI, например потомок wx.Panel или QWidget (кому что больше нравится)?

Сделать его попроще, и не тестировать 8) Когда я работал в OS/2, мы развлекались, заставляя программы работать от PostMessage (или как оно называлось) - ставили в очередь сообщений программ свои сообщения.

> есть класс, который синхронизирует БД с LDAP, так ведь для того чтобы его проверить мне нужна для тестирования собственно БД и LDAP. Хорошо ещё я Postgre использую, а вот был бы это Оракл... Что делать в таком случае?

В таком случае обычно имеют тестовую БД и тестовый сервер LDAP (и, наверное, нетривиальные методы setUp и tearDown).

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

А по-моему, так если в проекте занято человек 5-10, то по фигу, какой процесс использовать, всё равно они сами друг с другом договорятся, как им удобнее работать. А если человек 50-100, то тем более по фигу, всё равно проекту хана. :)

> Набор автоматически прогонябельных (без участия человека) тестов - это огромная помощь.

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

> Да, но тестирование не заменит этап разработки.

НКонечно, если не будет разработки, тестировать будет нечего 8) Под "разработкой" ты имел в виду "проектирование"?

Кстати, проектирование не заменяет тестирования :-P Программа с хорошо рассчитанной структурой, но плохо протестирования... ты понял, да? :)

> Под "разработкой" ты имел в виду "проектирование"?

Аха, точно.

> Кстати, проектирование не заменяет тестирования :-P Программа с хорошо рассчитанной структурой, но плохо протестирования... ты понял, да? :)

Понял. Но я также понял, чё хр - это попытка заменить проектирование парой обезянок. ИМХО мысль интересная, но неправильная.

> хр - это попытка заменить проектирование парой обезянок.

А как же "на практике не проверялось"? 8=O

>> хр - это попытка заменить проектирование парой обезянок.

> А как же "на практике не проверялось"? 8=O

В смысле? Чё там проверять? Это в самой методике описано. А вот результаты применения, да, не проверялись. Ибо нефих. За ксплуатацию обезянево труда вообще наказывать надо ИМХО.

А мне книга понравилась. Методика вообще выглядит какой-то слишком непривычной, но... это пока ты не попал в ситуацию, когда требования меняются на ходу, по мере "ввода в строй" новых компонентов программы (сам я XP не практикую). Ну а юнит-тестирование, признание необходимости рефакторинга - это практичные и здравые идеи.

>За ксплуатацию обезянево труда вообще наказывать надо ИМХО.

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

> требования меняются на ходу

http://www.nestor.minsk.by/sr/2003/07/30710.html :P

> признание необходимости рефакторинга

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

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

Ну чё делать, если в описании методики предполагаются именно такие слова?

> http://www.nestor.minsk.by/sr/2003/07/30710.html :P

Читал, и давно. Любимая цитата: "Однако я не думаю, что смогу убедить кого-нибудь (старше 25) выучить Lisp.". То есть - тем, кто постарше, голову уже не задуришь ;)

>> признание необходимости рефакторинга

> это принзнание что изначально сделано неправильно => признание в том, что и на этот раз будет сделано неправильно.

Первое из второго, в общем-то, не следует.

> Потому что действия не переосмыслены и предпосылки для ашыпкоф не устранены.

Может быть так, может быть и не так.

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

А ты, значит, всё делаешь правильно с первого раза? Или у тебя йайтсы уже оторваны?

"Только шаги учат ходить" -- (C) Непомнюкто

Вот. Нарыл прикольную ссылку про UnitTest-ы (для Python-а)

http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy

> Читал, и давно.

Ну и как, понравилось?

> Любимая цитата

"разодрали на цитаты" называется.

> тем, кто постарше, голову уже не задуришь ;)

Задурить - запросто. А вот способности к обучению с возрастом ухудшаются, да.

> Первое из второго, в общем-то, не следует.

Сможеш логически обосновать, почему?

> А ты, значит, всё делаешь правильно с первого раза?

"потренируйся лучше на кошечках" (С) кино

>> Читал, и давно.

> Ну и как, понравилось?

Да

>> Первое из второго, в общем-то, не следует.

>Сможеш логически обосновать, почему?

Блин, вот только в спор о формальной логике ввязываться мне и не хватало. Это твое высказывание - теорема. Докажи ее, если сможешь.

>> А ты, значит, всё делаешь правильно с первого раза?

>"потренируйся лучше на кошечках"

То есть - с первого раза у тебя не получается? Вот и будь скромнее. Тренироваться на кошечках - отличная идея... если у тебя есть на это время.

> Это твое высказывание - теорема. Докажи ее, если сможешь.

доказать что именно? То, что если единова сделано неправильно, то без переучивания и второй и пятый и дохренадцатый раз будет сделано неправильно? Или то, что раз уж нуждается в переделке без изменения условий, то сделано неправильно?

> То есть - с первого раза у тебя не получается?

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

> если у тебя есть на это время.

Млин, если посту раз одно и тоже переделывать-тестировать-отлаживать, времени точно не будет, даже пифка полакать :(

>Или то, что раз уж нуждается в переделке без изменения условий, то сделано неправильно?

А если условия изменились? И то, что в прошлом месяце было правильно, теперь стало неправильно?

это ужо не рефакторинг который мы тут обсуждаем http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80...

> Кто нибудь в разработке софта использует экстремальное программирование? И с каким результатом?

В целом мы XP не используем, у нас стандартным процессом идет RUP. Зато XP активно используем в качестве "книги бабушкиных рецептов". В целом получается 70/30.

> Просто слышал что это последняя серебренная пуля

"Серебрянной пули не существует" (С) Брукс.

XP применимо только в двух случаях: а) заказчик работает рядом с разработчиком и б) заказчик -- Вы сам. Очевидно, что XP неприменимо для команд больше 3-5 человек. Наконец, XP эффективно только в безнадежных проектах.

Пробовал - результаты отличные! :)

но есть подводные камни:

# когда программят два человека вместе - нередко возникают трения (как чего лучше сделать), ибо программеры - человеки творческие! ;)

Тут если не приходят к общему мнению, то либо кто-то кого-то задавливает авторитетом (что плохо сказываеться на работе и работа загнивает), либо работа загнивает сразу. :-/

Карочи: когда программят в паре - должно быть единодушие, как буд-то это семья! Ну или братя :)

Или должен быть рядом (или кто-то из пары) ну ооочень офигенный психолог! ;)

# времени уходит на программинг больше!
ибо много уходит времени на обсуждение чего и как сделать нужно, но это время окупаеться на вылавливании ошибок (после запуска проекта) - ибо ошибок получаеться гооооораздо меньше!

Огромный плюс: при правельном построении всего процесса XP исключает тупые ошибки (типа не там точку с запятой поставил) - что очень сильно экономит время и деньги после.

Это типа сам процес, про рефакторинг и тп. еще можно много чего сказать...

Но ведь XP это не только парное программирование, но и User Stories вместо классического ТЗ, CRC карточки, собрания стоя :-)

А это практикуете?