О создании сложных систем

Еще одна цитата из SICP:

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

Программирование и моделирование

Я тут начал читать замечательную книгу под названием "Структура и интерпретация компьютерных программ", а по сему я надеюсь на пополнение коллекции цитат из этой книги:) Итак, начнем.

Любая компьютерная программа – это порожденная человеческим разумом модель реального или воображаемого процесса. Эти процессы, возникающие из нашего опыта и мысли, многочисленны, сложны в деталях, и мы всегда понимаем их лишь частично. … Хотя наши программы представляют собой искусно собранные наборы отдельных символов, мозаики переплетенных функций, они непрерывно развиваются: мы изменяем их по мере того, как наше восприятие модели приобретает все большую глубину, расширяется и обобщается, до тех пор, пока модель не достигнет, наконец, метастабильного состояния в рамках следующей модели, с которой мы продолжим сражаться дальше.

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

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

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

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

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

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

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

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

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

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

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

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

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

Алан Перлис

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

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

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

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

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

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

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

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

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

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

Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

Часть 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

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

В книгах о менеджменте (которые я читал), говорится, что на 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. Обсуждение

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

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

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

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

 

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

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

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

 

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

 

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

 

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

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

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

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

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

Часть 1

Часть 2

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