программистское: посмотрите и сравните

[avva]

Питер Норвиг, автор (помимо множества прочих заслуг) знаменитых книг об 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

[nm-work.livejournal.com]

:) Agile и XP имеют свои преимущества, но я считаю что эти процессы нужно адаптировать к команде/продукту.

в одной из систем у нас, например, несколько критически важных классов были вообще вне тестов. сознательно :) потому что писать тесты на них заолбаешься, а если что в них поломать - слетает вся система, так как ими пользуются ВСЕ оставшиеся ;)

[xfyre.livejournal.com]

никакая, даже самая хорошая методология не может сделать хорошего программиста из плохого, и vice versa. методологии - они про организацию производства, а не про организацию мозгов :)

[quappa.livejournal.com]

«Поскольку наш кузнец Вася, как выпьет, может забить гвоздь в бревно кулаком, давайте объявим молотки вредным карго-культом»

[french-man.livejournal.com]

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

[nine_k]

Кстат, если "семантическая мощность" у питона и руби примерно одинаковая, то Джованнини легко побеждает тем, что в OCaml есть pattern matching, а в лиспе нет.

[meshko.livejournal.com]

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

[pingva.livejournal.com]

ну, ты сравнил Норвига (!), пишущего заметку для себя и других умных людей c, кхм, "профессиональным евангелистом", пишущим заметку для "профессиональных разработчегофф". Да еще и про sudoku! (т.е., trivial for the former, virtually insurmountable for the latter)

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

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

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

[mikhail-t.livejournal.com]

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

[msh.livejournal.com]

При всем моем скептицизме по отношению к Agile, TDD, XP т.д. должен заметить, что при разговоре о технологиях/методологиях программирования примеры меньше 6 человеко-месяцев неинтересны.

[cema.livejournal.com]

А я подумал, что просто Норвиг хороший программист. Но последний абзац, конечно, ключевой (в твоём посте).

[kanishchev.livejournal.com]

А какая сложность предложенного алгоритма решения судоку? Спасибо!

[astoon.livejournal.com]

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

[eoai.livejournal.com]

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

Разработчики пишут письмо Э. Гамма: "Мы реализовали в нашей системе уже двадцать шаблонов, а теперь думаем, как нам еще впихнуть в нее оставшиеся три. Уже весь мозг сломали, пытаясь придумать. Может вы взглянете на архитектуру и чего-нибудь посоветуете?"

[gruimed.livejournal.com]

Прочитайте код кернела линукса и gcc и возможно уверенность в том что вы знали все о XP станет несколько менее непоколебимой. "Читайте код" (С).

[vvs2002.livejournal.com]

специалист по Agile, XP и UML, автор книг обо всех этих методологиях, пишет код на Clojure,

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

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

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

[begemotv2718.livejournal.com]

Посмотрел я свой собственный (древний) код для судоку -- пожалуй что намного хуже даже второго будет в смысле читаемости. Пойду убиваться об стенку... Я, правда, тогда его быстро сравнительно написал...

[dimrub.livejournal.com]

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

[amosk.livejournal.com]

В примере на Ruby автор статьи постоянно оправдывался что нарушает принцип YAGNI, мол это только рекомендации, а не жесткие правила, и в некоторых ситуациях можно нарушать.
Но если посмотреть шире, то сама TDD является сознательным полномасштабным нарушением YAGNI: она буквально построена на написании кода который в данный момент не требуется - тестов.

[silugram.livejournal.com]

Вот это класс :-)
Sudoku is "a denial of service attack on human intellect"

[cousin-it.livejournal.com]

Reading those posts by Jeffries felt almost physically painful.

[iizc.livejournal.com]

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

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

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

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

[gineer.livejournal.com]

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

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

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

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

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

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

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

[greps.livejournal.com]

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

One more egghead jumps into the brawl

[(Anonymous)]

Sudoku and the way of the SAT solver
http://bramcohen.livejournal.com/70250.html

[ex-benzel.livejournal.com]

Я что-то не понял, что надо оценить -- разницу в количестве кода?
XP, Agile и всякий Скрам мне видятся чем-то вроде сект, не скрою. Но все же это перебор -- доказывать, что тестирование не нужно, на примере бесполезных олимпиадных задач. Все-таки количество строк в коде слабо коррелирует с его понятностью.
Если вспомнить Брукса, тесты -- это одна из тех вещей которая отличает программный продукт от программы.
Или я опять-таки чего-то не понял.