Объектно-ориентированный анализ и проектирование. Часть 3. Объектная модель. Основные определения.

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

В мире объектно-ориентированного анализа и проектирования также есть своя терминология и ключевые определения. Что такое ООП, что такое абстракция, что такое инкапсуляция и т.д. Всего определений огромное количество, поэтому в этом сообщении я ограничусь лишь основными, взятыми из главы 2. “Объектная модель” замечательной книги Гради Буча “Объектно-ориентированный анализ и проектирование с примерами приложений”.

Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образую иерархию наследования

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

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

Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

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

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

Иерархия - это упорядочение абстракций, расположение их по уровням.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм (concurrency) - это свойство, отличающее активные объекты от пассивных.

Сохраняемость (persistence) - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

Путь камикадзе. Часть 1

Сложно сказать что-либо новое о легендарной книге Эда Йордона “Путь камикадзе”, т.к. она уже давно стала классической в своей области. В бумажном виде у меня есть только первое издание, а оригинал вышел еще в 1997 году (хотя автор вовсю уже работает над третьим, подробности можно почитать здесь). Но если немного перефразировать Фредерика Брукса (правда он говорил это по отношению к другой легендарной книге в области управления проектами - “Peopleware”): этой книге уготована долгая жизнь по той же причине, почему рассказы Гомера пережили тысячи лет: эти рассказы о людях, и они также верны сегодня, как и тысячу лет назад.

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

Неразумное поведение корпораций заключается в том, что они делают одно и то же снова и снова, каждый раз ожидая различных результатов.
Глава 1.

Под безнадежным проектом я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%.
Глава 1.1 Определение безнадежного проекта

Другой способ охарактеризовать безнадежный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.
Глава 1.1 Определение безнадежного проекта

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

Многие разработчики ПО клянутся, что не дадут втянуть себя в политические игры, поскольку они считают это не своим делом. Кроме того, они полагают, что все связанное с политикой, - отвратительно. Увы, уйти от политики невозможно; как только в какое-либо совместное предприятие войдут двое или более человек, тут же начнется политика.
Глава 1.3.1 Политика, политика, политика

Если вы - революционер или мученик, то можете повоевать с корпоративной культурой, но вряд ли у вас при этом хоть что-нибудь получится.
Глава 1.3.5 Менталитет "Морского Корпуса": Настоящие программисты могут работать без сна!

Вознаграждение бывает не только денежным. Иногда просто приятно получить похвалу от руководителя проекта или доказать самому себе, что вы можете не растеряться в сложившейся ситуации.
Глава 1.4.1 Риск высок, но и вознаграждение тоже

“Джоэл о программировании”. Часть 2.

Вторая порция цитат из замечательной книги Джоэла Спольски “Джоэл о программировании”.

Вы хватаете за рукав первого попавшегося вам в коридоре человека и требуете, чтобы он поработал с кодом, который вы только что написали. Проделайте это пять раз и вы найдете 95% всех проблем с юзабилити в своем коде
("Корридорное тестирование")
Глава 3. Проводится ли юзабилити-тестирование на случайных людях?

Продвижение хороших кодеров выдвижением их на другие должности, где требуется писать на человеческом языке, а не на С++, служит классической иллюстрацией принципа Питера: люди продвигаются по службе, пока не достигнут своего уровня некомпетентности.
Глава 7. Как принимать на работу менеджера программы?

Многие неопытные менеджеры полагают, что могут "стимулировать" более быструю работу своих программистов, если будут задавать для них трудные, "напряженные" (нереалистично быстрые) графики. Я думаю, что такого рода мотивация - глупость. Если я выбиваюсь из графика, я чувствую себя обреченным, подавленным и немотивированным. Если же я работаю с опережением графика, я чувствую себя бодрым и работоспособным. Психологические игры с графиком очень опасны.
Глава 9. Ни в коем случае не позволяйте программистам занижать оценку времени.

Если у вас есть кучка деревянных кубиков, которые не помещаются в коробку, есть два выхода: взять коробку побольше или убрать некоторые кубики. Если вы думали, что сможете сделать продукт через 6 месяцев, а по графику получается 12, вам придется либо отложить выпуск продукта, либо отказаться от каких-то функций. Сделать кубики меньше вы не можете, а если вы считаете, что можете, значит, вы лишаете себя полезной возможности реально смотреть в будущее и лжете себе о том, что вы там видите.
Глава 9. График похож на набор кубиков

Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление
Глава 11. Тотальное уничтожение ошибок

Я заметил, что начиная с самой первой моей работы я как разработчик в среднем лишь два или три часа могу продуктивно писать код, и это меня изумляет. Когда я летом стажировался в Microsoft, то мой коллега-стажер рассказал мне, что фактически он ежедневно активно работал с 12 до 5. Пять часов, минус обед, и его бригада восхищалась им, потому что ему все удавалось сделать гораздо больше среднего. Я обнаружил, что со мной происходит то же самое. Я испытываю легкое чувство вины, замечая, как напряженно, по-видимому, работают все остальные, а у меня получается два или три часа настоящей работы в течение дня, и тем не менее я всегда был одним из самых результативных членов бригады. Видимо по этой причине "Peopleware" и экстремальное программирование настаивают на отмене сверхурочной работы и на строго 40-часовой рабочей неделе, будучи уверенными в том, что объем продукции команды от этого не уменьшится.
Глава 15. Огонь и движение

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Алан Шаллоуей и Джеймс Р. Тротт. Шаблоны проектирования. Часть 1

В “природе” существует не такое большое количество книг по “классическим” шаблонам проектирования, впервые описанных в знаменитой книге Банды Четырех.

Одним из достойнейших представителей этой категории книг является книга Алана Шаллоуея и Джеймса Р. Тротта “Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию”.

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

Множество ошибок появляется при внесении в текст программы изменений.
Попробуйте обосновать это утверждение исходя из собственного опыта. Вспомните, что всякий раз, когда в текст программы необходимо внести изменения, возникает опасение, что изменение текста программы в одном месте может привести к сбою в другом... Как это часто бывает с людьми, необходимость учесть при внесении изменений слишком много различных деталей обычно приводит к появлению ошибок.
Глава 1. Функциональная декомпозиция: в преддверии появления объектно-ориентированной парадигмы

И не имеет значения, сколько усилий было приложено, насколько тщательно был проведен анализ - пользователь просто не может сформулировать все необходимые требования сразу. Слишком много неизвестного несет в себе будущее. Времена меняются. И та было всегда...
Ничто не может предотвратить наступление перемен. Однако это не значит, что к их приходу нельзя подготовиться.
Глава 1. Функциональная декомпозиция: в преддверии появления объектно-ориентированной парадигмы

Любой опрос среди разработчиков программного обеспечения по качеству предоставленных им заказчиком требований к создаваемому программному продукту едва ли даст большое разнообразие ответов. Скорее всего они будут следующими.
- Требования являются неполными.
- Требования по большей части ошибочны.
- Требования (и пользователи) противоречивы.
- Требования не описывают поставленную задачу подробно.
Глава 1. Проблема формулирования требований к создаваемому программному обеспечению

Требования к программному обеспечению всегда изменяются.
Я также понял, что большинство разработчиков знают это обстоятельство и считают его весьма неприятным. Но лишь немногие из них действительно учитывают возможность изменения существующих требований при написании программы.
Глава 1. Проблема формулирования требований к создаваемому программному обеспечению

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

 

Все цитаты из книги книги Алана Шаллоуейа и Джеймса Тротта “Шаблоны проектирования”:

Часть 1

Часть 2

Часть 3

Несколько слов о работе с заказчиком

Объектно-ориентированный анализ и проектирование. Часть 2. Пять признаков сложных систем

Продолжая тему сложности, начатую в первой части цитат из замечательной книги Гради Буча “Объектно-ориентированный анализ и проектирование с примерами приложений”, я хочу отдельно опубликовать пять признаков сложных систем, которые, по мнению автора, присущи любой сложной системе.

 

 

 

1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням."

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

3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами".

4. "Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных".

5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".

Объектно-ориентированный анализ и проектирование. Часть 1. Сложность

В жизни многих разработчиков бывают моменты, кардинально изменившие их профессиональные взгляды, для одних – это изменение места работы, для других – курс в университете, для третьих – книги.

Мне повезло, т.к. эта замечательная книга Гради Буча попала мне в руки на заре моей профессиональной деятельности, когда у меня практически не было собственного мнения относительно того, что же такое процесс разработки, какие его основные сложности или какие плюсы и минусы разных методов проектирования. Поэтому, хорошо это или плохо, но мне не пришлось перестраивать свое мышление, чтобы проникнуться основными идеями этой книги.

Я остановился именно на втором издании книги, а не на третьем, т.к. с моей точки зрения основную ценность представляет первая часть, которая осталась практически без изменений, а также потому что третье издание на русский язык лучше бы вообще не переводили (см. мои замечания по поводу перевода на rsdn.ru). Мое развернутое мнение – как обычно на блоге и на rsdn.ru.

В этом сообщении речь пойдет об одном из самых интересных аспектах разработки ПО – о сложности.

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

Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. Компьютерные программы тоже бывают сложными, однако их сложность совершенно другого рода. Брукс пишет: "Эйнштейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы".
Глава 1.1. Простые и сложные программные системы

Сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных системам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя.
Глава 1.1. Простые и сложные программные системы

"Чем сложнее система, тем легче ее полностью развалить". Строитель едва ли согласится расширить фундамент уже построенного 100-этажного здания. Это не просто дорого: делать такие вещи значит напрашиваться на неприятности. Но что удивительно, пользователи программных систем, не задумываясь, ставят подобные задачи перед разработчиками. Это, утверждают они, всего лишь технический вопрос для программистов.
Глава 1.1. Последствия неограниченной сложности

Эксперименты психологов, например Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два. Вероятно, это связано с объемом краткосрочной памяти у человека. Саймон также отмечает, что дополнительным ограничивающим фактором является скорость обработки мозгом поступающей информации: на восприятие каждой новой единицы информации ему требуется около 5 секунд.
Глава 1.2. Организованная и неорганизованная сложность

Люди развили чрезвычайно эффективную технологию преодоления сложности. Мы абстрагируемся от нее. Будучи не в состоянии полностью воссоздать сложный объект, мы просто игнорируем не слишком важные детали и, таким образом, имеем дело с обобщенной, идеализированной моделью объекта.
Глава 1.3. Роль абстракции

Отладка приложений для Microsoft .NET. Об ошибках и отладке

На этот раз речь пойдет о цитатах из книги Джона Роббинса “Отладка приложений для Microsoft .NET”. В целом, книга весьма не простая, помимо большого числа интересных тем, довольно часто встречаются и довольно “дремучие”. Подробное мнение об этой книге можно посмотреть на моем блоге или на rsdn.ru.

 

 

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

Ошибки - это серьезно! Очень часто люди, работающий в нашей индустрии, представляют себе ошибки просто как досадные мелочи. Сильнее заблуждаться невозможно. Любой разработчик расскажет вам о проектах с немыслимым количеством ошибок и даже о компаниях, загнувшихся оттого, что их продукт содержал столько ошибок, что был непригоден. Когда я писал первое издание этой книги, NASA потеряла космический зонд, направленный на Марс, из-за ошибок, допущенных на этапе формулировки требований и проектирования ПО.
Введение

Пока я писал второе издание на солдат американского спецназа упала бомба, направленная на другую цель. Причиной была программная ошибка, возникшая при смене источника питания в системе наведения. За неделю до того, как я написал это введение к третьему изданию, корпорация Microsoft выпустила пакет исправлений для пакета исправлений, который ранее создал огромную уязвимость, связанную с переполнением буфера в Microsoft Internet Explorer 6.

Хотя к программным ошибкам уже начинают относится с бОльшим уважением, нам еще очень далеко до появления культуры разработки, в которой к ошибкам будут относиться чрезвычайно серьезно, а не как к незначительным проблемам, иногда возникающим в процессе разработки. Ошибки – это круто! Они помогают залезть в самую глубину и понять, как работают вещи. Мы все попали в этот бизнес, потому что нам нравится учиться, выслеживание ошибок – неотъемлемая часть обучения… Ведь так здорово бывает найти и исправить ошибку! Конечно же, самые хорошие ошибки – это те, которые обнаруживаются до того, как заказчик увидит ваш продукт. Таким образом, вы должны успевать сделать свою работу и найти ошибки до того, как это сделают ваши заказчики. Видеть, как заказчики обнаруживают ошибки, - это совершенно не круто.
Введение

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

Глава 1. Ошибки: откуда они берутся и как их устранять

Как выяснилось, мои кошки – отличные отладчики, и они помогли мне решить огромное количество действительно неприятных ошибок. Собирая их вокруг своего рабочего места, я рисую проблему на белой доске и позволяю кошкам воздействовать на меня своими магическими лучами. Конечно же, однажды я делал это, не приняв душ и будучи одетым в одни шорты, - было немного трудно объяснить ситуацию курьеру службы доставки, который все это время ошеломленно стоял у двери.

Глава 1. Шаг 5. Думайте творчески

Помните, что отладчик – это всего лишь инструмент, как например, отвертка. Он делает только то, что вы приказываете ему делать. Настоящий отладчик находится у вас в голове.
Глава 1. Последний секрет процесса отладки

“Джоэл о программировании”. Часть 1.

Сегодня речь пойдет о цитатах из книги “Джоэл о программировании” известного  блогера Джоэла Спольски (www.JoelOnSoftware.com). Это имя уже давно известно многим людям, занятым в области разработки ПО, да и не только в ней. Книга мне понравилась, она написана очень простым и интересным языком, охватывает множество самых разнообразных тем из области разработки программного обеспечения.

По-сути, эта книга является “блуком” (одно из новых веяний в литературе, которое пошло от английских слов book (книга) и blog) и построена на основе наиболее известных статей Джоэла, которые были опубликованы автором на своем сайте. Но несмотря на публичную доступность материала, я все же отдаю предпочтение печатным изданиям; как мне кажется подобную литературу удобнее читать на диване с карандашом, а не перед компьютером. Но не зависимо от формы носителя информации, здесь вы сможете ознакомиться с наиболее выдающимися ее фрагментами, что позволит точнее сформировать ваше собственное к ней отношение:)

Более развернутое мнение об этой книге можно почитать на моем блоге или, как обычно, на сайте rsdn.ru.

Кроме того, с этого сообщения я постараюсь уменьшить количество цитат на одно сообщение, чтобы их было не более 5-6-ти. Если такой формат будет более удачным (или наоборот – менее удачным) – вперед, высказывайте свое мнение в комментариях.

Ну что ж, приступим:)

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

Знаете, что я вам скажу? Управление программными проектами не имеет никакого отношения к программированию. Если вы до сих пор не занимались ничем, кроме написания кода, то вам предстоит открыть, что человеческие существа несколько менее предсказуемы, чем обычный процессор Intel.
Введение

Управление программными проектами требует совершенно иных навыков и приемов, нежели написание кода; это два совершенно различных и не связанных между собой поля. Написание кода так же отличается от управления проектом, как нейрохирургия от выпекания кренделей. Нет никаких оснований полагать, что у блестящего нейрохирурга, каким-то образом попавшего на производство кренделей в результате некоего разрыва в пространственно-временном континууме, окажется хоть малейшее представление о том, как делать эти самые крендели, даже если он окончил Гарвардский медицинский колледж. Но люди, однако, продолжают думать, что можно взять ведущего программиста и без какой-либо переподготовки перевести его в администраторы.
Введение

Я думаю, что некоторые крупнейшие ошибки - даже на самых верхних уровнях архитектуры - происходят из-за слабого или неверного понимания некоторых простых вещей на самых нижних уровнях. Вы построили замечательный дворец, но его фундамент никуда не годится. Вместо аккуратных бетонных плит навален булыжник. Здание выглядит прекрасно, но время от времени по совершенно непонятным причинам ванна начинает скользить по полу.
(О важности мышления на языке байтов)
Глава 2. Обращаясь к основам

В первоклассных командах не принято мучить программистов. Даже мелкие неприятности, вызываемые плохим инструментом, копятся и делают программистов сердитыми и мрачными. А сердитый программист - малопродуктивный программист.
Вдобавок ко всему, программистов очень легко подкупать, приобретая для них самые крутые и новые вещицы. Это гораздо более экономный способ заставить их трудиться, чем платить им более высокие, по сравнению с другими фирмами, зарплаты!
Глава 3. Стараетесь ли вы использовать для работы лучшие инструменты?

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Рефакторинг. Улучшение существующего кода. Часть 2

Обещанное продолжение цитат из замечательной книги Мартина Фаулера “Рефакторинг. Улучшение существующего кода”.

 

 

 

 

 

 

Если что-то плохо пахнет, это что-то надо поменять
                                 - Мнение бабушки Бек, высказанное
        при обсуждении проблем детского воспитания
Глава 3. Код с душком

Увидев одинаковые структуры кода в нескольких местах, можно быть уверенным, что если удастся их объединить, программа от этого только выиграет
Глава 3. Дублирование кода

Мы придерживаемся эвристического правила, гласящего, что если ощущается необходимость что-то прокомментировать, надо написать метод.
Глава 3. Длинный метод.

Весь смысл объектов в том, что они позволяют хранить данные вместе с процедурами их обработки. Классический пример дурного запаха - метод, который больше интересуется не тем классом, в котором он находится, а каким-то другим. Чаще всего предметом зависти являются данные. Не счесть случаев, когда мы сталкиваемся с методом, вызывающим полдюжины методов доступа к данным другого объекта, чтобы вычислить некоторое значение. К счастью, лечение здесь очевидно: метод явно напрашивается на перевод в другое место.
Глава 3. Завистливые функции

Брайан Фут (Brian Foote) предложил название "теоретическая общность" (speculative generality) для запаха, к которому мы очень чувствительны. Он возникает, когда говорят о том, что в будущем, наверное, потребуется возможность делать такие вещи, и хотят обеспечить набор механизмов для работы с вещами, которые не нужны. То, что получается в результате, труднее понимать и сопровождать. Если бы все эти механизмы использовались, их наличие было бы оправдано, в противном случае они только мешают, поэтому избавляйтесь от них.
Глава 3. Теоретическая общность

Цепочки сообщений появляются, когда клиент запрашивает у одного объекта другой, у которого клиент запрашивает еще один объект, у которого клиент запрашивает еще один объект и т.д. Это может выглядеть как длинный ряд методов getThis или последовательность временных переменных. Такие последовательности вызовов означают, что клиент связан с навигацией по структуре классов. Любые изменения промежуточных связей означают необходимость модификации клиента.
Глава 3. Цепочки сообщений

Почувствовав потребность написать комментарий, попробуйте сначала изменить структуру кода так, чтобы любые комментарии стали излишними.
Глава 3. Комментарии

Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты
Глава 4. Ценность самотестирующегося кода

Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
Глава 4. Тесты модулей и функциональные тесты

Тестирование приносит ощутимую пользу, даже если осуществляется в небольшом объеме. Ключ к проблеме в том, чтобы тестировать те области, возможность ошибок в которых вызывает наибольшее беспокойство. При таком подходе затраты на тестирование приносят максимальную выгоду.
Глава 4. Добавление новых тестов

Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты
Глава 4. Добавление новых тестов

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

Всегда есть риск что-то пропустить, но лучше потратить разумное время, чтобы выявить большинство ошибок, чем потратить вечность, пытаясь найти их все.
Глава 4. Добавление новых тестов

Маленькие методы действительно полезны, если выбирать для них хорошие имена. Иногда меня спрашивают, какой длины должно быть имя метода. Думаю, важна не длина, а семантическое расстояние между именем метода и телом метода. Если выделение метода делает код более понятным, выполните его, даже если имя метода окажется длиннее, чем выделенный код.
Глава 6. Выделение метода. Мотивировка.

Данная книга учит тому, как использовать короткие методы с названиями, отражающими их назначение, что приводит к получению более понятного и легкого для чтения кода. Но иногда встречаются методы, тела которых столь же прозрачны, как названия, либо изначально, либо становятся таковыми в результате рефакторинга. В этом случае необходимо избавиться от метода. Косвенность может быть полезной, но излишняя косвенность раздражает.
Глава 6. Встраивание метода. Мотивировка.

Когда код имеет четкую структуру, часто находятся более мощные оптимизирующие решения, которые без рефакторинга остались бы незамеченными.
Глава 6. Замена временной переменной вызовом метода. Техника.

Все переменные, выполняющие несколько функций, должны быть заменены отдельной переменной для каждой из этих функций. Использование одной и той же переменной для решения разных задач очень затрудняет чтение кода.
Глава 6. Расщепление временной переменной. Мотивировка.

Я никогда не пробовал спать на потолке. Говорят, есть несколько способов. Наверняка одни из них легче, чем другие. С алгоритмами то же самое. Если обнаруживается более понятный способ сделать что-либо, следует заменить сложный способ простым.
Глава 6. Замещение алгоритма. Мотивировка.

Разумное и правильное проектное решение через неделю может оказаться неправильным. Но проблема не в этом, а в том, чтобы не оставить это без внимания.
Глава 7. Перемещение объекта. Мотивировка

Одним из ключевых свойств объектов является инкапсуляция. Инкапсуляция означает, что объектам приходится меньше знать о других частях системы. В результате при модификации других частей об этом требуется сообщить меньшему числу объектов, что упрощает внесение изменений.
Глава 7. Сокрытие делегирования. Мотивировка.

Важно внести ясность в смысл слова неизменяемый (immutable). Если есть класс, представляющий денежную сумму и содержащий тип валюты и величину, то обычно это объект с неизменяемым значением. Это не значит, что ваша зарплата не может измениться. Это значит, что для изменения зарплаты необходимо заменить существующий объект денежной суммы другим объектом денежной суммы, а не изменять значение в существующем объекте. Связь может измениться, но сам объект денежной суммы не изменяется.
Глава 8. Замена ссылки значением. Мотивировка.

В хорошо организованной многоуровневой системе код, обрабатывающий интерфейс пользователя, отделен от кода, обрабатывающего бизнес-логику. Это делается по нескольким причинам. Может потребоваться несколько различных интерфейсов пользователя для одинаковой бизнес-логики; интерфейс пользователя становится слишком сложным, если выполняет обе функции; сопровождать и развивать объекты предметной области проще, если они отделены от GUI; с разными частями приложения могут иметь дело разные разработчики.
Глава 8. Дублирование видимых данных. Мотивировка.

Одна точка входа обеспечивается современными языками, а в правиле одной точки выхода на самом деле пользы нет. Ясность - главный принцип: если метод понятнее, когда в нем одна точка выхода, сделайте ее единственной, в противном случае не стремитесь к этому.
Глава 9. Замена вложенных условных операторов граничным оператором. Мотивировка.

В компьютерах, как и в жизни, иногда происходят неприятности, на которые надо как-то реагировать. Проще всего остановить программу и вернуть код ошибки. Это компьютерный эквивалент самоубийства из-за опоздания на самолет. Хотя я и пытаюсь снова шутить, но в решении компьютера о самоубийстве есть свои достоинства. Если потери от краха программы невелики, а пользователь терпелив, то можно и остановить программу. Однако в важных программах должны приниматься более радикальные меры.
Глава 10. Замена кода ошибки исключительной ситуацией. Мотивировка.

Преимущество исключительных ситуаций в том, что они четко отделяют нормальную обработку от обработки ошибок. Благодаря этому облегчается понимание программ, а создание понятных программ, как, я надеюсь, вы теперь верите, это достоинство, которое уступает только благочестию.
Глава 10. Замена кода ошибки исключительной ситуацией. Мотивировка.

Ральф Джонсон преподал мне важный урок, касающийся исследований: когда кто-то (рецензент статьи, участник конференции) заявляет, что он не понимает, или просто "не врубается", это наша вина. Наша обязанность постараться развить и донести свои идеи.
Глава 13. Проверка в реальных условиях

Это типичная дилемма исследователя, когда современное состояние науки опережает современное состояние практики.
Глава 13. Проверка в реальных условиях

Рефакторинг это ритм, а не отдельные ноты.
Как узнать, что вы действительно начали его понимать? Вы узнаете об этом, когда на вас снизойдет спокойствие. Когда вы почувствуете абсолютную уверенность, что как бы ни был закручен код, который вам достался, вы можете сделать его лучше, настолько лучше, чтобы развивать его дальше.
Глава 15. Складывая все вместе

Крупный рефакторинг - это способ навлечь на себя катастрофу. Каким бы ужасным ни выглядел беспорядок, приучите себя ограничиваться краями проблемы.
Глава 15. Складывая все вместе

Все цитаты из книги Мартина Фаулера “Рефакторинг. Улучшение существующего кода”.

Часть 1

Часть 2

Рефакторинг. Улучшение существующего кода. Часть 1

С момента выхода оригинального издания этой книги прошло десять лет и уже давно понятия "рефакторинга" стало неотъемлемой частью арсенала каждого разработчика. Также уже довольно давно сбылась мечта авторов этой книги и поддержка рефакторинга уже не ограничивается единственной IDE для Smalltalk, а доступна практически в каждой современной IDE. Некоторые разработчики могут подумать, что в связи с этим ценность этой книги стала уменьшаться, но это не так. Главная ее ценность была и остается в том, что такое "код с душком", почему важно качество кода, какое влияние оказывает рефакторинг на процесс проектирования, какова роль модульных тестов, понять когда следует проводить рефакторинг, а когда от него вообще стоит отказаться и многое другое.
Поскольку цитат, как обычно для хорошей книги, набралось довольно много, то я разбил их на две части.
Итак, приступим, часть первая.

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

Обнаружив, что в программу необходимо добавить новую функциональность, но код программы не структурирован удобным для добавления этой функциональности образом, сначала произведите рефакторинг программы, чтобы упростить внесение необходимых изменений, а только потом добавьте функцию.
Глава 1. Комментарии к исходной программе

Перед началом рефакторинга убедитесь, что располагаете надежным комплектом тестов. Эти тесты должны быть самопроверяющимися.
Глава 1. Первый шаг рефакторинга

При применении рефакторинга программа модифицируется небольшими шагами. Ошибку нетрудно обнаружить.
Глава 1. Декомпозиция и перераспределение метода statement

Стоит ли заниматься переименованием? Без сомнения, стоит. Хороший код должен ясно сообщать о том, что он делает, и правильные имена переменных составляют основу понятного кода. Не бойтесь изменять имена, если в результате код становится более ясным.
Глава 1. Декомпозиция и перераспределение метода statement

Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
Глава 1. Декомпозиция и перераспределение метода statement

Очень важно, чтобы код сообщал о своей цели. Я часто провожу рефакторинг, когда просто читаю некоторый код. Благодаря этому свое понимание работы программы я отражаю в коде, чтобы впоследствии не забыть понятое.
Глава 1. Декомпозиция и перераспределение метода statement

Рефакторинг (Refactoring) (сущ.): изменение во внутренней структуре программного обеспечения, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения.
Глава 2. Определение рефакторинга

Цель рефакторинга - упростить понимание и модификацию программного обеспечения
Глава 2. Определение рефакторинга

Рефакторинг напоминает наведения порядка в коде. Убираются фрагменты, оказавшиеся не на своем месте. Утрата кодом структурности носит кумулятивный характер. Чем сложнее разобраться во внутреннем устройстве кода, тем труднее его сохранить и тем быстрее происходит его распад. Регулярно проводимый рефакторинг помогает сохранять форму кода.
Глав 2. Рефакторинг улучшает композицию программного обеспечения

Беда в том, что когда вы бьетесь над тем, чтобы заставить программу работать, то совсем не думаете о разработчике, который будет заниматься ею в будущем. Надо сменить ритм, чтобы внести в код изменения, облегчающие его понимание. Рефакторинг помогает сделать код более легким для чтения.
Глава 2. Рефакторинг облегает понимание программного обеспечения

Я не считаю себя замечательным программистом. Я просто хороший программист с замечательными привычками
Высказывание Кента Бека
Глава 2. Рефакторинг помогает найти ошибки

Как правило, я против откладывания рефакторинга "на потом". На мой взгляд, это не тот вид деятельности. Рефакторингом следует заниматься постоянно понемногу. Надо не решать проводить рефакторинг, а проводить его, потому что необходимо сделать что-то еще, а поможет в этом рефакторинг.
Глава 2. Когда следует проводить рефакторинг?

Делая что-то в первый раз, вы просто это делаете. Делая что-то аналогичное во второй раз, вы морщитесь от необходимости повторения, но все-таки повторяете то же самое. Делая что-то похожее в третий раз, вы начинаете рефакторинг.
Глава 2. Правило трех ударов

Подрывная деятельность? Не думаю. Разработчики программного обеспечения - профессионалы. Наша работа состоит в том, чтобы создавать эффективные программы как можно быстрее. По моему опыту, рефакторинг значительно способствует быстрому созданию приложений. Если мне надо добавить новую функцию, а проект плохо согласуется с модификацией, то быстрее сначала изменить его структуру, а потом добавлять новую функцию. Если требуется исправить ошибку, то необходимо сначала понять, как работает программа, и я считаю, что быстрее всего можно сделать это с помощью рефакторинга. Руководитель, подгоняемый графиком работ, хочет, чтобы я сделал свою работу как можно быстрее; как мне это удастся - мое дело. Самый быстрый путь - рефакторинг, поэтому я и буду им заниматься.
Глава 2. Как объяснить это своему руководителю?

Вычислительная техника - это дисциплина, в которой считается, что все проблемы можно решить благодаря введению одного или нескольких уровней косвенности.
Деннис Де Брюле
Глава 2. Косвенность и рефакторинг

В некоторых случаях рефакторинг вообще не нужен. Основной пример - необходимость переписать программу с нуля. Иногда имеющийся код настолько запутан, что подвергнуть его рефакторингу, конечно, можно, но проще начать все с самого начала.
Глава 2. Когда рефакторинг не нужен?

С применением рефакторинга акценты смещаются. Предварительное проектирование сохраняется, но теперь оно не имеет целью найти единственно правильное решение. Все, что от него требуется, - это найти приемлемое решение. По мере реализации решения, с углублением понимания задачи становится ясно, что наилучшее решение отличается от того, которое было принято первоначально. Но в этом нет ничего страшного, если в процессе участвует рефакторинг, потому что модификация не обходится слишком дорого.
Глава 2. Проектирование и рефакторинг

Рефакторинг позволяет создавать более простые проекты, не жертвуя гибкостью, благодаря чему процесс проектирования становится более легким и менее напряженным. Научившись в целом распознавать то, что легко поддается рефакторингу, о гибкости решений даже перестаешь задумываться. Появляется уверенность в возможности применения рефакторинга, когда это понадобится. Создаются самые простые решения, которые могут работать, а гибкие и сложные решения по большей части не потребуются.
Глава 2. Проектирование и рефакторинг

Секрет создания быстрых программ, если только они не предназначены для работы в жестком режиме реального времени, состоит в том, чтобы сначала написать программу, которую можно настраивать, а затем настроить ее так, чтобы достичь приемлемой скорости.
Глава 2. Рефакторинг и производительность

Хорошее разделение программы на компоненты способствует оптимизации такого рода в двух отношениях. Во-первых, благодаря ему появляется время, которое можно потратить на оптимизацию. Имея хорошо структурированный код, можно быстрее добавлять новые функции и выиграть время для того, заняться производительностью. (Профилирование гарантирует, что это время не будет потрачено зря.) Во-вторых, хорошо структурированная программа обеспечивает более высокое разрешение для анализа производительности. Профайлер указывает на более мелкие фрагменты кода, которые легче настроить. Благодаря большей понятности кода лекче осуществить выбор возможных вариантов и разобраться в том, какого рода настройка может оказаться действенной.
Глава 2. Рефакторинг и производительность

Все цитаты из книги Мартина Фаулера “Рефакторинг. Улучшение существующего кода”.

Часть 1

Часть 2