Если Вы хотите одолжить на время книгу, которой у Вас нет, взамен предоставив доступ к своей библиотеке, то воспользуйтесь ссылкой , сообщив поселок / город / область, где Вы бываете, тему книг или названия книг, которые хотите прочесть и которые можете дать. Соответствующее объявление появится в выпусках рассылки.

Если Вы прочли книгу, но мнение о ней еще никто не просил, все равно - присылайте, и Ваше мнение попадёт в следующий же выпуск.

Нужен совет по выбору книги? - Спроси .

Digmet:
      Ситуация как у меня. Криптография с нулевого уровня для программистов. Читал книгу Брюс Шнайер "Прикладная криптография. Протоколы, алгоритмы, исходные тексты на Си" 2-е издание ( Триумф, 2003 ). Очень понравилось и всем рекомендую. Просто, доступно, и главное, не попсово на нормальном уровне изложено.

В выборе книги для обзора в этом выпуске участвовало 24 подписчика. 10 голосов было отдано за рефакторинг "Рефакторинг. Улучшение существующего кода" Фаулера. Читайте в этом выпуске.

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

Ведь всё просто, ибо скорее всего им это "тривиальное" решение кто-то случайно рассказал. Многие вещи стали привычными как раз потому, что кто-то когда-то нашёл решение, а дальше это решение просто пересказывается из поколения в поколение. Для нас очевидно, что слова удобней писать через пробелы, а не очень далёкие предки почти не использовали char(32): Можносказать,чтодополн ительныесимволыизлишни,онизамедляютписьмо,инужнытолькоту пымучениками,которыеникакнеосвоятазбуку. Смогли прочесть, не проговаривая? Применение пробелов дало нам скорость чтения. А смогли бы Вы _сами_ додуматься до использования пропуска как значащего символа?

При программировании таких "чаров" очень много. До какой-то части каждый из нас додумывается сам. Причем каждый до разных частей :) Что-то по ходу дела расскажет старший товарищ, а скорее всего подсмотришь, и станешь делать так же. А вот додуматься, что этому НУЖНО учить не на личном примере, а как методологию технологии.... Кого из Вас в школе учили как сочинение на 2 балла превратить в сочинение на 5 балов? А? Не как _сразу_ написать на 5 балов, а как замызганную всюду штопанную тряпочку превратить в бальное платье? Хотите узнать? - Читайте "улучшение существующего кода".

Теперь как читать. Для тех, у кого уже есть опыт публичных программ, стоит внимательно разобрать пример первой главы. Затем либо за объяснениями обратиться к главам 2 и 3 "принципа рефакторинга" и "код с душком", либо более опытным посмотреть главы 12 и 13 "крупные рефакторинги" и "повторное использование и реальность". Главы 6-11 являются справочником, и его нужно просто пробежать глазами - нет ли чего нового для вас лично. Лично мне было интересно сопоставлять мотивировку противоположных рефакторингов (замена значения ссылкой против замена ссылки значением), сравнивая со своими знаниями.

Для очень продвинутых и для редких пользователей SmallTalk-а будет очень интересна глава "Инструментальные средства проведения рефакторинга".

А начинающим программистам лучше начать с главы "код с душком", потом сразу вернуться к главе 2 "принципы рефакторинга", и только потом внимательно знакомиться со справочником главы 6-11. Несомненно разбирать примеры на Java c читабельными по-английски идентификаторами большинству, и, к сожалению, большинству школьных учителей, будет очень тяжело :(( Я намерено выделила _школьных_ учителей, так как по моему глубочайшему убеждению рефакторингу нужно учить одновременно с обучением кодированию, которое в настоящий момент во многих школах подменяет уроки информатики :(( - очень корявая фраза, но хорошей книги с пошаговыми инструкциями для рефакторинга текста на русском языке - не знаю :(

Возвращаясь к главному вопросу. Нет не "читать или не читать" - несомненно ЧИТАТЬ! И лучше в оригинале - если и будете зевать, то по-английски :)) Теперь к главному - покупать или нет, т.е. в личную библиотеку, или прочел и выбросил/продал/подарил? Вопрос сложный, ибо внешний формат не соответствует внутренней сути. В пятой главе автор специально выделил раздел "Насколько зрелыми являются предлагаемые методы", где чётко сказано, что эта книга - draft. Поэтому избыток пустых мест, белая красивая бумага, твердый переплёт здесь совершенно неприемлем. Я устала от того, что нужные ежедневные книги стали делать большими толстыми и тяжелыми. Я не могу брать этих монстров читать по дороге, они перестали помещаться в мои дамские сумочки :(( По-умному, нужно было бы выделить справочник методов в один том, а остальные главы в другой. Это чуть меньше двухтомного детектива. Тогда я копию купила бы и себе, а так просто верну книгу хозяину.

Ворчуния
(май 2005)

Опытные программисты знают, что разработка действительно большой программной системы со временем становится почти неуправляемой. Все благие намерения следовать графику, планомерно завершать этапы разработки, оказываются "дорогой в ад". Энтропия системы увеличивается - она сползает к хаосу. Как говорит Мартин Фаулер, "код медленно сползает от проектирования к хакерству". Заплаты ставятся на заплате, часто в спешке, лишь бы работало. То, что работает, по негласной заповеди программистов, неприкосновенно. Исправления делаются только при обнаружении ошибки. С этих позиций книга Мартина Фаулера и других гуру-программистов - прямо-таки потрясение основ! Изменять работающий код - так и хочется повертеть пальцем у виска! Но "торописса - не надо!"

Эта книга стоит в одном ряду с такими эпохальными трудами, как "Искусство программирования" Кнута, "Дисциплина программирования" Дейкстры, "Паттерны проектирования" Банды четырех и других. Однако она здорово отличается от всех других. Все книги учат, как надо правильно писать программы с самого начала. Эта же книга гораздо ближе к реальной жизни: в ней даются практические рецепты, как исправлять уже написанный код. Улучшенный код - более простой, надежный и быстродействующий. Как говорит сам Фаулер, "каждый шаг этого процесса прост до чрезвычайности. ... Однако суммарный эффект таких небольших изменений может радикально улучшить проект. Это прямо противоположно обычному явлению постепенного распада программы". И термин придуман звучный: РЕФАКТОРИНГ!

Для кого написана эта книга, пишет сам автор: "Книга рассчитана на профессионального программиста - того, кто зарабатывает себе на жизнь программированием". Пожалуй, наиболее ценной частью книги является список рефакторингов - приемов преобразования кода. Однако сам список ничего не даст, если не знать, в каких случаях его применять. Это во многих случаях основано на опыте и интуиции. Авторы попытались описать интуитивный процесс, выделив признаки плохого кода. Термин для этого придуман совершенно блестящий - "код с душком"! Очень интересной является глава 4 - о самопроверяющихся тестах. Описываются принципы организации среды тестирования Junit.

Книга написана просто и понятно, читается почти как детектив - на одном дыхании. Много реальных историй из жизни авторов. Код постоянно сопровождается соответствующими диаграммами UML. Несмотря на то, что код написан на Java, предмет книги ни в коей мере с кодом не связан - те же приемы с успехом можно применять и при программировании на других языках. По каким-то неизвестным нам причинам ряд книжек об антипаттернах ("Горький вкус Java" Брюса Тейта, "Типичные ошибки проектирования" Эрика Аллена) написаны для Java. Это отнюдь не снижает их ценности для других программистов.

Эту книжку должен держать под рукой каждый профессиональный программист.

Лаптев В.В.
(рецензия на РСДН)

Ваше мнение тоже будет ценным

Рефакторинг:улучшение существующего кода Мартин Фаулер Refactoring. Improving the Design of Existing Code Martin Fowler   Дата выпуска: 2003 Издательство: Символ-Плюс     ISBN: 5-93286-045-6 Формат: 24 x 17 см,   432 страницы твердый переплет,   вес - 700 г Цена:   399  рубля ( Чакона (Самара) )    360  рубля ( Books.ru )    403  рубля ( Bolero )