Цитатник

Об иерархиях наследования

2012-02-11T10:24:00.001-08:00

Очередная интересная мысль от Бертрана Мейера, на этот раз касается она проектирования иерархий объектов:

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

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

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

Сказка о повторном использовании

2012-01-29T13:18:00.001-08:00

Очередная цитата из книги Бертрана Мейера “Объектно-ориентированное конструирование программных систем”.

Эта сказка опубликована в разделе “Сказка о поиске классов”, но мое название, мне кажется более уместным (после прочтения будет ясно, почему).

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

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

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

Наконец, в один из темных зимних дней, когда снег покрыл все окружающие горные вершины, он вошел в комнату Мастера. С бьющимся сердцем, пересохшим от волнения голосом он задал свой сакраментальный вопрос: "Мастер, как мне найти классы?"

Мудрец склонил свою голову и ответил медленно и спокойно: "Возвращайся назад, откуда пришел. Классы уже найдены".

Оглушенный, он и не заметил, как слуги Мастера выводили его прочь. "Мастер", - теперь он почти кричал, - "пожалуйста, еще только один вопрос. Как называется эта история?" Старый Учитель покачал головой: "Разве ты еще не понял? Это сказка о повторном использовании".

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

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

На данный момент, это все еще является сказкой и я, честно говоря, сомневаюсь, что она когда-либо станет былью.

Как важно быть скромным

2012-01-22T11:55:00.001-08:00

Очередная потрясающая цитата от Бертрана Мейера:

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

А добавить, толком, и нечего:) Интересно было бы узнать, какое количество проектов было угроблено из-за упрямства менеджера, главного архитектора или ключевого человека со стороны заказчика.

О сопровождении

2012-01-22T10:08:00.001-08:00

Снова добрался до двухкилограммового талмуда Бертрана Мейера «Объектно-ориентированное конструирование программных систем». В одной из глав об объектной методологии разработки ПО, Мейер пишет:

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

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

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

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

Об изучении языков программирования

2012-01-17T10:51:00.001-08:00

Очередное интересное высказывание, на этот раз найденное в последней книге Бертрана Мейера “Почувствуй класс”:

Язык, который не влияет на ваш способ мышления, не стоит изучения.

Алан Перлис

Мысль разумная. Конечно, вокруг языка формируется еще и сообщество с собственной культурой, но я, например, не вижу особого смысла изучать Java для C# программиста или наоборот. Чем сильнее отличается культура, идиомы и паттерны в новом языке программирования, тем, потенциально, больше нового вы для себя узнаете.

Влияние психологии команды на архитектуру

2012-01-16T09:48:00.001-08:00

Листаю замечательную книгу “Идеальная архитектура”, которая, по-сути, является сборником статей “архитектурной” тематики.

Во второй главе есть такое любопытное примечание:

Здоровые отношения в группе разработки вносят непосредственный вклад в архитектуру системы. Нездоровые отношения и гипертрофированные самомнения порождают нездоровые продукты.

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

Только в здоровой атмосфере возможно приняте ошибок, которое практически невозможно при нездоровой атмосфере. А без этого сложно себе представить хорошую архитектуру; ведь ошибки – это лишь вопрос времени, и чем раньше “архитектор” их осознает, тем более качественными будут “управляющие воздействия” по их устранению. Ну а кто же признает свои ошибки при нездоровых отношениях в команде?

Еще раз о повторном использовании

2011-09-10T01:43:00.001-07:00

Сегодня открыл книгу “банды четырех”, чтобы уточнить определение одного из паттернов проектирования и в первой же главе увидел выделенную когда-то цитату:

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

Эрик Липперт, один из разработчиков компилятора C# очень часто говорит о проблеме “преждевременного обобщения” (premature generialization), с которой я, например, сталкиваюсь постоянно.

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

О паттернах проектирования

2011-04-27T05:46:00.001-07:00

Сейчас листаю весьма интересную книгу Боба Мартина и наткнулся на следующее высказывание:

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

А ведь он чертовски прав; важно не только каким инстрментом мы пользуемся, значительно важнее то, насколько умело и правильно мы это делаем.

О программировании

2010-12-05T02:11:00.001-08:00

Первый абзац в предисловии книги SICP (Структура и интерпретация компьютерных программ):

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

Мне уже нравится эта книга!

О разработке ПО, отладке и Эйнштейне

2010-10-23T12:19:00.001-07:00

Брайан Керниган (Brian Kernighan) когда-то выразил такую мысль:

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

Читая книгу Энди Ханта “Pragmatic Thinking and Learning” в одном из эпиграфов я встретил знаменитую цитату Эйнштейна:

Мы не можем решить проблему тем же способом мышления, посредством которого она появилась.

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

Оригинальная цитата Брайана Кернигана:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Оригинальная цитата Альберта Эйнштейна:

We can’t solve problem by using the same kind of thinking we used when we created them.

О понимании нужного уровня абстракции

2010-10-22T11:40:00.001-07:00

В одной из своих заметок о Reactive Extentions Ли Кэмпбел (Lee Campbell) выразил следующую мысль:

You should always understand at least one layer below what you are coding.

Или в вольном перевод:

Вы должны понимать как минимум на один уровень абстракции ниже того уровня, на котором вы кодируете.

Нужно сказать очень ценное замечание, следование которому поможет вам не только при написании кода, но также при его отладке и сопровождении.

Многопоточность

2010-06-11T08:51:00.001-07:00

Если кто-то считает, что многопоточность проста и понятна, убедитесь, что этот человек не принимает важных решений в вашем проекте. Если он их все же принимает – вы в беде!”

Брайан Гетц (Brian Goetz) “Thinking in Java”

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

“Дядюшка” Боб Мартин. “Чистый код”

Профессионализм

2010-05-13T22:21:00.001-07:00

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

“Дядюшка” Боб Мартин. “Чистый Код”.

О взаимозаменяемости разработчиков

2010-05-12T03:53:00.001-07:00

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

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений

Об изменениях в ПО

2010-05-04T04:26:00.001-07:00

Изменения в ПО неизбежны. Задача в том, чтобы уметь управлять ими.

Бертран Мейер “Объектно-ориентированное конструирование программных систем”.

О деньгах

2010-04-19T11:28:00.001-07:00

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

Дж. Ханк Рейнвотер “Как пасти котов”

Анализ задачи

2010-04-12T13:16:00.001-07:00

Анализ должен объяснить, что делает система, а не то, как она это делает.

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений

Организация и новые идеи

2010-04-12T13:15:00.001-07:00

Любая организация, которая сама не генерирует новые идеи, либо уже мертва, либо близка к этому.

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений.

Как пасти котов. Часть 1

2010-04-06T03:30:00.001-07:00

Сегодня я начну публикацию цитат из книги Дж. Ханк Рейнвотера “Как пасти котов. Наставление для программистов, руководящих другими программистами”. Мое личное отношение к этой книге весьма неоднозначное. С одной стороны, закладок и подчеркиваний (а соответственно и цитат) набралось достаточное количество, но почему-то эта книга меня не зацепила. Вроде бы и написано все верно, и советов правильных много, и по делу все, но, чего-то мне в ней не хватило.

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

Личность в сегодняшних условиях - это опыт плюс прочитанная литература.
Введение

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

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

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

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

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

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

Совершенный код. Часть 1

2010-04-04T08:37:00.001-07:00

В компьютерной индустрии существует не такое уж большое количество книг, не нуждающихся в представлении, и книга Стива Макконнелла “Совершенный код” входит в их число. Если в любой поисковой системе ввести название этой книги, то вы получите сотни отзывов и тысячи мнений. Мое мнение будет простым и коротким однозначно “Must have”, ну а приведенные цитаты смогут доказать (или опровергнуть) мое мнение по отношению к этой книге.

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

Не зависимо от экономических подъемов и спадов хороших программистов всегда не хватает, а жизнь слишком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов.
Глава 3.1 Причины неполной подготовки

Как сказал Дэвид Грайс, подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in language) и программирование с использованием языка (programming into language). Разработчики, программирующие "на" языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемым языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными.
Разработчики, программирующие "с использованием" языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Глава 4.3 Волны развития технологий

Хорст Риттел и Мелвин Беббер определили "грязную" проблему как проблему, которую можно ясно определить только путем полного или частичного решения. По сути данный парадокс подразумевает, что проблему нужно "решить" один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения.
Глава 5.1 Проектирование - "грязная" проблема

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

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

2010-03-31T00:22:00.001-07:00

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

Как отмечает Дейкстра, "Способ управления сложными системами был известен еще в древности - divide et impera (разделяй и властвуй)". При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо.
Глава 1.3 Роль декомпозиции

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

Объекты обладают целостностью, которая не должна - а, в действительности, не может - быть нарушена. Объект может только менять состояние, вести себя, управляться или становиться в определенное отношение к другим объектам. Иначе говоря, свойства, которые характеризуют объект и его поведение, остаются неизменными
Глава 2.1 OOP, OOD и OOA

Абстракция и икапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством.
Глава 2.1 Инкапсуляция

Лисков прямо утверждает, что "абстракция будет работать только вместе с инкапсуляцией". Практически это означает наличие двух частей в классе: интерфейса и реализации. Интерфейс отражает внешнее поведение объекта, описывая абстракцию поведения всех объектов данного класса. Внутренняя реализация описывает представление этой абстракции и механизмы достижения желаемого поведения. Принцип разделения интерфейса и реализации соответствует сути вещей: в интерфейсной части собрано все, что касается взаимодействия данного объекта с любыми другими объектами; реализация скрывает от других объектов все детали, не имеющие отношения к процессу взаимодействия объектов.
Глава 2.1 Инкапсуляция

Разумная инкапсуляция локализует те особенности проекта, которые могут подвергнуться изменениям.
Глава 2.1 Инкапсуляция

Сокрытие информации - понятие относительное: то, что спрятано на одном уровне абстракции, обнаруживается на другом уровне.
Глава 2.1 Инкапсуляция

Деление программы на модули бессистемным образом иногда гораздо хуже, чем отсутствие модульности вообще.
Глава 2.1 Модульность

Следует стремиться построить модули так, чтобы объединить логически связанные абстракции и минимизировать взаимные связи между модулями.
Глава 2.1 Модульность

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

Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры.
Глава 2.1 Иерархия

Дон Бокс о переходе на новые технологии

2010-03-30T04:13:00.001-07:00

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

Читателям, которых тревожит мысль о потере контроля над программой и передаче его инструментам, разработанным кем-то другим, советую вспомнить замену DOS платформой Windows NT. На первых порах было немало разработчиков, недовольных переходом от ручного управления физической памятью и прерываниями к виртуальной памяти и потокам. Они считали, что это замедлит выполнение программы, наложит дополнительные ограничения, что сыграет на руку только самым ленивым программистам. Многие из этих и подобных аргументов могут быть приведены и против CLR. Только время покажет, является ли среда CLR слишком “абстрактной”. Лично я, однако, убежден, что переход к средам с управляемым выполнением, таким, как CLR или виртуальная машина Java, – существенный шаг вперед, а не назад. Всякий раз, когда программисты оказываются перед выбором между производительностью своего труда и полнотой контроля над программой, в конечном итоге побеждают технологии, обеспечивающие более высокую производительность труда.

Дополнительные ссылки (подтверждающие то, что Дон Бокс не одинок в своих суждениях):

Интервью Бярна Страуструпа

Программист-прагматик. Инструменты

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

2010-03-30T01:38:00.001-07:00

Что-то в последнее время у меня не доходили руки до Цитатника, о чем я прошу прощения и постараюсь исправиться.

Сегодня будет продолжение цитат из замечательной книги Эдварда Йордона “Путь камикадзе”.

Почему люди штурмуют такие опасные горы, как Эверест, несмотря на риск и мучения? Почему они участвуют в марафонских забегах и доводят себя до физического изнеможения в многоборье? Потому что этим они бросают вызов окружающим. Еще больше возбуждает, если ты пытаешься совершить то, что до тебя никто не смог сделать. Например, из пяти миллиардов людей на планете только один может сказать: «Я был первым человеком, ступившим на Луну». Кто-то может подумать, что даже сама попытка совершить нечто подобное - это безумие и эгоизм, а другие, наоборот, хотели бы бросить вызов всем преградам в надежде завоевать славу и общественное признание.
Глава 1.4.2 Синдром покорителей Эвереста

Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?»
Глава 3.2 Допустимые компромиссы

Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать «грубую оценку» времени и количеству персонала, требуемым для реализации каких-либо частей проекта; и достаточно один раз сболтнуть об этом окружающим, как эти оценки могут превратиться в жесткие, не подлежащие изменению требования. Таким образом, в любой подобной ситуации менеджеру необходимо ответить что-либо наподобие: «Мне нужен один день (или неделя, или месяц - или даже час!), чтобы сделать необходимые расчеты, тогда я смогу дать оценку. Я отправлю ее по электронной почте».
Глава 3.4 Стратегии переговоров

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

Один из ключевых моментов в безнадежных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда. Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней - при условии правильного выбора этих 20 процентов.
Глава 5.1 Концепция "triage"

"Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди"
Поговорка ветеранов разработчиков
Глава 5.2 Важность управления требованиями

В действительности нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро - вот в чем заключается их определение «достаточно хорошего» ПО.
Глава 5.4 "Достаточно хорошее" программное обеспечение

Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое качество - хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.
Глава 5.4 "Достаточно хорошее" программное обеспечение

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

2010-03-05T00:00:00.001-08:00

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

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

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

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

Часть 1

Часть 2

Часть 3

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