Программистские книжки

[dimrub]

Читаю по наводке object уже третью книгу подряд. Вот они в порядке прочтения:

1. Agile software development
2. Test driven development by example
3. Refactoring (это та, которую сейчас читаю)

Мне, такому всему из себя "матерому зубру", должно быть немного неловко, но эти книги были для меня настоящим eye opener-ом. В отличие от традиционных книг по программированию, которые либо описывают конкретную технологию, либо говорят о дизайне в идеальном мире (см., скажем, Буч либо гэнг оф фор), эти книги говорят о том, как решать проблемы, с которыми большинство программистов вынуждены сталкиваться на практике в течении 90% своей профессиональной деятельности (время, потраченное на заседания, перекуры и тренинги - не в счет). Например - как быть, когда приходится иметь дело с кодом, написанным годы назад неизвестно кем, а потом поддерживающимся еще кучей народу, мало кто из которых до конца понимал, как работает код, который он изменяет. Как вести себя в условиях постоянно меняющихся требований, в условиях, когда эти новые требования тянут код в направлении, о котором не думали при певоначальном дизайне. И так далее. Очень рекомендую всем, кто еще не (и кто не дошел до всего своим умом).

Comments

[avva.livejournal.com]

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

TDD я воспринимаю как крайний случай такой вообще говоря невероятно полезной штуки, как commitment to thorough testing, в основном юнит-тестингу. Тесты - потрясающе полезная штука, когда их принимают всерьез; поддерживание юнит-тестов для всего вокруг - невероятно освобождающая (в смысле liberating) техника.

TDD, как радикальный вид серьезного юнит-тестинга, на мой взгляд бывает очень полезен, но не всегда универсально применим. Я не убежден в этом до конца, но мне кажется (и встречались такие случаи), что есть проекты и ситуации, когда TDD просто "не идет", и лучше сначала сделать какое-то количество exploratory programming, поиграть с несколькими основными возможностями, получить с помощью реального, пусть и очень простого и скелетного, кода лучшее представление о том, что мы собственно хотим сделать и какое поведение ожидаем от данного куска, а потом добавить к нему тесты. Если вместо этого силой тянуть TDD, может получиться медленно и более коряво. Так мне кажется (хотя опыта и наблюдений не так много, чтобы делать уверенные выводы). С другой стороны, несомненно есть ситуации, в которых TDD может быть полезен.

Более того, я бы сказал, что commitment to thorough testing на порядок важнее выбора "TDD или не TDD".

Из-за того, что TDD часто представляют как часть agile (или extreme programming, предыдущей инкарнации той болезни, которая сейчас называет себя agile), литература по нему и энтузиасты его часто оказываются заражены агилевским баззвордизмом и радикализмом (т.е. считают, что нужно TDD всегда и везде, и тот, кто решил в каком-то конкретном случае написать сначала код, а потом тест к нему - всегда предатель и ренегат). Я же вижу интерес к тестированию как что-то, что здоровым образом выросло независимо от моды на всякие агили. У очень динамических с точки зрения типизации языков (perl, python, Lisp итд.) еще с середины 90-х были развитые и полезные testing frameworks, потому что в этих языках тесты ловят ошибки, которые в других языках ловит компилятор (а также и кучу других ошибок, конечно). Постепенно увлечение тестами перекинулось с этих языков на Джаву итд., без всяких агилей, которые в определенном смысле стремятся сейчас представить это как свое достижение.

[dimrub.livejournal.com]

TDD я воспринимаю как крайний случай такой вообще говоря невероятно полезной штуки, как commitment to thorough testing, в основном юнит-тестингу.

Угу. При этом я обнаружил, что лично мне проще произвести этот commitment именно в режиме, о котором говорит TDD, т.е. test-code-refactor (хотя и без фанатизма, при котором функция при первых прогонах возвращает константу - только бы прошел первый тест). YMMV, как говорится.

Более того, я бы сказал, что commitment to thorough testing на порядок важнее выбора "TDD или не TDD".

Безусловно.

extreme programming, предыдущей инкарнации той болезни, которая сейчас называет себя agile

XP - это одна из методологий, существующих под "зонтиком" агиля. Вообще, ты прав, что агиль - это нечто очень аморфное, но в то же время это некий набор ну self-checks что-ли, которые позволяют (тьфу, глупость) переосмыслить свою деятельность. Скажем, когда они говорят value working code over documentation - это звучит, как банальность, но во многих случаях оказывается, что все наоборот, тратят кучу времени на ловлю собственного хвоста в попытках закрепить на бумаге то, что закрепить нельзя. И так далее - я тоже очень осторожно на это все смотрю, но нет-нет и замечаю кое-какие очень верные вещи.


Постепенно увлечение тестами перекинулось с этих языков на Джаву

Насколько я знаю, это пришло, наоборот, из smalltalk. Я его совсем не знаю, но он же, вроде, достаточно strongly typed?

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

Не сталкивался с таким. В книжке как раз напирают на то, что без TDD нет агиля, но агиль не есть TDD (и не с него начался).

[cmm.livejournal.com]

Насколько я знаю, это пришло, наоборот, из smalltalk. Я его совсем не знаю, но он же, вроде, достаточно strongly typed?

неа, он как раз динамический до упора.
недаром его автора трясёт при любом упоминании термина "ООП" в современном смысле.

[avva.livejournal.com]

what he said.

[avnik.livejournal.com]

С другой стороны лучше agile+TDD, чем без тестов вообще, +объяснение менеджерам закащзчика что такое тесты, и почему на них расходуются средства.

[haiut.livejournal.com]

На мой взгляд, абсолютно все вредно, если оно доведено до фанатизма.. А если без фанатизма, то и agile, и TDD вполне неплохо работают для многих организаций; главное, не воспринимать это все как абсолютную истину и не стесняться адаптировать эти методы под нужды и, главное, возможности команды.

А про TDD и commitment to thorough testing я так думаю: CTTT это правильная, но несколько абстрактная и абсолютно неконтролируемая штука, которая сильно зависит от личного восприятия каждого отдельного программиста. TDD загоняет этот самый commitment в некие рамки, т.е. превращают абстрактную штуку в простую, полезную и "сьедобную" схему.

И с рефакторингом, кстати, такая же штука. Методы, описываемые в книге просто помогают мальчикам и девочкам делать свою работу. Есть очень умные мальчики и девочки, которые и без книжки сразу узнают кривой код, и с легкостью решают проблемы и наводят красоту (см. твой план рефакторинга из 4х пунктов ниже), а есть такие, которым нужна помощь. Помощь старшего товарища или умной книжки, которая систематизирует и упрощает процесс. Книжка, в целом, полезнее и дешевле. Старший товарищ, как fallback, тоже тут.

And then again, без фанатизма ;-)

[avva.livejournal.com]

Видишь ли, "агиль без фанатизма" это идея, которая теоретически может сработать и привести к хорошим результатам, наверное, т.е. я могу себе это представить; но на практике снова и снова вижу, как она приводит в лучшем случае к чему-то очень посредственному и унылому. По-моему, это оттого, что маркетинговая сущность агиля разъедает моск.

[dumalkin.livejournal.com]

ну наконец-то "луч света в темном царстве" :)
+1Е5

[dimrub.livejournal.com]

И еще по поводу TDD: чисто психологический момент, имеющийся лично у меня, у других с этим проблем, возможно, нет: мне очень тяжело заставить себя сосредоточиться на уже написанном мною коде. Теперь чуть легче, чем бывало, а раньше это была серьезная проблема. Даже в университете на экзаменах мне, бывало, очень тяжело приходилось, когда оставалось время до конца экзамена, и надо было пройтись по всему экзамену и проверить, что же я там понаписал. Так и с тестами: в тот момент, когда код написан, и надо начинать писать тесты, я вхожу в procrastination mode. А TDD позволяет сделать тестирование интегральной частью собственно написания кода: в тот момент, когда код готов, тестов писать уже не надо. Это, разумеется, не совсем верно, потому что речь только о юнит тестах, интеграционные тесты все равно потом надо делать, но значительная часть работы уже сделана.

[avva.livejournal.com]

Да, соглсасен, в этом смысле TDD может быть психологически полезен. Но есть и другие способы мотивировать создание тестов. Например, можно стремиться создать культуру очень высокой заинтересованности тестов внутри компании, автоматическое измерение code coverage, которым можно гордиться, автоматический прогон тестов на каждое новое изменение в коде (очень помогает научиться ценить тесты), итд.