Цитатник

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

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

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

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

2010-03-04T23:51:00.001-08:00

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

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

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

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

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

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

Часть 1

Часть 2

Часть 3

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

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

2010-03-04T23:49:00.001-08:00

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

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

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

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

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

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

Часть 1

Часть 2

Часть 3

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

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

2010-03-03T04:24:00.001-08:00

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

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

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

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

Пятая причина (неуважительная), по которой у вас нет тестеров.
Я не могу себе этого позволить!
Эта отговорка самая глупая, и ее легче всего развенчать.
Как бы ни трудно было найти тестеров, они все же дешевле, чем программисты. Гораздо дешевле. А если вы не наймете тестеров, вам придется заставить программистов заниматься тестированием. А если вам не нравится, что тестеры часто меняются, посмотрим, как вам понравится, если придется искать замену классному программисту, получающему 100 000 в год, которому надоело ваше требование "потратить несколько недель на тестирование перед выпуском нашего продукта" и который перешел в другую, более профессиональную компанию. Вы могли бы нанять трех тестеров на год за гонорар агента по найму, который найдет вам программиста на замену.
Скупость на тестеров оказывается такой ложной экономией, что я просто поражаюсь, сколь многие люди этого не понимают.

Мы программисты. Все программисты в глубине души - архитекторы, а первое, что хочет сделать архитектор, прибыв на строительный участок, - это выровнять его бульдозером и построить нечто грандиозное. Нас не воодушевляют частичная реконструкция: копаться, улучшать, разбирать цветочные клумбы.
Есть скрытая причина, по которой программисты всегда хотят выкинуть старый код и начать все сначала. Это происходит потому, что прежний код кажется им запутанным. Я так думаю, что они, вероятно, ошибаются. Старый код кажется запутанным, потому что есть важный фундаментальный закон программирования.
Читать код труднее, чем писать его.
Глава 24. То, чего делать нельзя, часть первая

Все счастливые условия работы похожи друг на друга (закрытые офисы, тихая обстановка, отличные инструменты, редкие отвлечения и даже редкие большие совещания). Каждая несчастная рабочая обстановка несчастна по-своему.
Глава 31. Стратегия 5: избавьтесь от отвлечений

Берегись методологий. Они прекрасно обеспечивают жалкое, но терпимое качество труда каждого, но они раздражают людей талантливых, укладывая их в прокрустово ложе ограничений. Талантливый повар, конечно, не будет счастлив, испекая бургеры в Макдональдсе, именно из-за инструкций, насаждаемых Макдональдсом. Почему же ИТ-консультанты так хвалятся своими методологиями? (Не могу понять.)
Глава 33. Биг-Маки против "Голодного повара"

Если вы хотя бы 20 минут в своей жизни писали код, то, вероятно, открыли для себя хорошее эмпирическое правило: все не так просто, как может показаться.
Глава 34. Все не так просто, как может показаться

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

Когда ваша компания растет быстрее, чем на 100 процентов в год, просто невозможно, чтобы наставники передавали новичкам корпоративную культуру. Если программист перемещен на должность руководителя и получил вдруг пятерых новых подчиненных, набранных за день до этого, просто невозможно осуществлять такое наставничество.
Глава 36. Первое письмо о стратегии: Ben & Jerry's против Amazon

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

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

Часть 1

Часть 2

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

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

Часть 3

Джоэл о программировании. Секреты айсберга

2010-02-23T00:42:00.001-08:00

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

Вы знаете, что айсберг на 90% скрыт под водой? Так вот, программное обеспечение обычно на него похоже: в нем есть милый интерфейс пользователя, который требует процентов 10%, а 90% программистского труда скрыто от глаз. А если принять во внимание, что примерно половина времени уходит на отладку, то интерфейс требует лишь около 5% всех трудовых затрат. А если ограничить себя только видимой часть интерфейса, пикселами, тем, что вы увидите в PowerPoint, то речь пойдет вообще об 1% и менее.
Но секрет не в этом. Секрет в том, что люди, не являющиеся программистами, этого не понимают.
Глава 25. Секрет айсберга

Если вы покажете непрограммисту экран с интерфейсом, который будет выглядеть на 90% хуже, он решит, что программа на 90% хуже.
Глава 25. Важное следствие номер один

Если показать непрограммисту экран с интерфейсом пользователя, который на вид готов и красиво выглядит, то он решит, что программа почти готова.
Глава 25. Важное следствие номер два

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

Если вам нужно произвести впечатление ожидаемыми результатами, то единственное, что имеет значение для успеха, это снимки экранов. Они должны быть как можно красивее.
Глава 25. Важное следствие номер пять

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

Часть 1

Часть 2

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

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

Часть 3

Скотт Мейерс. Эффективное использование С++

2010-02-21T09:03:00.001-08:00

На этот раз речь пойдет о замечательной книге Скотта Мейерса “Эффективное использование С++”. И хотя возможно эта книга (и цитаты из нее, соответственно) будут более интересны разработчикам, которые в своей профессиональной деятельности занимаются языком программирования С++, многие идеи положенные в основу некоторых правил будут актуальны и для разработчиков из других областей.

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

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

Любой интерфейс, который требует, чтобы пользователь что-то помнил, может быть использован неправильно, ибо пользователь вполне способен забыть, что от него требуется.
Правило 18. Проектируйте интерфейсы так, что их легко было использовать правильно и трудно – неправильно

Женщина либо беременна, либо нет. Невозможно быть чуть-чуть беременной. Аналогично программная система является либо безопасной по исключениям, либо нет. Нет такого понятия, как частично безопасная система. Если система имеет всего одну небезопасную относительно исключений функцию, то она небезопасна и в целом, потому что вызов этой функции может привести к утечке ресурсов и повреждению структур данных. К несчастью, большинство унаследованного кода на С++ было написано без учета требований безопасности исключений, поэтому многие системы на сегодня являются в этом отношении небезопасными. Они включают код, написанный в небезопасной манере.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Сорок лет назад код, изобилующий операторами goto, считался вполне приемлемым. Теперь же мы стараемся писать структурированные программы. Двадцать лет назад глобальные данные ни у кого не вызывали возражений. Теперь мы стремимся данные инкапсулировать. Десять лет назад написание функций без учета влияния исключений было нормой. А сейчас мы боремся за достижение безопасности относительно исключений.
Времена меняются. Мы живем. Мы учимся.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Не забывайте об эмпирическом правиле "80-20", которое утверждает, что типичная программа тратит 80% времени на исполнение 20% кода. Это важное правило, поскольку оно напоминает, что цель разработчика программного обеспечения - идентифицировать те 20% кода, которые действительно способны повысить производительность программы. Можно до бесконечности оптимизировать и объявлять функции inline, но все это будет пустой тратой времени, если только вы не сосредоточите усилия на нужных функциях.
Правило 30. Тщательно обдумывайте использование встроенных функций

Делая класс D закрытым наследником класса B, вы поступаете так потому, что заинтересованы в использовании некоторого кода, уже написанного для B, а не потому, что между объектами B и D существует некая концептуальная взаимосвязь. Таким образом, закрытое наследование - это исключительно прием реализации. Можно сказать, что закрытое наследование означает наследование одной только реализации, без интерфейса. Если D закрыто наследует B, это означает, что объекты D реализованы посредством объектов B, и ничего больше. Закрытое наследование ничего не означает в ходе проектирования программного обеспечения и обретает смысл только на этапе реализации.
Правило 39. Продумывайте подход к использованию закрытого наследования

P.S. Спасибо Алексею Ершову за идею цитат из этой замечательной книги, и за отличную цитату об эволюции в области разработки ПО (вторая цитат из правила 29).

Джоэл о программировании. Справочник бойца по проведению собеседования

2010-02-08T04:18:00.001-08:00

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

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

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

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

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

Как же определить, что этого человека надо принять?
В принципе просто. Искать надо тех, кто:
1. Умен
2. Доводит дело до конца

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

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

Часть 1

Часть 2

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

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

Часть 3

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

2010-01-26T03:14:00.001-08:00

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

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

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

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

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

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

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

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

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

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

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

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

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

2010-01-20T03:54:00.001-08:00

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

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

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

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

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

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

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

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

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

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

2010-01-17T05:49:00.001-08:00

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

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

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

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

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

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

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

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

Часть 1

Часть 2

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

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

Часть 3

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

2010-01-14T01:55:00.001-08:00

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

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

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

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

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

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

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

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

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

Часть 1

Часть 2

Часть 3

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

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

2010-01-12T06:09:00.001-08:00

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

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

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

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

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

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

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

2010-01-12T06:05:00.001-08:00

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

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

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

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

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

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

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

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

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

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

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

2010-01-11T03:13:00.001-08:00

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

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

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

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

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

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

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

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

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

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

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

2010-01-09T04:24:00.001-08:00

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

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

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

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

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

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

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

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

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

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

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

Часть 1

Часть 2

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

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

Часть 3

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

2010-01-04T00:16:00.001-08:00

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

Если что-то плохо пахнет, это что-то надо поменять
- Мнение бабушки Бек, высказанное
при обсуждении проблем детского воспитания
Глава 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

2010-01-04T00:09:00.001-08:00

С момента выхода оригинального издания этой книги прошло десять лет и уже давно понятия "рефакторинга" стало неотъемлемой частью арсенала каждого разработчика. Также уже довольно давно сбылась мечта авторов этой книги и поддержка рефакторинга уже не ограничивается единственной 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

Deadline. Роман об управлении проектами. Часть 2

2009-12-25T14:07:00.001-08:00

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

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

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

Он и раньше сталкивался с идиотскими и губительными для команды «наказаниями за отставание от графика», и сегодняшний разговор разбередил в нем эти воспоминания. Откуда у некоторых руководителей эта слепая вера в кнуты и штрафы? Неужели из них получаются такие же ужасные родители? Скорее всего, да.
Мысли мистер Томпкинса о пользе наказания
Глава 4. Завод по изготовлению CD-ROM

— Если вдуматься, для руководства проектом голова вообще не больно-то нужна. Больше всего нужны нутро, сердце и душа.
— Нутро, сердце и душа?
— Да. Настоящий руководитель чувствует ситуацию нутром, управляет людьми исключительно сердцем и может вдохнуть живую душу в проект, команду или всю организацию.
Диалог Белинды Бинды и мистера Томпкинса о роли руководителя
Глава 6. Лучший в мире руководитель

Душа команды - это как песчинка в ракушке, вокруг которой начинает нарастать самое ценное. Сообщество.
Белинда Бинда о душе команды
Глава 6. Лучший в мире руководитель

- Давайте знакомиться с людьми, а не с их резюме.
Белинда о подборе персонала
Глава 7. Подбор персонала

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

— Иногда бывает трудно смотреть в глаза своему начальнику и говорить, что не сможешь сделать работу вовремя. Куда проще взять и опоздать. Но тогда твой босс узнает об опоздании на четыре недели позже, и у него просто не останется возможности хоть как-то исправить ситуацию. Именно поэтому мы выработали такую вот полуанонимную систему. Конечно же, я знаю, кто сейчас приходил на «исповедь», но делаю вид, что он мне не знаком. А в результате всегда узнаю плохие новости вовремя.
Молли Макмора об общении разработчиков с их руководителями
Глава 7. Подбор персонала

В этом и заключается наша работа — находить для своих подчиненных такую должность, на которой проявятся все их скрытые способности. А в чем еще заключается руководство, если не в этом?
Белинда о роли руководителя
Глава 12. Человек, который умел считать

— Да ладно вам, — вмешался Аристотель. — Как будто вы раньше этого не знали. Наверняка в глубине души каждый из нас знает, что сверхурочная работа — верный способ снизить производительность.
— Да, в общем-то, это так, — задумчиво сказала Белинда. — Недостатки сверхурочной работы хорошо всем известны: усталость, отсутствие творческой энергии, ошибки…
— А также потеря времени в течение обычного рабочего дня, — добавил Аристотель.
— А это почему?
— Потому что люди знают, что все равно будут работать допоздна. Поэтому они могут позволить себе долгие и не очень нужные совещания, перерывы и тому подобное.
— Да уж точно. А если запретить работать сверхурочно, то им волей-неволей придется использовать рабочее время более эффективно.
— Именно.
— Значит, в список недостатков сверхурочной работы можно добавить еще и это. А те данные, которые привел нам Вальдо, ясно показывают: недостатки сверхурочной работы все равно перевешивают пользу от дополнительных усилий разработчиков. Как правильно сказал Аристотель, все мы в глубине души знаем
это.
— Так что же делать руководителю в трудной ситуации? — взволнованно спросил мистер Томпкинс.
— Что-то другое, — ответила ему Белинда. — Что-то более сложное: принимать на работу новых сотрудников, придумывать способы мотивации персонала, развивать командные отношения и поддерживать боевой дух, привлекать к проекту грамотных людей, устранять из процесса разработки все малоэффективные действия, реже устраивать совещания, не давать людям Том ДеМарко: «Deadline. Роман об управлении проектами» 121
работать сверхурочно, сократить работу над документацией. Однако мистера Томпкинса это ничуть не успокоило.
Диалог Аристотеля, Томпкинса и Белинды о вреде сверхурочных
Глава 15. Думать быстрее!

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

Я считаю, что в каждом из нас, в душе или на уровне подсознания, живет тайный страх: мы боимся показать, что соображаем хуже других. Вся наша раса заражена этим страхом. Каждый готов предположить, что его мыслительные способности ниже средних, поэтому ему надо прикладывать дополнительные усилия, чтобы разобраться в том, в чем другие разбираются с ходу. А теперь возьмем нашу ужасную спецификацию. Ты читаешь ее целый день и обнаруживаешь, что ничего не понимаешь. И тут приходит начальник и спрашивает: «Ну как? Как вам спецификация?» Что сказать? И мы врем! «Все в порядке, босс. То есть я хочу сказать, что документ этот весьма непростой, но дайте нам еще немного времени, и мы во всем разберемся…» И так поступает каждый!
Белинда о корпоративном мышлении и отношению к руководству
Глава 16. План работы по подготовке к летним Олимпийским играм

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

Дорога к мудрости проста,
Как этот краткий стих:
Ошибки смело совершай -
И станет меньше их.
Пит Хайн
Глава 18. Маэстро Диеньяр

Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:

Часть 1. Из записной книжки мистера Томпкинса

Часть 2. Остальные цитаты

Deadline. Часть 1. Из записной книжки мистера Томпкинса

2009-12-25T11:36:00.001-08:00

Немногие знают, что помимо книг по управлению проектами и структурному анализу Том Демарко написал сборник рассказов под названием “Lieutenant America and Miss Apple Pie” и повесть “Dark Harbor House”.

Помимо компьютерных книг и художественной литературы у Тома Демарко есть и промежуточный вариант - “Deadline. Роман об управлении проектами”, в котором автор рассказывает историю мистера Томпкинса, менеджера проектами, который сталкивается с типичными проблемами управления программными проектами.

Во многом, темы этой книги пересекаются с темами из ставшей давно классической книги Демарко и Листера “Peopleware”. И хотя “Peopleware” написана замечательным языком и сама читается как художественное произведение, Демарко решил, что этого недостаточно и решил описать проблемы управления в виде настоящего романа.

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

Итак, перед вами целиком записная книжка мистера Томпкинса.

Глава 4. Четыре основных правила менеджмента

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

Глава 4. Безопасность и перемены

1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Глава 5. Отрицательная мотивация

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

Глава 6. Части тела, необходимые для управления проектами

1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу.

Глава 8. Повышение производительности

1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»

Глава 8. Управление рисками

1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Глава 9. Играй в защите

1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Глава 12. Сбор метрических данных

1. Определяйте размер каждого проекта.
2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Глава 15. Что дает давление сверху

1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.
3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком
сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Глава 16. Сердитый начальник

1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Глава 16. Туманные спецификации

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

Глава 17. Конфликт

1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с
непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Глава 18. Кто такой катализатор проекта

1. Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Глава 18. Человеку свойственно ошибаться

1. Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

Глава 19. О персонале

1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Глава 20. Проблемы социологии

1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какая-то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т.п.
4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

Глава 21. О патологической политике (еще раз)

1. Эту патологию невозможно вылечить снизу.
2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Глава 22. Злоба и скупость

1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.

Глава 23. Основы здравого смысла

1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.

Все цитаты из книги Тома Демарко “Deadline. Роман об управлении проектами”:

Часть 1. Из записной книжки мистера Томпкинса

Часть 2. Остальные цитаты

Роберт Гласс. Факты и заблуждения профессионального программирования

2009-12-21T12:56:00.001-08:00

Совсем недавно я дочитал книгу Роберта Гласса “Факты и заблуждения профессионального программирования”. В целом, книга понравилась, интересное и качественное произведение. Мое развернутое мнение можно почитать на моем блоге.

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

В книгах о менеджменте (которые я читал), говорится, что на 95% он (менеджмент) состоит из здравого смысла и на 5% - из советов не первой свежести, перекочевавших из прошлого десятилетия.
Глава 1. О менеджменте

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

В создании ПО важен человеческий фактор. ... Свою роль играют инструментальные средства. Важны и методы. И процессы. Но роль людей намного более значима.
Факт №1. Обсуждение

Разработка ПО - это интенсивная умственная деятельность, и среда, в которой она проходит, должна способствовать мышлению. Теснота и вызванные ею помехи в работе (намеренные или нет) сказываются на результатах весьма пагубно.
Факт №4. Обсуждение

В нашей современной культуре принято во что бы то ни стало укладываться в сроки (невозможные), жертвуя ради этого завершенностью и качеством.
Факт №12. Источник

Управление, сосредоточенное на контроле, не обязательно делает проект лучшим или даже более производительным.
Факт №13. Обсуждение

Если код программной системы предстоит модифицировать на 20-25% или больше, то проще и дешевле начать все заново и создать новый продукт. Этот порог низок (на самом деле он удивительно низок).
Факт №19. Источники

Некоторые исследователи говорят, что переизбыток паттернов (попытка применить их в тех программах, для которых они не подходят) может привести к появлению "непонятного ...кода, ...декораций на фасадах, построенных фабричным способом".
Факт №20. Полемика

Каждые 25% увеличения сложности задачи обусловливают 100% увеличения сложности программного решения. И еще запомните, что против этого нет никакого противоядия. Программные решения сложны, поскольку такова их природа.
Факт 21. Обсуждение

Чаще всего проекты, выходящие из-под контроля, на самом деле никогда и не были управляемыми.
Факт 23. Обсуждение

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

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

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

Полное покрытие структурным тестированием гарантирует обнаружение лишь 25% ошибок в программном продукте.
Факт 33. Обсуждение

Закон Линуса: все ошибки становятся заметными, если на них обращено достаточно много глаз - with enough eyeballs, all bugs are shallow.
Факт 34. Обсуждение

Процесс отладки - это детективный жанр программирования. Преследуя неуловимую программную ошибку, вы перевоплощаетесь в Шерлока Холмса. И подобно Шерлоку Холмсу, вы должны призвать на помощь свой интеллект и любые поддерживающие его и доступные вам средства.
Факт 36. Обсуждение

Самое трудное в сопровождении ПО - это понять, как работает уже имеющийся продукт.
Факт 44. Обсуждение

О качестве (ПО) мы говорим так: "Когда я его увижу, я пойму, что это оно".
Глава 3. О качестве

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

Человеку свойственно предсказывать будущее, опираясь на опыт прошлого. В конце концов, нельзя точно предсказать будущее, глядя в него же. Поэтому мы исходим из предположения, что вероятные события будущего будут похожи на те события, которые уже произошли. Иногда это предположение оправдывается. На самом деле довольно часто. Но иногда оно не оправдывается совершенно.
Заблуждение 9. Обсуждение

Реальность - это убийство прекрасной теории бандой мерзких фактов.
Выводы

Остаться в живых. Часть 2

2009-12-17T03:04:00.001-08:00

Продолжение цитат из книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

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

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

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

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

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

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

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

Для высококачественного программного продукта число тестировщиков должно равняться числу разработчиков.
Глава 9. Тестирование системы

Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.
Глава 9. Тестирование системы

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

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

Лучше работать разумно и много, чем неразумно много!
Глава 12. Если микровеховый план не выполняется

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

Поощрение команды никогда не приведет к провалу, а ее угнетение - к успеху.
Глава 19. Желательные действия

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2

Остаться в живых! Часть 1

2009-12-17T02:58:00.001-08:00

Сегодня я решил опубликовать цитаты из книги Стива Макконнелла ""Остаться в живых! Руководство для менеджера программных продуктов". Книгу я читал уже довольно давно (года три назад) и тогда она на меня произвела двоякое впечатление. Первая часть книги, в которой автор сосредотачивается на общих сведениях, мне очень понравилась, а вот вторая, более конкретная, мне понравилась не очень сильно и я не решился применять советы автора на практике. Хотя у вас может быть и другое мнение:)

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

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

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

Об авторе

Исследователи обнаружили, что стоимость позднего исправления ошибки, внесенной в проект на ранней стадии (например, при формировании требований или архитектуры), в 50-200 раз выше, чем стоимость ее исправления сразу же после внесения.
Глава 3. "В начале потока" и "в конце потока"

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

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

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

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

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

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

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

Не пытайтесь мотивировать разработчиков эффективными выступлениями, недостижимыми результатами или денежными вознаграждениями
Глава 4. "Человеческое обеспечение"

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

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

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

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

Эффективные проекты контролируют изменения; неэффективные проекты находятся под контролем изменений.
Глава 6. Стрельба по движущейся цели

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

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2

Голосование: Нужен ли рисунок с обложкой книги в начале сообщения с циатами?

2009-12-16T05:09:00.000-08:00

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

Джеймс Коплиен. Программирование на С++

2009-12-14T10:19:00.001-08:00

Хотя книга Джеймса Коплиена “Программирование на С++. Классика CS” вышла уже более 15 лет назад, в ней находится немало количество интересных, способных заинтересовать современного программиста.

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

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

Предисловие. Изучение языка программирования

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

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

Как сказал Страуструп, хорошие навыки программирования и проектирования являются результатом личного вкуса, проницательности и опыта.
Глава 1. Проектирование и язык

Принцип замещения Барбары Лисков: ...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в контексте T, поведение P не изменяется при замене o1 на o2, то S является базовым типом для T.
Глава 6. Случайное наследование – омонимы в мире типов

Мифический человеко-месяц. Радости профессии

2009-12-14T09:59:00.001-08:00

Один из комментариев к первой части цитат книги Фредерика Брукса “Мифический человеко-месяц” навела на мысль, что одной цитаты из раздела “Радости профессий” недостаточно. Но этот раздел настолько потрясен, что я думаю будет не лишним выделить его в отдельное сообщение.

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

Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:

Часть 1

Часть 2

Радости профессии

Программист-прагматик. Часть 6. Управление проектами

2009-12-13T03:15:00.001-08:00

Помимо философских высказываний, в книге Дейва Томаса и Энди Ханта можно найти немало полезной информации и по управлению проектами.

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

Одной из интересных особенностей оценки является тот факт, что интерпретация ее результата зависит от используемых вами единиц измерения. Если вы говорите, что для некоего действия потребуется 130 рабочих дней, то люди будут ожидать наступления этого события в достаточно узком интервале. Но если вы скажете «около шести месяцев», они будут знать, что этого события следует ожидать чрез 5-7 месяцев. Обе цифры обозначают одну и ту же продолжительность, но «130 дней», вероятно, подразумевает большую точность, чем вы полагаете.
Глава 2. Насколько точной является “приемлемая точность”?

Что сказать, если вас просят оценить что-либо?
Говорите: «Я вернусь к вам с этим позже».
Вы почти всегда можете добиться лучших результатов, если не будете торопиться… К оценкам, сделанным на ходу (например, у офисной кофеварки), придется возвращаться вновь и вновь (как, впрочем, и к кофе), теряя при этом покой.
Глава 2. Что сказать, если вас просят оценить что-либо

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

Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания "Пасторальной симфонии". Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Не собирайте требования – выискивайте их
Глава 7. Карьер для добычи требований

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

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

Однажды царь Фригии Гордий завязал узел, который никто не мог развязать. Было предсказано, что тот, кто сможет развязать его, станет властелином всей Азии. И вот пришел Александр Македонский, который разрубил узел своим мечом. Несколько иная интерпретация требований и все – он стал властителем всей Азии.
Глава 7. Разгадка невероятных головоломок

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

Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Глава 8. Генерирование web-сайта

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 5. Тестировние и отладка

2009-12-13T03:12:00.001-08:00

Тестирование и отладка занимает в книге достойное место. Книга не заменит специализированную литературу по отладке, но все же будет полезна многим разработчикам.

Английское слово bug (ошибка) используется для описания "объекта, вызывающего ужас" уже начиная с XIV века. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказалась первой, кто наблюдала компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе "завелся жучок", и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.
Глава 3. Отладка

Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: "А вот и я!".*
Звучит просто, но разъясняя проблему вашему собеседнику, вы должны явно заявить о тех вещах, которые считаете само собой разумеющимися при просмотре текста вашей программы. Поскольку вам приходится озвучивать некоторые из этих положений, вы можете по-новому взглянуть на суть данной проблемы – неожиданно для самого себя.

* Почему "резиновый утенок"? Один из авторов книги, Дэйв Хант, учился в лондонском Империал колледже и много работал совместно с аспирантом, которого звали Грег Паг и которого Д. Хант считает одним из лучших известных ему разработчиков. На протяжении нескольких месяцев Грег носил при себе крохотного желтого резинового утенка, которого он ставил на край монитора во время работы. Прошло некоторое время, пока Дэйв не отважился спросить…

Примечание: один очень известный bug-slayer (речь идет о Джоне Роббинсе), считает, что лучшие отладчики – это кошки, а не утята… Но это уже, скорее, дело вкуса :-)
Глава 3. Рассказ о резиновом утенке

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

Если ваша программа обнаруживает, что произошло событие, которое считалось невозможным, программа теряет жизнеспособность. Начиная с этого момента, все действия, которые она совершает, попадают под подозрение, так что выполнение программы необходимо прервать как можно быстрее. В большинстве случаев мертвая программа приносит намного меньше вреда, чем испорченная.
Глава 4. Аварийное завершение не означает “отправить в корзину для мусора”

Предположим, Фреду дано задание написать программу. Фред составляет некую программу, пробует ее запустить, и она вроде бы работает. Фред пишет еще один фрагмент, пробует его запустить, и снова все работает. В такой обстановке проходит еще несколько недель, но внезапно программа прекращает работать, и, потратив несколько часов на устранение дефекта, Фред все еще не знает, в чем причина. Фред может потратить много времени, копаясь с этим фрагментом, без перспективы на восстановление работы программы. И что бы он ни делал, кажется, что программа никогда не будет работать правильно.
Фред не знает, почему программа сбоит, потому что не знает, почему она работала вначале. Она лишь казалась работающей в условиях ограниченного «тестирования», которое проводил Фред, но это было лишь стечением обстоятельств. Находясь в плену ложной уверенности, Фред впал в забытье. Большинству интеллектуалов знаком этот образ Фреда, но мы знаем его лучше. Мы ведь не полагаемся на стечение обстоятельств, не так ли?
Глава 6. Программирование в расчете на стечение обстоятельств

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

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

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

Глава 8. Тестирование удобства использования

Если тестировщик обнаруживает дефект, это должно быть в первый и последний раз – обнаружение дефекта человеком. Автоматизированные тесты должны быть модифицированы для проверки наличия этого дефекта, начиная с момента его первоначального обнаружения, всякий раз, без каких-либо исключений, не обращая внимания на степень тривиальности, жалобы разработчика и его фразу "Этого больше не случится".
Глава 8. Кольцо сжимается

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 4. Проектирование

2009-12-13T03:09:00.001-08:00

Проблема сцепления (cohesion) и связности (coupling) беспокоит архитекторов в самых различных областях уже много лет; в области разработки ПО эта тема поднималась еще Эдвардом Йордоном и Ларри Константайном тридцать лет назад. И хотя тема построения слабосвязного ПО не является единственной темой по проектированию ПО, именно она проходит красной нитью через всю книгу “Программист-прагматик”.

Термин «ортогональность» заимствован из геометрии. Две линии являются ортогональными, если они пересекаются под прямым углом, например оси координат на графике. В терминах векторной алгебры две такие линии являются независимыми. Если двигаться вдоль одной из линий, то проекция движущейся точки на другую линию не меняется.
Этот термин был введен в информатике для обозначения некой разновидности независимости или несвязанности. Два или более объекта ортогональны, если изменения, вносимые в один из них, не влияют на любой другой.
Глава 2. Что такое ортогональность?

Ничто не вечно, и если вы всерьез полагаетесь на некоторое явление, то этим вы практически гарантируете, что оно непременно изменится.
Глава 2. Обратимость

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

Перед тем как вы займетесь созданием любого прототипа, основанного на программе, убедитесь, что все понимают – вы пишите одноразовую программу. Прототипы могут быть обманчиво привлекательными для людей, которые не знаю, что это всего лишь прототипы. Вы должны очень четко уяснить – эта программа одноразовая, незавершенная и не может быть завершена.
Легко впасть в заблуждение из-за очевидной завершенности демонстрационного прототипа, и спонсоры проекта или менеджмент могут настаивать на развертывании прототипа (или его потомства), если вы заранее не определите, что можно ожидать от прототипа. Напомните им, что вы, конечно, можете создавать великолепный прототип новой модели автомобиля из бальзовой древесины и клейкой ленты, но вы же не поедете на нем в час пик!
Глава 2. Как не надо использовать прототипы

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

Шпионы, диссиденты, революционеры и им подобные часто организованы в небольшие группы, называемые ячейками. Хотя отдельные личности в каждой ячейке могут знать друг о друге, они не знают ничего об участниках других ячеек. Если одна ячейка раскрыта, то никакое количество "сыворотки правды" неспособно выбить из ее участников информацию об их сподвижниках вне пределов ячейки. Устранение взаимодействий между ячейками убережет всех.
Мы полагаем, что этот принцип хорошо бы применить и к написанию программ. Разбейте вашу программу на ячейки (модули) и ограничьте взаимодействие между ними. Если один модуль находится под угрозой и должен быть заменен, то другие модули должны быть способны продолжить работу.
Глава 5. Несвязанность и закон Деметера

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

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

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

2009-12-13T03:06:00.001-08:00

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

Каждый ремесленник отправляется на поиски заработка, имея при себе походный набор инструментов. Столяру могут пригодиться линейки, шаблоны, пара ножовок, несколько рубанков, тонкие стамески, сверла и зажимы, киянки и струбцины. Эти инструменты он будет тщательно выбирать и настраивать, каждому из них будет уготована определенная работа, и, что наверное самое важное, каждый из них, оказавшись в умелых руках столяра, найдет свое место под солнцем.
После этого придет черед обучению и притирке. Каждому инструменту будут присущи свои особенности (и хитрости), и каждый из них потребует, чтобы с ним обращались по-своему. При работе столяр держит каждый инструмент особым образом и затачивает его под особым углом. Пройдет время, и от работы инструмент износится до того, что рукоятка превратится в слепок руки столяра, а режущая поверхность сравнится с углом, под которым столяр держит инструмент относительно рабочей плоскости. В этот момент инструменты станут проводниками идей от головы столяра к конечному продукту – они станут продолжением рук мастера. Со временем в арсенале столяра прибавятся новые орудия – резальные машины, лазерные станки для резки под углом, направляющие шаблоны "ласточкин хвост" – все это чудеса технологического прогресса. Но можно поспорить, что по-настоящему столяр счастлив только тогда, когда держит в руках инструмент из старого походного набора и слышит, как рубанок поет свою песню, выстругивая деревянную заготовку.
Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать. Начните с походного универсального набора инструментов. По мере того как вы приобретаете опыт и сталкиваетесь с специальными требованиями, ваш набор пополняется. Стоит уподобиться ремесленнику и пополнять набор регулярно. Старайтесь не прекращать поисков лучшего способа сделать что-либо. Оказавшись в ситуации, когда вы обнаруживаете, что ваших инструментов недостаточно, поищите иное, возможно, более мощное средство для осуществления задуманного. Ваши приобретения должны исходить из существующей необходимости.
Глава 3. Походный набор инструментов

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 2. Дублирование информации

2009-12-13T03:02:00.001-08:00

Это вторая часть цитат из книги Энди Ханта и Дейва Томаса “Программист-прагматик. Путь от подмастерья к мастеру”.

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

Принцип “Не повторяй себя” (DRY – Don’t Repeat Yourself):
Каждый фрагмент знания должен иметь единственное однозначное, надежное представление в системе
Глава 2. Пороки дублирования

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

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

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

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

Все, что вы пытаетесь делать, способствует развитию среды, где проще находить и многократно использовать существующий материал, чем создавать его самому. Но если это непросто (имеется ввиду непросто повторно использовать существующий код), люди просто не будут этого делать. И если вы будете не в состоянии многократно использовать этот материал, вы рискуете заняться дублированием знаний.
Глава 2. Коллективное дублирование

Программа должна иметь комментарии, но слишком большое их количество может быть так же плохо, как и малое.
В общем, комментарии должны обсуждать, почему выполняется та или иная операция, ее задачу и ее цель. Программа всегда демонстрирует, как это делается, поэтому комментирование – избыточная информация и нарушение принципа DRY.
Глава 8. Комментарии в программе

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Программист-прагматик. Часть 1. Философия программирования

2009-12-13T02:59:00.001-08:00

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

Мое более развернутое мнение можно посмотреть на моем блоге или на сайте rsdn.ru.

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

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами

Итак, начнем. Часть 1. Философия программирования.

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

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

Авторы призывают вас во время работы думать только о работе – только так вы останетесь программистом-прагматиком. Это не случайная оценка существующей практики, а критическая оценка каждого принимаемого вами решения – в течение каждого рабочего дня и по каждому проекту. Никогда не пользуйтесь автопилотом. Думайте постоянно, критикуя свою работу в реальном масштабе времени. Старый девиз фирмы IBM “ДУМАЙ!” является своего рода мантрой для программиста-прагматика.
Думай! О своей работе

Во время экскурсии по Итонскому колледжу в Англии турист спросил садовника, как ему удается содержать лужайки в столь идеальном состоянии. «Это несложно, - ответил садовник, вы просто стряхиваете росу каждое утро, выкашиваете лужайку через день и утрамбовываете раз в неделю».
«И это все?» - спросил турист.
«Абсолютно все, - ответил садовник, - если заниматься этим на протяжении 500 лет, то ваша лужайка будет не хуже».
Великие лужайки, как и великие программисты, нуждаются в ежедневном уходе. В ходе беседы консультанты в области менеджмента не преминут вставить японское слово «кайдзен». «Кайдзен» - японский термин, означающий политику непрерывного внедрения большого количества мелких усовершенствований. Считается, что «кайдзен» стала одной из основных причин резкого роста производительности и качества в японской промышленности, и эту политику стали применять во многих странах. «Кайдзен» применима и к отдельным личностям. Каждый день необходимо работать, оттачивая свои навыки и добавляя в свой репертуар новые произведения. В отличие от итонских газонов, для достижения результата потребуются дни. Годы спустя вы будете поражаться своему преуспеванию и карьерному росту.
От авторов. Непрерывность процесса

Некоторые здания, расположенные в старых кварталах города, находятся в хорошем состоянии и чистоте, тогда как другие представляют собой жуткие развалины. Почему? Исследователи в области преступности и упадка больших городов открыли удивительный механизм, запускающий процесс быстрого превращения чистенького, нетронутого жилого дома в полуразрушенную и заброшенную трущобу.
Причина – одно-единственное разбитое окно.
Одно разбитое окно, стекло в котором не меняется в течение длительного времени, развивает в обитателях здания ощущение заброшенности – ощущение, что властям нет дела до того, что происходит со зданием. Затем разбивается другое окно. Люди начинают мусорить. На стенах появляются похабные надписи. Возникают серьезные повреждения строительной конструкции. За относительно короткое время здание портится, несмотря на стремление владельца отремонтировать его, и ощущение заброшенности становится реальностью.
«Теория разбитого окна» дала полицейским участкам в Нью-Йорке и других больших городах стимул: навалиться всем миром на решение малых проблем ради сдерживания больших. И это срабатывает: сосредоточение усилий на первоочередном решении проблем разбитых окон, похабных надписей и других малых правонарушений привело к сокращению уровня тяжких преступлений.
Глава 1. Энтропия в программах

Человеческий фактор. Успешные проекты и команды. Часть 2

2009-12-07T01:00:00.001-08:00

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

Слово непрофессиональный часто употребляется для обозначения неожиданного и угрожающего поведения. Все, что может обеспокоить слабого руководителя, непрофессионально почти по определению. Так что попкорн – это непрофессионально. Длинные волосы – непрофессионально, если растут на мужской голове, но совершенно приемлемо, если на женской. Плакаты любого вида – это непрофессионально. Удобная обувь – непрофессионально. Танцы вокруг стола, когда происходит что-то хорошее, – непрофессионально. Хихикать и смеяться – непрофессионально. (Улыбаться можно, но не слишком часто.)
Глава 14. Кодовое слово: Профессионализм

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

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

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

Объемная документация - часть проблемы, а не часть решения
Глава 17. Безумие Методологии

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

Испытывая недоверие со стороны начальства, люди не слишком склонны объединяться в команду
Глава 20. Оборонительная позиция руководства

Типичные шаги, направленные на ускорение сдачи продукта, обычно приводят к снижению качества
Глава 20. Снижение качества продукта

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

Большинство организаций не стремятся к разрушению команд сознательно. Просто они так себя ведут
Глава 20. И опять на ту же грустную тему

Успех порождает успех, а продуктивная гармония - еще более продуктивную гармонию
Глава 21. Что здесь происходит?

Лучший успех – тот, в котором нет очевидного участия руководства, а команда работает как содружество равных. Лучший начальник – тот, кто может повторять это раз за разом, не давая участникам команды догадаться, что ими «руководят». Таких руководителей их собственные коллеги считают просто удачливыми. У них все получается словно само собой. У них есть команды, рвущиеся в бой, проекты, быстро набирающие ход, и до самого конца все вокруг такого руководителя работают с энтузиазмом. Эти руководители никогда не напрягаются. Выглядит все настолько просто, что никто не верит, что они вообще руководят.
Глава 21. Что здесь происходит?

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

Между превосходным ремесленником и подмастерьем существует связь естественного авторитетного характера – учитель знает, как делать работу, а ученик – нет. Подчинение такому авторитету не роняет ничьего достоинства, не исключает инициативу, не делает невозможным установление связей с коллегами. Неуверенность, требующая повиновения, есть полная противоположность естественному авторитету. Она гласит: «Я существо другой касты, я руководитель. Я принадлежу к классу мыслящих. Мои подчинённые наняты лишь для того, чтобы выполнять мои решения».
Глава 22. Кто здесь главный?

Команда - это сеть, а не иерархия. Несмотря на уважение к понятию лидерства (культовое слово в нашей области), лидерству здесь просто нет места.
Глава 23. Сетевая модель поведения команды

Где-то в глубинах нашей родовой памяти затаилась мысль, что работа должна быть в тягость. Если вам нравится делать что-либо, это уже не работа. Если вам это очень нравится, то это, должно быть, греховное занятие. Вам не следует этим заниматься слишком много, а может быть, и вообще. А уж платить за это вам точно не следует. Вам, наверное, следует найти что-то другое, что больше похоже на работу. Тогда вы будете уставать, скучать и вообще будете несчастны – как все остальные.
Часть 5. Удовольствие от работы? Здесь?

Препятствуйте критическим замечаниям вроде "Это дурацкая идея", поскольку дурацкие идеи часто наводят других людей на умные мысли.
Глава 24. Мозговой штурм

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

Социология имеет большее значение, чем технология или даже деньги. Работа должна приносить продуктивное удовлетворение. Если работа не приносит радости, ничто другое уже не стоит внимания.
Глава 26. Как пробудить Хольгера

Люди ненавидят перемены…

Дело в том, что люди ненавидят перемены…

Я хочу убедиться, что вы меня поняли.

Люди действительно ненавидят перемены.

Очень сильно ненавидят.
Стив Мак – Менамин ( Steve McMenamin ) The Atlantic Systems Guild
Глава 30. Как сделать перемены возможными

И следует учесть, нет занятия более сложного, более сомнительного в перспективе, более опасного, чем быть во главе новых порядков. Врагами тебе становятся все те, кому на руку прежние порядки, а робкими защитниками – все те, кто может получить выгоду от новых.
Никколо Макиавелли «Государь» (1513)
Глава 30. А теперь послушаем другого знаменитого системного консультанта

Основная реакция на перемены не логическая, но эмоциональная.
Глава 30. Классная идея, босс. Займусь немедленно

Неспособный измениться никогда не станет лучше.
- Том Демарко (1997)
Глава 30. Классная идея, босс. Займусь немедленно

Как ни парадоксально, изменения могут быть успешными лишь в том случае, если неудача (хотя бы до некоторой степени) также допустима.
Глава 30. Безопасность прежде всего

Предприятия интеллектуальной сферы должны осознавать, что именно вложения в человеческий капитал важнее всего. Хорошие компании давно это поняли
Глава 31. Под дудку Уолл-стрит

Обучение ограничено способностью организации сохранять своих людей
Глава 32. Опыт и обучение

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

Человеческий фактор. Успешные проекты и команды. Часть 1

2009-12-07T00:55:00.001-08:00

Сегодня я хочу опубликовать цитаты из замечательной книги Тома Демарко и Тимоти Листера "Человеческий фактор: успешные проекты и команды" (рецензия на моем блоге и сайте rsdn.ru). Как и книга Фредерика Брукса, эта книга произвела на меня сильное впечатление и является одной из самых любимых в библиотеке компьютерной литературы. В очередной раз перелистывая ее, понимаешь, насколько много в ней интересных мыслей и насколько эти мысли редко доходят до нужных голов и еще реже воплощаются на практике.

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

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

Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
Глава 1. Миражи высоких технологий

Если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на тёмной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».
Глава 1. Миражи высоких технологий

Нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.
Глава 2. Менеджмент, простецкое определение

Вена, которая, по словам Билли Джоэла, ждёт тебя, – это последняя остановка на твоём жизненном пути. Когда ты окажешься там, все будет кончено. Если вам кажется, что участников проекта никогда не интересуют такие серьёзные вещи, подумайте получше. Ваши люди очень остро понимают, что человеку дана лишь одна короткая жизнь, и они слишком хорошо знают, что в этой жизни должно быть что-то поважнее, чем их глупая работа.
Глава 3. Письмо из дома

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

Сверхурочные похожи на спринт: он имеет смысл на последней стометровке марафонской дистанции для тех людей, у которых ещё остались силы, но если начать спринт на первом километре, вы только зря потеряете время. Если заставлять людей постоянно бежать в темпе спринта, они лишь потеряют уважение к руководителю. Лучшие из сотрудников уже все это проходили – они будут молчать и закатывать глаза, пока руководитель бредит, что эту работу просто необходимо закончить к апрелю. После этого они воспользуются компенсирующими недоработками и в конечном итоге каждую неделю будут работать не более сорока часов. Так реагируют лучшие; все остальные – просто трудоголики.
Глава 3. Сверхурочные не существуют

Осознание того, что большие ценности (семья, любовь, дом, молодость) принесены в жертву меньшим (работа), разрушительно. Оно заставляет человека, совершившего столь глупую жертву, искать отмщения. Он не пойдёт к шефу, чтобы спокойно и вдумчиво объяснить, что положение вещей должно измениться; он просто уйдёт – ещё один человек, который сгорел на работе. Так или иначе, его больше не будет.
Глава 3. Трудоголики

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

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

В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растёт, заполняя любое отведённое под неё время. Сейчас это мнение известно как закон Паркинсона.
Глава 5. Еще раз о законе Паркинсона

Даже в тех редких случаях, когда давление на человека остаётся единственным вариантом, руководитель должен это давление оказывать последним. Эффект гораздо сильнее, когда давление исходит от команды. Нам встречались случаи однородных команд, где руководителям пришлось бы занимать очередь, чтобы покричать на единственного человека, который не старается вмести со всеми.
Глава 5. А нашего Ивана вы видели?!

Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Глава 5. Университет Нового Южного Уэльса: некоторые данные

Назначение руководителя не в том, чтобы заставить людей работать, а в том, чтобы создать им условия для работы
Глава 6. Это и есть руководство

Есть миллион способов потерять рабочий день и ни одного, который бы компенсировал потерю
Часть 2. Офисная среда

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

Поток – это состояние глубокого, почти медитативного погружения в работу. В этом состоянии человек испытывает лёгкое чувство эйфории и не замечает течения времени: «Я начал работать. Когда оторвался, прошло уже три часа». Человек не прикладывает сознательных усилий, потому что работа, кажется, идёт потоком.
Глава 10. Поток

К сожалению, поток нельзя «включать» по желанию. Требуется медленное погружение в предмет, не менее пятнадцати минут концентрации, прежде чем появится это состояние. В период погружения вы особенно чувствительны к шуму и остановкам. Шумная среда может затруднить или сделать невозможным вход в поток
Глава 10. Поток

Мифический человеко-месяц. Часть 2

2009-12-04T01:13:00.001-08:00

Обещанная вторая часть цитат из замечательной книги Фредерика Брукса.

Как оказывается, что проект запаздывает на год?
... Сначала он запаздывает на один день.
Глава 14. Назревание катастрофы

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

Каждому начальнику нужно два вида данных: информация о срывах плана, которая требует вмешательства, и картина состояния дел, чтобы быть в курсе.
Глава 14. Под ковром

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

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

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

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

Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол.
У разработчика программного обеспечения нет такой утешительной веры. Сложность, с которой он должен совладать, по большей части является произвольной, необоснованно вызванной многочисленными человеческими установлениями и системами, которым должны удовлетворить его интерфейсы. Системы различаются интерфейсами и меняются во времени не в силу необходимости, а лишь потому, что были созданы не Богом, а разными людьми.
Глава 16. Глава 16. Неизбежны ли трудности? Трудности, вытекающие из сущности

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

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

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

Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было, нет и не будет
Александр Поуп "О критике"

В конце концов, я по происхождению программист, а оптимизм - это профессиональная болезнь данного ремесла
Глава 17. Анализ Харела

Любыми средствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языке не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода.
Глава 17. Объектно-ориентированное программирование: а медная пуля не подойдет?

Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем "одноразовые" компоненты
Эдвард Йордон
Глава 17. Что с повторным использованием?

История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.
Глава 19. Для чего понадобилось юбилейное двадцатое издание?

Архитектора можно сравнить с режиссером, а менеджера - с продюсером кинокартины
Глава 19. Центральные аргумент: концептуальная целостность и архитектор

Дополнительно привлекаемые на поздних стадиях проекта работники должны быть игроками команды, стремящимися войти в игру и вписаться в процесс, а не пытаться изменить или усовершенствовать сам процесс!
Глава 19. Насколько мифичен человеко-месяц? Модель и данные Бёма

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

Немногим Бог дает право зарабатывать на жизнь тем, чем они с радостью занимались бы по собственной воле, по увлечению. Я благодарен судьбе.
Эпилог. Пятьдесят лет удивления, восхищения и радости

Область связанных с компьютерами знаний претерпела взрыв, как и соответствующая технология. Будучи аспирантом в середине 50-х, я мог прочесть все журналы и труды конференций. Я мог оставаться на современном уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной жизни приходится с сожалением расставаться с интересами то в одной, то в другой подобласти, поскольку количество документов превысило всякую возможность справиться с ними. Масса интересов, масса замечательных возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие радости.
Эпилог. Пятьдесят лет удивления, восхищения и радости

Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:

Часть 1

Часть 2

Радости профессии

Мифический человеко-месяц. Часть 1

2009-12-04T01:11:00.001-08:00

Книга Фредерика Брукса “Мифический человеко-месяц” произвела на меня неизгладимое впечатление (более подробно можно почитать на моем блоге или на сайте rsdn.ru). Просто удивительно, насколько книга, написанная уже почти 35 лет назад может быть столь актуальной сегодня, особенно учитывая темпы, с какими развиваются компьютерная индустрия.

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

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

Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
Это радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг — отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
Глава 1. Радости профессии

Разработка грандиозных идей — это удовольствие, а поиск паршивых маленьких «жучков» — это всего лишь работа. В каждом творческом деле бывают ужасные периоды однообразного и кропотливого труда, и программирование не является исключением.
Глава 1. Печали профессии

Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.
Глава 2. Этот мифический "человеко-месяц"

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

В основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять.
Глава 2. Оптимизм

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

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

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

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

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.

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

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

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

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

Архитектор всегда должен быть готов показать пример реализации любой описанной им функции, но он не должен пытаться навязывать определенную реализацию.
Глава 6. Письменные спецификации - руководство

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

Мыслители встречаются редко, практики еще реже, но реже всего - мыслители-практики
Глава 7. Организация крупного программного проекта

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

Линейная экстраполяция данных, относящихся к коротким задачам, бессмысленна. Если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю менее чем за три минуты.
Глава 8. Объявляя удар

В неопубликованном исследовании 1964 года, которое провел E. F. Bardain, показано, что программисты продуктивно используют 27% рабочего времени.
Глава 8. Данные Портмана. Сноска №6

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

Планируйте выбросить первую версию — вам все равно придется это сделать.
Глава 11.Опытные заводы и масштабирование

Нежелание документировать проект происходит не только от лени или недостатка времени. Оно происходит от нежелания проектировщика связывать себя отстаиванием решений, которые, как он знает, предварительные. «Документируя проект, проектировщик становится объектом критики со всех сторон, и должен защищать все, что написал. Если организационная структура может представлять угрозу, не будет документироваться ничего, кроме того, что нельзя оспорить.»
Глава 11. Планируйте организационную структуру

Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50 процентов) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, один назад».
Глава 11. Два шага вперед, шаг назад

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

Среди современных кудесников, как и встарь, встречаются хвастуны: «Я могу писать программы, которые управляют воздушным движением, перехватывают баллистические ракеты, делают переводы по банковским счетам, управляют производственными линиями». На что есть ответ: «И я могу, и каждый может, но будет ли работать то, что ты напишешь?»
Глава 13. Целое и части

Все цитаты из книги Фредерика Брукса “Мифический человеко-месяц”:

Часть 1

Часть 2

Радости профессии

UPD: Добавлена цитата из главы 8. Спасибо intr за наводку:)

Крис Дейт. “Введение в системы баз данных”

2009-12-03T03:56:00.001-08:00

Крис Дейт в предисловии к своей замечательной книге "Введение в системы баз данных" приводит следующую выдержку Бертрана Рассела:

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

Интервью++: Бьерн Страуструп об эволюции языков

2009-12-03T03:47:00.001-08:00

Источник: MSDN Magazine 5/2008

Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, - в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций).