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

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

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

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

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

Брайан Керниган (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.

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

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

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

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

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

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

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

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

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

Комментарии

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

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

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

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

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

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

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

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

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

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

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

О деньгах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как отмечает Дейкстра, "Способ управления сложными системами был известен еще в древности - 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 Иерархия

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

Часть 1

Часть 2

Часть 3

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

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

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

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

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

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

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

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

Часть 1

Часть 2

Часть 3

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

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

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

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

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

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

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

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

Часть 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

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

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

Мое развернутое мнение, в виде рецензии, можно почитать на моем блоге, а также на сайте 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).

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

Часть 3

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

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

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

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Часть 1

Часть 2

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

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

Часть 3

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

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

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часть 1

Часть 2