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

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

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

Обширный опыт общения с заказчиками позволил мне понять несколько важных моментов.
- Как правило, заказчики знают проблемную область очень хорошо (более того, они знают ее лучше, чем я когда-либо буду знать).
- Чаще всего заказчики не воспринимают предметную область на концептуальном уровне, как это принято у разработчиков. Напротив, они говорят о конкретных проявлениях тех или иных частных случаев.
- Заказчики часто используют определение "всегда", но на самом деле следовало бы говорить "обычно".
- Также часто они используют определение "никогда", подразумевая "редко".
- Заказчики часто утверждают, что рассказали обо всех возможных ситуациях, тогда как в действительности речь шла только о том, что случается обычно.
Подводя итог, можно сказать, что я полностью доверяю объяснениям заказчиков, когда они дают ответы на заданные мной конкретные вопросы, но с большим сомнением отношусь к их общим рассуждениям. Я всегда стараюсь вести диалог с заказчиком на максимально конкретном уровне. Даже те из заказчиков, которые полагают, что они способны осмыслить задачу на концептуальном уровне, в попытках оказать помощью разработчику часто переоценивают свои возможности.
Глава 20. Вариации в учебном примере - система международной электронной торговли

 

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

Часть 1

Часть 2

Часть 3

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

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

Суждение о том, что некоторое здание является красивым, - это не просто вопрос вкуса. Красоту можно описать с помощью объективных критериев, которые могут быть измерены.
Кристофер Александер об объективных категориях качествах
Глава 5. Шаблоны проектирования пришли из области архитектуры и культурологии

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

Шаблоны проектирования предоставляют нам абстрактный высокоуровневый взгляд как на проблему, так и на весь процесс объектно-ориентированной разработки. Это помогает избежать излишней детализации на ранних стадиях проектирования.
Глава 5. Зачем нужно изучать шаблоны проектирования

Шаблоны позволяют нам видеть лес за деревьями, поскольку помогают поднять уровень мышления.
Глава 5. Зачем нужно изучать шаблоны проектирования

Наличие возможности реализовать что-либо вовсе не означает, что это обязательно должно быть выполнено.
Глава 13. Принцип проектирования от контекста

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

Часть 1

Часть 2

Часть 3

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

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

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

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

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

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

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

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

Часть 1

Часть 2

Часть 3

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

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

Часть 3

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