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

[dimrub]

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

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

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

Comments

[dimrub.livejournal.com]

В агиле, как раз, мне далеко не все нравится. Но TDD и рефакторинг (именно в смысле, который в это слово вкладывает книжка) кажутся мне очень мощными инструментами.

[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, которым можно гордиться, автоматический прогон тестов на каждое новое изменение в коде (очень помогает научиться ценить тесты), итд.

[avva.livejournal.com]

Что же касается рефакторинга, то это просто надо уметь и делать, да. Неясно, чему здесь особо учить, кроме одной главной, и действительно нетривиальной поначалу мысли: при наличии commitment to thorough testing (! - критически важная составляющая), рефакторинг - довольно безопасная и часто очень полезная штука, и следует преодолеть боязнь менять существующий работающий, но сделанный через задницу, код. Если она этому учит, то это хорошо, но нужна ли целая книга? :) Впрочем, я ее не видел.

[dimrub.livejournal.com]

Ну да, все верно, просто книга несколько систематезирует рефакторинг, тем самым его во многих случаях упрощая. Что-то типа чеклиста для каждого вида рефакторинга.

[avva.livejournal.com]

А какие бывают виды? Я представляю себе один вид:

1. Это написано черед задницу.
2. (напряженная работа мысли)
3. Это должно быть написано вот так!
4. Меняем.

[dimrub.livejournal.com]

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

[dumalkin.livejournal.com]

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

У нас один есть - любитель ООП в извращенной форме. В одном модуле он использовал 3 вида базовых классов - template, prototype & base (в смысле этими словами оканчивались названия базовых классов).
Я его попросил объяснить разницу (чем ВеникTemplate концептуально отличается от МетелкиPrototype), ее никто не понял. В итоге я его уговорил писать по принципу KISS, и вся красота была поругана - остался один вид, который ради умиротворения я ему дал назвать template (дав в качестве домашнего задания разобраться чем С++ template отличается от generics, и как они живут вместе в managed c++.)

[avnik.livejournal.com]

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

[avva.livejournal.com]

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