?

Log in

No account? Create an account
программистское: посмотрите и сравните - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

программистское: посмотрите и сравните [окт. 6, 2009|03:08 pm]
Anatoly Vorobey
Питер Норвиг, автор (помимо множества прочих заслуг) знаменитых книг об AI и Лиспе, автор эссе Teach Yourself Programming in Ten Years, которое следует прочитать каждому программисту, рассказывает, как написать программу, решающую любую задачу Судоку. 100 строк на Питоне.

Рон Джеффриз, один из изобретателей системы XP Programming, один из духовных отцов движения Agile и авторов Agile Manifesto, пытается написать программу для решения Судоку: раз, два, три, четыре, пять. На Руби, с использованием TDD (test-driven development).

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

Бонус:

Роберт Мартин ("Uncle Bob Martin"), один из главных создателей Agile, специалист по Agile, XP и UML, автор книг обо всех этих методологиях, пишет код на Clojure, с помощью TDD, вычисляющий результат игры Bowling Game, простого варианта боулинга. Вот его код.

Матиас Джованнини пишет код на OCaml, без TDD, для решения той же проблемы. Вот его код.

Сравните, и вы будете знать все, что следует знать об XP, Agile и TDD.

Все всегда звучит очень заманчиво. Все всегда звучат очень убедительно. Все полемики и манифесты можно просто не читать, а если читать, то ни в коем случае не воспринимать всерьез. Читайте код. Или, если есть время и желание, пробуйте сами. А манифесты и методологические книги - пусть себе скрипит губерния.
СсылкаОтветить

Comments:
Страница 1 из 2
<<[1] [2] >>
[User Picture]From: nm_work
2009-10-06 05:30 pm
:) Agile и XP имеют свои преимущества, но я считаю что эти процессы нужно адаптировать к команде/продукту.

в одной из систем у нас, например, несколько критически важных классов были вообще вне тестов. сознательно :) потому что писать тесты на них заолбаешься, а если что в них поломать - слетает вся система, так как ими пользуются ВСЕ оставшиеся ;)
(Ответить) (Thread)
From: 9000
2009-10-06 05:44 pm
TDD — он не про то ведь, как написать красивый и эффективный код. Он про то, как контролировать для себя корректность кода.
Agile — не про то, как [...]. Он про то, как всегда иметь прототип для показа заказчику и последовательно его рихтовать и оживлять.

Могу вообразить, что хороший системный программист напишет решение судоку на ассемблере коротко, понятно и легко читаемо, а плохой программист на хаскеле — длинно, непонятно и медленно. Но точно так же может выйти наоборот; всё зависит от того, на какой стороне окажется хороший программист.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: xfyre
2009-10-06 05:39 pm
никакая, даже самая хорошая методология не может сделать хорошего программиста из плохого, и vice versa. методологии - они про организацию производства, а не про организацию мозгов :)
(Ответить) (Thread)
[User Picture]From: quappa
2009-10-06 05:45 pm
«Поскольку наш кузнец Вася, как выпьет, может забить гвоздь в бревно кулаком, давайте объявим молотки вредным карго-культом»
(Ответить) (Thread)
[User Picture]From: french_man
2009-10-06 05:47 pm
Я, собственно, не совсем понимаю, причем тут язык. Если есть алгоритм, то он более-менее должен реализовываться на любом языке. А если нет, то и самый прекрасный язык бесполезен.
(Ответить) (Thread)
[User Picture]From: avva
2009-10-06 05:49 pm
Язык совершенно ни при чем, я просто указывал его для полноты информации.
(Ответить) (Parent) (Thread)
From: 9000
2009-10-06 05:50 pm
Кстат, если "семантическая мощность" у питона и руби примерно одинаковая, то Джованнини легко побеждает тем, что в OCaml есть pattern matching, а в лиспе нет.
(Ответить) (Thread)
[User Picture]From: meshko
2009-10-06 05:53 pm
Очень смешно, но дело-то на самом деле не в XP, а только в том, что Норвиг очень умный, а Мартин менее. Можно порассуждать о том, что методология, придуманная средними программистов для средних программистов имеет право на существование.
Хотя сам-то я считаю, что всех, кто любит любые методологии, нужно заставлять выучивать "Нет серебряной пули" Брукса наизусть, окраплять святой водой и отпускать с миром.
(Ответить) (Thread)
[User Picture]From: object
2009-10-08 05:11 am
Да и то, говоря о том, что Мартин менее умен, стоит, видимо, выделить, в чем он менее умен. Потому что в методологии он очень даже умен.
(Ответить) (Parent) (Thread)
[User Picture]From: pingva
2009-10-06 05:56 pm
ну, ты сравнил Норвига (!), пишущего заметку для себя и других умных людей c, кхм, "профессиональным евангелистом", пишущим заметку для "профессиональных разработчегофф". Да еще и про sudoku! (т.е., trivial for the former, virtually insurmountable for the latter)

Это даже как-то нечестно.

(у Рона отвратный Руби)

Бонус про дядю Боба вообще убойный, кошмар.

(Ответить) (Thread)
[User Picture]From: avva
2009-10-06 09:02 pm
ясно, что сравнение неправомерно, но в этом и заключается мессидж :)
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: sdt78
2009-10-06 06:14 pm
+1
(Ответить) (Parent) (Thread)
[User Picture]From: msh
2009-10-06 05:59 pm
При всем моем скептицизме по отношению к Agile, TDD, XP т.д. должен заметить, что при разговоре о технологиях/методологиях программирования примеры меньше 6 человеко-месяцев неинтересны.
(Ответить) (Thread)
[User Picture]From: xfyre
2009-10-06 06:38 pm
мне вообще не очень понятно, зачем сравнивать теплое с мягким

любые методологии (хоть agile, хоть iso, хоть черт в ступе) предназначены для организации производственного процесса и снижения рисков, связанных с человеческим фактором.

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

p.s. второй пример вообще некорректен: текст на clojure честно предваряется замечанием "I’m trying to learn Clojure, and I’m finding the effort challenging. Perhaps you can help me."
(Ответить) (Parent) (Thread)
[User Picture]From: cema
2009-10-06 06:11 pm
А я подумал, что просто Норвиг хороший программист. Но последний абзац, конечно, ключевой (в твоём посте).
(Ответить) (Thread)
[User Picture]From: kanishchev
2009-10-06 07:08 pm
А какая сложность предложенного алгоритма решения судоку? Спасибо!
(Ответить) (Thread)
From: yacpdb
2009-10-06 07:20 pm
Экспоненциальная от числа пустых квадратов, вроде. Constraint handling сильно разрежает дерево перебора, но ассимптотически это по-прежнему перебор.
(Ответить) (Parent) (Thread) (Развернуть)
(Удалённый комментарий)
[User Picture]From: eoai
2009-10-06 08:54 pm

Напоминает грустный анекдот о паттернах проектирования.

Разработчики пишут письмо Э. Гамма: "Мы реализовали в нашей системе уже двадцать шаблонов, а теперь думаем, как нам еще впихнуть в нее оставшиеся три. Уже весь мозг сломали, пытаясь придумать. Может вы взглянете на архитектуру и чего-нибудь посоветуете?"
(Ответить) (Thread)
[User Picture]From: avva
2009-10-06 09:00 pm
Ага, все это было бы смешно...
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: gruimed
2009-10-06 08:56 pm
Прочитайте код кернела линукса и gcc и возможно уверенность в том что вы знали все о XP станет несколько менее непоколебимой. "Читайте код" (С).
(Ответить) (Thread)
[User Picture]From: avva
2009-10-06 08:59 pm
Да читал я код линукса. И gcc. И даже gdb. И выжил, хотя до сих пор иногда просыпаюсь в холодном поту, с криком, застрявшим в горле.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: vvs2002
2009-10-06 09:06 pm
специалист по Agile, XP и UML, автор книг обо всех этих методологиях, пишет код на Clojure,

Матиас Джованнини пишет код на OCaml, без TDD, для решения той же проблемы.


По-моему, у Вас тут передергивание. Мартин изучает Clojure (I’m trying to learn Clojure) и сомневается в своем решении (tests, especially, look bizzare and backwards to me).

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

(Ответить) (Thread)
[User Picture]From: avva
2009-10-06 09:41 pm
Да, тут есть некоторая натяжка. Проблема в том, что у Мартина нет вообще почти никакого кода, по которому его мастерство можно было бы как-то оценить.
(Ответить) (Parent) (Thread)
[User Picture]From: begemotv2718
2009-10-06 10:33 pm
Посмотрел я свой собственный (древний) код для судоку -- пожалуй что намного хуже даже второго будет в смысле читаемости. Пойду убиваться об стенку... Я, правда, тогда его быстро сравнительно написал...
(Ответить) (Thread)
[User Picture]From: dimrub
2009-10-06 10:55 pm
Интересно, я как раз на днях попробовал написать программу для решения судоку, но забыл ее на уже бывшей работе, не успев доделать. Попробую еще разок.
(Ответить) (Thread)
[User Picture]From: ygam
2009-10-06 11:05 pm
Ты в курсе того, что это NP-полная задача?
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: amosk
2009-10-07 04:32 am
В примере на Ruby автор статьи постоянно оправдывался что нарушает принцип YAGNI, мол это только рекомендации, а не жесткие правила, и в некоторых ситуациях можно нарушать.
Но если посмотреть шире, то сама TDD является сознательным полномасштабным нарушением YAGNI: она буквально построена на написании кода который в данный момент не требуется - тестов.
(Ответить) (Thread)
From: illy_drinker
2009-10-08 12:52 am
поразился сколько в этой дискуссии аббревиатур, которые я не знаю (YAGNI)
(Ответить) (Parent) (Thread)
[User Picture]From: silugram
2009-10-07 07:20 am
Вот это класс :-)
Sudoku is "a denial of service attack on human intellect"
(Ответить) (Thread)
[User Picture]From: cousin_it
2009-10-07 08:09 am
Reading those posts by Jeffries felt almost physically painful.
(Ответить) (Thread)
[User Picture]From: avva
2009-10-07 08:57 am
Yup.
(Ответить) (Parent) (Thread)
From: iizc
2009-10-07 02:15 pm
Замечательная статья Норвига. Я не думаю однако, что те кто пишет или компилирует книги для обучения в 3 дня верят, что это реально - они отвечают на массовый запрос.

Что касается TDD я буду осторожен: Некоторое время тому назад написал review на Амазоне о "Test Driven: TDD and Acceptance TDD for Java Developers" by Lasse Koskela. Немножко перебрал с оценкой: книга вовсе не плохая, много хороших примеров, техники тестирования и т.д. Меня почти единогласно побили ногами и обещали не брать на работу за ересь.

В целом проблема на мой взгляд заключается в том, что когда принцип (даже хороший) возводится в ранг религии, внимание переключается от проблем к поддержанию чистоты принципа. Тесты хороши и дизайн ой как нужен, особенно, если большое и надолго.
(Ответить) (Thread)
[User Picture]From: gineer
2009-10-07 03:06 pm

добавлю свои 5 копеек

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

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

То есть, выражаясь прямо -- это два примера которые некорректно сравнивать, тем более без оговорок.

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

Еще.
Есть у Гаррисона такая повесть. http://ru.wikipedia.org/wiki/Фантастическая_сага
Где сценариста отправляют машиной времени куда-то в мезозой, и он там несколько месяцев пишет сценарий фильма.
А по времени студии проходит всего один час, и директор студии на радостях, порывается оплатить не несколько месяцев работы над сценарием, а только этот один час, на что режисер ему аргументировано отвечает --

http://lib.web-malina.com/getbook.php?bid=1438&page=9
""- Сценарий за час! - на лице Л.М. появилась счастливая улыбка. - Да
это же настоящая революция в кинопромышленности! Давай не будем скупиться,
Барни. Дадим этому парню самую высокую ставку, какая у нас есть, а затем
увеличим ее в два раза! Я не скупердяй. Мне хочется поступить по
справедливости, и уж я позабочусь о том, чтобы Чарли Чанг получил самую
высокую почасовую оплату, которая когда-либо была выплачена сценаристу за
один час его времени!
- Вы не совсем поняли меня, Л.М. Может быть, это с вашей точки зрения
прошел всего один час, но Чарли Чанг трудился как ишак над этим сценарием
более двух месяцев, включая субботы и воскресенья, и ему придется
заплатить за все это время.
- Он не сможет этого доказать! - Л.М. сделал свирепую гримасу.
- Нет, сможет. Каждый день он пробивал карточку на часах-табеле, и к
сценарию приложены все его карточки.
- Тогда пусть обращается в суд! На работу потребовался один час, и я
заплачу ему за один час.
- Сэм, - взмолился Барни, - поговорите с ним. Скажите ему, что в этом
мире ничего нельзя получить даром. Ведь деньги за восемь недель работы -
это гроши за такой великий сценарий!
- Мне больше нравится одночасовой сценарий, - заметил Сэм.
- Нам всем они больше нравятся, только одночасовых сценариев на свете
не бывает. Это просто новый метод работы, однако нам придется платить ту
же самую сумму за работу, что бы ни случилось.
""
(Ответить) (Thread)
[User Picture]From: greps
2009-10-07 07:07 pm

Классный пост!

1. Спасибо автору поста за интересный наброс пост.
2. Тем не менее - самый главный (IMHO) элемент успеха работы Норвига - что он работал ОДИН (и для собственного удовольствия, а не в коллективе с половиной команды из Индии и - сдать работу за две недели....). И еще, по поводу ТДД - а кто-то проверил что это действительно работает на всех квадратиках? Или это должно быть так поскольку само решение так построено?
(Ответить) (Thread)
From: (Anonymous)
2009-10-08 06:01 am

One more egghead jumps into the brawl

Sudoku and the way of the SAT solver
http://bramcohen.livejournal.com/70250.html
(Ответить) (Thread)
From: ex_benzel
2009-10-09 12:27 am
Я что-то не понял, что надо оценить -- разницу в количестве кода?
XP, Agile и всякий Скрам мне видятся чем-то вроде сект, не скрою. Но все же это перебор -- доказывать, что тестирование не нужно, на примере бесполезных олимпиадных задач. Все-таки количество строк в коде слабо коррелирует с его понятностью.
Если вспомнить Брукса, тесты -- это одна из тех вещей которая отличает программный продукт от программы.
Или я опять-таки чего-то не понял.
(Ответить) (Thread)
[User Picture]From: avva
2009-10-09 05:24 am
Я вовсе не доказываю, что тестирование не нужно.
(Ответить) (Parent) (Thread)
Страница 1 из 2
<<[1] [2] >>