The Pragmatic
Programmer
20'h Anniversary Edition
David Thomas
Andrew Hunt
./•'У Addison-Wesley
Boston • Columbus • New York • San Francisco • Amsterdam • Саре Town
Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City
Sao Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
Программист
прагматик
Второе юбилейное издание
к 20-летию выхода книги
Дэвид Томас
ЭндрюХант
Москва
• Санкт-Петербург
2020
ББК
32.973.26-018.2.75
Х19
УДК
681.3.07
ООО "Диалектика"
Зав. редакцией С.Н. Тршуб
Перевод с анrлийскоrо И.В. Берштейна
Под редакцией канд. техн. наук И.В. Красикова
По общим вопросам обращайтесь в издательство "Диалектика" по адресу:
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме
и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на
магнитный носитель, если на это нет письменного разрешения издательства
1. Это ваша жизнь
Тема 2. Кот съел мой исходный код
Доверие в команде
Взятие на себя ответственности
Тема
3. Программная энтропия
- не навредить
Тема 4. Суп из камней и вареные лягушки
Прежде всего
Со стороны селян
Тема
5. Достаточно хорошее программное обеспечение
Идите на компромиссы с пользователями
Знайте меру
Тема
6. Ваш багаж знаний
29
30
31
32
32
34
36
37
38
40
41
42
Ваш багаж знаний
43
43
Создание своего багажа знаний
44
Цели
45
Возможности для обучения
47
47
49
Критическое мышление
Тема
7.
Общайтесь!
Знайте, с кем вы общаетесь
50
Знайте, что вам требуется сказать
51
51
Выбирайте удобный момент
Выбирайте стиль общения
Подавайте свои идеи в привлекательной форме
Привлекайте тех, с кем общаетесь
Учитесь слушать
Отвечайте людям
Документация
54
54
Краткие итоги
Глава
2. Прагматичный
52
52
53
53
53
подход
Тема
8. Сущность качественного проектирования
- это ценность, а не правило
Тема 9. DRY - пороки дублирования
Принцип DRY не только для кодирования
Принцип ЕТС
Инструментальные средства и библиотеки
Кодирование
Тестирование
Документация
Как уживаться с ортогональностью
Тема
11. Обратимость
Обратимость
Гибкая архитектура
Тема
12. Трассирующие пули
Код, сверкающий в темноте
Трассирующие пули не всегда попадают в цель
Трассирующий код в сравнении с прототипированием
Тема
13.
Прототипы и памятные записки
Что подлежит прототипированию
Как пользоваться прототипами
Прототипирование архитектуры
Как не следует пользоваться прототипами
Тема
14. Предметно-ориентированные языки
Некоторые предметно-ориентированные языки
Характеристики предметно-ориентированных языков
Компромисс между внутренними и внешними предметно
ориентированными языками
Внутренний предметно-ориентированный язык почти даром
Тема
15.
Оценивание
Какой точности оценки достаточно?
Откуда берутся оценки
Оценивание сроков выполнения проектов
Что ответить на просьбу что-нибудь оценить
Глава
Тема
3. Основные инструментальные средства
16. Сила простого текста
Что такое простой текст
В чем сила простого текста
Наименьший общий знаменатель
97
98
100
100
101
103
105
107
109
109
110
112
8
Оrnавnение
Тема
17.
Игры в скорлупки
Ваша собственная оболочка
Тема
18. Эффективное редактирование
Что означает свободное владение редактором
Стремление к свободному владению редактором
Тема
19.
Контроль версий
Все начинается с исходного кода
Ветвление
Контроль версий как центральный узел проекта
Тема
20.
Отладка
Психология отладки программ
Мысленная установка на отладку
С чего начинать отладку
Стратегии отладки
Программист в чужой стране
Бинарный поиск
Метод резинового утенка
Элемент удивления
Контрольный список вопросов по отладке
Тема
168
170
Крушения поездов
173
Изъяны rлобализации
175
Наследование усугубляет связывание
175
Все дело в изменениях
176
Тема 29. Манипулирование реальным миром
176
События
177
Конечные автоматы
181
Проектный шаблон "Обозреватель"
182
Модель "издатель-подписчик"
183
Реактивное проrраммирование, потоки данных и события
185
События вездесущи
186
Тема 30. Преобразовательное проrраммирование
189
Обнаружение преобразований
193
В чем же здесь польза
194
А как насчет обработки ошибок
198
Преобразования преобразуют проrраммирование
199
Тема 31. Налоr на наследование
199
Немноrо предыстории
200
кода
Трудности применения наследования для совместноrо использования
202
Лучшие альтернативы
207
Наследование редко является ответом
208
Тема 32. Конфиrурирование
208
Статическая конфиrурация
209
Конфиrурация как служба
210
Не пишите морально устаревший код
28.
Глава
Тема
6. Параллельность
213
33. Разрывание временноrо связывания
В поисках параллельности
Возможности для достижения параллельности
Возможности для достижения параллелизма
Выявить возможности проще всеrо
Тема 34. Общее состояние
-
неверное состояние
Неатомарные обновления
Множественные транзакции ресурсов
Обновления без транзакций
214
215
216
217
219
219
220
224
225
Оглавление
10
Другие виды исключительного доступа
Доктор, мне больно...
Тема
35. Акторы и процессы
Акторы могут быть только параллельными
Простой актор
Отсутствие явной параллельности
Erlang подготавливает почву
Тема
36. Классные доски
Классная доска в действии
Системы обмена сообщениями могут быть подобны классным доскам
Но не все так просто...
Глава
Тема
7. По ходу кодирования
37. Прислушивайтесь к своим инстинктам
Боязнь пустой страницы
Борьба с собой
Как прислушиваться к своим инстинктам
Время играть!
Не только свой код
Не только код
Тема
38.
Программирование по совпадению
Как программировать по совпадению
Как программировать обдуманно
Тема
39. Быстродействие
алгоритмов
Что подразумевается под оценкой алгоритмов
Асимптотическое обозначение
Разумное оценивание алгоритмов
Быстродействие алгоритма на практике
Тема 40. Рефакторинг
Когда следует выполнять рефакторинг
Порядок выполнения рефакторинга
Тема 41. Тестировать, чтобы кодировать
Обдумывание тестов
Кодирование на основе тестов
52. Доставляйте удовольствие своим пользователям
Тема 53. Гордость и предубеждение
331
332
332
336
337
338
340
Приложение А. Послесловие
343
программиста-прагматика
Ведение проекта путем контроля версий
Строгое и непрерывное тестирование
Затягивание сетки
Полная автоматизация
Тема
Нравственный ориентир
Представляйте будущее таким, каким вы хотите его видеть
344
345
Приложение Б. Библиоrрафия
347
Приложение В. Возможные ответы на упражнения
349
Предметный указатель
364
Отзывы о втором издднии книги
"По мнению некоторых, в своей книге Энди и Дэйв поймали молнию в бу
тылку; вряд ли кому-нибудь удастся в ближайшее время написать книгу, спо
собную взбудоражить целую отрасль так же, как и эта. Впрочем, молния иногда
поражает одно и то же место дважды, и эта книга служит явным тому доказа
тельством. Ее обновленное содержимое обеспечит ей неизменное присутствие в
списке самых лучших книг по разработке программного обеспечения в течение
последующих
20
лет, т.е. там, где ей и надлежит быть".
ВМ (Вики) Брассер
(VM (Vicky)
Brasseиr),
директор программы Ореп Soиrce
Strategy
(Стратегия открытого исходного кода)
в компании Jипiper
Networks
"Если вы стремитесь сделать свое программное обеспечение легко модерни
зируемым и сопровождаемым, держите под рукой эту книгу. В ней вы найдете
немало практических советов как технического, так и профессионального ха
рактера, которые еще многие годы сослужат вам верную службу в ваших про
ектах".
Андреа Гуле (Aпdrea Goиlet),
генеральный директор компании
учредитель компании
Corgibytes;
LegacyCode.Rocks.
"Это одна из тех книг, которые вывели меня из прежней колеи и направили
на путь успешной профессиональной деятельности в области разработки про
граммного обеспечения. Читая ее, я открыл для себя возможности стать искус
ным мастером своего дела, а не просто шестеренкой в большом механизме. Это
одна из самых знаменательных книг в моей жизни':
Оби Фернандес (ОЬiе Fernaпdez),
автор книги Тhе
Rails Way.
"Для новых читателей эта книга может послужить увлекательным введением
в мир современных практик разработки программного обеспечения, в станов
лении которого не последнюю роль сыграло первое издание книги. Те, кто уже
читал первое издание книги, вновь откроют в ней поучительные выводы и муд
рые практические советы, которыми она отличается в первую очередь. Матери
ал настоящего издания тщательно отобран и обновлен':
Дэвид А. Блэк
автор книги Тhе
(David А. Black),
Well-Grounded Rubyist.
14
"Я бережно храню на своей книжной полке старый экземпляр первого изда
ния этой книги. Мне не раз приходилось перечитывать ее, чтобы изменить свое
отношение к занятию программированием. В новом издании изменилось все и
ничего: сейчас я читаю книгу на своем планшете
iPad, разбирая
примеры исход
ного кода на современных языках программирования, но при этом основопола
гающие принципы, понятия и подходы остаются по-прежнему актуальными и
повсеместно применимыми. Спустя двадцать лет эта книга остается востребо
ванной, как никогда прежде. И мне радостно осознавать, что нынешние и буду
щие разработчики смогут многое почерпнуть из кладезя знаний Энди и Дэвида,
как это некогда удалось и мне".
Сэнди Мамоли (Saпdy Maтoli),
наставник по гибкой разработке программного обеспечения,
автор книги
How Self-Selection Lets People Excel.
"Первое издание этой книги, вышедшее двадцать лет назад, коренным обра
зом изменило направление моей профессиональной деятельности. Новое изда
ние может сделать то же самое и в вашей жизни':
автор книги
Майк Кон (Mike Соhп),
Succeeding with Agile, Agile Estimating
and Planning, and User Stories Applied.
ПОСВЯЩЕНИЯ
Посвящается Джельет и Элли, Захари и Элизабет, Генри и Стюарту.
0& АВТОРАХ
Дэйв Томас и Энди Хант являются признанными на международном уровне
ведущими авторитетами в сообществе разработчиков программного обеспече
ния. Они консультируют и выступают с докладами по всему миру. Совместно
они основали издательство
Pragmatic Bookshelf,
выпускающее завоевывающие
награды передовые книги для разработчиков программного обеспечения и яв
ляются авторами Манифеста гибкой разработки
(Agile Manifesto).
В настоящее время Дэйв преподает в колледже, увлекается резьбой по дереву
и экспериментирует с новыми технологиями и парадигмами программирования.
Энди пишет научно-фантастические повести, активно музицирует и любит по
возиться с техникой. Но больше всего оба они стремятся постоянно учиться.
pragdave.me
toolshed.com
Помню, как Дэйв и Энди впервые сообщили в
Tweeter о
новом издании этой
книги. И это было важное известие. Я наблюдал, с каким воодушевлением со
общество программистов встретило это известие, и оживленно откликнулся на
него, предвидя, что двадцать лет спустя настоящее издание окажется столь же
востребованным, как и прежде.
И то, что книга с подобной историей получила такие отклики, говорит о мно
гом. Мне выпала честь прочитать рукопись этой книги, чтобы написать насто
ящее предисловие к ней, и тогда я понял, почему она вызвала такой переполох.
И хотя это техническая литература, назвав ее таковой, можно сослужить ей
плохую службу. Ведь техническая литература нередко отпутивает своим содер
жимым, изобилующим сложными описаниями, непонятными терминами, за
мысловатыми примерами, невольно вызывающими у читателя ощущение собс
твенной тупости. Чем опытнее автор книги, тем легче читателю забыть, что при
изучении новых концепций он является начинающим.
Несмотря на многолетний опыт программирования, Дэйву и Энди пришлось
преодолеть немалые трудности, чтобы писать книгу с воодушевлением людей,
только что освоивших уроки данной профессии. Они не обращаются с чита
телем свысока, не считают его знатоком и даже не предполагают, что он читал
первое издание книги. Они воспринимают читателей такими, какими они есть
на самом деле,
-
программистами, которые стремятся совершенствоваться.
И чтобы помочь читателям в этом, они посвящают данной цели немало страниц
своей книги, делая один практический шаг за другим.
Откровенно говоря, они уже делали это и прежде. Ведь первое издание книги
изобиловало реальными примерами, новыми идеями и практическими совета
ми, которые и ныне актуальны для приобретения навыков программирования
и выработки умения мыслить как программист. И все же в настоящее обновлен
ное издание были внесены два важных усовершенствования.
Первое усовершенствование вполне очевидно и состоит в исключении уста
ревших ссылок и примеров, которые были заменены новым, современным со
держимым. В настоящем издании вы не найдете примеры инвариантов циклов
или сборочных машин. Не обращаясь к прежним примерам, Дэйв и Энди пос
тарались составить материал таким образом, чтобы читатели смогли извлечь из
него наибольшую пользу, прорабатывая отдельные уроки. В настоящем издании
такие старые принципы, как "не повторяться"
(don't repeat yourself, DRY),
очи-
Предисловие
17
щепы он накопившейся пыли и отреставрированы, и сверкают новыми яркими
красками.
Но по-настоящему привлекательным настоящее издание делает именно вто
рое усовершенствование. После написания первого издания книги у ее авторов
была возможность поразмыслить над тем, что они пытались в ней сказать, что
ее читатели должны были вынести из нее и воспринять ее так, как хотелось бы
авторам. Они получили отзывы на первое издание, выяснили, что было не так,
что требовало уточнения, а что было неверно понято. За двадцать лет книга
дошла до рук и сердец программистов во всем мире, а Дэйв и Энди, изучив от
зывы о ней, сформулировали новые принципы и понятия.
Они усвоили важность поддержки и осознали, что поддержка, бесспорно,
присуща разработчикам программного обеспечения в большей степени, чем
представителям большинства других профессий. Поэтому они начали настоя
щее издание с простого, но мудрого посыла: "это ваша жизнь': Он напоминает
нам о нашем потенциале в развитии созданной нами кодовой базы, нашей ра
боте и карьере. Он задает тон всей остальной части книги, которая представля
ет собой нечто большее, чем очередная техническая литература, изобилующая
примерами исходного кода.
Эта книга выгодно отличается от многочисленной технической литературы
на данную тему ясным пониманием ее авторов, что в действительности означает
быть программистом. Программирование
-
это попытка облегчить будущее, а
следовательно, труд коллег. Это умение быстро оправиться после совершенных
оплошностей, воспитание хороших привычек и овладение арсеналом инстру
ментальных средств. Но само программирование является лишь частью мира
программиста, который исследуется в этой книге.
Мне пришлось потратить немало времени, размышляя о жизненном пути в
программировании. Я не вырос на программировании, не изучал его в колледже
и не увлекался в юности техникой. Я приобщился к области программирования
к
25
годам, когда мне пришлось самому разбираться, что означает быть програм
мистом. Сообщество программистов заметно отличается от других сообществ, в
которые мне довелось входить. В этом сообществе заметна особая преданность
обучению и практичности, которая не только оживляет, но и отпугивает.
Для меня вхождение в такое сообщество сродни открытию совершенно но
вого мира или, по крайней мере, нового города, где мне нужно познакомиться с
соседями, выбрать свой продуктовый магазин, найти лучшую из кофеен. Потре
буется немало времени, чтобы сориентироваться на местности, найти наиболее
эффективные маршруты, избегать улиц с интенсивным движением, знать, когда
наиболее вероятны транспортные пробки. Погодные условия также могут быть
иными, чем в старом месте жительства, а следовательно, придется сменить свой
гардероб.
18
Предисловие
Первые несколько недель, а то и месяцев пребывания в новом городе мо
гут оказаться ужасными. И в этот период было бы замечательно иметь друже
любного знающего соседа, давно живущего в городе. Кто может провести для
вас экскурсию по кофейням? Только тот, кто хорошо знает местную культуру,
чувствует пульс жизни города и поможет вам не только почувствовать себя как
дома, но и стать полезным членом сообщества. И такими соседями для вас, чи татели, окажутся Дэйв и Энди.
У относительно начинающего может легко вызвать потрясение не столько
сам акт программирования, сколько процесс его становления как программиста.
Ведь для этого потребуется определенный сдвиг в образе мышления, изменение
привычек, видов поведения и ожиданий. Процесс вашего становления лучшим
программистом не произойдет лишь потому, что вы знаете, как программиро
вать. Ему должно удовлетворять твердое намерение и тщательно продуманная
практика. И эта книга служит руководством по эффективному становлению
лучшим программистом.
Но имейте в виду, что в книге ничего не говорится о том, как следует про
граммировать. Никаких философских рассуждений и обоснований по этому по
воду вы в ней не найдете. Авторы просто и ясно поясняют, как стать програм
мистом-прагматиком и выбрать свой подход к программированию, оставляя за
читателями право самим решать, желают ли они стать именно такими програм
мистами. Если вы считаете, что быть программистом-прагматиком
-
не для
вас, то авторы ничего против этого не будут иметь. Но если вы все же решите
им стать, они станут вашими дружелюбными соседями, показывающими путь
к желанной цели.
Сарон Йитбарек
(Saron Yitbarek),
учредитель и генеральный директор компании
CodeNewЬie
Host of Соттапd Line Heroes.
В далекие 1990-е годы мы работали с компаниями, испытывающими затруд
нения в своих проектах. И оказалось, что мы каждый раз спрашивали у них
одно и то же: "Может, вам лучше сначала тестировать свои программные про
дукты, а затем поставлять их? Почему код создается только на машинах разра
ботчиков и никто не спрашивает о нем мнения пользователей?"
Чтобы сэкономить время новых клиентов, мы стали делать заметки, которые
в конечном счете превратились в эту книгу. И к нашему удивлению, книга, по
видимому, нашла живой отклик у читателей, не потеряв свою популярность в
течение прошедших двадцати лет.
Но двадцать лет
-
немалый срок для разработки программного обеспечения.
Если попытаться переместить разработчика во времени из
1999
года и ввести
его в современную команду, он будет бороться с чуждым ему новым миром. Но
ведь и мир 1990-х годов в равной степени чужд современному разработчику.
Ссылки в настоящем издании на литературу по
CORBA, CASE,
индексирован
ным циклам были бы в лучшем случае забавны и, вероятнее всего, сбивали бы
с толку.
В то же время прошедшие двадцать лет не оказали никакого влияния на то,
что называется общими принципами. Ведь могла измениться технология, но не
люди. Некогда пригодные нормы практики и методы остаются таковыми и по
ныне. Эти вопросы, рассматривавшиеся ранее в книге, теперь вполне созрели.
И когда настало время выпустить настоящее 20-летнее юбилейное издание,
нам пришлось принять нелегкое решение. С одной стороны, мы могли бы про
смотреть и обновить описание тех технологий, на которые мы ссылались в пре
дыдущем издании, и на этом поставить точку. А с другой стороны, мы могли
бы пересмотреть свои рекомендации по поводу тех норм практики, которые мы
рекомендовали раньше, исходя из опыта, накопившегося за прошедшие двад
цать лет. Но в конечном счете мы сделали и то и другое.
В итоге книга стала чем-то подобным кораблю Тесея 1 • Около
одной трети тем
в ней оказались совершенно новыми, а остальные были частично или полно
стью переписаны. Мы намеревались сделать изложение материала более понят
ным, уместным и, как можно надеяться, непреходящим.
1 Известный
философский парадокс: если с годами заменить каждую вышедшую из строя
часть корабля, то останется ли он в итоге тем же самым кораблем?
20
Вступnение ко второму изданию
Нам пришлось принять ряд трудных решений. В частности, мы опустили при
ложение "Первоисточники" как потому, что было бы невозможно сохранить его
актуальность, так и потому, что нужные первоисточники читателю проще найти
самостоятельно. Кроме того, мы реорганизовали и переписали темы, касающи
еся параллелизма, принимая во внимание современное изобилие аппаратного
обеспечения для параллельных вычислений и недостаток способов их органи
зации. Наконец, мы добавили материал, отражающий перемены в отношениях и
средах: от движения за гибкую разработку, началу которого мы способствовали,
до растущего принятия идиом функционального программирования и потреб
ности принимать во внимание конфиденциальность и безопасность.
Любопытно, однако, что споров по поводу содержимого настоящего издания
у нас было меньше, чем при написании первого издания этой книги. Мы оба
считали, что выявить важный материал на этот раз было проще.
Так или иначе, настоящее издание увидело свет, так что пользуйтесь им во
благо, возможно, приняв новые нормы практики, а может быть, решив, что
некоторая часть предлагаемого нами материала вам не подходит. Но в любом
случае мы надеемся, что вы глубже вникнете в свое ремесло и откликнетесь на
нашу книгу. А самое главное, не забудьте позабавиться.
СТРУКТУРА книги
Эта книга написана как собрание кратких тем, каждая из которых самодоста
точна и посвящена конкретному предмету. В тексте вы найдете многочислен ные перекрестные ссылки, помогающие ввести каждую тему в соответствующий
контекст. Отдельные темы можно читать в произвольном порядке, поскольку
эта книга составлена таким образом, чтобы не читать ее от корки до корки.
Периодически в книге вам будут встречаться врезки под заголовком "Совет
пп" (например, "Совет
1.
Заботьтесь о своем ремесле"). Мы рассматриваем по
добные советы как обращающие на себя внимание места в тексте книги. Они
имеют самостоятельное значение и служат для того, чтобы пользоваться ими
ежедневно в практической деятельности.
В настоящем издании были включены упражнения и задачи там, где это было
уместно. Как правило, упражнения имеют относительно простые решения, тог
да как задачи допускают многие решения. Чтобы дать представление о ходе сво
их рассуждений, мы выделили решения упражнений в отдельное приложение к
книге, хотя лишь немногие из них имеют единственное правильное решение. А
предлагаемые задачи могут послужить основанием для групповых обсуждений
или самостоятельных работ на специализированных курсах по программирова
нию. Кроме того, в конце книги приведен перечень литературы (книг и статей),
на которую делаются явные ссылки в тексте самой книги.
Вступnение ко второму изданию
21
Что ОЗНАЧАЕТ имя
"- Когда я
беру слово, оно означает то,
что я хочу, не больше и не меньше,
сказал Шалтай-Болтай презрительно" 2 •
Льюис Кэрролл, Алиса в Зазеркалье
Текст книги испещрен различными профессиональными терминами: как
обычными словами, несколько искаженными, чтобы выразить какой-то особый
технический смысл, так и жуткими словами, намеренно выбранными для обоз
начения отдельных понятий из вычислительной техники теми специалистами
в данной области, которые пренебрежительно относятся к языку. При первом
употреблении термина делается попытка определить понятие, которое он обоз
начает, или хотя бы намекнуть на его смысловое значение. Но, на наш взгляд,
одни термины так и остались невостребованными, тогда как другие (например,
объект и реляционная база данных)
-
настолько распространены, что не требу
ют дополнительного определения. Если же вам встретится незнакомый прежде
термин, не пропускайте его, а найдите время, чтобы выяснить его обозначение
в Интернете или справочнике по вычислительной технике. И если ваши поиски
завершатся удачно, то сообщите нам по электронной почте, чтобы мы добавили
найденное вами определение термина в последующее издание книги.
Несмотря на все сказанное выше, мы все же решили отомстить специалистам
по вычислительной технике. В частности, мы решили пренебречь некоторыми
вполне пригодными терминами для обозначения отдельных понятий. Почему?
А потому, что существующая ныне терминология, как правило, ограничивает
ся конкретной предметной областью или стадией разработки. Но ведь один из
основных принципов данной книги состоит в том, что большая часть рекомен
дуемых нами методик оказывается универсальной. Так, модульность применима
к исходному коду, проектным решениям, документации и организации команд
разработчиков. Когда же требовалось употребить обычный термин в более
широком контексте, то возникало недоразумение, поскольку нам не удавалось
преодолеть границы той смысловой нагрузки, которую нес первоначальный тер
мин. И когда происходило нечто подобное, мы решали пренебречь языковыми
нормами, изобретая свои термины.
2
Перевод Н.М. Демуровой.
22
Вступление ко второму изданию
Исходный код и ДРУГИЕ РЕСУРСЫ
Большая часть исходного кода, приведенного в этой книге, взята из компили -
руемых исходных файлов и свободно доступна для загрузки с нашего веб-сай
та3. Там приведены также ссылки на другие полезные ресурсы наряду с обновле
ниями книги и новостями о других разработках программистов-прагматиков.
ПРИСЫЛАЙТЕ НАМ СВОИ ОТЗЫВЫ
Мы будем рады вашим откликам на книгу. Пишите нам по адресу электрон
ной почты
ppbook@pragprog. сот.
БЛАГОДАРНОСТИ ЗА ВТОРОЕ ИЗДАНИЕ КНИГИ
Мы выгодно воспользовались буквально тысячами интересных бесед о про
граммировании, проведенных за последние двадцать лет, встречая разных людей
на конференциях, курсах, а иногда и просто в самолете. Каждая из таких бесед
расширила наше представление о процессе разработки программного обеспече
ния и способствовала обновлению настоящего издания. Благодарим всех участ
ников этих бесед и просим известить нас, если мы в чем-то не правы.
Благодарим также участников процесса создания бета-версии этой книги.
Ваши вопросы и комментарии помогли нам лучше разъяснить отдельные воп
росы, затронутые в книге.
Прежде чем перейти к бета-версии этой книги, мы поделились ее рукописью
с несколькими людьми, чтобы они оставили свои комментарии к ней. Благо
дарим ВМ (Вики) Брассера
(VM (Vicky) Brasseur), Джеффа Лангра (Jeff Langr)
Shrier) за подробные комментарии, а Хозе Валима (Jose
Valim) и Ника Катберта (Nick Cuthbert) - за техническое рецензирование.
Благодарим Рона Джеффриса (Ron Jeffries) за предоставленную нам возмож
и Кима Шриера (Кim
ность воспользоваться примером из судоку. Выражаем большую признатель
ность сотрудникам издательства
Pearson,
согласившихся на то, чтобы мы со
ставили эту книгу по-своему. Особая благодарность выражается незаменимой
Джанет Ферлоу
(Janet Furlow),
которая мастерски справляется со всем, за что бы
она ни бралась. В частности, она следила за тем, чтобы мы поэтапно выполняли
свою работу над книгой в срок.
Наконец, выражаем во всеуслышание слова искренней признательности всем
программистам-прагматикам, сделавшим программирование лучше для всех за
последние двадцать лет. Теперь остается еще двадцать лет.
3
См. по адресу https: / /pragprog. com/titles/tpp20/source_code.
Эта книга поможет вам стать более совершенным программистом. Вы можете
быть самостоятельным разработчиком, членом команды в крупном проекте или
консультантом, одновременно работающим со многими компаниями. Так или ина
че, эта книга поможет вам в индивидуальном плане лучше выполнять свою работу.
Она не носит теоретический характер, а сосредоточена на практических вопросах
и применении накопленного опыта для принятия более обоснованных решений.
Термин прагматик происходит от латинского слова
pragmaticus,
обозначающего
"опытный в деле" и производного, в свою очередь, от греческого слова ттрауµат1к6~,
обозначающего "пригодный для использования': Это книга о делании.
Программирование
-
это ремесло. В простейшем случае оно сводится к тому,
чтобы заставить компьютер сделать то, что требуется программисту или поль
зователю его программы. Программист выступает отчасти в роли слушателя,
советчика, переводчика и диктатора. Он пытается уяснить туманные исходные
требования и найти способ выразить их таким образом, чтобы вычислительная
машина смогла воздать им должное. Он старается задокументировать и органи
зовать результаты своих трудов таким образом, чтобы другие могли их понять и
опереться на них. Более того, программист старается сделать все это, несмотря
на неумолимые сроки выполнения проекта. Каждый день программист творит
небольшие чудеса, а это трудное дело.
Многие люди готовы оказать помощь программисту. Так, поставщики инс
трументальных средств на все лады расхваливают чудеса, которые способны
творить их программные продукты. Знатоки методологии обещают, что их ме
тодики гарантированно принесут ожидаемые результаты. И каждый заявляет,
что его язык программирования самый лучший, а операционная система дает
ответы на все мыслимые вопросы.
Все это, конечно, не соответствует действительности, ведь простых ответов
не бывает. Не существует самого лучшего решения, будь то инструментальное
средство, язык программирования или операционная система. А могут быть
лишь такие системы, которые более пригодны в конкретных обстоятельствах.
Именно здесь и может пригодиться прагматизм, который означает, что не
следует привязываться к какой-нибудь конкретной технологии, но нужно иметь
достаточно обширные знания и опыт, позволяющие принимать правильные
решения в конкретных обстоятельствах. Знания проистекают из понимания
основных принципов вычислительной техники, а опыт
-
из обширного ряда
практических проектов. Теория в сочетании с практикой составляют прочный
фундамент для программиста.
Из вступпения к первому изданию
24
Свой подход программист приспосабливает к текущим обстоятельствам и
окружению. Он оценивает относительную важность всех факторов, оказываю
щих влияние на проект и пользуется своим опытом для выработки подходящих
решений. И делает он это постоянно по мере продвижения своей работы. Про
граммисты-прагматики доводят свою работу до конца и делают ее хорошо.
Кому АДРЕСОВАНА этА книгА
Она адресована тем, кто стремится стать более эффективным и продуктив
ным программистом. Вы, вероятно, испытываете разочарование от того, что
не раскрываете, как вам кажется, свой истинный потенциал. А может быть, вы
обращаете внимание на своих коллег, которые пользуются инструментальными
средствами с целью повысить производительность своего труда. Возможно, в
своей нынешней работе вы пользуетесь старыми технологиями и хотите узнать,
как приложить новые идеи к тому, что вы делаете.
Мы не претендуем ни на то, чтобы ответить на все (или хотя бы большинство)
вопросы, возникающие у программистов, ни на применимость наших идей во всех
возможных случаях. Мы можем лишь сказать, что если вы выберете наш подход,
то быстро приобретете необходимый опыт, производительность вашего труда воз
растет и вы станете лучше понимать весь процесс разработки программного обес
печения. И в конечном счете вы сможете писать более качественные программы.
Что ОЗНАЧАЕТ БЫТЬ ПРОГРАММИСТОМ-ПРАГМАТИКОМ
Каждый разработчик неповторим, отличаясь своими сильными и слабыми
сторонами, симпатиями и антипатиями. Со временем каждый разработчик со
здает свою собственную среду, отражающую его индивидуальность в той же не
умолимой степени, как и его увлечения, одежда или прическа. Но если вы явля
етесь программистом-прагматиком, то вам присущи многие из перечисленных
ниже общих характеристик.
•
Своевременно принимаете новшества на вооружение и быстро приспо
сабливаетесь к ним. Инстинктивно чувствуете преимущества отдельных
технологий и методик, и вам нравится опробовать их. Если вам дают что
то новое, вы быстро осваиваете его, присоединяя приобретенное к осталь
ным своим знаниям. Ваша уверенность рождается с опытом.
•
Любознательны. Стремитесь задавать вопросы. Например: как вы это
сделали? Возникли ли у вас трудности с данной библиотекой? Что такое
квантовые вычисления, о которых я слышал? Каким образом реализуются
символические ссылки? Задавая подобные вопросы, вы как барахольщик
собираете мелкие факты, каждый из которых может оказать влияние на
какое-нибудь решение многие годы спустя.
Из вступления к первому изданию
•
25
Мыслите критически. Редко принимаете что-то на веру, не получив сна
чала подтверждающие факты. Так, если коллеги говорят: "Потому что надо
делать так!" или если поставщик обещает решить все ваши проблемы, вы
нюхом чуете предстоящие трудности.
•
Реалистичны. Стараетесь понять потаенный характер каждого возника
ющего у вас затруднения. Подобный реализм дает вам ясное понимание,
в чем именно состоят трудности и как долго их придется преодолевать.
Глубоко понимая, что процесс должен быть трудным или его завершение
отнимет время, вы приобретаете необходимую выдержку, чтобы спра
виться с ним .
•
Мастер на все руки. Прилежно стараетесь освоить обширный ряд тех
нологий и сред, работая над тем, чтобы быть в курсе новых разработок.
И хотя ваша текущая работа может потребовать специальной квалифи
кации, вы всегда готовы перейти в новые сферы деятельности и принять
новые вызовы.
Мы оставили рассмотрение большинства основных характеристик напосле
док. Они присущи всем программистам-прагматикам и настолько просты, что
их можно сформулировать в виде отдельных советов, как показано ниже.
11;.ц411
Заботьтесь о своем ремесле
Мы считаем, что разрабатывать новое программное обеспечение нет смысла,
если не позаботиться о том, чтобы делать это как следует.
Думайте! О своей работе
Чтобы стать программистом-прагматиком, мы призываем вас думать о том,
что вы делаете в тот момент, когда вы это делаете. Это не единовременная ре
визия текущих норм практики, а непрерывная критическая оценка каждого
принимаемого решения, производимая каждый день и в каждом проекте. Ни
когда не двигайтесь на автопилоте. Постоянно думайте, критически оценивая
свою работу в реальном времени. Старый девиз корпорации IBM "ДУМАЙ!"
(THINК!) является мантрой для программиста-прагматика.
Если такая работа покажется вам трудной, значит, вы выказываете реалис
тичную характеристику. На это потребуется немного вашего драгоценного вре
мени, которого, вероятно, и так не хватает. Но в награду за усердие вы более
активно вовлекаетесь в свое любимое дело, чувствуя, что вполне владеете не
уклонно расширяющимся рядом предметов, а такжеполучаете удовольствие от
Из вступления к первому изданию
26
постоянного совершенствования. А в долгосрочной перспективе потраченное
вами время окупится сторицей, когда вы и ваша команда станете работать бо
лее эффективно, чтобы писать легко сопровождаемый код и проводить меньше
времени на совещаниях.
ИНДИВИДУАЛЬНЫЕ ПРАГМАТИКИ И КРУПНЫЕ КОМАНДЫ
Некоторые считают, что индивидуальности нет места в крупных командах
или сложных проектах. "Программное обеспечение
лина,
-
-
говорят они,
-
техническая дисцип
которая нарушается, если отдельные члены команды
принимают решения самостоятельно". Мы категорически не согласны с таким
утверждением.
В построении программного обеспечения должна присутствовать техничес
кая составляющая, но это совсем не мешает проявлять индивидуальное мас
терство. Рассмотрим в качестве примера крупные кафедральные соборы, пост
роенные в Европе в период Средневековья. Воздвижение каждого из них потре
бовало немалых затрат, измеряемых тысячами человеко-часов в течение многих
десятилетий. Усвоенные уроки передавались от одного поколения строителей
к другому поколению, которое совершенствовало строительную технику свои
-
ми индивидуальными достижениями. Но ведь плотники, каменотесы, резчики
и стеклодувы были ремесленниками, воплощавшими технические требования
в нечто целое, выходившее за пределы исключительно механической стороны
строительства. Даже те, кто лишь тешут камни, должны всегда представлять
себе целые соборы.
Во всей структуре проекта всегда найдется место индивидуальности и мас
терству. И это особенно справедливо для текущего состояния разработки про
граммного обеспечения. Это состояние может показаться через сто лет таким
же архаичным, как и методы, применявшиеся средневековыми строителями ка
федральных соборов, современным инженерам-строителям, хотя мастерство в
данной отрасли по-прежнему в почете.
Это НЕПРЕРЫВНЫЙ ПРОЦЕСС
Турист, однажды посетивший Итонский колледж в Англии, спросил са
довника, как ему удается поддерживать лужайку в идеальном состоянии.
"Очень просто,
-
ответил тот.
-
Нужно лишь смахивать росу каждое
утро, стричь траву каждый день и сволакивать ее раз в неделю".
"И это все?"
-
спросил турист.
'116солютно все! -
ответил садовник.
-
Делайте это в течение 500 лет,
и у вас тоже получится прекрасная лужайка".
Из вступления к первому изданию
27
Прекрасные лужайки требуют небольшого ухода, как, впрочем, и отличные
программисты. Консультанты по управленческим вопросам любят вставлять
словечко кайзен в свои беседы. Термин кайзен по-японски обозначает понятие
непрерывного процесса внесения многих мелких усовершенствований, что по
служило одной из главных причин для коренных изменений в производитель
ности и качестве изготовления японских товаров и широко размножившееся по
всему миру. Кайзен применяется и на индивидуальном уровне, где отдельные
личности ежедневно работают над совершенствованием собственных навыков,
пополняя свой арсенал новыми инструментальными средствами. Но, в отличие
от итонских лужаек, они начинают замечать результаты буквально через счи
танные дни. А с годами они изумляются, насколько расцвел их личный опыт, и
развились их индивидуальные навыки.
От издАтЕльствА
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим
ваше мнение и хотим знать, что было сделано нами правильно, что можно было
сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно
услышать и любые другие замечания, которые вам хотелось бы высказать в наш
адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам
электронное сообщение, либо просто посетить наш веб-сайт и оставить свои за
мечания там. Одним словом, любым удобным для вас способом дайте нам знать,
нравится или нет вам эта книга, а также выскажите свое мнение о том, как сде
лать наши книги более интересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее
авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим
мнением и обязательно учтем его при отборе и подготовке к изданию последу
ющих книг.
Наши электронные адреса:
E-mail:
info@dialektika.com
WWW:
http://www. dialektika. com
Глдвд
Эта книга о вас. Будьте уверены, что программирование
а самое главное
-
-
1
это ваша карьера,
это ваша жизнь, и она принадлежит вам. И вы приступили
к чтению этой книги потому, что знаете, что можете не только сами стать более
искусным разработчиком, но и помочь другим разработчикам стать лучше. Сле
довательно, вы способны стать программистом-прагматиком.
Что же отличает программистов-прагматиков? На наш взгляд, это отноше
ние, стиль и философский подход к задачам и их решениям. Их мышление вы
ходит за пределы непосредственной задачи, ставя ее в более крупный контекст,
чтобы получить общую картину. Ведь как иначе быть прагматичным без этого
более крупного контекста и как в таком случае находить разумные компромис
сы и обоснованные решения?
Еще один ключ к успеху состоит в том, что программисты-прагматики берут
на себя ответственность за все, что делают, как обсуждается в разделе "Кот съел
мой исходный код': Будучи ответственными, программисты-прагматики не си
дят без дела, безучастно наблюдая за тем, как их проекты буквально распадают
ся на части из-за небрежения ими. Поэтому в разделе "Программная энтропия"
далее в этой главе поясняется, как поддерживать свои проекты в безупречном
состоянии.
Большинство людей находят перемены трудными
-
иногда по веским осно
ваниям, а иногда просто по укоренившейся инерции. Поэтому в разделе "Суп из
камней и вареные лягушки" рассматривается стратегия побуждающих к дейс
твию перемен и (ради равновесия) представлена поучительная история об од
ном земноводном, пренебрегшем опасностями, скрывающимися в постепенных
переменах.
Одно из преимуществ, дающих понимание контекста, в котором вы работа
ете, заключается в том, что вам просто легче выяснить, насколько качественно
разработанное вами программное обеспечение. Иногда близкое к идеальному
качество оказывается лишь одним из возможных вариантов, но зачастую при
ходится идти на компромиссы. Более подробно этот вопрос рассматривается в
разделе "Подходящее программное обеспечение':
30
Глава
1 • Философия
прагматизма
Безусловно, чтобы все это осилить, потребуется обширная база знаний, по
этому обучение
-
это непрерывно продолжающийся процесс. В связи с этим в
разделе "Ваш багаж знаний" описываются некоторые стратегии поддержания
динамики данного процесса.
Наконец, никто из нас не работает в вакууме. Все мы проводим немало вре
мени, общаясь с другими людьми. Поэтому в разделе "Общайтесь!" перечислены
способы, помогающие делать это лучше.
Прагматичное программирование происходит от философии прагматичного
мышления. И в этой главе закладывается основание для такой философии.
l1Jitii
Это ВАША жизнь
"Я в этом мире не для того, чтобы жить по вашим
ожиданиям, а вы
-
не для того, чтобы жить по моим".
Брюс Ли 4
Это ваша жизнь, и она принадлежит вам. Вы ее ведете и творите.
Многие разработчики жалуются нам на свою разочарованность. Их пробле
мы различны . Одни ощущают застой в своей работе, а другие считают, что тех
нический прогресс обошел их стороной. Они полагают, что их недооценивают,
им недоплачивают или в их командах отравляющая атмосфера. Возможно, они
хотят переехать в Азию или в Европу, а может быть работать дома. И в ответ на
все эти жалобы мы всегда задаем один и тот же вопрос: "Почему вы не можете
это изменить?"
Разработка программного обеспечения должна находиться близко к началу
любого доступного списка требующихся специальностей. Навыки разработчи
ков востребованы, их знания распространяются за пределы географических гра
ниц, они работают в удаленном режиме, получая за свой труд хорошую плату.
И вообще, они могут делать почти все, что хотят.
Но по какой-то причине разработчики противятся переменам. Они выжида
ют, надеясь, что положение дел переменится к лучшему. Они пассивно наблюда
ют за тем, как их навыки устаревают, жалуясь на то, что их компании ничему их
не обучают. Они рассматривают рекламные объявления экзотических стран в
городском транспорте, а затем выходят под холодный дождь и бредут на работу.
Поэтому ниже приведен самый важный совет в этой книге.
l•З+t§fl
4
У вас есть свобода выбора
Bruce Lee - гонконгский и американский киноактер, режиссер, сценарист, продюсер,
- Примеч. пер.
популяризатор и реформатор в области китайских боевых искусств.
Тема 2 • Кот съеп мой исходный код
31
Вас заедает среда? Вам надоела работа? Попробуйте исправить положение, но
не затягивайте свою попытку до бесконечности. По этому поводу Мартин Фау
лер говорит следующее: "Вы можете сменить организацию или изменить свою
организацию" 5.
Если вам кажется, что технический процесс обходит вас стороной, навер
стайте упущенное, изучая в свое личное время то, что вам кажется интересным.
Тем самым вы инвестируете в самих себя
-
так что заниматься самообразова
нием в свободное от работы время вполне благоразумно.
Желаете работать в удаленном режиме? Поинтересуйтесь в одном месте. Если
вам откажут, поищите другое место, где вас возьмут на работу. Данная отрасль
дает вам немало замечательных возможностей, поэтому проявите заранее ини
циативу, чтобы воспользоваться ими.
Другие разделы, свяэаннъ1е с данной темой
•
Тема
4.
Суп из камней и вареные лягушки.
•
Тема
6.
Ваш багаж знаний.
l1jЦfj Кот съел мой исходный код
"Величайшей из всех слабостей есть страх
показаться слабым".
Ж.Б. Боссюэ6,
Политика из Святого Писа11ин
(Politics from Holy Writ), 1709 z.
Одним из краеугольных камней прагматичной философии является идея
взять на себя ответственность за свои действия в отношении продвижения по
карьерной лестнице, обучения и образования, выполнения своего проекта и
повседневной работы. Программисты-прагматики сами заботятся о своей ка
рьере и не боятся признавать свое невежество или ошибки . Это, конечно, не
самая приятная сторона программирования, но она все же проявляется даже в
самых удачных проектах. Порой дело не ладится, несмотря на проведенное тес
тирование, грамотно составленную документацию и сплошную автоматизацию.
И тогда выпуск программного продукта задерживается в связи с возникшими
непредвиденными техническими трудностями .
Если происходит нечто подобное, мы стараемся обращаться с командой как
можно более профессионально. А это означает быть честными и откровенны-
См. по адресу http: / /wiki. с2 . c orn/ ?ChangeYourOrganization.
J.B. Bossuet - французский проповедник и богослов XVII века, а также писатель и епис
коп. - Примеч. пер.
5
6
Гnава 1 • Философия прагматизма
32
ми. Мы можем гордиться своими способностями, но должны признавать и свои
недостатки: невежество и ошибки.
ДОВЕРИЕ В КОМАНДЕ
Прежде всего, ваша команда должна доверять вам и полагаться на вас, а
вы
-
спокойно полагаться на каждого из ее членов. Доверие в команде совер
шенно необходимо для проявления творческой инициативы и сотрудничества,
как следует из литературы, в которой исследуется данный вопрос 7 • В здоровом
окружении, основанном на доверии, вы можете смело высказывать свои мысли,
представлять свои идеи на суд коллег и полагаться на других членов команды
так же, как и они на вас. Ведь без доверия ...
Представьте, что высокотехнологичная команда ниндзя незаметно проникает
в самое логово преступников. После нескольких месяцев тщательного планиро
вания и изнуряющих тренировок вы, наконец-то, добрались до места. И теперь,
когда настал ваш черед настроить систему лазерного наведения, вы неожиданно
для остальных заявляете: "Извините, ребята, у меня нет с собой лазера. Мой кот
играл с красной точкой лазерного целеуказателя, и поэтому я оставил его дома".
Нарушенное подобным образом доверие вряд ли удастся восстановить.
ВЗЯТИЕ НА СЕБЯ ОТВЕТСТВЕННОСТИ
Ответственность
-
это нечто такое, на что вы активно соглашаетесь. В част
ности, вы берете на себя обязательство обеспечить правильность выполнения
какой-то работы, но совсем не обязательно имеете непосредственный контроль
над каждой стадией данного процесса. Помимо того, что вы стараетесь выпол
нить свою работу как можно лучше, вам приходится также анализировать си
туацию на наличие неподконтрольных вам рисков. Вы имеете полное право не
брать на себя ответственность за непредсказуемую ситуацию или такую, когда
риски слишком велики или этические последствия слишком постыдны. И тогда
вам придется принимать решение, исходя из ваших собственных ценностей и
суждений.
Если вы все же берете на себя ответственность за конечный результат, то
должны учитывать, что вам придется нести ответственность за него. И если вы
допустите оплошность, как это делаем все мы, или совершите ошибку в сужде
нии, то признайте ее честно и постарайтесь предложить другие варианты выхо
да из затруднительной ситуации.
Не сваливайте вину на кого-то или что-то другое и не ищите оправданий. Не
вините во всем трудности у поставщика, язык программирования, руководство
7
Наглядный пример мета-анализа см. в статье Trust and team performance: А meta-analysis
of main effects, moderators, and covariates
(Доверие и производительность команды. Мета
анализ основных эффектов, посредников и ковариаций), доступной по адресу
или коллег. Любой из этих факторов может сыграть свою отрицательную роль,
но именно вьt должны найти правильные решения, а не оправдания.
На случай, если существует риск, что поставщик вас подведет, у вас должен
быть план экстренных мероприятий. Если же выйдет из строя устройство памя
ти, а вместе с ним исчезнет весь исходный код и у вас не окажется его резервной
копии,
это будет вашей оплошностью. Оправдание перед начальством вроде
-
"кот съел мой исходный код" просто не пройдет.
111
Предлагайте варианты разрешения затруднений,
а не оправдания и извинения
Прежде чем подходить к кому-нибудь и объяснять причины, по которым
что-то нельзя сделать, что-то запаздывает или не работает, остановитесь и пос
лушайте себя. Обратитесь к резиновому утенку или котенку на своем мониторе,
чтобы опробовать на нем, звучат ли ваши оправдания благоразумно или нелепо
и как они будут звучать перед вашим начальством.
Воспроизведите весь разговор в уме и подумайте, что, вероятнее всего, от
ветит друrой его участник. Спросит ли он вас, пробовали ли вы сделать вот это
или не учли ли вы вот то? Как вы на это ответите? Прежде чем идти к нему,
чтобы сообщить плохие новости, подумайте, можно ли опробовать что-нибудь
еще? Иногда вы просто знаете, что он вам ответит, так что избавьте его от лиш
них хлопот.
Вместо оправданий предлагайте свои варианты разрешения затруднений.
Не говорите, что чего-то нельзя сделать. Лучше поясните, что можно сделать,
чтобы выйти из трудного положения. Некоторый исходный код должен быть
удален? Скажите об этом и объясните важность этого рефакторинга (см. раздел
"Тема
40.
Рефакторинг" главы
7
"По ходу кодирования").
Требуется ли вам время на прототипирование, чтобы найти наилучший путь
продолжить разработку (см. раздел "Тема
главы
2
ное тестирование (см. разделы "Тема
вы
7
13.
Прототипы и памятные записки"
"Прагматичный подход")? Требуется ли вам внедрить более совершен
41.
Тестировать, чтобы кодировать" гла
"По ходу кодирования" и "Строгое и непрерывное тестирование" главы
"П рагматичные
проекты
")
9
или его автоматизация, что б ы не повторять тестиро-
вание снова вручную?
Вам могут понадобиться дополнительные ресурсы для окончательного реше
ния задачи тестирования, а возможно, придется уделить больше времени взаи
модействию с пользователями. Или же все дело просто в вас самих, а значит, вам
требуется более углубленно изучить какую-нибудь методику или технологию.
Помогут ли вам в этом какие-нибудь книги или курсы? Не бойтесь задаваться
подобными вопросами или признаваться в том, что вам нужна помощь.
Глава
34
1•
Философия лрагматизма
Старайтесь избавиться от слабых оправданий, прежде чем произносить их
вслух. Если вы все же считаете, что должны оправдаться, сделайте это сначала
перед своим котом. И если уж ваш Мурзик готов взять всю вину на себя, то ...
Другие ра3делы, СВR3анные с данной темой
•
Тема
49.
Прагматичные команды, глава
9
"Прагматичные проекты':
Задачи
•
Как вы отреагируете, если кто-нибудь (например, банковский служащий,
автомеханик или чиновник) придет к вам со слабым оправданием? Какое
у вас составится в итоге мнение о них и об их организации?
•
Если вы, так уж вышло, говорите: "Я не знаю", непременно прибавьте: "Но
я найду выход". Это отличный способ признать, что вы чего-то не знаете,
но все же берете на себя ответственность как профессионал.
ПРОГРАММНАЯ ЭНТРОПИЯ
llj}.f;fl
Несмотря на то что разработка программного обеспечения не подвержена
большинству физических законов, все мы сильно подвержены воздействию
неуклонного роста энтропии. Физический термин энтропия обозначает вели
чину беспорядка в системе. К сожалению, законы термодинамики утверждают,
что энтропия во вселенной стремится к максимуму. Если же беспорядок воз
растает в программном обеспечении, то такое явление называется деградацией
последнего. Некоторые могли бы назвать это явление более оптимистическим
термином "технический долг': подразумевающим, что когда-нибудь они погасят
этот долг,
-
хотя этого, скорее всего, не произойдет. Но как бы ни называлось
данное явление, техническим долгом или деградацией, оно может распростра
няться бесконтрольно.
Имеется немало факторов, способствующих деградации программного обес
печения, и самый важный из них, по-видимому, имеет отношение к психоло
гии или культуре в работе над проектом . Психология может оказаться весьма
тонким свойством вашего проекта, даже если вы работаете над ним самостоя
тельно. Какими бы совершенными ни были составленные планы или участники
проекта, он все равно может быть подвергнут деградации и разрушению в те
чение всего срока своего действия . Тем не менее существуют и такие проекты,
которые успешно противостоят естественной тенденции к беспорядку и ухит
ряются завершиться вполне удачно, несмотря на огромные трудности и посто
янные задержки и помехи.
Тема 3 • Проrраммная энтропия
35
В чем же тогда отличие? В старых кварталах городов одни здания красивы
и чисты, тогда как другие выглядят как трухлявые развалины. Исследователи в
сфере преступности и упадка городов открыли замечательный пусковой меха
низм, очень быстро превращающий чистое, нетронутое, нежилое здание в раз
рушенную и заброшенную трущобу8 • Это разбитое окно.
Оказывается, что если не отремонтировать хотя бы одно разбитое окно в
течение какого-нибудь значительного периода времени, у жильцов возникнет
ощущение заброшенности здания, а следовательно, отсутствия заботы городских
властей о его состоянии. И, как следствие, разбивается еще одно окно, а люди
начинают захламлять здание всяким мусором. На стенах такого здания появля
ются граффити и начинается серьезное разрушение его конструкции. В течение
относительно короткого периода времени здание разрушается настолько, что
у его владельца не возникает никакого желания отремонтировать его, и тогда
ощущение заброшенности становится вполне реальным.
Почему же возникает такое отличие? Как показывают исследования, прове
денные психологами 9 , безнадежность может оказаться заразной. Так, если рас
смотреть вирус гриппа в тесном помещении, то явное пренебрежение эпидеми
ческой ситуацией способно лишь утвердить в мысли, что ничего, вероятно, не
льзя исправить, никого это не волнует и все обречены на заболевание гриппом.
Подобным же образом негативные мысли могут распространяться среди членов
команды, образуя порочный круг.
IGФI§iJ
Нельзя жить с разбитыми окнами
Совет "Нельзя жить с разбитыми окнами': по существу, означает, что нельзя
мириться с неудачными проектными решениями или плохо написанными фраг
ментами кода, оставляя их неисправленными. Исправляйте их, как только обна
ружите. Если же времени на исправление недостаточно, закомментируйте неис
правный код, выведите сообщение "Не реализовано" или же подставьте вместо
него фиктивные данные подобно тому, как временно заколачивают разбитые
окна. Словом, предпримите какое-то действие, чтобы предотвратить дальней
ший ущерб и тем самым показать, что вы владеете ситуацией.
Нам приходилось видеть, как нормально функционирующие системы быс
тро приходят в негодность, как только начинают разбиваться окна. Имеются и
другие факторы, способствующие деградации программного обеспечения, и мы
еще коснемся их в дальнейшем, а до тех пор следует подчеркнуть, что пренебре
жение ускоряет деградацию быстрее, чем любой другой фактор.
8
См. The police and neighborhood safety [WH82].
9 См. Contagious depression: Existence, specificity to depressed symptoms,
seeking [Joi94].
and the role ofreassurance
Глава 1 • Философия прагматизма
36
Можно, конечно, возразить, что ни у кого нет времени на обследование про
екта и его полную очистку от разбитого стекла. В таком случае лучше заплани
ровать установку мусорного контейнера или переезд в соседнее здание. Но в
любом случае не позволяйте энтропии одержать верх.
ПРЕЖДЕ ВСЕГО -
НЕ НАВРЕДИТЬ
У Энди некогда был баснословно богатый знакомый. Его дом был в идеаль
ном порядке, обставленный дорогим антиквариатом, предметами искусства и т.д.
Однажды гобелен, висевший слишком близко к камину, загорелся. Пожарные
быстро прибыли на место, чтобы потушить пожар и спасти дом от разруши
тельного огня. Но прежде чем затащить свои длинные и грязные шланги в дом,
они остановились, чтобы раскатать мат между входной дверью и очагом пожара,
поскольку им не хотелось испортить ковер
-
в самый разгар пожара.
Возможно, это и весьма крайний пример. Ведь первая обязанность пожар
ных
-
погасить огонь, пренебрегая сопутствующим ущербом. Но они трезво
оценили ситуацию, будучи уверенными в своей способности справиться с ог
нем, и действовали аккуратно, чтобы не нанести имуществу лишний ущерб.
Именно таким образом следует обращаться и с программным обеспечением, не
нанося ему сопутствующий ущерб лишь потому, что оно находится в каком-то
критическом состоянии. Ведь и одно разбитое окно
-
это уж слишком.
Одного разбитого окна (т.е. плохо написанного фрагмента кода, неудачного
управленческого решения, с которым команде приходится мириться в течение
всего проекта) достаточно, чтобы все начало приходить в упадок. Если окажет
ся, что вы работаете над проектом с большим количеством разбитых окон, вам
очень легко может прийти в голову следующая мысль: "Вся остальная часть это
го кода написана скверно, и я поступлю точно так же': И совсем не важно, что
до этого момента проект находился в отличном состоянии. В первоначальном
эксперименте, на основании которого была выдвинута теория "разбитого окна",
заброшенный автомобиль стоял нетронутым целую неделю. Но однажды в нем
было разбито одно окно, после чего автомобиль был обчищен и перевернут
вверх дном в считанные часы.
Подобным же образом, присоединившись к проекту, где код безупречен (т.е.
написан ясно, изящно и грамотно), вам следует действовать крайне осторожно,
чтобы не навредить, как пожарные в упомянутом выше примере. Даже если по
жар в самом разгаре (поджимают сроки, приближается дата выпуска, выставоч
ная демонстрация и т.д.), вы не должны стать первым, кто испортит все дело или
нанесет дополнительный ущерб. Просто скажите себе: "Никаких разбитых окон':
Другие раэдель1, связанные с данной темой
•
•
•
Тема
10.
Тема 40.
Тема 44.
Ортогональность, глава
Рефакторинг, глава
Именование, глава
2
"Прагматичный подход".
7 "По ходу кодирования':
7 "По ходу кодирования':
Тема 4 • Суп из камней и вареные лягушки
37
Задачи
•
Помогите укреплению команды, обследовав окрестности проекта. Выбери
те два или три "разбитых окна" и обсудите со своими коллегами возник
шие трудности и возможные пути их разрешения.
•
Можете ли вы предсказать, когда разобьется первое окно? Какова будет
ваша реакция? Если это стало следствием чужого решения или приказа
начальства, то что вы можете с этим поделать?
l1;M@i
СУП ИЗ КАМНЕЙ И ВАРЕНЫЕ ЛЯГУШКИ
Три солдата, возвращавшихся с войны домой, проголодались. Когда они
увидели перед собой село, то воспряли духом, поскольку были уверены,
что селяне накормят их. Но когда они добрались до села, то обнаружи
ли двери домов запертыми на замок, а окна закрытыми. После многих
лет войны селянам не хватало еды, а ту, что у них была, они припря
тывали.
Невзирая на постигшую их неудачу, солдаты вскипятили котелок воды,
аккуратно положив в него три камня. Пораженные селяне вышли пос
мотреть на происходящее.
"Э то
.", -
суп из камнеи
положили?"
-
пояснили сол д аты.
-
"И
это все, что вы в него
спросили селяне. "Абсолютно все, хотя говорят, что он
будет лучше на вкус, если положить в него немного моркови ..." Один из
селян удалился, тотчас вернувшись с корзиной моркови из своих при
прятанных запасов.
Пару минут спустя селяне снова спросили: "Это все?". "Пожалуй,
ветили солдаты,
-
-
от
пару картофелин придадут ему больше густоты''.
И тогда удалился другой селянин.
В течение последующего часа солдаты перечислили другие ингредиенты,
которые могли бы сделать суп еще вкуснее: говядину, лук-порей, соль,
зелень и специи. И всякий раз какой-нибудь другой селянин удалялся,
чтобы принести что-нибудь из своих личных запасов.
В итоге солдаты сварили большой котел горячего, дымящегося супа.
Они извлекли из него камни и сели вокруг котла вместе со всем селом,
чтобы впервые за многие месяцы насладиться сытным обедом, которо
го ни одному из них уже давно не доводилось отведывать.
Из этой истории о супе из камней следуют два поучительных вывода. Солда
ты хитро воспользовались любопытством селян, чтобы заполучить у них еду. Но
еще важнее, что солдаты действовали подобно катализатору, объединив селян
38
Глава
1•
Философия прагматизма
вместе и тем самым показав им, что совместно они могут сотворить нечто та
кое, чеrо не удалось бы сделать каждому из них в отдельности. И это называется
синерrическим эффектом, коrда в конечном счете выиrрывают все.
Время от времени и вам, может быть, придется подражать этим солдатам.
Ведь вы можете оказаться в такой ситуации, коrда точно знаете, что и как нуж
но делать. Перед вашим мысленным взором вся система, и вы знаете, что с ней
все в порядке. Но стоит вам попросить разрешение взяться за доводку всеrо в
целом, вы встретите препятствия и недоуменные взrляды. Люди сформируют
комитеты, бюджеты потребуют утверждения, и все только усложнится. Каждый
будет защищать свои ресурсы, что иноrда называется "изначальной апатией".
И тоrда наступает время выставить камни. Тщательно обдумайте, что имен
но вы можете обоснованно попросить. Разработайте и покажите это в rотовом
виде друrим, чтобы изумить их. И тоrда они скажут: "Конечно, было бы лучше,
если бы мы это добавили ..." Притворитесь, что это неважно. Не вмешивайтесь
до тех пор, пока они не начнут просить вас внедрить функциональное средство,
которое вам первоначально требовалось. Ведь людям леrче присоединиться к
уже достиrнутому успеху. Приоткройте им перспективы на будущее, и они спло
тятся вокруr вас 10 •
Будьте катализатором перемен
Со СТОРОНЫ СЕЛЯН
С друrой стороны, история о супе из камней повествует о едва заметном и
постепенно употребляемом лукавстве, а также о чрезмерной сосредоточенности
на чем-то одном. Ведь думая о камнях, селяне забывают обо всем остальном. Все
мы попадаем в подобную западню едва ли не каждый день, когда что-нибудь
незаметно подкрадывается к нам.
Нам не раз приходилось наблюдать подобные симптомы, коrда проекты мед
ленно, но верно выходили из подчинения. Большинство бедствий в програм
мном обеспечении начинается с едва заметных мелочей, и большинство проек
тов постепенно выходят за установленные пределы. Системы отклоняются от
своих спецификаций одно функциональное средство за друrим, тогда как одна
"заплата" за другой вставляется во фраrмент кода до тех пор, пока в нем не
останется ничего первоначальноrо. Зачастую именно накапливающиеся посте
пенно мелочи портят нравы и разрушают команды .
10
Делая это, вам, возможно, будет удобнее придерживаться линии поведения, припи
сываемой контр-адмиралу д-ру Грейс Хоппер
(Grace Hopper),
попросить прощения, чем получить разрешение:'
которая говорила: "Легче
Тема 4 • Суп из камней и вареные лягушки
11з+Ф''
39
Не забывайте об общей картине
Честно говоря, мы никогда не пробовали этого сами, но знатоки говорят, что
если взять лягушку и опустить ее в кипящую воду, она тотчас выпрыгнет из
нее наружу. Но если погрузить лягушку в кастрюлю с холодной водой, а затем
постепенно нагреть ее, то лягушка не заметит постепенного повышения темпе
ратуры и сварится в кастрюле.
Следует, однако, иметь в виду, что случай с лягушкой отличается от случая
с разбитыми окнами, обсуждавшегося ранее в разделе "Тема
3.
Программная
энтропия''. Согласно теории разбитых окон люди теряют всякую охоту бороться
с энтропией, поскольку воспринимают ее как безразличие всех остальных. А ля
гушка просто не замечает никаких изменений.
Не уподобляйтесь пресловутой лягушке. Внимательно следите за общей кар
тиной происходящего. Постоянно присматривайте за тем, что происходит вок
руг вас, а не только за тем, что вы делаете сами.
Другие раэдепы, свяэанные с данной темой
•
Тема
1.
•
Тема
38.
Это ваша жизнь.
Программирование по совпадению, глава
7
"По ходу кодирова-
"
ния.
Задачи
•
Рецензируя рукопись первого издания этой книги, Джон Лакос поднял сле
дующий вопрос: солдаты сознательно в~одят все больше в заблуждение
селян, хотя перемены, которые они ускоряют, идут всем только на пользу.
Но если сознательно вводить все больше в заблуждение лягушку, то можно
нанести ей вред. Можете ли вы определить, готовите ли вы суп из камней
или лягушек, когда пытаетесь ускорить перемены? Является ли такое ре
шение субъективным или объективным?
•
Быстро ответьте, не rлядя на потолок, сколько осветительных приборов
висит над вами? Сколько выходов из помещения, где вы находитесь, и
сколько в нем присутствует людей? Есть ли там что-нибудь чуждое или
выглядящее неуместным? Это упражнение в осведомленности об окружа
ющей обстановке
-
метод, практикуемый в разных кругах: от бойскаутов
до летчиков. Выработайте сначала в себе привычку смотреть и замечать
все, что происходит вокруг вас, а затем перенесите ее на свой проект.
40
Глава 1 • Философия прагматизма
ДОСТАТОЧНО ХОРОШЕЕ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
"Для лучшего добро сгубить легко".
У. Шекспир, Король Лир, действие
Есть старый анекдот об американской компании, заказавшей
1,
сцена
100 тысяч
4
мик
росхем у японского производителя. В спецификации на микросхемы было, в
частности, указано, что брак должен составлять
1 штуку
на 1О тысяч хороших
микросхем. Заказ был доставлен через несколько недель и состоял из одной
крупной коробки, содержавшей тысячи микросхем, и другой, мелкой, в которой
было всего лишь десять микросхем. К этой коробке была приклеена этикетка, на
которой было написано "Бракованные микросхемы':
Хорошо, если бы и у нас контроль качества был на таком же уровне. Но ре
альность не позволяет нам производить ничего совершенно идеального, и осо
бенно бездефектного программного обеспечения. Ведь время, технология и тем
перамент словно сговорились против этого.
Но это и не повод для разочарования. Как описал Эд Юрдон в своей статье
When good-enoиgh software is best (Когда достаточно хорошее программное обес
печение оказывается наилучшим) в журнале IEEE Software, [You95], можно при
учить себя писать достаточно хорошие программы, которые достаточно хороши
для пользователей, будущих сопровождающих их программистов и для спокойс
твия вашего духа. В этом случае вы работаете более продуктивно, а пользовате
ли ваших программ удовлетворены в большей степени. А кроме того, вы можете
обнаружить, что ваши программы только выигрывают от сокращения их инку
бационного периода.
Прежде чем продолжить, необходимо пояснить, о чем, собственно, здесь
идет речь. Слово "подходящий" совсем не подразумевает небрежно или плохо
написанный код. Все системы должны удовлетворять требованиям пользова
телей, чтобы считаться удачно спроектированными, а также соответствовать
основным нормам производительности, конфиденциальности и безопасности.
Мы просто ратуем за то, чтобы дать пользователям возможность участвовать в
процессе принятия решения о том, когда произведенный программный продукт
следует считать достаточно хорошим для удовлетворения их потребностей.
Тема 5 • Достаточно xopowee программное обеспечение
41
ИДИТЕ НА КОМПРОМИССЫ С ПОЛЬЗОВАТЕЛЯМИ
Как правило, вы пишете программы для других людей. И даже иногда не за
бываете выяснить, что же им, собственно, требуется 1 . Но спрашиваете ли вы
их вообще, насколько хорошее программное обеспечение они хотят получить?
Иногда у них просто нет никакого выбора. Если вы разрабатываете кардиости
мулятор, автопилот или низкоуровневую библиотеку, предполагающую широ
кое распространение, требования будут более строгими, а возможности вашего
выбора
-
ограниченными.
Но если вы работаете над совершенно новым программным продуктом, то на
вашу разработку накладываются самые разные ограничения. Так, специалистам
по сбыту требуется сдержать свои обещания, конечные пользователи могут со
ставлять планы, исходя из сроков поставки, а ваша компания, как всегда, испы
тывает дефицит денежных средств. Поэтому было бы непрофессионально пре
небрегать требованиями всех этих пользователей, просто дополнив программу
новыми функциональными возможностями или "отполировав" исходный код
еще раз. Мы ни в коем случае не сеем панику. Ведь в равной степени непрофес
сионально обещать невозможные временные рамки выполнения работ и нару
шать элементарные правила проектирования, чтобы уложиться в крайний срок.
Область действия и качество производимой вами системы должны обсуждаться
как часть требований к ней.
GФt§i=I
Включайте в требования к системе вопрос о ее качестве
Нередки случаи, когда приходится идти на разные компромиссы. Как ни
странно, но многие пользователи готовы применять не до конца доведенное
программное обеспечение сейчас, чем ждать еще целый год, пока оно не будет
доведено до состояния готовой к выпуску полноценной версии. Хотя на самом
деле то, что может понадобиться через год, все равно окажется совершенно
другим. И с этим согласятся отделения информационных технологий (ИТ) мно
гих компаний со скромными бюджетами. Хорошее программное обеспечение
сегодня зачастую оказывается более предпочтительным, чем совершенное про
граммное обеспечение завтра. Если вы предоставляете что-нибудь пользовате
лям для экспериментирования как можно раньше, их отзывы могут привести к
более совершенному окончательному решению (см. раздел "Тема
ющие пули" главы
1 Это,
2 "Прагматичный
конечно, шутка!
подход").
12.
Трассиру
Гnава 1 • Фиnософия прагматизма
42
ЗНАЙТЕ МЕРУ
В какой-то степени программирование подобно живописи. Вы начинаете с
чистого холста и некоторых основных исходных материалов. Используя соче
тание науки, искусства и ремесла, вы решаете, что с ними делать. Сначала вы
набрасываете общую форму, затем раскрашиваете исходное окружение и, нако
нец, заполняете детали. При этом вы постоянно отходите назад и критическим
взглядом оцениваете то, что уже сделано. А время от времени вы отбрасываете
холст и начинаете все с самого начала. Но художники скажут вам, что все тяжкие
труды пойдут прахом, если не вовремя остановиться. Так, если накладывать один
слой краски на другой, деталь на деталь, то в краске потеряется сама живопись.
Старайтесь не испортить грамотно написанную программу чрезмерными
украшательствами и усовершенствованиями. Просто имейте в виду, что она
никогда не будет совершенной. (Подробнее об основных принципах написания
кода и несовершенстве этого мира речь пойдет в разделе "Пока вы программи
руете" главы
7.)
Другие разделы, связанные с данной темой
•
Тема
45.
Западня требований, rлава
•
Тема
46.
Решение неразрешимых головоломок, глава
8
"До начала проекта".
8
"До начала проекта':
Задачи
•
Просмотрите инструментальные средства и операционные системы, кото
рыми регулярно пользуетесь. Сможете ли вы найти в них признаки того,
что их производители и/или разработчики спокойно выпускают програм
мное обеспечение, заранее зная, что оно несовершенно? Как его пользова
тель вы, скорее всего:
1) подождете до тех пор, пока не будут исправлены все программные
ошибки;
2)
примите как должное некоторые программные ошибки, учитывая слож
ность программного обеспечения;
3)
или же выберете более простое программное обеспечение, но с мень
шими дефектами?
•
Рассмотрите влияние модульности на выпуск программного обеспечения.
Потребуется ли больше или меньше времени, чтобы получить тесно свя
занный монолитный программный блок требуемого качества по сравне
нию с системой, состоящей из очень слабо связанных модулей или мик
рослужб? Каковы преимущества и недостатки каждого из этих методов
проектирования?
Тема 6 • Baw баrаж знаний
•
43
Можете ли вы сказать о распространенном программном обеспечении,
что оно страдает от раздутости функциональных средств, т.е. содержит
намного больше функциональных средств, чем вам вообще может потре
боваться? Ведь каждое функциональное средство может стать источником
программных ошибок и брешей в защите. И чем больше таких средств, тем
труднее их находить, когда потребуется ими воспользоваться. Чувствуете
ли вы себя в опасности попасть в такую западню?
11м;а ВАШ БАГАЖ ЗНАНИЙ
"Инвестиции в знания приносят наибольшие дивиденды".
Бенджамин Франклин
Ох, уж этот старина Бенджамин Франклин
-
никогда не упустит случай про
изнести нравоучительную проповедь! Ну как же? Ведь если бы мы рано ложи
лись спать и рано вставали, то разве не стали бы отличными программистами?
Ранней пташке
-
ранний корм ... и что же тогда станет с ранним червячком? Но
в данном случае Бенджамин попал не в бровь, а в глаз. Ведь ваши знания и опыт
являются ныне самыми важными профессиональными ресурсами.
К сожалению, эти ресурсы исчерпываются2 • Ваши знания устаревают по
мере разработки новых методик, языков и сред. Изменение в расстановке сил
на рынке способно сделать ваш опыт устаревшим или неуместным. Принимая
во внимание постоянно растущие темпы перемен в технологическом обществе,
это может произойти довольно быстро.
По мере убывания ваших знаний убывает и ваша ценность для вашей компа
нии или клиента. И нам хотелось бы воспрепятствовать такой тенденции, вооб
ще искоренив ее. Ваши способности учиться чему-то новому как раз и состав
ляют самый важный стратегический ресурс. Но как приобрести способность
учиться чему-то новому и как знать, чему именно следует учиться?
ВАШ БАГАЖ ЗНАНИЙ
Мы предпочитаем рассматривать все, что программисты знают о вычисле
ниях, прикладных областях, в которых они работают, а также весь их опыт как
багаж знаний, которыми они обладают. Управление багажом знаний очень похо
же на управление финансовым портфелем по описываемым ниже руководящим
принципам.
2 Исчерпывающийся ресурс -
это нечто такое, чья ценность убывает со временем. К харак
терным его примерам относится склад, заполненный бананами, а также билет на футбол.
Глава 1 • Философия прагматизма
44
1.
Серьезные инвесторы по привычке регулярно вкладывают во что-нибудь
свои денежные средства.
2.
Ключом к успеху в долrосрочной перспективе является диверсификация.
3.
Смышленые инвесторы составляют свои портфели, находя определенное
равновесие междуконсервативными и высокодоходными, хотя и слишком
рискованными инвестициями.
4.
Инвесторы пытаются приобретать ценные бумаги по малой цене, а про
давать их по высокой цене, чтобы получить наибольшую прибыль.
5.
Портфели должны периодически пересматриваться и заново уравновеши
ваться.
Чтобы быть успешным в своей профессии, необходимо инвестировать в
собственный багаж знаний, следуя таким же руководящим принципам, как и
описанные выше для финансового портфеля. Правда, управление такоrо рода
инвестициями
-
это такой же навык, как и любой другой, а следовательно, ему
можно научиться. Самое главное
-
сначала заставить себя, а затем развить в
себе привычку делать это. С этой целью выработайте соответствующую проце
дуру, чтобы следовать ей до тех пор, пока она не укоренится в вашем сознании.
И тогда вы обнаружите, что впитываете новые знания автоматически.
СОЗДАНИЕ СВОЕГО БАГАЖА ЗНАНИЙ
•
Инвестируйте регулярно. Подобно финансовому инвестированию, вы
должны не менее регулярно инвестировать в баrаж своих знаний, пусть
даже и в небольших объемах. И здесь привычка важна в такой же степени,
как и объемы инвестиций, поэтому зарезервируйте для этой цели время и
место, чтобы не отвлекаться ни на что другое. Несколько примерных целей
перечислены в следующем разделе.
•
Диверсифицируйте свои инвестиции. Чем более разнообразны ваши зна
ния, тем ценнее вы сами. Вы должны как минимум знать все особенности
той технолоrии, которой пользуетесь в настоящий момент. Но не останав
ливайтесь на этом. Перемены в вычислительной технике происходят очень
быстро, и если какая-нибудь технология весьма востребована сегодня, то
завтра она окажется практически бесполезной или, по крайней мере, не
востребованной. Чем больше технолоrий вы освоите, тем леrче вам будет
приспосабливаться к переменам. И не забывайте все остальные навыки,
которые могут вам потребоваться в любой момент, в том числе и навыки,
приобретенные в нетехнических областях знаний.
Тема 6 • Baw баrаж знаний
•
45
Управляйте риском. Технологии бывают самые разные: от рискованных,
но и потенциально высокорентабельных и до малорискованных, но и ма
лорентабельных. Не стоит вкладывать все свои средства ни в высокорис
кованные акции, которые могут внезапно обесцениться, ни тратить их
консервативно, упуская при этом неплохие возможности. Не кладите все
яйца в одну корзину, полагаясь на какую-то одну технологию.
•
Покупайте дешево, а продавайте дороrо. Освоить появившуюся техноло
гию еще до того, как она найдет широкое распространение, пожалуй, так
же трудно, как и найти акции, продающиеся по цене существенно ниже
рыночной. Но затраченные усилия могут вполне окупиться сторицей. Так,
изучать язык
Java
в то время, когда он только появился и был малоизвес
тен, было рискованно, но усилия тех, кто принял его сразу, окупились
впоследствии сторицей, когда он стал мейнстримом в данной отрасли.
•
Пересматривайте и заново балансируйте баrаж своих знаний. Информа
ционная отрасль развивается очень динамично. Новоиспеченная техноло
гия, в которую вы начали инвестировать в прошлом месяце, сегодня мо
жет оказаться окаменевшим ископаемым. Возможно, вам стоит освежить
знания технологий баз данных, которыми вы уже давно не пользовались, а
может быть, лучше подумать о новой работе и попытаться изучить другой
язык".
Самый первый из всех перечисленных выше руководящих принципов легче
всего выполнить, поэтому он еще раз упоминается ниже.
GФI§tl
Регулярно инвестируйте в свой багаж знаний
Цели
Теперь, когда известны некоторые руководящие принципы управления бага
жом знаний, необходимо выяснить самый лучший путь для приобретения ин
теллектуального капитала, который можно инвестировать в этот багаж знаний.
Ниже приведен ряд рекомендаций по этому поводу.
•
Каждый rод изучайте хотя бы один новый язык. Разные языки позволя
ют по-разному решать одни и те же задачи. Изучив самые разные подходы
к решению задачи, вы расширяете горизонты ее осмысления, избегая опас
ности застрять в тупике. Кроме того, изучение многих языков облегчается
благодаря большому разнообразию свободно доступного программного
обеспечения.
Глава 1 • Философия прагматизма
46
•
Читайте по одной книге из технической литературы каждый месяц. Не
смотря на обилие кратких статей и порой надежных ответов в Интернете,
для углубленного понимания предмета требуются книги с подробным его
изложением. Просмотрите среди предложений в книготорговой сети ин
тересную литературу, связанную с вашим текущим проектом 3 • Как только
чтение технической литературы войдет у вас в привычку, читайте ежеме
сячно по одной книге. Освоив технологии, которыми вы пользуетесь в на
стоящий момент, обратитесь к какой-нибудь другой технологии, не связан
ной с вашим текущим проектом.
•
Читайте и нетехническую литературу. Очень важно не забывать, что ком
пьютерами пользуются люди, потребности которых вы стараетесь удовлет
ворить. Вы работаете с людьми, вам дают работу другие люди, а некото
рые люди даже пытаются незаконно проникнуть в вашу вычислительную
систему. Поэтому не забывайте о человеческой стороне вашей профессии,
которая требует совершенно иных навыков для межличностного общения
(и хотя мы иронично называем их "легкими", на самом деле приобрести
их трудно).
•
Посещайте курсы повышения квалификации. Поищите интересные кур
сы в местном колледже, университете или в Интернете, а возможно, и на
очередной выставке или конференции.
•
Участвуйте в местных пользовательских группах или собраниях. Изо
ляция может оказаться убийственной для вашей карьеры, поэтому поз
накомьтесь с людьми, работающими за пределами вашей организации.
Старайтесь принимать активное участие во встречах по интересам, а не
только приходить и слушать.
•
Экспериментируйте с разными средами. Если раньше вы работали толь
ко с
Windows,
уделите время работе с
Linux.
Если вы пользовались только
сборочными файлами и текстовым редактором, опробуйте логически раз
витую интегрированную среду разработки с современными функциональ
ными средствами, и наоборот.
•
Оставайтесь в курсе дела. Читайте новости и публикации в Интернете о
технологиях, отличающихся от тех, которыми вы пользуетесь в своем теку
щем проекте. Это отличный способ выяснить, каким опытом их примене
ния обладают другие люди, ознакомиться с применяемой ими конкретной
терминологией и т.д.
3 Возможно,
мы субъективны, но отличную подборку литературы можно найти по адресу
https: / /pragprog. сот.
Тема 6 • Ваш баrаж знаний
47
Очень важно не прерывать инвестирование в багаж своих знаний. Как толь
ко вы освоите какой-нибудь новый язык или технологическое новшество, пере
ходите к следующему, чтобы изучить его.
Совершенно не важно, пользуетесь ли вы любой из освоенных вами тех
нологий в своем проекте или просто указываете их при составлении резюме.
В процессе обучения вы расширяете горизонты своего мышления, открываете
новые возможности и способы сделать что-нибудь конкретное. При обучении
большое значение имеет взаимное обогащение идеями. Старайтесь применить
усвоенные уроки в своем текущем проекте. И даже если конкретная технология
в вашем проекте не применима, то вы все равно можете позаимствовать из нее
какие-нибудь идеи. Так, если вы овладеете принципами объектно-ориентиро
ванного программирования, то сможете писать процедурные программы уже
иначе. А уяснив парадигму функционального программирования, сможете ина
че написать объектно-ориентированный код и т.д.
Возможности для ОБУЧЕНИЯ
Итак, вы взахлеб читаете книги, держитесь в курсе самых передовых разра
боток в вашей области, что совсем не так легко. Когда же кто-то обращается к
вам с вопросом и вы не имеете ни малейшего представления, что ему ответить,
то открыто признаетесь в этом. Но это не должно вас останавливать. Примите
это как личный вызов и найдите ответ. Поспрашивайте у других, поищите ответ
в Интернете, причем не только в бытовых, но и в академических кругах.
Если вы не можете найти ответ сами, найдите того, кто способен это сделать.
Не оставляйте заданный вам вопрос без ответа. Общение с другими людьми по
может вам создать свой личный круг знакомств, где в ходе расспросов вы можете
неожиданно для себя найти ответы и на другие, не связанные с данным вопросы.
И при этом багаж ваших прежних знаний станет пополнятся новыми ...
На все это чтение и изучение вам, конечно, требуется время, которого и так
не хватает, поэтому подобные занятия необходимо планировать заранее. У вас
всегда должно быть что-нибудь почитать в те моменты, когда вам нечего делать.
Так, временем ожидания приема у доктора, в очереди или в городском транспор
те можно выгодно воспользоваться для чтения, поэтому берите всегда с собой
электронную книгу. Хотя вы, может быть, предпочитаете по старой привычке
мусолить пальцами печатные издания вроде зачитанной до дыр газеты
1973 года
о положении в Папуа Новой Гвинее.
КРИТИЧЕСКОЕ МЫШЛЕНИЕ
Наконец, очень важно уметь критически осмысливать то, что вы читаете и
слышите. Вам следует позаботиться о том, чтобы знания в вашем багаже были
точными, непредубежденными и не поддающимися влиянию поставщиков или
Глава 1 • Философия прагматизма
48
шумихе, поднятой в средствах массовой информации. Берегитесь страстных
приверженцев, настаивающих на том, что только их догма дает правильный от
вет
-
это может быть и неприемлемо для вас, и вашего проекта.
Ни в коем случае не следует недооценивать силу коммерциализации. Если
что-то оказывается в первых строчках результатов поиска в Интернете, то это
совсем не означает, что оно самое лучшее. Ведь за то, чтобы занять ведущее
положение в результатах поиска, могли просто заплатить. И если какая-нибудь
книга выставлена на заметное место в книжной лавке, то это совсем не означает,
что она хорошая или даже популярная. Ведь издательство могло заплатить за то,
чтобы его книгу выставили на видном месте.
13.ц411.1
Критически анализируйте то, что вы читаете и слышите
Критическое мышление само по себе является отдельной дисциплиной, по
этому мы рекомендуем вам изучать ее и читать все, что только можно найти о
ней. Между тем, вы можете начать с нескольких перечисленных ниже вопросов
и обдумать их.
•
Пять вопросов "Почему?". Задать хотя бы пять вопросов "Почему?"
-
из
любленный прием консультантов. Задайте сначала один такой вопрос и
получите ответ. Затем копните глубже, задав еще один вопрос "Почему?".
Повторяйте эту процедуру словно нетерпеливый, но вежливый четырех -
летний ребенок. Подобным образом вам, возможно, удастся приблизиться
к коренной причине.
•
Кому это выгодно? Такой вопрос может показаться циничным, но следо
вание за деньгами
-
это очень полезный путь для анализа. Выгоды для
кого-нибудь другого лица или другой организации могут совпадать или не
совпадать с вашими личными выгодами.
•
Каков контекст? Все происходит в своем контексте, именно поэтому уни
версальные решения годятся не на все случаи жизни. Так, если вы читаете
статью или книгу, где пропагандируется "норма наилучшей практики': вам
уместно задаться следующими вопросами. Наилучшая практика для кого?
Каковы предпосылки и последствия в краткосрочной и долгосрочной пер
спективе?
•
Когда и где это будет действовать? При каких обстоятельствах? Не слиш
ком ли поздно или же слишком рано? Не останавливайтесь на мышлении
первого порядка: что произойдет дальше? Но перейдите далее к мышле
нию второго порядка: что произойдет после этого?
•
Почему зто вызывает трудности? Есть ли какая-то базовая модель и как
она действует?
Тема 7 • Общайтесь!
49
К сожалению, на этом простые вопросы исчерпываются. Но, пополняя багаж
своих знаний и применяя в какой-то степени критический анализ к целой лавине
читаемых вами технических статей, вы сможете уяснить и сложные вопросы.
Другие разделы, сеRэанные с данной темой
•
Тема
1.
•
Тема
22.
Это ваша жизнь.
Технические дневники, глава
3
"Основные инструментальные
средства".
Задачи
•
Начните на этой неделе изучение нового языка. Если вы привыкли про
граммировать на одном и том же старом языке, опробуйте
Clojure, Elixir,
Elm, F#, Go, Haskell, Python, R, ReasonML, Ruby, Rust, Scala, Swift, TypeScript
или любой другой язык, который может привлечь ваше внимание или
просто понравиться вам 4 .
•
Начните читать новую книгу (как только дочитаете эту!). Если вы зани
маетесь подробной реализацией и кодированием, прочитайте книгу по
проектированию и архитектуре программного обеспечения. А если вы
занимаетесь высокоуровневым или архитектурным проектированием, то
прочитайте книгу по технологиям кодирования.
•
Обсудите какую-нибудь технологию с людьми, не занятыми в вашем теку
щем проекте или работающими в других организациях. Познакомьтесь с
такими людьми в кафетерии вашей организации или на местном собрании
приверженцев данной технологии.
'·Mt*A
ОБЩАЙТЕСЬ!
''Я считаю, что лучше быть проигнорированной вовсе,
чем недооцененной".
Мэй
4
Уэст, 5
фильм "Красавица 90-х" (Belle of the Nineties), 1934 г.
Если вы никогда не слышали ни одном из этих языков, вспомните, что знание - ис
черпывающийся ресурс, и то же самое можно сказать о распространенной технологии.
Перечень новейших и экспериментальных языков сильно изменился после первого изда
ния данной книги, а возможно, он уже будет иным к тому времени, когда вы будете читать
эти строки. И это служит еще одним веским основанием для того, чтобы не переставать
учиться.
5
Мае West - актриса, драматург, сценарист и секс-символ первой половины ХХ века в
- Примеч. пер.
Америке
Глава
50
1•
Философия прагматизма
Вполне возможно, что мы в состоянии усвоить урок, преподанный мисс Уэст.
Ведь дело не только в том, что у вас есть, а в том, как вы это преподнесете. Имея
самые лучшие идеи, самый изящный код или самое прагматичное мышление,
вы в конечном счете окажетесь в полной изоляции, если на сумете общаться с
другими людьми . Хорошая идея без эффективного общения осиротеет.
Как разработчики, мы должны общаться на самых разных уровнях. Мы про
водим немало часов на совещаниях, слушая и говоря, общаемся с конечными
пользователями, пытаясь уяснить их потребности, пишем код, передающий
наши намерения вычислительной машине и документирующий наше мышле
ние для будущих поколений разработчиков, а также пишем предложения и па
мятные записки, требующие и обосновывающие ресурсы, составляем отчеты
о текущем состоянии дел и предлагаем новые подходы. Наконец, мы работаем
каждый день в своих командах, проповедуя собственные идеи, видоизменяя су
ществующие нормы практики и предлагая новые. Большую часть своего рабоче
го дня мы проводим в общении, а следовательно, нам нужно делать это умело .
Рассматривайте свой родной язык как очередной язык программирования .
Пишите на естественном языке так, как вы пишете код, учитывая принципы
DRY
и ЕТС, рассматриваемые в следующей главе, возможности автоматизации
и пр.
GфIJlll Родной язык - это просто еще один язык программирования
В последующих разделах перечислены дополнительные идеи по поводу обще
ния, которые, на наш взгляд, кажутся полезными.
ЗНАЙТЕ, с КЕМ вы ОБЩАЕТЕСЬ
Общение полноценно лишь в том случае, если вы передаете собеседнику то,
что подразумеваете, а для этого недостаточно просто говорить. Для этого не
обходимо знать потребности, интересы и способности тех, с кем вы общаетесь.
Всем нам не раз приходилось присутствовать на совещаниях, где некоторые
разработчики с остекленевшим взглядом слушали длинный монолог вице-пре
зидента по сбыту о преимуществах какой-нибудь мудреной технологии. Это не
общение, а просто говорильня, навевающая скуку.
Допустим, вам требуется внести изменения в свою систему дистанционного
текущего контроля, чтобы воспользоваться сторонним брокером сообщений для
распространения уведомлений о состоянии данной системы. С этой целью вы
можете представить данное обновление системы самыми разными способами в
зависимости от того, с кем именно вы общаетесь. Так, конечные пользователи
по достоинству оценят такое обновление, поскольку их системы теперь смогут
взаимодействовать с друтими службами, пользующимися предлагаемым браке-
Тема 7 ' Общайтесь!
51
ром сообщений. Отдел сбыта вашей организации сможет воспользоваться этим
фактом, чтобы увеличить объемы продаж, а руководители отделов разработки
и эксплуатации просто обрадуются, поскольку заботы по сопровождению этой
части системы лягут на чужие плечи. Наконец, разработчикам будет, возможно,
интересно приобрести опыт работы с новыми прикладными интерфейсами и
даже попробовать найти брокеру сообщений новые области применения. Сде
лав соответствующий краткий доклад для каждой из этих групп в отдельности,
вы сможете заинтересовать их всех своим проектом.
Как и во всех остальных формах общения, самое главное здесь
-
обратная
связь. Следует не просто ждать вопросов, а попросить их задавать. Обращайте
внимание на движения тел и выражения лиц тех, кто вас слушает. Одна из ис
ходных предпосылок в нейролингвистическом программировании гласит: зна
чение вашего общения состоит в реакции, которую вы получаете. Постоянно
совершенствуйте свои знания тех, с кем общаетесь.
ЗНАЙТЕ, ЧТО ВАМ ТРЕБУЕТСЯ СКАЗАТЬ
Едва ли не самой трудной частью более формальных стилей общения, приме
няемых в деловой сфере, является умение подобрать именно те слова, которые
требуется сказать. Писатели нередко составляют планы своих книг, прежде чем
приступить к их написанию, а составители технической документации просто
садятся за клавиатуру, набирают, например, приведенный ниже заголовок, а за
тем все, что следует после него.
1.
Введение
Планируйте то, что хотите сказать. Сделайте сначала набросок своей речи, а
затем спросите себя: "Передает ли эта речь тем, кто меня слушает, то, что я хочу
выразить, именно так, как им было бы полезно?" Уточняйте свою речь до тех
пор, пока не достигнете желанной цели.
Такой подход пригоден не только для составления речей и документов. Когда
вы встречаетесь с главным заказчиком на важном совещании или дискуссии,
набросайте те идеи, которые хотите донести до него, и запланируйте пару стра
тегий ясного их изложения. Теперь, когда вы знаете, что именно вам требуется
сообщить слушателям, останется лишь правильно подать все это.
ВЫБИРАЙТЕ УДОБНЫЙ МОМЕНТ
Представьте, что сейчас конец рабочего дня в пятницу недели, когда про
ходила аудиторская проверка. Младший ребенок вашей начальницы попал
в больницу, на дворе льет дождь как из ведра, а дорога за город домой сулит
превратиться в сущий кошмар. Это, вероятно, не самый подходящий момент
попросить у начальницы разрешение увеличить оперативную память на вашем
компьютере.
Глава
52
1 • Философия прагматизма
Чтобы понять, что именно готовы услышать те, с кем вы общаетесь, необ
ходимо, в частности, выяснить их приоритеты. Поймайте своего руководителя
сразу после нелегкого разговора с высшим начальством по поводу утери неко
торой части исходного кода, и вы не найдете более восприимчивого слушателя к
вашим идеям относительно хранилищ исходного кода. Старайтесь высказывать
свои идеи в подходящий момент, облекая их в удобную для восприятия форму.
Иногда для этого достаточно спросить: "Удобно ли сейчас поговорить о ... ?"
ВЫБИРАЙТЕ СТИЛЬ ОБЩЕНИЯ
Подбирайте стиль донесения своих мыслей под тех, кому вы их адресуете.
Одним требуется формальное краткое сообщение "самих только фактов", а дру
гим
-
длинная, обширная дискуссия, прежде чем перейти к делу. Поэтому необ
ходимо знать уровень их квалификации и опыта в данной области, т.е. являются
ли они знатоками или новичками. Требуется ли им подробная сопроводитель
ная записка или же краткое изложение самой сути в сообщении по электронной
почте? Если сомневаетесь, спрашивайте.
Но не забывайте, что вы
-
лишь половина двухстороннего общения. Если
кто-нибудь скажет вам, что ему требуется лишь абзац с кратким описанием ва
шего предложения, а вы не видите способа изложить его короче, чем на несколь
ких страницах, скажите об этом откровенно. Не забывайте о том, что ответная
реакция, какой бы она ни была, также является формой общения.
ПОДАВАЙТЕ СВОИ ИДЕИ В ПРИВЛЕКАТЕЛЬНОЙ ФОРМЕ
Ваши идеи, безусловно, важны и поэтому заслуживают того, чтобы сообщить
их в привлекательной форме. Составляя письменные документы, слишком мно
гие разработчики (или их руководители) сосредоточивают основное внимание
только на их содержании. Мы считаем это ошибкой. Любой повар (или менед
жер сети ресторанов) скажет вам, что вы можете часами работать как каторж
ный на кухне лишь для того, чтобы кто-то испортил все ваши труды плохой
подачей блюда.
Ныне оформлению малопривлекательных документов нет оправдания
-
современное программное обеспечение способно на поразительные результаты
подготовки документов, будь они созданы с использованием языка разметки
или в текстовом редакторе. Для этого достаточно выучить всего лишь несколь
ко команд. Так, если вы пользуетесь текстовым редактором, подберите подходя
щие таблицы стилей и шаблоны. (Вполне возможно, что они уже определены в
вашей организации, а следовательно, вы можете воспользоваться уже готовыми
шаблонами.) Научитесь оформлять верхние и нижние колонтитулы страниц.
Чтобы получить представление о стилях оформления и компоновке докумен-
Тема 7 ~ Общайтесь!
53
тов, обратитесь к образцам, входящим в состав пакета текстового редактора.
Выполните проверку орфографии сначала автоматически, а затем вручную. Ведь
в тексте могут быть ошибки, которые не удастся уловить средству проверки
-
человеку свойственно ошиваться .: )
ПРИВЛЕКАЙТЕ ТЕХ, С КЕМ ОБЩАЕТЕСЬ
Нередко оказывается, что составляемые вами документы в конечном счете
оказываются менее важными, чем сам процесс их подготовки. Поэтому при
влекайте по возможности тех, кому эти документы адресованы, уже на ранних
стадиях их составления в черновом варианте. Получите их отзывы и восполь
зуйтесь их советами. Таким образом вы наладите хорошие рабочие отношения
и при этом сможете улучшить свой документ.
Учитесь слУшАть
Если хотите, чтобы вас услышали другие, научитесь слушать их. Даже в том
случае, если вы полностью информированы, и даже тогда, когда стоите на фор
мальном совещании перед двадцатью руководителями, они не услышат вас, если
вы не слышите их.
Пригласите людей к дискуссии, задавая вопросы, или же попросите их сфор
мулировать обсуждаемую тему своими словами. Превратите совещание в диа
лог, и тогда вы сможете донести свою точку зрения более четко и эффективно.
Кто знает, может быть, вы чему-то в итоге научитесь.
ОТВЕЧАЙТЕ людям
Если вы задаете кому-нибудь вопрос и человек вам не отвечает
-
вам ка
жется, что он невежлив. Но как часто вы сами не отвечали людям, когда они
присылали вам сообщение по электронной почте или памятную записку, прося
сообщить какую-нибудь информацию или предпринять некоторое действие?
В суматохе повседневной жизни очень легко об этом забыть. Поэтому старай
тесь всегда отвечать на сообщения по электронной почте, даже если это будет
простая фраза: "Я отвечу вам позже': Если держать людей в курсе, они будут го
товы простить вам случайные оплошности, чувствуя, что вы о них не забыли.
Qфl§lfj Важно не только то, что вы говорите, но и как вы это говорите
Вы должны непременно общаться, если только не работаете в полной изоля
ции. Чем эффективнее будет ваше общение, тем больше станет ваше влияние.
Гnава 1 • Фиnософия прагматизма
54
ДОКУМЕНТАЦИЯ
Наконец, осталось рассмотреть вопрос об общении через документацию. Как
правило, разработчики мало задумываются о документации. В лучшем случае
они считают ее досадной необходимостью, а в худшем
-
низкоприоритетной
задачей, надеясь, что начальство забудет о ней под конец проекта.
Программисты-прагматики воспринимают документацию как неотъемлемую
часть общего процесса разработки. Составление документации можно упрос
тить, не дублируя усилия, не тратя зря время и держа документацию под рукой
и, в частности, непосредственно в исходном коде. На самом деле к документа
ции можно применить все те же прагматические принципы, что и к исходному
коду.
Создавая документацию, не фиксируйте ее навечно
Качественную документацию можно получить из комментариев в исходном
коде, и поэтому модули и экспортируемые функции рекомендуется снабжать
комментариями, чтобы облегчить участь других разработчиков, когда им при
дется пользоваться этими программными компонентами. Но это совсем не оз
начает, что мы согласны с теми, кто говорит, что каждую функцию, структуру
данных, объявление типа данных и т.д. следует непременно снабдить коммента
риями. Такой механичный подход к составлению комментариев на самом деле
усложняет сопровождение кода, поскольку при внесении изменений обновлять
приходится не только исходный код, но и документацию. В связи с этим ре
комендуется ограничить комментирование исходного кода, не относящегося к
прикладному интерфейсу
API,
указанием причин, назначения и целей написа
ния кода. Ведь сам исходный код уже ясно показывает, как он написан, а сле
довательно, комментировать
"не повторяться"
его излишне, поскольку это нарушает принцип
(DRY).
Комментирование исходного кода дает идеальную возможность задокумен
тировать те трудноуловимые особенности проекта, которые нельзя задокумен
тировать где-нибудь еще: инженерные компромиссы, причины принятия конк
ретных решений и отвержения альтернативных решений и т.д.
КРАТКИЕ итоги
•
Знайте, что вам требуется сказать.
•
Знайте, с кем вы общаетесь.
•
Выбирайте удобный момент.
Тема 7 • Общайтесь!
•
Выбирайте стиль общения.
•
Подавайте свои идеи в привлекательной форме.
•
Привлекайте тех, с кем общаетесь.
•
Учитесь слушать.
•
Отвечайте людям.
•
Храните исходный код и документацию вместе.
55
Другие раэдель1, связанные с данной темой
•
Тема
15.
•
Тема
18.
Оценивание, rлава
2 "Прагматичный
подход".
Эффективное редактирование, глава
3
"Основные инструмен
тальные средства".
•
Тема
45.
Западня требований, глава
•
Тема
49.
Прагматичные команды, глава
8
"До начала проекта".
9
"Прагматичные проекты".
Задачи
•
Имеется несколько хороших книг, в которых описывается общение в ко
мандах разработчиков, в том числе следующие:
-· The Mythical Man-Month: Essays
оп
Software Engineering [Bro96].
- Peopleware: Productive Projects and Teams [DL13].
•
Постарайтесь прочитать эти книги в ближайшие
18 месяцев. Кроме того,
обратите внимание на книrу Dinosaur Brains: Dealing with All Those ImpossiЬle
People at Work [BR89], в которой обсуждается эмоциональный багаж, с ко
торым все мы приходим в новую рабочую среду.
•
Когда будете в следующий раз делать презентацию или писать памятную
записку, чтобы донести свою точку зрения, постарайтесь проработать со
веты из этого раздела, прежде чем приступить к делу. Ясно определите
круг тех лиц, с которыми вам предстоит общаться. Пообщайтесь с ними,
если это возможно, впоследствии, чтобы выяснить, насколько точно вы
оценили их потребности.
Глава 1 • Философия прагматизма
56
ОБЩЕНИЕ В ОПЕРАТИВНОМ РЕЖИМЕ
Все, что упоминалось выше об общении в письменной форме, в равной степени
применимо и к общению по электронной почте, в социальных сетях, блогах и т.д.
В частности, возможности электронной почты развились до такой степени,
что она стала оплотом корпоративной связи, применяется для обсуждения
контрактов, организации диспутов и даже служит в качестве свидетельств
в суде. Но по какой-то причине люди, никогда не посылавшие ни жалкого
листка документации по обычной почте, с удовольствием рассылают элект
ронной почтой скверного вида неуместные сообщения по всему миру.
Наши рекомендации по общению в оперативном режиме довольно просты
и перечислены ниже.
•
Тщательно выверяйте написанное, прежде чем щелкнуть на кнопке
ОТПРАВИТЬ.
• Выполняйте орфографическую проверку, чтобы обнаружить оплошности
автоматической корректуры.
• Придерживайтесь простого и понятного формата.
•
Старайтесь как можно меньше цитировать исходное сообщение при от
вете. Никому не нравится получать обратно свое сообщение по электрон
ной почте с присоединенным к нему единственным словом "Согласен'~
•
Если цитируете чужое сообщение в электронной почте, укажите его ав
тора и процитируйте его в теле своего сообщения, а не в виде вложения.
Это же относится и к общению в социальных сетях.
•
Избегайте перепалок или троллинга, если не хотите преследований, ко
торые непременно последуют за таким поведением. Если не решаетесь
высказать кому-нибудь в лицо все, что о нем думаете,
-
не делайте этого
и в сети.
•
Проверяйте список получателей ваших сообщений, прежде чем отравлять
их. Уже стало едва ли не нормой критиковать начальство по электронной
почте, не замечая, что оно присутствует в качестве получателя сообщения
в списке рассылки. А еще лучше
-
отказаться от критики начальства по
электронной почте.
Как считает бесчисленное множество организаций и политиков, электрон
ная почта и социальные сети
-
это уже навсегда. Поэтому постарайтесь
уделить электронной почте столько же внимания, сколько и любой другой
памятной записке или отчету.
Глдвд
2
Имеются определенные рекомендации и приемы, применяемые на всех уров
нях разработки программного обеспечения, совершенно универсальные процес
сы и почти аксиоматические идеи. Но такие подходы редко документируются,
а вместо этого они зачастую обнаруживаются в виде отрывочных записей дис
куссий о проектировании, управлении проектом или программировании. Но
ради вашего удобства мы постараемся здесь собрать все эти идеи и процессы
вместе.
Первая и, может быть, самая важная тема касается самой сути разработки
программного обеспечения и раскрывается в разделе "Сущность качественного
проектирования". Из нее следует все остальное. Далее следуют разделы
"DRY -
пороки дублирования" и "Ортогональность", в которых раскрываются две тесно
связанные темы. В первом из них содержится предупреждение не дублировать
знания по системам, а во втором
-
не разделять никакие фрагменты знаний по
многим компонентам системы.
По мере увеличения темпов изменений становится все труднее и труднее со
хранять приложения в должном состояния. Поэтому в разделе "Обратимость"
мы рассмотрим некоторые методики, помогающие ограждать проекты от их из
меняющейся среды.
Два последующих раздела также взаимосвязаны. Так, в разделе "Трассиру
ющие пули" речь пойдет о стиле разработки, позволяющем одновременно со
бирать требования, проверять проектные решения и реализовывать код. И это
единственный способ идти в ногу с современной жизнью. А в разделе "Прото
типы и памятные записки" будет показано, каким образом прототипирование
применяется для проверки архитектур, алгоритмов, интерфейсов и идей. В сов
ременном мире крайне важно проверять идеи и получать ответную реакцию,
прежде чем безоговорочно принимать их.
По мере созревания вычислительной техники разработчики во все большем
количестве создают языки высокого уровня. И хотя еще не изобретен компиля
тор, способный принимать команду "сделай это вот так': в разделе "Предметно
ориентированные языки" представлены более скромные рекомендации, которые
вы можете реализовать самостоятельно.
58
Гnава 2 • Прагматичный подход
Наконец, все мы работаем в условиях ограниченного времени и ресурсов .
Нехватку таких ресурсов можно перенести легче (и принести большее удовлет
ворение начальству или клиентам), если постараться выяснить, как долго они
будут затребованы. Именно об этом и пойдет речь в разделе "Оценивание':
Упомянутые выше принципы следует непременно иметь в виду во время раз
работки, чтобы писать более совершенный, быстродействующий и устойчивый
код. Вы можете даже сделать его более удобочитаемым.
СУЩНОСТЬ КАЧЕСТВЕННОГО ПРОЕКТИРОВАНИЯ
В мире полно умников и знатоков проектирования программного обеспече
ния, жаждущих передать свою мудрость, приобретенную тяжкими трудами. Для
этого существуют особые сокращения, списки (почему-то обычно из пяти пунк
тов), шаблоны, диаграммы, видеоматериалы, беседы, а возможно, и увлекатель
ные сериалы (Интернет есть Интернет), поясняющие закон Деметры с помощью
интерпретирующего танца .
И мы, авторы этой книги, грешим этим. Но нам хотелось бы внести поправ
ки в пояснение того, что лишь стало для нас очевидным. Прежде всего сделаем
заявление общего характера.
СЭ.Ц§l@I Удачное проектное решение легче изменить, чем неудачное
Вещь считается удачно спроектированной, если она приспосабливается к
тем, кто ею пользуется. Для кода это означает, что он должен приспосабливать
ся к изменениям . Поэтому мы верим в принцип легкости изменения
Change -
(Easier to
ЕТС). Вот и все.
Насколько мы можем судить, всякий принцип проектирования является
частным случаем принципа ЕТС. Чем, например, хорошо уменьшение степени
связывания? Оно хорошо тем, что разделяет обязанности, чтобы их легче было
изменить. А это и есть принцип ЕТС. В чем польза принципа единственной
ответственности? Она состоит в том, что изменения в требованиях зеркально
отображаются в изменениях лишь в одном модуле. И это соответствует принци пу ЕТС. Почему так важно именование? А потому, что удачные имена делают
исходный код более удобочитаемым, а ведь его приходится читать, чтобы вне
сти в него изменения. И в этом случае соблюдается принцип ЕТС!
ПРИНЦИП ЕТС
Ценности
-
-
это ЦЕННОСТЬ, А НЕ ПРАВИЛО
это сущности, помогающие принять решение сделать то или
другое . Что касается осмысления программного обеспечения, то ЕТС является
Тема 8 • Сущность качественного проектирования
59
руководящим принципом, помогающим выбрать правильный путь. Как и все
остальные ценности, этот принцип должен плавно следовать за здравой мыс
лью, мягко подталкивая в правильном направлении.
Но как этого добиться? Как показывает наш опыт, для этого требуется пер
воначальное сознательное подкрепление. Вам, возможно, придется потратить
около недели, сознательно задавая себе вопрос: "Облегчило или же затруднило
изменение всей системы в целом то, что я только что сделал?" Делайте это, когда
сохраняете файл, пишете тест или исправляете ошибку в программе.
В принципе ЕТС присутствует неявное предположение. Он предполагает, что
человек способен выбрать из многих путей именно тот, который будет легче
сменить впоследствии. Зачастую здравый смысл позволяет выбрать правиль
ный путь и дает возможность сделать обоснованное предположение. Но иногда
на это нет и намека. Что ж, бывает и так. Мы считаем, что в подобных случаях
можно сделать две вещи.
Во-первых, если вы не знаете, какую конечную форму примут вносимые вами
изменения, то всегда можете вернуться к пути "легкости изменений": попытать
ся сделать заменяемым фрагмент кода, который вы пишете. В таком случае, что
бы ни произошло впоследствии, этот фрагмент кода не станет неодолимой пре
градой на вашем пути. Такая мера кажется крайней, но на самом деле вы долж
ны так или иначе прибегать к ней постоянно. Это всего лишь забота о сохране
нии кода не связанным и согласованным.
Во-вторых, рассматривайте это как способ развития инстинктов. Запишите
данную ситуацию в своем журнале технического учета, упомянув выбранные
вами варианты и некоторые предположения об изменениях. Оставьте метку в
исходном коде. В дальнейшем, когда этот фрагмент кода придется изменить, вы
сможете оглянуться назад и предоставить отчет самому себе. Это может помочь,
когда вы в очередной раз окажетесь на аналогичной развилке.
В остальных разделах этой главы рассматриваются конкретные идеи по по
воду проектирования. Но все они вызваны описанным здесь одним и тем же
принципом легкости изменения.
Другие разделы, связанные с данной темой
•
Тема
•
•
•
•
•
Тема
9. DRY -
пороки дублирования.
10. Ортогональность.
Тема 11. Обратимость.
Тема 14. Предметно-ориентированные языки.
Тема 28. Развязывание, глава 5 "Гибкость или ломкость".
Тема 30. Преобразовательное программирование, глава 5
"Гибкость или
ломкость':
•
Тема
31.
Налог на наследование, глава
5 "Гибкость
или ломкость".
Глава 2 • Прагматичный подход
60
Задачи
•
Обдумайте принцип проектирования, которым пользуетесь регулярно. На
правлен ли он на то, чтобы сделать что-то легко изменяемым?
•
Подумайте также о языках и парадигмах программирования: объектно
ориентированного, функционального и т.п. Какие главные положительные,
отрицательные или те и другие стороны они имеют для написания кода в
соответствии с принципом ЕТС?
•
Что вы можете сделать при программировании для того, чтобы исключить
отрицательные и выделить положительные стороны 1 ?
•
Во многих текстовых редакторах имеется (встроенная или через расшире
ния) поддержка команд, выполняемых при сохранении файла. Настраи
вайте текстовый редактор на вывод сообщения "ЕТС?" всякий раз2 , когда
сохраняете изменения в файле. Пользуйтесь такой возможностью в качес
тве напоминания о необходимости обдумать написанный вами код. На
сколько легко его изменить?
DRY -
ПОРОКИ ДУБЛИРОВАНИЯ
Капитан Джеймс Тиберий Кирк 3 предпочитал снабжать компьютер двумя
противоречащими друг другу фрагментами знаний, чтобы нейтрализовать враж
дебный искусственный интеллект. К сожалению, тот же самый принцип может
очень легко погубить ваш код.
Программисты обычно собирают, организуют, хранят и используют знания.
Они документируют знания в спецификациях, возрождают их в выполняемом
коде и пользуются ими для проверок во время тестирования. К сожалению, зна
ния непостоянны. Они изменяются, и зачастую очень быстро. Так, ваше пред
ставление о каком-нибудь требовании может измениться после совещания с
клиентом. Стоит правительству изменить какой-нибудь нормативный акт, и со
ответствующая бизнес-логика устаревает. Тесты могут показать, что выбранный
алгоритм неработоспособен. Все это непостоянство означает, что нам приходит
ся большую часть времени работать в режиме сопровождения, реорганизации и
преобразования знаний в своих системах.
1
Перефразируя старую песню Ассепtиаtе The Positive (Делайте акцент на положительном)
(Johnny Mercer) - американского исполнителя, популярного в 1940-х
Джонни Мерсера
годах.
2
Или хотя бы каждый десятый раз, чтобы оставаться в здравом уме".
3
Персонаж научно-фантастического телевизионного сериала Звёзднь1й путь: Оригиналь
(Star Trek: The Original Series). - Примеч. пер.
ный сериал
Тема 9 • DRY - пороки дублирования
61
Многие полагают, что сопровождение приложения начинается после его выпуска
и означает устранение программных ошибок и совершенствование функциональ
ных средств. Мы считаем, что они не правы. Программисты постоянно работают
в режиме сопровождения, поскольку их представления изменяются день за днем ,
когда поступают новые требования, а уже имеющиеся требования развиваются
по мере сосредоточения усилий на проекте. Может измениться и сама среда. Но,
независимо от конкретной причины, сопровождение является не каким -то отде
льным видом деятельности, а обыкновенной стадией всего процесса разработки.
Когда выполняется сопровождение, приходится искать и изменять представ
ления вещей, т. е. те крупицы знаний, которые вложены в приложение. Но дело в
том, что знания очень легко продублировать в спецификациях, процессах и раз
рабатываемых программах. И делая это, разработчики навлекают сущий кошмар
сопровождения, который начинается еще до выпуска приложения . Мы считаем,
что единственный способ надежно разрабатывать программное обеспечение
и упростить понимание и сопровождение разработок
"не повторяться"
-
следовать принципу
(DRY):
У каждого фрагмента знаний должно быть единственное, недвусмыс
ленное, непререкаемое представление в системе.
А почему этот принцип называется
DRY?
А вот почему:
L!J!!l!!!•!!]:!!t§!l!!f"1!!~-D~RY~_:D"o"n"'t"R.:.epeat Yourself, т.е. "не повторяйся"
Альтернатива состоит в присутствии чего-то одного в двух или более местах.
Если в таком случае изменить что-то одно, то нужно не забыть изменить и все
остальное, а иначе программа будет загнана противоречием в угол, как компью
теры пришельцев . И вопрос не в том, чтобы вспомнить об изменениях, а в том,
когда они забудутся.
Принцип
DRY
будет еще не раз упоминаться на страницах этой книги, и за
частую в таком контексте, который не имеет ничего общего с программирова
нием. Мы считаем, что это одно из самых важных инструментальных средств
в арсенале программиста-прагматика . И в этом разделе мы вкратце изложим
трудности, возникающие в связи с дублированием, а также предложим общие
стратегии их преодоления .
ПРИНЦИП
DRY
НЕ только для КОДИРОВАНИЯ
Прежде всего устраним некоторое недоразумение. В первом издании этой
книги мы поступили неверно, объяснив лишь, что мы подразумевали под выра
жением "не повторяться': И многие посчитали, что принцип
DRY
имеет отноше
ние только к коду, думая, что он означает "не выполнять копирование и вставку
Глава 2 • Прагматичный подход
62
строк исходного кода". Но это лишь часть принципа
мая простая. Принцип
DRY
DRY,
причем мелкая и са
имеет отношение к дублированию знаний, а также
намерений, т.е. к выражению одного и того же в двух разных местах, кроме того,
возможно, разными способами.
В качестве пробного камня попробуйте ответить на следующие вопросы: если
должно быть изменено какое-нибудь свойство кода, то не придется ли вносить
изменения во многих местах и в самых разных форматах? Не придется ли из
менять исходный код и документацию, схему базы данных и хранящуюся в ней
структуру и т.д.? Если это именно так, то такой код не соответствует принципу
DRY.
Рассмотрим некоторые типичные примеры дублирования.
ДУБЛИРОВАНИЕ В ИСХОДНОМ КОДЕ
Каким бы банальным это ни показалось, но дублирование кода
-
довольно
частое явление. Ниже приведен характерный тому пример.
def print_balance(account)
printf "Debits: %10.2f\n", account.debits
printf "Credits: %10.2f\n", account.credits
if account.fees О
f += 20 * a.returned check count
end
if a.overdraft_days > 3
f += lO*a.overdraft_days
end
if a.average_balance > 2 ООО
f /= 2
end
f
end
Назначение приведенной выше функции указано дважды: один раз
ментариях к ней, второй раз
-
-
в ком
в ее исходном коде. Если заказчик изменит по
рядок начисления комиссионных, обновить придется как исходный код, так и
комментарии. И можно гарантировать, что со временем комментарии окажутся
несогласованными с исходным кодом.
Непременно задайтесь вопросом: какие комментарии вводятся в исходный
код? На наш взгляд, комментарии лишь возмещают неудачное именование и
компоновку. Так, в приведенном ниже фрагменте кода имена ясно указывают
назначение элементов кода. И если кому-нибудь понадобятся подробности, то
он обнаружит их в исходном тексте. Именно так и соблюдается принцип
DRY!
def calculate_account_fees(account)
fees = 20*account.returned check count
fees += lO*account.overdraft_days if account.overdraft days > 3
if account.average_balance > 2 ООО
fees /= 2
fees
end
Нарушение принципа DRY в данных
Структуры данных представляют знания, и они тоже могут противоречить
принципу
DRY.
Рассмотрим в качестве примера следующий класс, пре-дставля
ющий прямую линию:
class Line {
Point start;
Point end;
douЫe length;
);
На первый взгляд, такое определение класса может показаться вполне обос
нованным. В нем явно определены поля для начальной и конечной точек пря-
Гnава 2 • Праrматичный подход
66
мой линии, а также ее длины, даже если она нулевая. Но в нем все равно при -
сутствует дублирование. Ведь длина прямой линии определяется ее начальной и
конечной точками. Достаточно изменить одну из них, чтобы изменилась длина
прямой линии. Поэтому поле длины лучше сделать вычисляемым, как показано
ниже.
class Line {
Point start;
Point end;
douЬle length() { return start.distanceTo(end); }
};
На последующей стадии процесса разработки, возможно, придется пойти на
нарушение принципа
DRY
из соображений производительности. Зачастую это
происходит в том случае, когда требуется кешировать данные, чтобы исключить
повторение затратных операций. И здесь самое главное
-
локализовать отри
цательное влияние, чтобы оно не распространялось наружу. Отличия должны
быть заметны лишь в методах класса, как показано ниже.
class Line {
private douЬle length;
private Point start;
private Point end;
Line(Point start, Point end) {
this.start = start;
this.end = end;
calculateLength();
puЬlic
11 Открытые методы
void setStart(Point р)
void setEnd(Point р)
this.start
this.end =
Point getStart()
Point getEnd ()
douЬle getLength()
return start;
return end; }
return length;
=
calculateLength();
calculateLength(); }
р;
р;
private void calculateLength() {
this.length = start.distanceTo(end);
};
В данном примере также наглядно демонстрируется следующее важное по
ложение: всякий раз, когда модуль раскрывает структуру данных, весь исполь
зующий ее код привязывается к реализации этого модуля. Поэтому для чтения
и записи содержимого свойств или полей объекта следует всегда пользоваться
функциями доступа там, где это возможно. Благодаря этому впоследствии упро
щается внедрение дополнительных функциональных возможностей.
Тема 9 • DRY - пороки дублирования
67
Такое употребление функций доступа тесно связано с принципом единообра
зия доступа, описанным Мейером в книге Object-Orieпted
Software
Coпstrиctioп
[Меу97] и гласящим следующее:
Все службьt, предоставляемые модулем, должны быть доступны с помо
щью единообразной системы обозначений, которая не зависит от того,
как они реализуются: через хранение в памяти или вычисление.
ПРЕДСТАВИТЕЛЬНОЕ ДУБЛИРОВАНИЕ
Написанный вами код взаимодействует с внешним миром: с другими библи
отеками
через интерфейсы прикладного программирования
-
службами
-
(API),
с другими
через удаленные вызовы, с данными из внешних источников и т.д.
И всякий раз, когда вы организуете такое взаимодействие, так или иначе нару
шаете принцип
DRY.
Ведь в вашем коде требуются знания, которые присутству
ют во внешнем объекте, в том числе
API,
схема базы данных, коды ошибок и
пр. Дублирование в данном случае состоит в том, что обеим сторонам взаимо
действия (вашему коду и внешнему объекту) необходимо знать представление
их интерфейсов. Достаточно изменить его у одной стороны, и на другой стороне
все будет нарушено. И хотя такое дублирование неизбежно, его все же можно
умерить. Ниже описывается ряд стратегий, позволяющих добиться этого.
Дублирование через внутренние АР/
Что касается внутренних
API,
то следует найти такие инструментальные
средства, которые позволяют указать интерфейс прикладного программирова
ния в некоторого рода нейтральном формате. Как правило, такие инструмен
тальные средства автоматически генерируют документацию, функциональные
тексты, имитирующие
API
и их клиентов, причем последних
-
на самых разных
языках. В идеальном случае такое инструментальное средство способно сохра
нять внутренние
API
в центральном хранилище, делая их общедоступными для
команд разработчиков.
Дублирование через внешние АР/
Все чаще можно обнаружить, что открытые
API
формально документирова
ны с использованием таких средств, как, например, OpenAPI 4 • Это дает возмож
ность импортировать спецификации
API
в локальные инструментальные сред
ства и более надежно интегрировать их с соответствующими службами.
Если вам не удастся найти подходящую спецификацию, рассмотрите возмож
ность создать и опубликовать ее самостоятельно. Это не только принесет пользу
другим, но и поможет ее сопровождению.
4 См. по адресу https: //github. com/OAI/OpenAPI-Specification.
68
Гnава 2 • Праrматичный nодход
Дублирование череэ источники данных
Многие источники данных позволяют выполнять самоанализ своих схем
данных. Этим обстоятельством можно воспользоваться, чтобы по большей час
ти исключить дублирование между источниками данных и прикладным кодом.
Вместо того чтобы писать вручную код для работы с данными из подобных ис
точников, можно сформировать контейнеры непосредственно из схемы данных.
Многие каркасы могут сделать эту рутинную работу вместо вас.
Имеется и другая, на наш взгляд, более предпочтительная возможность.
Вместо того чтобы писать код, представляющий внешние данные в фиксирован
ной структуре (например, экземпляре структуры или классе), достаточно ввести
их в структуру данных в виде пар "ключ-значение': которая может называться
отображением, хешем, словарем или даже объектом, в зависимости от конкрет
ного языка программирования.
Само по себе это рискованно, поскольку необходимо знать, какие именно
данные следует обрабатывать, а от этого существенно снижается уровень бе
зопасности. Поэтому рекомендуется вводить в такое решение второй уровень
в виде простого табличного набора тестов для проверки достоверности, чтобы
выяснить, содержит ли созданное отображение требующиеся данные в нужном
формате. Вполне возможно, что имеющемуся у вас инструментальному средству
документирования прикладных интерфейсов
API
удастся сформировать такой
набор тестов.
ДУБЛИРОВАНИЕ СРЕДИ РАЗРАБОТЧИКОВ
Едва ли не самый трудный для обнаружения и устранения вид дублирова
ния происходит между разными разработчиками в проекте. Неумышленно мо
гут быть сдублированы целые наборы функциональных возможностей, годами
оставаясь необнаруженными и существенно затрудняя сопровождение. Нам
приходилось слышать, как государственные вычислительные системы США об
следовались на соблюдение требований в связи с наступлением
показала проверка, более
10
2000
года. Как
тысяч программ содержали разные версии кода
проверки номера социального обеспечения.
На самом общем уровне с дублированием можно справиться, организовав
сильную команду, сплоченную хорошо налаженным общением. А вот на уров
не модуля данная проблема проявляется не так явно. Ведь зачастую требуются
функциональные возможности или данные, которые не входят в очевидные гра
ницы ответственности, и поэтому они могут быть многократно реализованы.
Для борьбы с дублированием на этом уровне, на наш взгляд, лучше всего поощ
рять активное и частое общение разработчиков друг с другом.
Возможно, стоит проводить ежедневные "летучки" по методике
Scrum
или
организовать форумы (например, через каналы корпоративного обмена сообще-
Тема 1О • Ортоrонаnьность
ниями типа
Slack).
69
Подобным образом обеспечивается ненавязчивое общение
(даже во многих местах) с постоянным хранением архивов всего сказанного.
Одного из членов команды можно назначить в качестве библиотекаря проек
та, вменив ему в обязанность содействовать обмену знаниями. Выделите цент
ральное место в дереве исходного кода, где можно было бы размещать служеб
ные программы и сценарии, и возьмите себе за правило читать исходный код
и документацию других разработчиков как неформально, так и во время про
смотров исходного кода. Ведь так вы сами учитесь у них, а не подглядываете за
ними. И не забывайте, что доступ к исходному коду должен быть взаимным
-
не смущайте тех, кто внимательно изучает ваш исходный код, а возможно, и
копается в нем.
CJфI§IA
Упрощайте повторное использование исходного кода
Старайтесь взрастить такую среду, где было бы проще находить и повторно
использовать существующий исходный код, чем писать его самому. Если это
нелегко сделать, люди вообще не будут так поступать. Если же вы не умеете
повторно пользоваться исходным кодом, то рискуете дублировать знания.
Другие раэдепь1, свяэанные с данной темой
•
Тема
8.
•
Тема
28.
Развязывание, глава
•
Тема
32.
Конфигурирование, глава
•
Тема
38.
Программирование по совпадению, глава
•
Тема
40.
Рефакторинг, глава
Сущность качественного проектирования.
5
7
"Гибкость или ломкость':
5 "Гибкость
или ломкость".
7 "По ходу кодирования':
"По ходу кодирования".
liДfj(e) ОРТОГОНАЛЬНОСТЬ
Понятие ортогональности имеет решающее значение для создания таких
систем, которые легко проектировать, строить, тестировать и расширять. Но
это понятие редко изучают непосредственно. Зачастую оно считается неявным
свойством совсем других изучаемых приемов и методов, а это ошибка. Научив
шись применять принцип ортогональности непосредственно, вы сразу же заме
тите, насколько повысится качество создаваемой вами системы.
Что ТАКОЕ ОРТОГОНАЛЬНОСТЬ
Термин ортогональность заимствован из геометрии, где две линии называ
ются ортогональными, если они пересекаются под прямым углом (например,
70
Глава 2 • Праrматичный подход
оси на графике). А в терминологии векторов две подобные линии считаются
независимыми. Так, линия № 1 на приведенной ниже диаграмме направлена на
север, и она никоим образом не изменяет положение на восток или запад. А ли
ния №2 направлена на восток, а не на север или юг.
Восток-----
В вычислительной технике термин ортогональность стал означать незави
симость, или развязывание. Два или более компонента считаются ортогональ
ными (не связанными), если изменения в одном из них не оказывают никакого
влияния на остальные компоненты системы. В грамотно спроектированной сис
теме исходный код базы данных будет ортогональным по отношению к пользо
вательскому интерфейсу. Это означает, что пользовательский интерфейс можно
изменить, не оказывая никакого влияния на базу данных, а последнюю
-
заме
нить, не меняя первый. Но прежде чем обсуждать преимущества ортогональных
систем, рассмотрим систему, которая не является ортогональной.
НеортоzональнаR система
Представьте, что вы совершаете вертолетную экскурсию по Большому Каньо
ну, шт. Колорадо, и вдруг пилот, съевший, очевидно, по ошибке рыбу на обед,
застонал и потерял сознание. К счастью или несчастью, но он оставил вертолет
без управления зависшим на высоте около
30
м над землей.
По счастливой случайности вам довелось прочитать прошлым вечером стра
ницу Википедии о вертолетах, и поэтому вам известно, что у вертолета имеются
четыре основных рычага управления. В частности, вы берете ручку продольно
поперечного управления циклическим шагом несущего винта в правую руку и
перемещаете ее так, чтобы вертолет двигался в нужном направлении. А в левую
руку берете рычаг управления общим шагом несущего винта и тянете его на
себя, чтобы увеличить шаг на всех лопастях и, таким образом, набрать высоту.
На конце рычага управления общим шагом находится рукоятка управления га
зом. Наконец, двумя педалями вы можете изменить силу тяги хвостового винта,
чтобы повернуть вертолет.
"Легко!
-
подумаете вы.
-
Плавно опусти ручку продольно-поперечного уп
равления циклическим шагом несущего винта и аккуратно приземлишься, ге
рой': Но, попытавшись это сделать, вы обнаружите, что не все так просто. Верто
лет нырнет носом вниз и начнет передвигаться по спирали влево. И неожиданно
Тема 1О • Ортогональность
71
для вас выяснится, что каждое управляющее воздействие на систему, в которой
вы летите, имеет побочные эффекты. Стоит опустить рычаг в левой руке, и вам
придется добавить уравновешивающее обратное движение ручкой в правой руке
и нажатием правой педали. Но и тогда каждое из этих изменений снова окажет
влияние на все остальные органы управления. Таким образом, вы вдруг обнару
жите, что пытаетесь манипулировать невероятно сложной системой, где каждое
изменение оказывает влияние на все остальные входные воздействия. В итоге на
вас падает необычайная нагрузка, поскольку ваши руки и ноги постоянно дви
гаются, пытаясь уравновесить все взаимодействующие силы. И это означает, что
органы управления вертолетом решительно неортогональны.
ПРЕИМУЩЕСТВА ОРТОГОНАЛЬНОСТИ
Как демонстрирует приведенный выше пример вертолета, неортогональным
системам присущи большая сложность при внесении изменений и управлении.
Если компоненты какой-нибудь системы в высшей степени взаимозависимы, то
говорить о локальном исправлении ошибок не приходится вовсе.
'i+Ы'Р
Исключайте взаимное влияние несвязанных
компонентов системы
Компоненты системы следует разрабатывать таким образом, чтобы они были
самостоятельными, независимыми и имели единственное, вполне определенное
назначение, т.е. то, что Юрдон
(Yourdon) и Константин (Constantine) называют
в своей книге Structured Design: Fundamentals of а Discipline of Computer Program
and Systems Design [УС79] сцеплением (cohesion). Если компоненты обособлены
один от другого, то один из них можно свободно изменить, не опасаясь затро
нуть все остальные. При этом вы можете быть уверены, что не внесете никаких
осложнений, способных распространиться по всей системе, если только не из
меняете внешние интерфейсы компонента. Проектируя ортогональные системы,
вы получаете два основных преимущества: повышение производительности и
снижение рисков.
повь1шение проиэводительносmи
Это преимущество означает следующее.
•
Изменения локализуются, поэтому время разработки и тестирования со
кращается. Относительно небольшие, самостоятельные компоненты на
писать проще, чем один крупный блок кода. Простые компоненты мож
но спроектировать, запрограммировать, протестировать, а затем забыть
о них, поскольку не нужно постоянно изменять уже существующий код,
когда вводится новый.
Глава 2 • Прагматичный подход
72
•
Ортогональный метод проектирования способствует повторному исполь
зованию. Так, если на компоненты возлагаются конкретные, вполне оп
ределенные обязанности, их можно объединять с новыми компонентами
даже так, как того не предвидели те, кто их первоначально реализовывал.
Чем более слабо связаны системы, тем легче они поддаются перекомпонов
ке и перепроектированию.
•
Объединение ортогональных компонентов дает едва заметный выигрыш в
производительности. Допустим, один компонент выполняет М отдельных
операций, а другой компонент
- N
операций. Если оба эти компонента
ортогональны и объединяются, то в итоге получается система, выполняю
щая
MxN операций.
Но если оба компонента не ортогональны, то проис
ходит наложение, а в итоге выполняется меньше операций. Таким образом,
объединяя ортогональные компоненты, можно получить больше функцио
нальных возможностей на единицу объема выполненных работ.
Сокращение риска
При ортогональном подходе сокращаются риски, присущие любой разработ
ке и состоящие в следующем.
•
Неисправные разделы кода изолируются. Если какой-нибудь модуль пов
режден, вероятность, что признаки его ущербности распространятся на
остальную систему, становится меньше при ортогональном подходе. Кро
ме того, такой модуль проще вычленить и заменить каким-нибудь новым
и вполне работоспособным модулем.
•
Конечная система менее уязвима. А мелкие изменения и исправления в
конкретной области или любые вносимые вами осложнения ограничива
ются данной областью.
•
Ортогональная система лучше поддается тестированию, поскольку ее про
ще спроектировать и провести тесты ее компонентов.
•
Вас ничто не будет тесно связывать с конкретным поставщиком, програм
мным продуктом или платформой, поскольку интерфейсы с этими сторон ними компонентами ограничиваются небольшими частями общей разра
ботки.
А теперь рассмотрим некоторые способы применения принципа ортогональ
ности на практике.
ПРОЕКТИРОВАНИЕ
Большинству разработчиков хорошо известна потребность в проектиро
вании ортогональных систем, хотя для описания данного процесса они могут
пользоваться такими терминами, как модулыюе, компонентное и многоуровневое
Тема 1О • Ортогональность
73
проектирование. Системы должны состоять из ряда взаимодействующих моду
лей, каждый из которых реализует независимые друг от друга функциональ
ные возможности. Иногда такие компоненты организуются в отдельные уров
ни, каждый из которых обеспечивает определенный уровень абстракции. Такой
многоуровневый подход оказывается весьма эффективным для проектирования
ортогональных систем. А поскольку на каждом уровне используются только те
абстракции, которые обеспечиваются нижележащими уровнями, то появляется
возможность очень гибко изменять базовые реализации, не оказывая никакого
влияния на исходный код. Многоуровневое представление позволяет также сни
зить риск появления бесконтрольных зависимостей между модулями. Зачастую
многоуровневое представление системы выражается в виде диаграмм, аналогич
ных приведенной ниже.
Пользовательский интерфейс
Доступ к базе
данных
Авторизация
Бизнес-логика
Каркас приложений
Стандартные библиотеки
Контейнерные службы
Проверить проектирование системы на ортогональность совсем не трудно.
Как только вы наметите компоненты системы, задайте себе следующий воп
рос: если я внесу коренные изменения в требования к конкретной функции, на
какое количество модулей это повлияет? В ортогональной системе ответ на этот
вопрос должен быть "один" 5 • Так, перемещение экранной кнопки в графичес
ком пользовательском интерфейсе не должно требовать изменений в схеме базы
данных, а добавление контекстно-зависимой справки
-
изменений в подсистеме
выписки счетов.
Рассмотрим в качестве примера сложную систему управления и текущего кон
троля нагревательной установки . В первоначальном требовании было указано
обязательное наличие пользовательского интерфейса, но затем это требование
было дополнено интерфейсом для мобильных устройств, позволяющим инже
нерам постоянно контролировать основные параметры процесса нагрева. Чтобы
5
На практике не все оказывается так просто. Лишь при очень счастливом стечении обстоя
тельств большинство изменений в реальных требованиях не окажет влияние на многие функ
ции в системе. Но если анализировать изменения по функциям, то каждое функциональное
изменение в идеальном случае должно все же оказывать влияние лишь на один модуль.
74
Глава 2 , Прагматичный подход
удовлетворить этим требованиям, в ортогонально спроектированной системе
придется внести изменения лишь в модули, которые непосредственно связаны
с пользовательским интерфейсом, тогда как базовая логика управления нагрева
тельной установки останется без изменения. В самом деле, если структура такой
системы тщательно спроектирована, то обеспечить поддержку обоих интерфей
сов удастся с помощью одной и той же кодовой базы.
Спросите себя: насколько структура вашей системы отделена от изменений
в реальном мире? Так, если вы используете номер телефона в качестве иденти
фикатора клиента, то что произойдет, если телефонная компания переназначит
телефонные коды городов, областей и регионов? Почтовые индексы, номера со
циального обеспечения или паспортов, адреса электронной почты и домены Ин тернета
-
все это внешние идентификаторы, которые вам не подвластны и могут
измениться в любой момент по какой угодно причине. Поэтому ни в коем случае
не полагайтесь на свойства объектов, неподвластные вашему контролю.
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА И БИБЛИОТЕКИ
Старайтесь сохранять ортогональность своей системы, внедряя сторонние
инструментальные средства и библиотеки. Благоразумно выбирайте подходя
щие технологии.
Внедряя набор инструментальных средств (или даже библиотеку от других
членов команды), спросите себя: какие нежелательные изменения в исходном
коде это может повлечь? Так, если схема сохраняемости объектов оказывается
прозрачной, то она спроектирована ортогонально. Если же требуется создавать
объекты (или получать к ним доступ) каким-то особым образом, то схема их
сохраняемости неортогональна. Отделение таких подробностей реализации от
вашего кода дает дополнительное преимущество, упрощающее поставщикам
внедряемых средств внесение изменений в будущем.
Система
EJB (Enterprise Java Beans -
корпоративные компоненты
Java Beans)
служит интересным примером ортогональности. В большинстве ориентирован
ных на транзакции систем на прикладной код возлагается обязанность обоз
начить начало и конец каждой транзакции. В системе
EJB
такая информация
выражается декларативно в виде аннотаций и за пределами методов, выпал -
няющих всю необходимую работу. Один и тот же прикладной код может быть
выполнен без всяких изменений в разных средах транзакций
EJB.
EJB служит наглядным примером применения
"Декоратор" (Decorator), по которому функциональные
В известном смысле система
проектного шаблона
возможности вводятся в компоненты системы без их изменения. Такой стиль
программирования может быть реализован практически в любом языке про
граммирования и совсем не обязательно требует наличия каркаса или библи
отеки. Он требует лишь соблюдать определенную дисциплину в процессе про
граммирования.
Тема 1О • Ортогональность
75
КОДИРОВАНИЕ
Всякий раз, когда вы пишете код, вы рискуете убавить ортогональность свое
го приложения. И если не контролировать постоянно не только свои действия,
но и более крупный контекст приложения, то можно неумышленно сдублиро
вать функциональные возможности в каком-нибудь другом модуле или выра
зить существующие знания дважды.
Ниже вкратце описываются некоторые методики, с помощью которых можно
поддерживать ортогональность.
•
Поддерживайте свой код развязанным. Пишите код экономно, создавая
модули, не раскрывающие ничего лишнего другим модулям и не опираю
щиеся на их реализации. Старайтесь соблюдать закон Деметры, поясняе
мый в разделе "Тема
28.
Развязывание" главы
5.
Если требуется изменить
состояние объекта, добейтесь того, чтобы он делал это автоматически. По
добным образом ваш код останется обособленным от реализации другого
кода и тем самым повысятся шансы сохранить ортогональность того, что
вы проектируете.
•
Избегайте глобальных данных. Всякий раз, когда в вашем коде выполняет
ся обращение к глобальным данным, он привязывается к другим компо
нентам, совместно использующим эти же данные. Даже глобальные пере
менные, предназначенные только для чтения, могут привести к осложне
ниям (например, в том случае, если срочно потребуется сделать ваш код
многопоточным). В общем, если вы явно передаете любой требующийся
контекст своим модулям, ваш код будет легче понять и сопровождать.
В объектно-ориентированных приложениях контекст обычно передается в
виде параметров конструкторам объектов. А в другом коде можно создать
структуры, содержащие контекст, и передавать ссылки на них.
•
Проектный шаблон Синглтон
Patterns:
Eleтents
(Singleton), описанный в книге Design
of RеиsаЫе Object-Oriented Software [GHJV95], - это
средство, гарантирующее существование лишь одного экземпляра объекта
конкретного класса. Многие разработчики пользуются полученными та
ким образом одиночными объектами в качестве глобальных переменных
(особенно в таких языках, как
Java,
где глобальные переменные иным об
разом не поддерживаются). Пользуйтесь, однако, синглтонами аккуратно,
поскольку они также могут привести к ненужному связыванию.
• Избегайте сходных функций. Зачастую встречается ряд функций, очень по
хожих, например, тем, что они совместно используют общий код в начале
и в конце, хотя имеют разные алгоритмы в центре. Такое дублирование
кода служит явным признаком структурных недостатков. Более хорошую
реализацию может предоставить проектный шаблон "Стратегия"
[GHJV95].
(Strategy),
76
Глава 2 • Прагматичный подход
Приобретите привычку постоянно осматривать свой код критическим взгля
дом. Ищите возможности улучшить его структуру и ортогональность. Такой
процесс называется рефакторингом и настолько важен, что мы посвятили ему
отдельный раздел "Тема
40.
Рефакторинг" в главе
7.
ТЕСТИРОВАНИЕ
Ортогонально спроектированную и реализованную систему легче тестиро
вать. Взаимодействия компонентов такой системы формализованы и ограни
чены, и поэтому на уровне отдельных модулей можно произвести большую
часть тестирования системы. И это хорошо, поскольку определить и выполнить
модульное (или блочное) тестирование намного проще, чем комплексное. При
этом предполагается, что подобные тесты должны проводиться автоматически
как часть обычного процесса сборки (см. раздел "Тема
кодировать" главы
41.
Тестировать, чтобы
7).
Написание модульных тестов само по себе является интересной проверкой
ортогональности. Что же требуется для составления и выполнения модульного
теста? Приходится ли для этого импортировать львиную долю остального кода
системы? Если да, то можно считать, что обнаружен модуль, который недоста
точно отвязан от остальной системы.
Но устранение программных ошибок также является удобным моментом
для оценивания ортогональности всей системы в целом. Когда вы обнаружите
ошибку, оцените, насколько локализовано ее исправление. Изменяется ли при
этом лишь один модуль, или же изменения распространяются по всей системе?
Если вы вносите изменение, исправляет ли оно все ошибки или же загадочным
образом возникают другие ошибки? Это удобная возможность задействовать
автоматизацию. Если вы пользуетесь системой контроля версий исходного кода
(а вы ею все равно станете пользоваться, как только прочитаете раздел "Тема
Контроль версий" главы
3),
19.
отмечайте исправления ошибок, когда будете снова
проверять код после тестирования. И тогда вы сможете составлять и просмат
ривать ежемесячные отчеты, анализируя тенденции в целом ряде исходных фай
лов, на которые повлияло исправление каждой ошибки.
ДОКУМЕНТАЦИЯ
Как ни странно, принцип ортогональности распространяется и на докумен тацию. В данном случае ортогональность проявляется в плоскости координат
содержания и представления. Если документация истинно ортогональная, ее
внешний вид удается изменить коренным образом, совершенно не меняя со
держание. Для этой цели в текстовых редакторах предоставляются таблицы
стилей и макрокоманды. Мы лично предпочитаем пользоваться такой системой
Тема 1О • Ортогональность
разметки, как
Markdown.
77
При составлении документации мы уделяем основное
внимание только содержанию, оставляя представление тому инструментально
му средству, которое воспроизводит документацию 6 .
КАК УЖИВАТЬСЯ С ОРТОГОНАЛЬНОСТЬЮ
Ортогональность тесно связана с принципом
деле "Тема
9. DRY -
DRY,
описанным ранее в раз
пороки дублирования". Соблюдая принцип
DRY,
вы ищете
возможность свести к минимуму дублирование в системе, а соблюдая принцип
ортогональности
-
сократить взаимозависимость компонентов системы. Не
смотря на то что само слово "ортогональность" как-то не укладывается в обыч
ные представления программиста, придерживаясь принципа, который это слово
обозначает, наряду с принципом
DRY,
вы непременно обнаружите, что разраба
тываете более гибкую, понятную и простую для отладки, тестирования и сопро
вождения системы.
Если вас привлекли к работе над проектом, где остальные его участники от
чаянно борются за то, чтобы внести изменения, и где каждое изменение может
привести к тому, что дело не заладится и в четырех других местах, вспомните
об описанном ранее кошмаре с управлением вертолетом. Вероятнее всего, такой
проект спланирован и запрограммирован неортогонально.
И, если вы пилотируете вертолет, не ешьте рыбу...
Другие раэдель1, связанные с данной темой
•
Тема
3.
Программная энтропия, глава
•
Тема
8.
Сущность качественного проектирования.
•
Тема 11. Обратимость.
•
Тема
28.
Развязывание, глава
•
Тема
31.
Налог на наследование, глава
•
Тема
33.
Разрывание временного связывания, глава
•
Тема
34.
Общее состояние
-
1 "Философия
прагматизма':
"Гибкость или ломкость':
5
5 "Гибкость
или ломкость':
6
"Параллельность".
неверное состояние, глава
6
"Параллель
ность".
•
Тема
36.
Классные доски, глава
6
"Параллельность".
Задачи
•
Выясните, чем инструментальные средства с графическим пользователь
ским интерфейсом отличаются от небольших, но легко объединяемых в
На самом деле английское издание этой книги было написано в системе разметки
Markdown и напечатано в типографии непосредственно из исходного файла Markdown.
6
Глава 2 • Прагматичный подход
78
командной строке утилит. Какая из этих разновидностей инструменталь
ных средств оказывается более ортогональной и почему? Какой из них
удобнее пользоваться в тех целях, для которых она непосредственно пред
назначена? Какую из них легче объединить с другими инструментальными
средствами для решения новых задач? И какую из них легче изучить?
•
В языке С++ поддерживается множественное наследование, тогда как в
языке
языке
Java допускается реализация в классе нескольких интерфейсов, а в
Ruby имеются миксины. Какое влияние оказывает применение этих
языковых средств на ортогональность? Имеются ли какие-нибудь отличия
в применении множественного наследования и многих интерфейсов, деле
гирования и наследования?
Упражнения
1. Допустим,
вам было предложено реализовать построчное чтение исходно
го файла. Каждую строку вы должны разбить на поля. Какой из приведен
ных ниже определений псевдоклассов, по вашему мнению, является более
ортогональным? 7
class Splitl {
constructor(fileName)
def readNextLine()
def getField(n)
#
#
#
открывает файл для чтения
#
разбивает строку на поля
#
возвращает
переходит к следующей строке
возвращает
n-e
поле из текущей строки
или
class Split2 {
constructor(line)
def getField(n)
2.
n-e
поле из текущей строки
Чем объектно-ориентированные и функциональные языки программирова
ния отличаются в смысле ортогональности? Присущи ли эти отличия самим
языкам или же только тому способу, каким люди ими пользуются?
7
Возможные ответы на это и все остальные упражнения в данной книге см. в прило
жении В.
Тема 11 • Обратимость
l1@ili
79
ОБРАТИМОСТЬ
"Нет ничего опаснее идеи, если это все, что у вас есть".
-
Эмиль-Огюст Шартье, псевдоним 'i\лен",
О религии
(Propos
sиr
la religion), 1938 г.
Инженеры предпочитают простые, однозначные решения задач. Контрольные
работы по математике, позволяющие с полной уверенностью заявить, что х =
2,
намного более удобны, чем неясные, хотя и страстные рассуждения о многих
причинах Французской революции. Начальство готово согласиться с инжене
рами, что однозначные, простые вопросы изящно вписываются в электронные
таблицы и проектные планы.
Если бы реальный мир пошел таким же образом навстречу! К сожалению,
если х сегодня равно
ле
- 3.
2,
то завтра х может быть равно
5,
а на следующей неде
Ведь ничто не вечно, и если вы сильно полагаетесь на какой-то факт, то
можете быть уверены, что он все равно изменится.
Реализовать что-нибудь можно всегда не одним, а несколькими способами.
Кроме того, предоставить сторонний программный продукт может не один, а
несколько поставщиков. Если вы вступаете в проект, недальновидно считая, что
разработать его можно только одним способом, то будете неприятно удивлены.
Многие проектные команды просто вынуждены пристально вглядываться в бу
дущее по мере разворачивания событий. И вот тому наглядный пример:
"Но вы же сказали, чтобы мы пользовались базой данной
программировали проект уже на
нить!
-
-
85%,
XYZ!
Мы за
и теперь уже нельзя ничего изме
запротестовал программист.
Извините, но наша компания решила перевести все наши проекты
на базу данных
PDQ
как на стандартную. И я не могу с этим ничего
поделать. Нам просто придется перепрограммировать проект, а всем
вам
-
работать и в выходные, впредь до особого распоряжения".
Изменения совсем не обязательно должны быть до такой степени коренными
или даже немедленными. Но со временем, по мере развития проекта, вы можете
оказаться в безвыходном положении, если с каждым очень важным решением
проектная команда берет на себя обязательство достичь более мелкой цели, воп
лощающей суженную версию реально с меньшим числом вариантов выбора.
И к тому времени, когда многие важные решения будут сделаны, цель ока
жется настолько мелкой, что вы непременно промахнетесь, если она сместится,
Гnава 2 • Прагматичный подход
80
изменится направление ветра или японская бабочка махнет в Токио крылышка
ми8. А промахнуться вы можете очень сильно.
Все дело в том, что важные решения не так легко повернуть вспять. Как толь
ко вы решите воспользоваться базой данных конкретного поставщика, архитек
турным шаблоном или определенной моделью развертывания, тем самым вы
возьмете на себя обязательство выполнить порядок действий, который нельзя
отменить, разве что ценой немалых затрат.
ОБРАТИМОСТЬ
Многие темы в этой книге посвящены особенностям производства гибко
го, адаптируемого программного обеспечения. Если придерживаться приведен -
ных в них рекомендаций, особенно принципа
"Тема
9. DRY -
"Тема
28.
DRY,
описанного ранее в разделе
пороки дублирования", развязывания, обсуждаемого в разделе
Развязывание" главы
как поясняется в разделе "Тема
5, а также применения внешней конфигурации,
32. Конфигурирование" главы 5, то не придет
ся принимать много важных решений, которые могут оказаться необратимыми.
И это совсем неплохо, поскольку мы не всегда принимаем наилучшие решения с
первого раза. Придерживаясь определенной технологии, мы лишь впоследствии
обнаруживаем, что не можем нанять достаточно людей с требующимися навы
ками. Мы замыкаемся на определенном поставщике стороннего программного
обеспечения, после чего его перекупает конкурент. Требования, пользователи и
аппаратные средства меняются быстрее, чем нам удается разработать програм мное обеспечение.
Допустим, на ранней стадии работы над проектом вы решили воспользо
ваться базой данных от поставщика А. Гораздо позже, на стадии тестирования
производительности, вы обнаруживаете, что выбранная вами база данных ра
ботает слишком медленно, тогда как документная база данных от поставщика В
работает быстрее. Выходит, что вам просто не повезло, как это бывает в боль
шинстве обыкновенных проектов. Зачастую обращения к сторонним програм
мным продуктам глубоко вплетены в исходный код. Но если вы действительно
обобщите саму идею базы данных, причем до такой степени, чтобы она просто
предоставляла услуги хранения данных в качестве службы, то у вас появится
удобная возможность поменять лошадей на переправе.
Аналогично допустим, что ваш проект начинается как браузерное приложе
ние, но на более поздней его стадии в отделе сбыта решают, что им на самом
деле требуется мобильное приложение. Насколько трудно вам будет перестро8 Попробуйте внести небольшое изменение в одно из входных воздействий нелинейной или
хаотической системы. В итоге вы можете получить существенно иной и зачастую непред
сказуемый результат. Обыкновенная японская бабочка, машущая крылышками в Токио,
может стать началом целой цепочки событий, которая закончится торнадо в штате Техас.
Не напоминает ли это какой-нибудь известный вам проект?
Тема
11 • Обратимость
81
иться по ходу дела? В идеальном случае это не должно особенно повлиять на
ваш проект
-
по крайней мере, на его серверную сторону. Вам придется лишь
удалить НТМL-разметку воспроизведения, заменив ее соответствующим
API.
Ошибка кроется в допущении, что любое решение принимается окончатель
но, а следовательно, в неготовности к непредвиденным обстоятельствам, кото
рые могут так или иначе возникнуть. Вместо того чтобы принимать решения
бесповоротно, как высеченные на камне, рассматривайте их как начертанные
на береговом песке. Ведь большая волна может нахлынуть в любой момент и
смыть их без следа.
IЗфI§ll:I
Окончательных решений не существует
ГИБКАЯ АРХИТЕКТУРА
Несмотря на то что многие программисты стараются сохранять как можно
более гибким сам код, необходимо также подумать и об удобстве сопровожде
ния на уровне архитектуры, развертывания и интеграции сторонних програм
мных продуктов. С начала нынешнего столетия и вплоть до момента написания
этих строк появились следующие "нормы наилучшей практики" построения
серверных архитектур.
•
Большая груда железа.
•
Образования больших груд железа.
•
Кластеры недорогого стандартного оборудования, выровненные по нагрузке.
Контейнеризованные варианты облачных виртуальных машин.
•
Бессерверные приложения с облачной поддержкой.
•
И как неизбежность, вполне очевидный возврат к большим грудам железа
для решения некоторых задач.
Можете дополнить этот список самыми последними веяниями и благоговей
но считаться с ними как с каким-то чудом, благодаря которому что-то вообще
работает. Можно ли вообще запланировать все это многообразие архитектур
ных решений? Никак нельзя.
Единственное, что можно действительно сделать,
-
это упростить измене
ния. В частности, скрывайте сторонние API за собственными уровнями абстрак
ции. Разбивайте свой код на компоненты, даже если их придется развертывать
на одном крупном сервере. Ведь это намного проще, чем разбивать на части
одно монолитное приложение. Мы убедились в этом на собственном горьком
Глава 2 • Праrматичный подход
82
опыте. Наконец, приведем еще один полезный совет, хотя он и не имеет непос
редственного отношения к рассматриваемому здесь вопросу обратимости.
G+tцp1
Остерегайтесь увлекаться новомодными веяниями
Никто не знает, что сулит нам будущее! Поэтому заставляйте свой код "тряс
тись': когда это возможно, и живо "крутиться': когда это необходимо, как в тан
це рок-и-рол.
Другие разделы, связаннь1е с данной темой
Сущность качественного проектирования.
•
Тема
8.
•
Тема
10.
•
Тема
19. Контроль версий,
•
Тема
28.
•
Тема
45. Западня
•
Тема
51.
Ортогональность.
глава
Развязывание, глава
5
3 "Основные инструментальные средства':
"Гибкость или ломкость':
требований, глава
8
"До начала проекта':
Начальный набор инструментальных средств программиста-праг
матика, глава
9
"Прагматичные проекты':
Задачи
•
А теперь уделите немного времени квантовой механике, проведя мыслен -
ный эксперимент, называемый "котом Шрёдингера". Представьте, что вы
закрыли кота в ящике с радиоактивной частицей, которая распадется на
две другие частицы с вероятностью
50%.
Если она распадется, то убьет
кота, а если не распадется, то кот останется живым. Так погибнет кот или
выживет? По мнению Шрёдингера, верно и то и другое
-
по крайне мере,
до тех пор, пока ящик закрыт. Всякий раз, когда происходит субъядерная
реакция с двумя возможными исходами, мир распадается на два других:
один, где событие произошло, а другой, где оно не произошло. Кот выжи
вет в одном мире и погибнет в другом. И вы узнаете, в каком именно мире
находитесь сами, лишь тогда, когда откроете ящик.
Не удивительно, что программировать на будущее так трудно.
Но подумайте об эволюции своего кода как о ящике, в котором полно ко
тов Шрёдингера, когда всякое решение может привести к разным версиям
кода в будущем. Сколько возможных вариантов будущего развития спосо
бен поддерживать ваш код? Какие из них наиболее вероятны? Насколько
трудно будет их поддерживать, когда настанет время? Отважитесь ли вы
открыть ящик?
При разработке программного обеспечения нередко речь заходит о попада
нии в цель. И хотя мы не стреляем по мишени на огневом рубеже, такая мета
фора все же оказывается очень удобной. В частности, любопытно выяснить, как
попасть в цель в сложном и постоянно меняющемся мире.
Ответ на этот вопрос, безусловно, зависит от характера того устройства,
которое вы нацеливаете. И у вас лишь один шанс прицелиться и лишь затем
убедиться, попали ли вы в яблочко, удовлетворив своего клиента. Но есть и
лучший способ.
Вам, вероятно, приходилось не раз видеть в кино, по телевизору или в видео
играх, как люди стреляют из пулеметов? В подобных сценах траектории полета
пуль нередко наблюдаются как яркие полосы света в атмосфере. Такие полосы
оставляют за собой трассирующие пули.
Трассирующие пули устанавливаются в пулеметную ленту через определен
ные промежутки вместе с обычными боеприпасами. Когда они выстреливаются,
содержащийся в них фосфор загорается, оставляя огненный след, тянущийся от
пулемета к тому месту, куда они попадают. Если трассирующие пули попадут в
цель, то в нее попадут и обычные пули. Солдаты делают очереди трассирующи
ми пулями для того, чтобы уточнить прицеливание, поскольку они дают вполне
прагматичную, оперативную реакцию в условиях реальной стрельбы.
Аналогичный принцип можно применить и к проектам, особенно в том слу
чае, если приходится проектировать нечто совершенно новое, не имея прежне
го опыта. Мы пользуемся термином разработка методом трассирующих пуль,
чтобы наглядно показать потребность в немедленной реакции в действительных
условиях с подвижной конечной целью.
Проектируя совершенно новую систему, вы, подобно пулеметчикам, пытае
тесь попасть в цель, находясь в полной темноте. Ваши пользователи вообще не
сталкивались прежде с такой системой, поэтому их требования не совсем ясны.
А вам приходится решать уравнение со многими неизвестными, поскольку вы
можете пользоваться незнакомыми прежде алгоритмами, методиками, языками
или библиотеками. Для завершения подобных проектов требуется время, и по
этому можно смело предположить, что ваша рабочая среда изменится задолго
до того, как вы завершите работу над своим проектом.
Классический подход к проектированию системы состоит в том, чтобы со
ставить ее спецификацию во всех подробностях, исписав стопки бумаги, акку
ратно составив перечень всех требований, связав все неизвестные и наложив
Глава 2 • Прагматичный подход
84
ограничения на рабочую среду. При этом стрельба по конечной цели ведется
с точным расчетом: сначала делается один крупный предварительный расчет,
а затем производится выстрел с надеждой попасть в цель. Но программисты
прагматики предпочитают в подобных случаях пользоваться программным эк
вивалентом трассирующих пуль.
Код, СВЕРКАЮЩИЙ В ТЕМНОТЕ
Трассирующие пули удобны тем, что они действуют в тех же условиях и при
тех же самых ограничениях, что и настоящие пули. Они быстро достигают цели,
так что стрелок сразу же получает ответную реакцию . А с практической точки
зрения они являются относительно недорогим решением . Чтобы добиться ана
логичного результата в коде, мы ищем нечто, быстро наглядно и неоднократно
приводящее нас от исходного требования к некоторому свойству конечной сис
темы.
Ищите сначала самые важные требования, определяющие систему, а затем те
участки, где у вас имеются сомнения и где вы видите наибольшие риски. Рас
ставьте далее приоритеты в своей разработке, чтобы они указывали на те учас
тки, с которых следует в первую очередь начать программирование.
IЗ.J:f§fj1) Пользуйтесь методом трассирующих пуль для отыскания цели
В действительности, принимая во внимание сложность организации проекта
в современных условиях с массой внешних зависимостей и инструментальных
средств, метод трассирующих пуль приобретает еще большее значение. Для раз
работчиков первая трассирующая пуля просто состоит в том, чтобы создать
проект, добавить в него код, выводящий пробное сообщение типа "Здравствуй,
мир!': а затем убедиться, что этот код компилируется и выполняется. Далее сле
дует найти участки неопределенности во всем приложении и добавить скелет
ный вариант, требующийся для того, чтобы привести его в работоспособное
состояние.
Рассмотрим приведенную ниже диаграмму, где показаны пять архитектурных
уровней проектируемой системы. Нас интересует, каким образом они интегри
руются, поэтому найдем простое функциональное средство, позволяющее испы
тать их вместе . Диагональная линия на этой диаграмме показывает путь, кото
рый некоторое функциональное средство проходит через исходный код . Чтобы
воплотить все это в жизнь, достаточно реализовать окрашенные сплошным цве
том участки диаграммы на каждом уровне, тогда как все, что обозначено на ней
завитками, будет реализовано в дальнейшем.
Тема 12 • Трассирующие пули
85
Nv:v\l'J Еще не реализовано
Однажды нам пришлось вести сложный маркетинговый проект с базой дан
ных архитектуры "клиент-сервер". Часть требований к данному проекту состоя
ла в предоставлении возможности составлять и выполнять временные запросы.
На серверах был установлен целый ряд реляционных и специализированных
баз данных, а клиентский пользовательский интерфейс был написан на произ
вольно выбранном языке А, в котором применялся ряд библиотек, написанных
на другом языке для обеспечения интерфейса с серверами. Пользовательский
запрос сохранялся на сервере в виде Lisр-подобной записи, прежде чем быть
преобразованным в оптимизированный запрос
SQL непосредственно
перед его
выполнением. В данном проекте было много неизвестных и самых разных сред,
причем никто не знал точно, как должен себя вести пользовательский интер
фейс.
Это была прекрасная возможность воспользоваться трассирующим кодом.
С этой целью мы разработали каркас клиентской части системы, библиотеки для
представления запросов и структуру для преобразования хранимых запросов в
фактические запросы конкретной базы данных. Затем мы собрали все это вместе
и проверили на работоспособность. И хотя мы могли направить в этом первона
чально собранном варианте лишь запрос, в котором перечислялись все строки в
таблице базы данных, мы все же смогли убедиться, что пользовательский интер
фейс способен взаимодействовать с библиотеками, сами библиотеки
нять сериализацию и десериализацию запроса, а сервер
SQL из полученного результата.
-
-
выпол
формировать запрос
В течение последующих месяцев мы постепенно
наполнили деталями эту основную структуру, добавили новые функциональные
возможности, параллельно нарастив каждый компонент трассирующего кода.
По мере внедрения нового типа запроса в пользовательский интерфейс библио
тека разрасталась, а формирование запроса
SQL усложнялось.
Глава 2 • Прагматичный подход
86
Трассирующий код пишется не для одноразового применения, а надолго. Он
содержит все проверки ошибок, структурирование, документирование и само
проверку, как и любой фрагмент выходного кода. Он просто не полностью функ
ционален. Но как только будет достигнуто сквозное соединение компонентов
вашей системы, вы сможете проверить, насколько близки вы к желанной цели, и
вносить коррективы по мере надобности. Как только цель будет достигнута, до
бавить требующиеся функциональные возможности не составит особого труда.
Разработка методом трассирующих пуль согласуется с представлением о том,
что проект никогда не завершается. В нем всегда найдется место для изменений
и добавлений новых функций. Это постепенный подход. Обычно его альтерна
тивой является тяжеловесный подход, при котором исходный код разбивается
на модули, программируемые по отдельности. Эти модули затем объединяются
в сборки, а те, в свою очередь, объединяются дальше до тех пор, пока однажды
не получится готовое приложение. И лишь тогда приложение может быть пред
ставлено как единое целое пользователям для последующего тестирования.
У подхода к разработке с помощью трассируемого кода имеются следующие
преимущества.
•
Пользователи моrут увидеть нечто работоспособное уже на ранней ста
дии разработки. Если вы своевременно известите пользователей о том, что
вы делаете (см. раздел "Тема
ствие" главы
9),
52. Доставляйте своим пользователям удоволь
они будут заранее знать, что увидят нечто еще не зрелое.
Следовательно, их не разочарует нехватка функциональных возможностей,
и они будут восторженно приветствовать видимый прогресс в разработке
создаваемой для них системы. Они также смогут внести свой вклад в про
ект по ходу работы над ним, повысив тем самым свою заинтересованность
в нем. Те же самые пользователи, вероятнее всего, подскажут вам, насколь
ко вы приблизились к желанной цели на каждом последующем шаге.
•
Разработчики создают структуру, чтобы работать в ней. Больше всего
пугает пустой лист бумаги, на котором вообще ничего не написано. Если
вы выяснили все сквозные взаимодействия в своем приложении и вопло
тили их в коде, то вашей команде не придется ничего особенного брать с
потолка. Это способствует повышению общей производительности труда
и согласованности действий в команде.
•
У вас есть платформа для интеграции. Как только вы осуществите сквоз
ное соединение компонентов системы, вы получите в свое распоряжение
такую среду, в которую можно будет благополучно внедрить новые фраг
менты кода, как только они пройдут модульное тестирование. Вместо того
чтобы пытаться интегрировать все одним махом, вы можете выполнять
интеграцию каждый день, а то и несколько раз в день. В этом случае вли
яние каждого нового изменения становится более очевидным, тогда как
Тема 12 з Трассирующие пули
взаимодействия
-
87
более ограниченными, а следовательно, отладка и тес
тирование выполняются быстрее и точнее.
•
Вам есть что продемонстрировать. Спонсоры проекта и высшее началь
ство обычно требуют, чтобы им показали демонстрационные версии в са
мые неподходящие для этого моменты. Благодаря трассирующему коду у
вас всегда будет что предъявить.
•
Вы лучше ощущаете проrресс. Работая над проектом методом трассирую
щих пуль, разработчики занимаются прецедентами использования по оче
реди. Справившись с одним прецедентом использования, они переходят к
друтому. Благодаря этому оказывается намного проще количественно оце
нить производительность и продемонстрировать пользователям прогресс
в работе над проектом. А поскольку каждая индивидуальная разработка
ведется в более мелких масштабах, то можно избежать создания монолит
ных блоков кода, о завершенности которых на
95%
разработчики отчиты
ваются с недели на неделю.
ТРАССИРУЮЩИЕ ПУЛИ НЕ ВСЕГДА ПОПАДАЮТ В ЦЕЛЬ
Обычно трассирующие пули показывают, куда вы попали. Но это не всегда
может быть желанная цель. В таком случае вам придется поправлять прицел до
тех пор, пока вы не попадете точно в цель. И в этом основная идея трассирую
щих пуль.
То же самое относится и к трассирующему коду. Вы пользуетесь данным ме
тодом в обстоятельствах, когда не знаете точно, куда движетесь. И поэтому не
удивляйтесь, если, сделав две первые попытки, вы промахнетесь, а пользователь
скажет: "Это совсем не то, что я имел в виду': нужные вам данные окажутся не
доступны именно тогда, когда они вам потребуются, или же упадет производи
тельность. В таком случае измените результат, которого вы уже добились, чтобы
перенести его поближе к цели, и будьте благодарны за то, что вы воспользова
лись данной методикой разработки. Ведь небольшой фрагмент кода обладает
малой инертностью, так что его можно очень быстро и легко изменить. Помимо
этого, вы сумеете собрать отзывы о своем приложении, а затем быстро и деше
во сгенерировать новую, более точную его версию. А поскольку все основные
компоненты вашего приложения представлены в трассирующем коде, то поль
зователи могут быть уверены, что все, что они увидят, основывается на чем-то
реальном, а не только на бумажной спецификации.
ТРАССИРУЮЩИЙ КОД В СРАВНЕНИИ С ПРОТОТИПИРОВАНИЕМ
Можно решить, что рассматриваемый здесь метод трассирующего кода ока
зывается не более, чем прототипированием, только более воинственно назван
ным. Ведь с помощью прототипа вы нацеливаетесь на исследование конкретных
88
Гnава 2 • Прагматичный подход
свойств конечной системы. А настоящий прототип помогает вам отбросить все,
что вы связали вместе, когда опробовали какой-нибудь принцип, а затем пере
программировать, руководствуясь извлеченными вами уроками.
Допустим, вы разрабатываете приложение, помогающее грузоотправителям
выяснить, как упаковать ящики нестандартных размеров в контейнеры. Среди
прочих трудностей, пользовательский интерфейс такого приложения должен
быть интуитивным, тогда как алгоритмы, применяемые вами для определения
оптимального варианта упаковки, довольно сложные.
Вы могли бы, конечно, создать с помощью специального инструментального
средства прототип пользовательского интерфейса для его демонстрации конеч
ному пользователю, а также запрограммировать его настолько, чтобы он реа
гировал на действия пользователя. И как только пользователь согласился бы с
компоновкой прототипа, вы могли бы отбросить его и перепрограммировать
пользовательский интерфейс - на этот раз уже с бизнес-логикой, используя це
левой язык. Аналогично вы могли бы прототипировать целый ряд алгоритмов,
выполняющих конкретную задачу упаковки. Кроме того, вы могли бы написать
функциональные тесты на таком неприхотливом языке высокого уровня, как,
например, Python, а тесты производительности на низком уровне - на каком
нибудь простом языке, близком к машинному. Но в любом случае, как только
вы приняли бы решение, вам пришлось бы начинать все заново, программируя
алгоритмы в среде их конечного применения, взаимодействующей с реальным
миром. В этом, собственно, и состоит прототипирование, польза от которого
несомненна.
Метод трассирующего кода направлен на разрешение другого затруднения,
когда вам требуется знать, насколько удачно все приложение связано вместе.
Ведь пользователям вашего приложения нужно показать, каким образом про
исходит его взаимодействие с ними на практике, а разработчикам - предоста
вить скелетный вариант его архитектуры, который можно было бы наполнить
конкретным кодом. В таком случае вы можете написать трассирующий код, со
стоящий из тривиальной реализации алгоритма упаковки контейнера (возмож
но, действующего по принципу "первым пришел, первым обслужен"), а также
простой, но работоспособный пользовательский интерфейс. И как только вы
скомпонуете вместе все компоненты своего приложения, то получите каркас,
который можно показать как пользователям, так и разработчикам. Со временем
вы дополните этот каркас новыми функциональными возможностями, заменив
ими суррогатные процедуры. Но сам каркас останется нетронутым, а вы будете
уверены, что система и дальше поведет себя таким же образом, как и по завер
шении первого трассирующего кода.
Рассмотренное выше отличие настолько важно, что его стоит еще раз пов
торить. Прототипирование приводит к генерации одноразового кода. А трас
сирующий код
-
скудный, но завершенный, образующий скелетный вариант
Тема 13 • Прототипы и памятные записки
89
конечной системы. Прототипирование можно рассматривать как своего рода
разведку местности и добывание разведывательных данных, прежде чем будет
выпущена первая трассирующая пуля.
Другие раэделы, сввэанные с данной темой
•
Тема
13.
Прототипы и памятные записки.
•
Тема
27.
Не опережайте свет фар вашего автомобиля, rлава
4
"Прагматич-
ная паранойя':
•
Тема
40.
Рефакторинг, rлава
•
Тема
49.
Прагматичные команды, rлава
9
•
Тема
50.
Кокосами не обойтись, rлава
"Прагматичные проекты':
•
Тема
51. Начальный набор инструментальных средств
9 "Прагматичные проекты':
7
"По ходу кодирования".
9
"Прагматичные проекты':
программиста-праг
матика, глава
•
Тема
52.
Доставляйте своим пользователям удовольствие, глава
9
"Праг
матичные проекты':
'•MIFI ПРОТОТИПЫ и ПАМЯТНЫЕ ЗАПИСКИ
Прототипы применяются во многих отраслях промышленности для опробо
вания конкретных идей, ведь создавать прототипы намного дешевле, чем произ
водить полномасштабные образцы продукции. Например, автомобилестроители
могут создавать самые разные прототипы новой конструкции, используя каж
дый из них для испытания конкретного свойства автомобиля: аэродинамики,
стилевого оформления, конструктивных характеристик и т.д. А приверженцы
старых традиций пользуются моделью из глины для испытаний в аэродинами
ческой трубе, тогда как для отдела дизайна может вполне подойти пробковое де
рево и клейкая лента. Менее романтичным выглядит моделирование на экране
компьютерного монитора или в виртуальной реальности, хотя оно и обходит
ся намного дешевле. В последнем случае рискованные и ненадежные элементы
конструкции можно испытать, не прибегая к построению настоящего образца.
Мы создаем прототипы программ аналогичным образом и в тех же целях:
чтобы проанализировать и выявить риск, а также дать возможность внести кор
рективы, существенно снизив затраты. Как и автомобилестроители, мы можем
нацелить прототип на проверку одного или нескольких конкретных аспектов
проекта.
Мы привыкли считать, что прототипы основываются на коде, хотя это не
всегда именно так. Как и автомобилестроители, мы можем построить прототи
пы из различных материалов. В частности, памятные записки на клейких лис-
Гnава 2 • Прагматичный подход
90
точках бумаги как нельзя лучше подходят для прототипирования таких динами
ческих элементов, как рабочий поток и прикладная логика. А пользовательский
интерфейс можно прототипировать в виде рисунка на белой доске или нефунк
ционального макета, нарисованного в программе раскраски или в конструкторе
интерфейса.
Прототипы служат для поиска ответов лишь на немногие вопросы, поэтому
они обходятся намного дешевле и создаются быстрее, чем приложения , пере
даваемые в эксплуатацию. В коде прототипа можно пренебречь подробностя
ми, которые не важны в данный момент, но впоследствии могут стать очень
важными для пользователей. Так, если создается прототип пользовательского
интерфейса, в таком случае можно довольствоваться и неточными результата
ми или данными . А если исследуются вычислительные или производительные
особенности приложения, то можно довольствоваться и весьма скромным поль
зовательским интерфейсом, а возможно, и вообще обойтись без него.
Но если вы окажетесь в такой среде, где нельзя пренебречь подробностями,
то спросите себя: а стоит ли вообще создавать прототип? В таком случае вам,
может быть, больше подойдет разработка методом трассирующих пуль (см.
выше раздел "Тема
12. Трассирующие
пули").
Что ПОДЛЕЖИТ ПРОТОТИПИРОВАНИЮ
Что можно выбрать для исследования с помощью прототипа? Все, что несет
в себе риск, все, что еще не было опробовано, или то, что крайне важно для ко
нечной системы , а также все, что не проверено, экспериментально, сомнитель
но или то, в чем нет никакой уверенности . Итак, прототипированию подлежит
следующее.
•
Архитектура.
•
Новые функциональные возможности уже имеющейся системы.
•
Структура или содержание внешних данных.
•
Сторонние инструментальные средства или компоненты.
•
Вопросы производительности.
•
Оформление пользовательского интерфейса.
Прототипирование означает опыт познания. Его ценность состоит не в про
изводимом коде, а в извлекаемых уроках. И в этом заключается весь смысл про
тотипирования.
Gфt§fJI
Создавайте прототипы для обучения
Тема 13 • Прототипы и памятные записки
91
КАК ПОЛЬЗОВАТЬСЯ ПРОТОТИПАМИ
Ниже перечислены подробности, которыми можно пренебречь, создавая
прототипы.
•
Правильность. Там, где это уместно, возможно, удастся воспользоваться
фиктивными данными.
•
Завершенность. Прототип может функционировать лишь в весьма огра
ниченном смысле, а возможно, и с единственным предварительно выбран
ным фрагментом входных данных и одним пунктом меню.
•
Надежность. Проверка ошибок вряд ли должна быть полной, а возмож
но, и вообще должна отсутствовать. Если отклониться от заранее опреде
ленного пути, прототип может потерпеть крах и сгореть ярким пламенем.
И это нормально.
•
Стиль программирования. Исходный код прототипа вряд ли следует снаб
жать комментариями или документировать, хотя и можно написать целые
стопки документации, опираясь на свой опыт работы с прототипом.
В прототипах подробности не принимаются во внимание, которое сосредото
чено в основном на конкретных свойствах исследуемой системы, и поэтому про
тотипы можно реализовать на языке сценариев (например,
Python
или
Ruby),
который по своему уровню выше, чем другие языки, применяемые в остальной
части проекта, поскольку они могут лишь стать помехой. Продолжить дальней
шую разработку можно как на языке, выбранном для создания прототипа, так
и перейти на другой язык. Ведь в конечном итоге прототип все равно будет
отброшен за ненадобностью.
Для прототипирования пользовательского интерфейса можно воспользовать
ся инструментальным средством, позволяющим сосредоточиться на внешнем
виде и/или взаимодействии интерфейса с пользователем, не особенно беспоко
ясь о коде или разметке. Языки сценариев вполне пригодны и в качестве связую
щего звена для объединения низкоуровневых фрагментов в новые комбинации.
Применяя такой подход, можно очень быстро собрать существующие компонен
ты в новые конфигурации, чтобы проверить их на работоспособность.
ПРОТОТИПИРОВАНИЕ АРХИТЕКТУРЫ
Многие прототипы создаются для моделирования всей рассматриваемой сис
темы. В отличие от метода трассирующих пуль, индивидуальные модули совсем
не обязательно должны как-то по-особому функционировать в прототипной
системе. В действительности для прототипирования архитектуры можно даже
не программировать, поскольку это можно сделать на белой доске, листках для
памятных записок или карточках для записей. В данном случае требуется вы
яснить, каким образом система связана в единое целое, не обращая, опять же,
Глава 2 • Прагматичный подход
92
внимания на подробности. Ниже перечислен ряд конкретных вопросов, кото
рые требуется выяснить, рассматривая архитектурный прототип.
•
Вполне ли определены и приемлемы области ответственности основных
компонентов системы?
•
Вполне ли определены взаимодействия основных компонентов системы?
о Сведено ли к минимуму связывание?
•
Можно ли выявить потенциальные источники дублирования?
•
Насколько приемлемы определения интерфейсов и ограничения?
•
Имеется ли у каждого модуля путь доступа к данным, которые требуются
ему во время выполнения? Имеет ли каждый модуль доступ именно тогда,
когда он требуется?
Последний ряд вопросов приносит больше всего неожиданностей и самых
ценных результатов из опыта прототипирования.
КАК НЕ СЛЕДУЕТ ПОЛЬЗОВАТЬСЯ ПРОТОТИПАМИ
Прежде чем приступить к любому прототипированию на основе кода, убеди
тесь, что все заинтересованные лица ясно отдают себе отчет, что вы собираетесь
писать одноразовый код. Ведь прототипы могут быть обманчиво привлекатель
ны для тех людей, которые не знают, что это всего лишь прототипы. Поэтому вы
должны очень ясно дать понять, что данный код одноразовый, незавершенный
и непригодный для завершения.
Кажущаяся завершенность демонстрируемого прототипа может легко ввести
в заблуждение, а попечители проекта или руководство могут даже настаивать
на развертывании прототипа (или его детища), если вы не дадите ясно понять,
чего именно следует ожидать от него. Напомните им, что вы можете построить
отличный прототип нового автомобиля из пробкового дерева и клейкой ленты,
но поехать на нем в часы пик вряд ли удастся!
Если вы остро ощущаете, что назначение прототипного кода в вашей среде
или культуре может быть понято превратно, в таком случае вам лучше выбрать
метод трассирующих пуль. В конечном счете у вас будет прочный каркас в ка
честве основания для последующей разработки.
Надлежащим образом применяемые прототипы позволяют сэкономить не
мало времени, средств и трудов, выявляя и корректируя потенциальные проб
лемные места на ранней стадии цикла разработки, когда исправление ошибок
делается просто и обходится недорого.
Доставляйте своим пользователям удовольствие, глава
8
"До начала проекта':
9
"Праг
матичные проекты':
Упражнения
3.
В отделе сбыта предложили обсудить вместе с вами несколько вариантов
оформления веб-страниц, в том числе карты ссылок, выбираемые щелчком
кнопкой мыши для перехода на другие страницы, и т.д. Но они не могут
выбрать модель для изображения на карте ссылок из нескольких вариантов:
автомобиля, телефона и дома. У вас имеется список целевых страниц и их
содержимого, и поэтому им хотелось бы посмотреть несколько прототипов.
Кстати, вам на это дается
15 минут.
Какими инструментальными средствами
вы могли бы для этого воспользоваться?
'•Mltl ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЕ языки
"Границы моего языка означают границы моего мира".
Людвиг Виттгенштейн 9
Языки программирования компьютеров оказывают влияние на то, как мы
осмысливаем задачу и как понимаем общение. У каждого такого языка имеется
перечень средств, означаемых специальными терминами вроде статической или
динамической типизации, раннего или позднего связывания, функционально
го или объектно-ориентированного программирования, моделей наследования,
примесей, макрокоманд, причем все они могут предложить или затруднить оп
ределенные решения. Выработка решения, принимая во внимание особеннос
ти программирования на языке С++ , может привести к иным результатам, чем
решение, основанное на мышлении в стиле языка
Haskell,
и наоборот. Но в то
же время и язык предметной области может предложить решение для програм
мирования, что, на наш взгляд, важнее.
9
Ludwig Wittgenstein - австрийский философ и логик ХХ века. - Примеtt. пер.
Глава 2 • Прагматичный подход
94
Мы всегда пытаемся писать код, пользуясь словарем из прикладной области
(см. раздел "Ведение словаря" главы
8
"До начала проекта"). Иногда програм
мисты-прагматики могут перейти на следующий уровень и сразу приступить к
программированию, пользуясь словарем, синтаксисом и семантикой (т.е. язы
ком) предметной области.
Программируйте близко к предметной области
НЕКОТОРЫЕ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЕ ЯЗЫКИ
Итак, рассмотрим несколько примеров, в которых было сделано именно то,
что и рекомендуется в приведенном выше совете.
RSpec
RSpec - это библиотека для тестирования кода 10 , написанного на языке Ruby.
Она вдохновила на создание версий большинства других современных языков.
Тест в
RSpec преследует цель отразить ожидаемое поведение проверяемого
кода,
как показано в приведенном ниже примере .
des c ribe BowlingScore do
it "totals 12 if you score 3 four times" do
score = BowlingScore .new
4.times { score.add_p i ns(З) }
expect(score.total) .to eq(12)
end
end
Cucumber
Cucumber - это язык программирования 11 , позволяющий составлять тесты
нейтральным способом. Для выполнения тестов используется версия Cucumber,
подходящая для применяемого языка. Чтобы поддерживать такой же синтаксис,
как и у нейтрального языка, придется написать также конкретные сопоставите
ли, распознающие фразы и извлекающие параметры для тестов. Ниже приведен
характерный тому пример.
Feature: Scoring
Background:
Given an empty scorecard
Scenario: bowling а lot of З s
Given I throw а 3
And I throw а 3
And I throw а 3
And I throw а 3
Тhen the score should Ье 12
10
11
См. по адресу https: / /rspec. info.
См. по адресу https: / /cucumЬe r . i o / .
Тема 14 • Предметно-ориентированные языки
Тесты составлены на языке
Cucumber таким
95
образом, чтобы их могли прочи
тать клиенты программного обеспечения (хотя такое очень редко происходит на
практике; возможные причины этого поясняются в приведенной ниже врезке).
ПОЧЕМУ МНОГИЕ КОРПОРАТИВНЫЕ ПОЛЬЗОВАТЕЛИ
НЕ ЧИТАЮТ ФУНКЦИИ CucuMBER
Одна из причин, по которым классический подход "собирание требований,
проектирование, программирование, выпуск" оказывается недейственным,
состоит в том, что он зиждется на понятии о том, что требования извест
ны, хотя такое бывает редко. Корпоративные пользователи весьма смутно
представляют, чего они хотят достичь, но им неизвестны, да
и
не важны
подробности. И в этом отчасти состоит ценность разработчиков, поскольку
они постигают внутренним чутьем намерения своих клиентов и воплощают
их в коде.
Следовательно, когда вы настоятельно просите корпоративного пользова
теля окончательно утвердить требования или согласовать их с рядом фун
кций
Cucumber,
это все равно, что заставить его проверить правописание
в сочинении, написанном на шумерском языке. Он внесет ряд случайных
изменений в требования, чтобы не уронить свое лицо, и утвердит их, чтобы
побыстрее выпроводить вас из своего учреждения.
Лучше предоставьте корпоративным клиентам работоспособный код, чтобы
они могли опробовать его на практике. Именно тогда и проявятся их реаль
ные потребности.
Маршруты
Phoenix
Во многих каркасах веб-приложений имеется средство маршрутизации, пре
образующее входящие НТТР-запросы в функции их обработки в коде. Ниже
приведен характерный тому пример из Phoenix 12 •
scope "/", HelloPhoenix do
pipe_through :browser #
использовать стандартный стек браузера
get "/", PageController, :index
resources "/users", UserController
end
12
См. по адресу https: / /phoenixframework. org/.
Глава 2 • Прагматичный подход
96
В данном примере запросы, начинающиеся со знака
"/ ",
должны пройти
через ряд фильтров, пригодных для браузеров. Сам запрос ресурса
дет обработан функцией
UsersController
index ()
из модуля
PageController.
"/"
бу
А в модуле
реализуются все функции, требующиеся для управления
ресурсом, доступным по следующему
URL: /users.
AnsiЫe
AnsiЬle -
это инструментальное средство 13 , предназначенное для конфигу
рирования программного обеспечения, как правило, на целом ряде удаленных
серверов. С этой целью оно читает предоставляемую ему спецификацию, а затем
делает все необходимое, чтобы зеркально отобразить ее на них. Спецификация
может быть написана на YAML 14
-
языке, предназначенном для построения
структур данных из текстовых описаний. Так, в приведенном ниже примере
обеспечивается установка веб-сервера
nginx
на удаленных серверах, его запуск
по умолчанию, а также применение предоставляемого файла конфигурации.
- name: install nginx
apt: name=nginx state=latest
- name: ensure nginx is running (and еnаЫе it at boot)
service: name=nginx state=started enaЫed=yes
- restart nginx
ХАРАКТЕРИСТИКИ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКОВ
Рассмотрим приведенные выше примеры более подробно. В частности, при
меры теста
(Ruby
и
RSpec и марштрутизатора Phoenix написаны на их базовых языках
Elixir). В них употребляется довольно замысловатый код, включающий
в себя метапрограммирование и макрокоманды, но в конечном счете они ком
пилируются и выполняются как обычный код.
Тесты
Cucumber
и конфигурации AnsiЬle написаны на их собственных язы
ках. В частности, тест
Cucumber преобразуется
в выполняемый код или в струк
туру данных, тогда как спецификации AnsiЬle всегда преобразуются в структуру
данных, выполняемую непосредственно в AnsiЬle.
В итоге код теста
RSpec
и марштрутизатора
Phoenix
внедряется в выпол
няемый прикладной код в виде подлинных расширений его словаря. А тесты
Cucumber
13
14
и конфигурации AnsiЬle читаются прикладным кодом и преобра-
См. по адресу https: / /www. ansiЫe. сот/.
См. по адресу https: / /yaml. org/.
Тема 14 • Предметно-ориентированные языки
97
зуются в некоторую форму, пригодную для употребления в прикладном коде.
Тест
RSpec
и маршрутизатор
Phoenix
можно назвать примерами внутренних
предметно-ориентированных языков, тогда как тест
AnsiЬle
-
Cucumber и
конфигурацию
примерами внешних предметно-ориентированных языков.
КОМПРОМИСС МЕЖДУ ВНУТРЕННИМИ И ВНЕШНИМИ
ПРЕДМЕТНО-ОРИЕНТИРОВАННЫМИ ЯЗЫКАМИ
В общем случае во внутреннем предметно-ориентированном языке могут
выгодно использоваться средства его базового языка, поскольку создаваемый
предметно-ориентированный язык обладает большими функциональными воз
можностями, которые даются даром. Например, для автоматического создания
набора тестов
RSpec можно
воспользоваться некоторым кодом
Ruby.
В этом слу
чае можно проверить очки на промахи или попадания:
describe BowlingScore do
(0 .. 4) .each do lpinsl
(1 .. 20) .each do lthrowsl
target = pins * throws
i t "totals #{target) i f you score #{pins) #{throws) times" do
Недостаток внутренних предметно-ориентированных языков заключается в
необходимости привязываться к их синтаксису и семантике. И хотя некоторые
языки данной категории проявляют в этом отношении замечательную гибкость,
все равно приходится искать компромисс между языком, который требуется,
и языком, который можно реализовать. И все, что в конечном счете будет до
стигнуто, должно быть по-прежнему согласовано с синтаксисом целевого языка.
Языки с макрокомандами (например,
Elixir, Clojure и Crystal)
предоставляют не
много больше удобств, но синтаксис все равно остается синтаксисом.
На внешние предметно-ориентированные языки подобные ограничения
не накладываются. Если имеется возможность написать синтаксический ана
лизатор для такого языка, то именно так и следует поступить. Иногда можно
воспользоваться сторонним синтаксическим анализатором, как это сделано в
AnsiЬle с помощью
YAML,
но и тогда приходится искать компромисс.
Написание синтаксического анализатора, вероятнее всего, означает внедре
ние новых библиотек (а возможно, и инструментальных средств) в разрабаты
ваемое приложение. А ведь написать качественный синтаксический анализа-
Глава 2 • Прагматичный подход
98
тор
-
дело непростое. Но если отважиться, то можно поискать и применить
подходящие генераторы синтаксических анализаторов (например, Ьison или
ANTLR)
или каркасы для синтаксического анализа (например, многочисленные
реализации анализаторов
PEG -
грамматики, разбирающей выражения).
Наша рекомендация довольно проста: не тратить усилий больше, чем можно
сэкономить. Написание предметно-ориентированного языка так или иначе уве
личивает затраты на проект, и поэтому необходимо убедиться, что они окупятся
(потенциально
-
в долгосрочной перспективе).
В общем, пользуйтесь по возможности готовыми внешними предметно-ори
ентированными языками (например,
YAML, JSON
или
CSV),
а иначе
-
поищите
подходящий внутренний язык. Пользоваться внешними языками рекомендуется
только в тех случаях, когда выбранный вами язык будет написан пользователя
ми вашего приложения.
ВНУТРЕННИЙ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЙ язык почти ДАРОМ
Наконец, если просачивание синтаксиса базового языка не имеет особо
го значения, можно прибегнуть к одной хитрости, чтобы создать внутренний
предметно-ориентированный язык. В частности, вместо усердного метапрог
раммирования достаточно написать функции, выполняющие все необходимые
действия. На самом деле нечто подобное делается в
RSpec,
как показано ниже.
describe BowlingScore do
it "totals 12 if you score 3 four times" do
score = BowlingScore.new
4.times { score.add_pins(З) )
expect(score.total) .to eq(12)
end
end
В приведенном выше фрагменте кода
всего лишь методы языка
Ruby.
describe, i t, expect, to
и
eq -
это
И хотя в нем скрыт внутренний механизм пере
дачи объектов, это все же код. Более подробно этот вопрос рассматривается в
последующих упражнениях.
Другие разделы, связанные с данной темой
•
Тема
8.
•
Тема
13.
Прототипы и памятные записки.
•
Тема
32.
Конфигурирование, глава
Сущность качественного проектирования.
5
"Гибкость или ломкость".
Задачи
•
Можно ли выразить какое-нибудь требование к вашему текущему проекту на
предметно-ориентированном языке? И можно ли написать компилятор или
транслятор, способный сгенерировать большую часть требующегося кода?
Тема 14 • Предметно-ориентированные языки
•
99
Если вы решаете принять мини-языки как средство программирования
поближе к предметной области, то тем самым признаете, что для их реали
зации придется приложить некоторые усилия. Можете ли вы найтипути
для повторного применения в других проектах того каркаса, который раз
рабатываете в текущем проекте?
Упражнения
4.
Требуется реализовать мини -язык для управления простой системой чере
пашьей графики. Такой язык должен состоять из однобуквенных команд и
одиночных цифр, указываемых после некоторых из них. В качестве примера
применения такого языка ниже приведены входные команды для рисования
прямоугольника.
Р 2
D
W2
N1
Е 2
S 1
U
#
#
#
#
#
#
#
выбрать перо
2
опустить перо
нарисовать линию длиной
2
см в западном направлении
затем нарисовать линию длиной
далее нарисовать линию длиной
и,
наконец,
2
2
см в северном направлении
см в восточном направлении
провести линию обратно в южном направлении
поднять перо
Напишите код, реализующий синтаксический анализ команд этого мини -
языка. Он должен быть разработан таким образом, чтобы вводить новые
команды было просто.
5.
В предыдущем упражнении вам было предложено реализовать синтаксичес
кий анализатор для языка рисования, и это был внешний предметно-ориен
тированный язык. Теперь реализуйте его снова, но для внутреннего языка.
Постарайтесь не делать ничего заумного, а просто напишите функцию для
синтаксического анализа каждой команды. Вполне возможно, что вам при
дется изменить имена команд, обозначив их строчными буквами, а может
быть, и заключить их в какую-нибудь оболочку, чтобы предоставить опре
деленный контекст.
6.
Разработайте грамматику
BNF
(запись Бэкуса-Наура) для синтаксического
анализа формата времени. Для такого анализа должны быть приемлемы все
приведенные примеры формата времени.
4pm, 7:38pm, 23:42, 3:16, 3:16am
7.
Реализуйте на избранном вами языке синтаксический анализатор для грам
матики
PEG.
BNF из
предыдущего упражнения, используя генератор анализаторов
Такой анализатор должен выводить целое число, обозначающее коли
чество минут, прошедших после полуночи.
8.
Реализуйте синтаксический анализатор формата времени, используя язык
сценариев и регулярные выражения.
100
Глава 2 • Прагматичный подход
l1Щijfj ОцЕНИВАНИЕ
В Библиотеке Конгресса США в Вашингтоне хранится около
75
терабайт
цифровой информации, доступной в оперативном режиме. Любопытно, сколь
ко времени потребуется, чтобы переслать всю эту информацию по сети на ско
рости
1 Гбит/с?
А сколько памяти потребуется для хранения миллиона Ф.И.О.
и адресов? Сколько времени отнимет уплотнение
100
Мбайт текста? Наконец,
сколько месяцев вам потребуется, чтобы выпустить свой проект? Отвечайте,
живо!
В какой-то степени все эти вопросы бессмысленны, поскольку они содержат
недостаточно информации. И тем не менее на все эти вопросы вы можете найти
ответы, если умеете выполнять оценки. Более того, в процессе оценивания вы
сможете лучше понять среду, в которой обитают ваши программы.
Научившись оценивать и развивать в себе этот навык до такой степени, что
бы чувствовать величины оцениваемых вещей, вы сможете проявить кажущу
юся, на первый взгляд, волшебной способность определять их осуществимость.
Так, если кто-нибудь скажет: "Мы отправим резервную копию по сетевому со
единению в центральное хранилище': вы должны быть в состоянии интуитивно
почувствовать, насколько это практично. А когда вы программируете, вы долж
ны понимать, какой именно системе требуется оптимизация и какие системы
можно оставить в покое.
IG+t§fD
Выполняйте оценку, чтобы исключить неожиданности
В качестве поощрения приведем в конце этого раздела единственно правиль
ный ответ, который следует дать, если вас попросят что-нибудь оценить.
КАКОЙ точности ОЦЕНКИ ДОСТАТОЧНО?
Все ответы являются в той или иной мере оценками. Просто одни из них
более точные, чем другие. Поэтому первый вопрос, который вы должны выяс
нить, когда вас попросят оценить что-нибудь, связан с контекстом, в котором
вы должны дать свою оценку. В частности, требуется ли оценка с большой точ
ностью, или просящего о ней вполне удовлетворит приблизительное значение?
Оценивание любопытно, в частности, тем, что интерпретация его результатов
зависит от выбранных единиц измерения. Так, если вы скажете, что на какой
нибудь проект потребуется около
130
рабочих дней, то можно вполне предпо
ложить, что такая оценка достаточно точная. Но если вы скажете, что для этого
потребуется около шести месяцев, то такая оценка будет воспринята как весь
ма приблизительная
-
в пределах от пяти до семи месяцев. Обе упомянутые
Тема 15 • Оценивание
101
числовые оценки обозначают один и тот же срок, но первая из них, вероятно,
подразумевает большую точность, чем вы считаете. Поэтому мы рекомендуем
пользоваться приведенной ниже шкалой временных оценок.
Продолжительность
Оценка (порядок величин)
1-15 дней
Дни
3-6
недель
8-20
20
Недели
недель
Месяцы
и больше недель
Прежде чем оценивать, стоит хорошенько подумать
Итак, если вы, проделав всю необходимую работу, решите, что выполнение
проекта отнимет
125
рабочих дней
(25
недель), то вам придется дать оценку
"около шести месяцев''. По тому же принципу оцениваются любые другие вели
чины: выберите единицы измерения, отражающие точность, с которой вы на
мерены дать свою оценку.
ОТКУДА БЕРУТСЯ ОЦЕНКИ
Все оценки основываются на моделях решаемой задачи. Но прежде чем пе
рейти к подробному описанию методов построения таких моделей, следует
упомянуть простой прием оценивания, всегда дающий хорошие результаты:
спросите того, кто уже это делал. Следовательно, прежде чем строить модель,
поищите того, кто уже бывал в подобном положении, и выясните, как он решил
свою задачу. Вы вряд ли найдете решение, точно соответствующее вашей задаче,
но будете удивлены, как часто вы сможете обращаться к чужому опыту.
понимание того, что спрашивается
Первая часть любого упражнения в оценивании состоит в понимании того,
о чем именно спрашивают. Помимо рассмотренных выше вопросов, необходи
мо уяснить пределы предметной области. Нередко это подразумевается в самом
вопросе, но необходимо выработать в себе привычку обдумывать пределы, пре
жде чем строить догадки. Зачастую выбранные пределы составляют часть отве
та, например: "Если не произойдет никаких дорожных происшествий и топлива
в автомобиле окажется достаточно, я должен добраться до места за
20
минут''.
построение модели системь1
Это самая любопытная часть оценивания. Понимая то, о чем спрашивают,
можно приступить к построению приближенной элементарной модели. Так, если
вы оцениваете время реакции системы, ваша модель может включать в себя сер
вер и определенного рода входящий трафик. Для проекта моделью могут стать
те стадии разработки, которые принято использовать в вашей организации, а
102
Глава 2 • Прагматичный подход
также весьма приблизительное общее представление о том, каким образом сис
тема может быть реализована.
Построение модели может стать как творческим, так и полезным в долго
срочной перспективе процессом. Нередко процесс построения модели приво
дит к открытиям подспудных шаблонов и процессов, которые не были видны
на поверхности. Возможно, даже придется проанализировать первоначальный
вопрос заново, например: "Вы просили оценить компонент Х. Но похоже, что
компонент У как вариант компонента Х можно сделать в два раза быстрее, по
теряв лишь одно свойство".
Построение модели вносит неточности в процесс оценивания, и это неиз
бежно, хотя и приносит известную пользу. Вам приходится искать компромисс
между простотой и точностью модели. Так, удвоив усилия для проработки мо
дели, можно добиться лишь незначительного повышения ее точности. И здесь
опыт должен подсказать вам, когда следует остановиться, уточняя модель.
Разделение модели на комnоненть1
Как только модель будет построена, ее можно разделить на компоненты.
Для этого придется обнаружить математические правила, описывающие вза
имодействие компонентов. Иногда компонент привносит единственное значе
ние, добавляемое к конечному результату. Одни компоненты могут привносить
множественные факторы, тогда как другие могут быть более сложными, как,
например, те, которые имитируют поступление трафика в узел сети. Как прави
ло, у каждого компонента имеются свои параметры, оказывающие влияние на
его участие в общей модели. В таком случае на данной стадии следует просто
определить каждый параметр.
Присваивание значения каждому параметру
Как только будут определены все параметры, можно пройтись по ним, при
своив каждому соответствующее значение. На этом этапе можно ожидать вне
сения некоторого количества ошибок, поэтому следует выбрать те параметры,
которые оказывают наибольшее влияние на конечный результат, и сосредо
точить все внимание на том, чтобы они получили правильные значения. Как
правило, те параметры, значения которых добавляются к конечному результату,
менее важны, чем те, значения которых умножаются или делятся. Так, удвоение
скорости передачи данных в канале связи может привести к удвоению объема
данных, принимаемых в час, тогда как добавление транзитной задержки на
5 мс
не окажет заметного влияния.
Для расчета этих очень важных параметров следует иметь вполне обосно
ванный способ. Например, для оценивания проектируемой системы массового
обслуживания, возможно, придется измерить фактическую частоту поступле
ния транзакций в существующей системе или же найти аналогичную систему,
чтобы измерить данный параметр. Аналогично можно измерить текущее время
Тема 15 • Оценивание
103
обслуживания запроса или же оценить его, используя методы, описываемые в
этом разделе. В действительности свои оценки нередко приходится основывать
на других подоценках. Именно здесь и вкрадываются самые крупные ошибки.
Вычисление ответов
Лишь в самых простых случаях оценивание дает единственный ответ. Так,
вы можете, не моргнув глазом, заявить, что способны пройти пять городских
кварталов за
15
минут. Но по мере усложнения систем вам, вероятно, придется
давать более осторожные ответы. Проведите многократные вычисления, варьи
руя значения самых важных параметров до тех пор, пока не получите такие зна
чения, которые действительно приводят модель в действие. И здесь неоценимую
помощь могут оказать электронные таблицы. Затем сформулируйте свой ответ,
исходя из этих параметров, например: "Время реакции составляет приблизитель
но три четверти секунды, если в системе применяются твердотельные накопите
ли и оперативная память объемом
16
32
Гбайт, и одну секунду, если объем памяти
Гбайт': (Обратите внимание, насколько иное ощущение точности вызывает
формулировка "три четверти секунды" по сравнению с обозначением
750
мс.)
На стадии вычисления вы можете получить ответы, которые покажутся вам
странными, но не спешите их отвергать. Если ваши арифметические расчеты
правильны, вероятно, вы неверно понимаете стоящую перед вами задачу; воз
можно также, что неверна ваша модель. И это весьма ценная информация для
оценивания.
Проспеживанче своих способностей оценивать
Мы считаем, что вам стоит вести учет своих оценок, чтобы иметь возмож
ность выяснить, насколько они точны. Так, если для общей оценки требуется
вычислить подоценки, проследите и их. Зачастую оценки будут казаться вам
довольно хорошими, и со временем они, действительно, станут такими, как вы
ожидали.
Если оценка окажется неверной, не отмахивайтесь от нее и не уходите от от
вета, а лучше найдите причину. Вполне возможно, что вы выбрали такие пара
метры, которые не соответствуют действительности решаемой задачи, а может
быть, ваша модель оказалась неверной. Какова бы ни была причина, уделите
время, чтобы разобраться в произошедшем. И тогда следующая оценка окажется
лучше.
0ЦЕНИВАНИЕ СРОКОВ ВЫПОЛНЕНИЯ ПРОЕКТОВ
Как правило, вас могут попросить оценить, сколько времени отнимет работа
над чем-то конкретным. И если это нечто сложное, дать ему оценку, возможно,
будет нелегко. В этом разделе мы рассмотрим два метода, позволяющих умень
шить неопределенность, проявляющуюся в подобных случаях.
104
Гnава 2 • Прагматичный подход
покраска ракеmь1
-
Сколько времени потребуется, чтобы покрасить дом?
-
Ну, если все будет нормально и расход этой краски окажется таким,
как заявлено производителем, то может потребоваться не меньше
1О
часов, хотя это маловероятно. Думаю, что более реалистичная оценка
ближе к
18
часам. И, конечно, если погода испортится, то работа мо
жет растянуться до
30
часов, а то и больше.
Именно таким образом люди обычно оценивают окружающую их реальность,
т.е. целым рядом возможных вариантов, а не одним числом, если только не при
нудить их дать именно такую оценку. Коrда ВМС США потребовалось сплани
ровать проект баллистической ракеты "Поларис" для атомных подводных лодок,
был принят именно такой порядок оценивания по так называемой методолоrии
PERT (Program Evaluation and Review Technique - Метод оценки и анализа про
ектов). По методолоrии PERT каждая задача получает оптимистическую, наибо
лее вероятную и пессимистическую оценки. Все задачи орrанизованы в rраф за
висимостей, а для выявления самых оптимистичных и пессимистичных сроков
выполнения работ во всем проекте используется простая статистика.
Используя такую область значений, удается блаrополучно избежать самой
распространенной причины ошибок при оценивании: раздувания цифр из-за
неуверенности. Вместо этого статистика по методолоrии
PERT
распределяет не
определенность автоматически, позволяя точнее оценить проект в целом.
Тем не менее мы не являемся страстными поклонниками такой методолоrии.
Ведь разработчики привыкли рисовать едва ли не на всю стену диаrраммы всех
задач в проекте, неявно полаrая, что имеют
ero
точную оценку просто потому,
что они воспользовались какой-то формулой. И если они никогда не делали это
го прежде, то, скорее всего, точную оценку они не получат.
поедание слона
Мы считаем, что составить календарный план проекта можно лишь на осно
вании опыта работы над тем же самым проектом. И в этом не будет никакоrо
парадокса, если практиковать поэтапную разработку, повторяя шаrи перечис
ленной ниже процедуры, на которых функциональные возможности внедряются
очень тонкими слоями.
•
Проверить требования.
•
Проанализировать риски (начав с самых рискованных элементов).
•
Спроектировать, реализовать, интеrрировать.
•
Проверить правильность с помощью пользователей.
Поначалу у вас может сложиться лишь смутное представление, сколько раз
придется повторить данную процедуру и как долrо это может продолжаться.
Тема 15 • Оценивание
105
И хотя некоторые методы требуют закрепить ее как часть первоначального пла
на, на самом деле это будет ошибкой во всех проектах, кроме самых тривиаль
ных. Ведь вам придется просто гадать, если только вы не разрабатывали прежде
аналогичное приложение с той же самой командой.
Итак, завершив кодирование и тестирование первоначальных функциональ
ных возможностей, отметьте это как окончание первого шага повторяющейся
процедуры. Основываясь на приобретенном опыте, вы сможете теперь уточнить
первоначальное предположение о количестве последующих шагов и о том, что
следует включить в каждый из них. С каждым разом уточнение становится все
лучше и вместе с тем растет уверенность в правильности графика выполнения
работ. Такого рода оценивание нередко выполняется во время подведения ко
мандой итогов в конце повторяющегося цикла. И это еще раз подтверждает ста
рую шутку: слона нужно есть по кусочкам.
Повторно уточняйте график выполнения работ
по мере написания кода
Такой метод оценивания может и не найти признания у руководства, ко
торому, как правило, требуется точное число еще до начала проекта. Поэтому
вы должны объяснить руководству, что именно состав команды, ее произво
дительность и среда будут определять график выполнения работ. Формализуя
это положение и уточняя график на каждом шаге повторяющейся процедуры,
вы сумеете дать руководству самую точную оценку планирования работ, какую
только сможете.
Что ОТВЕТИТЬ НА ПРОСЬБУ ЧТО-НИБУДЬ ОЦЕНИТЬ
На это следует ответить: "Вернемся к этому позже". Если вы замедлите про
цесс, уделив время прохождению всех шагов описанной выше процедуры, то
почти всегда сможете добиться лучших результатов. А оценки, данные мимохо
дом за чашкой кофе, будут еще не раз навещать и тревожить вас.
Другие разделы, связанные с данной темой
•
Тема
7.
•
Тема
39.
Общайтесь!, глава
1 "Философия
прагматизма".
Быстродействие алгоритма, глава
7 "По
ходу кодирования':
Задачи
•
Начните вести журнал своих оценок. Проследите за тем, насколько точной
оказалась каждая из них. Если допущенная вами ошибка превысила
постарайтесь выяснить, в чем именно она оказалась неверной.
50%,
106
Гпава 2 • Прагматичный подход
Упражнения
9.
Представьте, что к вам обратились со следующим вопросом: "Чья пропуск
ная способность выше: сетевого соединения на скорости
ловека, перемещающегося
между двумя компьютерами
с
1
Гбит/с или че
запоминающим
устройством емкостью 1 Тбайт в своем кармане?" Какие ограничения вы
наложите на свой ответ, чтобы дать его в правильных пределах? (Вы може
те, например, сказать, что временем доступа к запоминающему устройству
можно пренебречь.)
10.
Так чья же пропускная способность выше?
Глдвд
3
ОсновныЕ
Каждый мастер начинает свое ремесло с основного набора качественных ин
струментов. В частности, столяру могут потребоваться линейки, уровни, пилы,
качественные рубанки, тонкие долота, сверла и скрепы, киянки и струбцины.
Эти инструменты тщательно подбираются, чтобы служить долго для выполне
ния особых работ вместе с другими инструментами, а самое, возможно, глав
ное
-
чтобы столяру было удобно работать с ними, держа их в своих пока еще
неумелых руках.
Затем начинается процесс обучения работе с инструментами и приспосаб
ливания к ним. Ведь у каждого инструмента свои свойства и особенности, а
следовательно, он требует особого обращения. Каждый инструмент нужно по
особому заточить и соответственно держать в руках. Со временем все инстру
менты изнашиваются, вплоть до того, что их рукоятка напоминает отпечаток
руки столяра, а режущая кромка идеально совпадает с углом, под которым он
держит свой инструмент. И в этот момент инструменты превращаются в про
водников замыслов, возникающих в уме мастера, доводя их до готового изделия
и становясь как бы продолжением его рук. Постепенно столяр пополняет свой
арсенал новыми инструментами, в том числе ламельными фрезерными станка
ми, торцовочными пилами с лазерным наведением, шаблонами под "ласточкин
хвост" и прочими чудесами техники деревообработки. Но можно не сомневать
ся, что столяру будет намного приятнее работать с одним из своих первых ин
струментов, держа его в руках и чувствуя, например, как рубанок буквально
поет, скользя по дереву.
Инструменты развивают ваши способности. Чем они лучше, и чем лучше вы
знаете, как ими пользоваться, тем выше может стать производительность ваше
го труда. Начните с простого набора инструментальных средств, подходящих в
общем случае. По мере обретения опыта обращения с ними и появления каких
то особых требований вы будете постепенно пополнять этот простой набор но
выми средствами. Как и любому другому мастеру, вам придется делать это
pery-
108
Глава 3 , Основные инструментальные средства
лярно, поэтому старайтесь всегда искать лучшие способы делать свое дело. Если
же возникнет ситуация, с которой текущие инструментальные средства, на ваш
взгляд, не справятся, сделайте себе заметку, чтобы поискать какое-нибудь дру
гое или более эффективное инструментальное средство, которое поможет вам
справиться с данной ситуацией. Пусть вашими приобретениями правит нужда.
Многие начинающие программисты совершают ошибку, останавливая свой
выбор лишь на одном эффективном инструментальном средстве (например, на
конкретной интегрированной среде разработки), так и не покидая его удобный
интерфейс. А вы должны чувствовать себя уверенно и за пределами конкрет
ной интегрированной среды разработки. И достичь этого можно единственным
способом, храня свой набор простых инструментальных средств в постоянной
готовности к применению.
В этой главе речь пойдет об инвестировании в собственный набор простых
инструментальных средств. Как и любое грамотное обсуждение инструменталь
ных средств, мы начнем (в следующем разделе) с рассмотрения исходных мате
риалов, которые требуется облечь в нужную форму. А далее мы перейдем к вер
стаку (в нашем случае
-
к компьютеру), чтобы выяснить, как пользоваться им,
чтобы извлечь наибольшую пользу из инструментальных средств. Подробнее об
этом
-
в разделе "Игры в скорлупки". И как только в нашем распоряжении ока
жется сырьевой материал и станок для его обработки, мы обратимся к одному
из наиболее употребительных инструментов (в данном случае
-
к текстовому
редактору). Так, в разделе "Эффективное редактирование" предлагаются спосо
бы, повышающие эффективность труда программиста.
Чтобы не утратить ничего из своей ценной работы, мы должны всегда поль
зоваться системой контроля версий
-
даже для таких личных документов, как
рецепты или заметки. А поскольку Мерфи был все же оптимистом, несмотря на
сформулированные им пессимистические законы, то нельзя стать грамотным
программистом до тех пор, пока не приобретешь превосходные навыки отладки
исходного кода.
Чтобы скрепить все чудесное вместе, потребуется нечто вроде клея. Некото
рые возможности добиться этого рассматриваются в разделе "Манипулирование
текстом". Наконец, самые бледные чернила лучше, чем самая хорошая память.
Поэтому ведите учет своих мыслей и предыстории, как поясняется в разделе
"Технические дневники':
Уделяя время изучению всех упомянутых выше инструментальных средств,
вы однажды с удивлением обнаружите, как ваши пальцы перемещаются по кла
виатуре, безотчетно манипулируя текстом. И это будет означать, что применяе
мые вами инструменты стали продолжением ваших рук.
Тема 16 • Сила простого текста
109
llJttмQ (ИЛА ПРОСТОГО ТЕКСТА
Будучи программистами-прагматиками, мы выбираем в качестве исходного
материала не дерево и не железо, а знания. Сначала мы собираем требования
как знания, а затем выражаем эти знания в своих проектных решениях, реа
лизациях, тестах и документах. И мы считаем, что наилучшим форматом для
постоянного хранения данных является простой текст. Благодаря простому
тексту мы получаем возможность манипулировать знаниями как вручную, так и
программно, пользуясь буквально каждым инструментальным средством, име
ющимся в нашем распоряжении.
Но трудности обращения с большинством бинарных форматов состоят в том,
что контекст, требующийся для понимания данных, отделен от самих данных,
и тогда они искусственно отторгаются от своего смыслового значения. Кроме
того, данные могут быть зашифрованы, и поэтому анализировать их без при -
кладной логики совершенно бессмысленно. Тем не менее простой текст дает
возможность получить поток самостоятельно описываемых данных независимо
от того приложения, в котором он создан.
Что ТАКОЕ ПРОСТОЙ ТЕКСТ
Простой текст состоит из печатных символов в форме, передающей ин
формацию. Это может быть, например, простой список покупок, аналогичный
приведенному ниже, или же сложный текст, подобный рукописи данной книги.
(Она действительно набрана простым текстом к явному неудовольствию издате
ля, которому хотелось бы, чтобы мы пользовались для этого специализирован
ным текстовым редактором.)
*
*
молоко
*
кофе
сахар
И здесь важна информационная часть. Так, следующая строка простого текста вряд ли принесет какую-то пользу:
hlj;uijn bfjxrrctvh
jkni'pioбp7gu;vh
bjxrdi5rgvhj
Как, впрочем, и эта строка:
Fieldl9=467abe
Ведь читающий ее понятия не имеет, в чем смысл значения
4 6 7 аЬе.
Поэтому
мы стараемся сделать набираемый нами простой текст удобочитаемым.
Храните свои знания в виде простого текста
11 О
8
Гnава 3 , Основные инструментаnьные средства
ЧЕМ СИЛА ПРОСТОГО ТЕКСТА
Простой текст совсем не означает, что сам он не структурирован.
JSON, YAML
HTML,
и все аналогичные форматы служат примерами простого текста,
как, впрочем, и большинство основных сетевых протоколов, в том числе НТТР,
SMTP, IMAP
и т.д. И для этого имеется ряд веских оснований, включая следу
ющие.
•
Гарантия от устаревания.
•
Эффективное использование инструментальных средств.
•
Упрощение тестирования.
Гарантия от устаревания
Удобочитаемые формы данных и описывающие сами себя данные, несомнен но, переживут все остальные формы данных и те приложения, в которых они
сформированы. А раз они уцелеют, то есть шанс воспользоваться ими даже че
рез много времени после того, как перестанет функционировать первоначальная
версия приложения, в котором они были сформированы. Такого рода файл дан
ных можно проанализировать, зная лишь частично его формат. Что же касается
большинства бинарных файлов, то для успешного их анализа необходимо знать
во всех подробностях их формат.
Рассмотрим в качестве примера файл данных из устаревшей системы 1 , кото
рую вам дали сопровождать. Исходно вам мало что известно об ее первоначаль
ной версии, помимо того, что в ней ведется список номеров социального обес
печения клиентов, который требуется найти и извлечь. Среди прочих данных вы
обнаруживаете следующее:
123-45-6789
567-89-0123
901-23-4567
Распознав формат номера социального обеспечения, вы можете быстро на
писать небольшую программу для извлечения данных из файла, даже если вам
больше ничего не известно о другом его содержимом.
Но представьте, что файл отформатирован иначе
-
например, так, как по
казано ниже.
АС27123456789В11Р
XY43567890123QTYL
6Т2190123456788АМ
1 Все
программное обеспечение устаревает в момент его написания.
Тема 16 • Сила простого текста
111
Вполне возможно, что вам не удастся легко распознать смысловое значение
приведенных выше чисел. В этом, собственно, и состоит отличие удобочитае
мого содержимого файлов от неудобочитаемого. Тем не менее содержимое поля
FIELDlO в рассматриваемом здесь файле мало чем помогает уяснить его смыс
ловое значение. А вот приведенный ниже формат делает его намного более по
нятным, гарантируя, что такие данные переживут тот проект, в котором они
сформированы.
l23-45-6789
Эффективное использование инструментальных средств
Буквально каждое инструментальное средство в области вычислений (от сис
темы контроля версий до утилит командной строки) может оперировать простым
текстом. Допустим, вы развертываете крупное приложение в условиях его эксплу
атации с помощью специального файла конфигурации. Если этот файл содержит
простой текст, вы можете заменить его в системе контроля версий (см. далее раз
дел "Тема
19.
Контроль версий"), чтобы автоматически отслеживать предысторию
всех изменений. С помощью таких средств сравнения файлов, как, например, ути
литы
diff
и
fc,
вы можете сразу выяснить, какие именно изменения были вне
сены, тогда как утилита
s um
поможет сформировать контрольную сумму, чтобы
проверить файл на предмет случайной (или злонамеренной) модификации.
ФилосоФия Uм1х
Как известно, операционная система
утилит
-
Unix
спроектирована по принципу
небольших заточенных инструментов, каждый из которых пред
назначен для выполнения одной конкретной операции. Этот основной при
нцип позволяет использовать общий базовый формат файлов с простым
построчно расположенным текстом. Все базы данных, используемые в Unix
для системного администрирования (пользователей и паролей, конфигура
ции сети и т.д.), организованы в виде файлов с простым текстом. (Ради оп
тимизации в некоторых системах поддерживается также бинарная форма
определенных баз данных. При этом версия базы данных в простом тексте
хранится для сопряжения с ее бинарной версией.)
Если система выйдет из строя, для ее восстановления, возможно, придет
ся иметь дело с минимальной средой, не имея, например, доступа к графи
ческим драйверам. В подобных случаях можно по достоинству оценить не
сложность простого текста.
Кроме того, простой текст проще для поиска. Так, если вы не помните, какой
именно файл конфигурации управляет созданием резервных копий систе
мы, команда
qrep -r backup /etc
поможет вам быстро найти его.
Глава 3 • Основные инструментальные средства
112
Упрощение тестирования
Если вы пользуетесь простым текстом, чтобы сформировать синтетические
данные для тестирования системы, в таком случае вам достаточно ввести, об
новить или модифицировать тестовые данные, даже не создавая для этого спе
циальные инструментальные средства. Аналогично результаты регрессионного
тестирования, выведенные простым текстом, совсем не трудно проанализиро
вать с помощью команд оболочки или простого сценария.
НАИМЕНЬШИЙ ОБЩИЙ ЗНАМЕНАТЕЛЬ
Вездесущие текстовые файлы понадобятся даже в будущих интеллектуаль
ных агентах на основе блокчейна, автономно перемещающихся в дикой и опас
ной среде Интернета, для согласования обмена данными. В действительности
преимущества простого текста в гетерогенных средах перевешивают все их не
достатки. Нужно лишь обеспечить общение всех сторон по общему стандарту.
И таким стандартом является простой текст.
Другие разделы, связанные с данной темой
•
Тема
17.
Игры в скорлупки.
•
Тема
21.
Манипулирование текстом.
•
Тема
32.
Конфигурирование, глава
5 "Гибкость
или ломкость".
Задача
•
Спроектируйте на избранном вами языке небольшую базу данных для хра
нения адресной книги (Ф.И.О., номера телефонов и т.д.), используя про
стое бинарное представление. Сделайте это, прежде чем читать остальную
часть этой задачи.
-
Преобразуйте данный формат в простой текст формата
-
Добавьте для каждой версии новое поле переменной длины
XML
или
JSON.
directions,
в котором можно было бы ввести направления к дому каждого лица,
указанного в адресной книге.
Какие вопросы, связанные с контролем версий и расширяемостью, у вас
возникнут? Какую форму легче видоизменить? А как насчет преобразова
ния имеющихся данных?
Тема 17 • Иrры в скорлупки
113
llMIU ИГРЫ в СКОРЛУПКИ
Каждому столяру требуется хороший, прочный и надежный верстак, где
можно было бы закрепить заготовки на такой высоте, чтобы их было удобно об
рабатывать. Таким образом, верстак становится центром столярной мастерской,
в которую мастер будет периодически возвращаться по мере того, как заготовка
станет приобретать нужную форму.
Для программиста, манипулирующего текстовыми файлами, таким верста
ком служит командный процессор, иначе называемый просто оболочкой. По
приглашению из командной строки оболочки можно вызывать весь арсенал
инструментальных средств, объединяя их с помощью конвейеров так, как это и
не снилось их разработчикам. Из оболочки можно также запускать приложения,
отладчики, браузеры, редакторы и утилиты, искать файлы, запрашивать состо
яние систем и фильтровать выводимые результаты. Программируя на уровне
оболочки, можно строить сложные макрокоманды для автоматизации часто вы
полняемых действий.
Для программистов, привыкших работать с использованием графических
интерфейсов пользователя и интегрированных сред разработки, такой вариант
может показаться крайним. Поэтому у них может возникнуть вполне резонный
вопрос: нельзя ли одновременно пользоваться как оболочкой для ввода команд,
так и графическим интерфейсом пользователя для манипулирования мышью?
Самый простой ответ на этот вопрос отрицательный.
GUI,
безусловно, при
мечательны тем, что позволяют быстрее и удобнее выполнять простые опера
ции. Перемещение файлов, чтение и запись сообщений электронной почты,
построение и развертывание проекта
-
все эти операции обычно требуется
выполнять в графической среде. Но если делать всю свою работу только в гра
фическом интерфейсе пользователя, то вряд ли удастся раскрыть полностью
истинный потенциал своей рабочей среды и, в частности, автоматизировать ти
пичные задачи или использовать весь потенциал доступных инструментальных
средств, а также объединять их, создавая специализированные макрокомандь1.
Главное преимущество графического интерфейса пользователя заключается в
том, что он действует по принципу
WYSIWYG (what you see is what you get -
что видишь, то и получишь). Но главным его недостатком является принцип
WYSIAYG (what you see is all you get -
получишь лишь то, что видишь).
Возможности графических сред, как правило, ограничиваются теми целями,
которые преследовали их разработчики. Если же требуется выйти за переде
лы той модели поведения графической среды, которая была предусмотрена ее
разработчиками (что требуется чаще, чем хотелось бы), то сделать это вряд ли
удастся. Программисты-прагматики не просто специализируются на написании
кода, разработке объектных моделей или составлении документа, а делают все
это сами. Область действия любого инструмента обычно ограничивается теми
114
Глава 3 • Основные инструментальные средства
задачами, для выполнения которых он предназначен. Допустим, в интегриро
ванную среду разработки требуется встроить препроцессор кода, чтобы реали
зовать принципы проектирования по контракту или многопоточной обработки.
Сделать это не удастся, если разработчик интегрированной среды разработки не
предоставил явно соответствующие функциональные возможности .
Используйте всю мощь командных оболочек
Освойте оболочку как следует, и производительность вашего труда не за
медлит резко возрасти. Так, если требуется составить список всех однозначных
имен пакетов, явно импортируемых в коде
list
Java,
его можно сохранить в файле
с помощью следующей команды, вызываемой из оболочки:
Такая команда может выглядеть пугающе, если вы не уделяли должного вре
мени изучению функциональных возможностей командных оболочек тех сис
тем, которыми пользуетесь. Все же немного потрудитесь, чтобы поближе озна
комиться с доступной вам командной оболочкой, и вскоре все станет на свои
места. Поэкспериментировав с ней, вы с удивлением обнаружите, насколько
возрастет производительность вашего труда.
ВАША СОБСТВЕННАЯ ОБОЛОЧКА
Подобно тому, как столяр упорядочивает свое рабочее место и подгоняет его
под себя, разработчик должен специально настроить свою оболочку. Как прави
ло, это подразумевает также изменение конфигурации применяемой терминаль
ной программы. Ниже перечислены типичные изменения, которые требуется
внести при этом.
•
Установка цветовых тем. Опробование каждой такой темы, доступной
в оперативном режиме для конкретной оболочки, может отнять немало
времени.
•
Настройка приглашения. Приглашение, которое сообщает о готовности
оболочки к вводу команд, можно настроить на отображение лишь самой
необходимой информации, поскольку остальная его часть вряд ли вообще
понадобится. И здесь явно проявляются личные предпочтения. Нам, на
пример, больше нравятся простые приглашения, где в укороченной форме
указано имя текущего каталога, текущая версия оболочки и время.
Тема 17 • Игры в скорлупки
•
115
Псевдонимы и функции оболочки. Упростите свой рабочий процесс, пре
образовав в простые псевдонимы те команды, которыми вы часто пользу
етесь. Так, если вы регулярно обновляете свою платформу
Linux,
но в то
же время можете забыть, в какой именно последовательности следует это
делать: обновлять и модернизировать или же модернизировать и обнов
лять, создайте для данной цели псевдоним, как показано ниже.
alias apt-up='sudo apt-get update && sudo apt-get upgrade'
Если вы случайно удалили файлы командой
rm,
отметив, что делаете это
слишком часто, создайте на будущее следующий псевдоним, чтобы всегда
выводить соответствующее приглашение:
alias rm ='rm -iv'
•
Автозавершение комаиц. В большинстве оболочек поддерживается авто
завершение команд и файлов: достаточно набрать несколько первых сим
волов, нажать клавишу табуляции, и оболочка постарается автоматичес
ки завершить ввод той команды, которую вы подразумеваете. Но можно
пойти еще дальше, настроив оболочку таким образом, чтобы распознавать
вводимые команды, предлагая контекстно-зависимые варианты их завер
шения, а иногда даже делая это в зависимости от текущего каталога.
Вам придется немало времени работать в одной из таких оболочек 2 • Будьте
как рак-отшельник, сделав оболочку своим обиталищем.
Другие разделы, связанные с данной темой
2 "Прагматичный
•
Тема
13.
Прототипы и памятные записки, глава
•
Тема
16.
Сила простого текста.
•
Тема
21.
Манипулирование текстом.
•
Тема
30.
Преобразовательное программирование, глава
5
подход".
"Гибкость или
ломкость".
•
Тема
51.
Начальный набор инструментальных средств программиста-праг
матика, глава
9
"Прагматичные проекты':
Задачи
•
Есть ли какие-нибудь операции, которые вы в настоящее время выполняе
те в
GUI?
Даете ли вы своим коллегам какие-то инструкции, включающие
в себя такие действия, как, например, "щелкни на этой кнопке" или "выбе
ри этот элемент"? Можно ли их как-то автоматизировать?
•
Всякий раз, когда вы переходите в новую среду, постарайтесь выяснить,
какие в ней имеются командные оболочки и не удастся ли вам перенести
свою текущую оболочку в новую среду.
2
Игра слов: shell (англ.) - оболочка, ракушка. - Примеч.пер.
Гnава 3 • Основные инструментаnьные средства
116
•
Изучите альтернативы своей текущей оболочке. Если окажется, что ваша
командная оболочка не справляется со своими обязанностями, выясните,
сможет ли справиться с ними лучше альтернативная оболочка.
lйЫji:t ЭФФЕКТИВНОЕ РЕДАКТИРОВАНИЕ
Как упоминалось ранее, рабочие инструменты являются продолжением рук
мастера. И это относится к текстовым редакторам даже в большей степени, чем
к любым другим программным средствам. Ведь у вас должна быть возможность
манипулировать текстом, прилагая как можно меньше усилий, поскольку текст
служит сырьевым материалом для программирования.
В первом издании этой книги мы настоятельно рекомендовали пользоваться
одним и тем же редактором для выполнения самых разных операций: програм
мирования, документирования, памятных записок, системного администриро
вания и т.д. Но теперь мы немного смягчили свою позицию, рекомендуя исполь
зовать сколько угодно редакторов, поскольку сами стремимся умело работать с
текстом в каждом из них.
IЗфI§fD
Стремитесь свободно владеть редактором
Почему это так важно? Не хотим ли мы просто сказать о том, что это сэконо
мит нам массу времени? По сути, да: ведь за год вы сможете сэкономить целую
неделю, повысив эффективность редактирования текста лишь на
нечно, вам приходится делать это по
20
4%
(если, ко
часов в неделю).
Но настоящая выгода состоит даже не в этом, а в том, чтобы, научившись
свободно владеть редактором, вы больше не задумывались о самом механизме
редактирования. Благодаря этому сокращается промежуток между осмыслением
чего-нибудь и появлением результата в буфере редактора. От этого ваше програм
мирование только выигрывает, поскольку поток ваших мыслей не прерывается.
(Если вам приходилось учить кого-нибудь вождению автомобиля, то вы хорошо
знаете, насколько начинающий водитель, обдумывающий каждое свое действие,
отличается от опытного водителя, интуитивно управляющего автомобилем.)
Что ОЗНАЧАЕТ СВОБОДНОЕ ВЛАДЕНИЕ РЕДАКТОРОМ
Ниже перечислены задачи редактирования текста, которые проясняют, что
значит свободно владеть редактором.
•
Перемещение и выделение теста по отдельным символам, словам, строкам
и абзацам.
Тема 18 • Эффективное редактирование
•
117
Перемещение различных синтаксических единиц (совпадающих ограничи
телей, функций, модулей и т.д.)
•
Повторное форматирование исходного кода с отступами после внесения
изменений.
•
Комментирование и раскомментирование блоков кода одной командой.
•
Отмена и повторизменений.
•
Разбиение окна редактора на несколько панелей и перемещение между
ними.
•
Перемещение на строку с конкретным номером.
•
Сортировка выбранных строк.
•
Поиск как по символьным строкам, так и по регулярным выражениям и
повторение предыдущего поиска.
•
Временное создание нескольких курсоров по выделенному тексту или
совпадению с шаблоном и параллельное редактирование текста в позиции
каждого курсора.
•
Отображение ошибок компиляции в текущем проекте.
•
Выполнение тестов в текущем проекте.
Сможете ли вы сделать все это, не пользуясь мышью, сенсорной панелью или
иным координатно-указательным устройством? Конечно, вы можете сказать, что
текущий редактор не позволяет выполнить некоторые из перечисленных выше
задач. В таком случае вам, может быть, стоит сменить редактор?
СТРЕМЛЕНИЕ К СВОБОДНОМУ ВЛАДЕНИЮ РЕДАКТОРОМ
Мы не сомневаемся, что найдется больше десятка людей, знающих все коман
ды в конкретном эффективном редакторе, но в то же время готовы предполо
жить, что вы к их числу не относитесь. Поэтому предлагаем более прагматичный
подход: изучить те команды редактора, которые упрощают работу с текстом.
Рецепт этого довольно прост. Сначала проанализируйте свои действия во
время редактирования. Всякий раз, когда вы ловите себя на том, что делаете
что-нибудь повторяющееся, выработайте в себе привычку обдумать и найти
лучший способ сделать это.
Как только вы обнаружите новое полезное средство, непременно освойте его
вплоть до автоматизма, чтобы пользоваться им, не задумываясь. Этого можно
добиться лишь многократным повторением. Сознательно ищите возможности
применить свои вновь приобретенные сверхнавыки (в идеальном случае
-
мно
го раз в течение рабочего дня). И через неделю или около того вы сможете поль
зоваться ими, даже не задумываясь.
118
Глава 3 • Основные инструментальные средства
Расширение возможностей редактора
Большинство эффективных редакторов исходного кода построены на ядре,
наращиваемом посредством расширений. Некоторые расширения поставляются
вместе с редактором, тогда как другие могут быть внедрены впоследствии.
Если вы натолкнетесь на какое-то очевидное ограничение применяемого
вами редактора, поищите его расширение, позволяющее преодолеть это огра
ничение. Вероятнее всего, такие функциональные возможности требуются не
только вам, и вполне возможно, что кто-нибудь уже опубликовал свое решение
данной задачи.
Не останавливаясь на этом, можете даже освоить язык расширений своего
редактора. Научитесь пользоваться им для автоматизации некоторых часто пов
торяемых вами операций. Зачастую для этого потребуется лишь одна или две
строки кода.
Иногда можно пойти еще дальше, самостоятельно написав полноценное рас
ширение. В таком случае опубликуйте его. Ведь если оно понадобилось вам, то,
скорее всего, понадобится и другим.
Другие разделы, связаннь1е с данной темой
•
Тема
7.
Общайтесь!, глава
1 "Философия
прагматизма':
Задачи
•
Откажитесь от автоповторов. Все привыкли делать следующее: нажимать
клавишу
,
ожидая автоповтора, чтобы удалить последнее на
бранное слово. Можем побиться об заклад, что вы уже поднаторели делать
это в уме настолько, что можете точно рассчитать, когда отпустить данную
клавишу. Поэтому отключите режим автоповтора, а вместо него освойте
комбинации клавиш для перемещения, выбора и удаления символов, слов,
строк и блоков.
•
Этот способ дается нелегко. Отставьте мышь или иное координатно-ука
зательное устройство в сторону, чтобы целую неделю редактировать текст
только с помощью клавиатуры. В итоге вы обнаружите, что немало опе
раций манипулирования текстом вы в состоянии выполнять, не наводя
курсор и не щелкая кнопкой мыши. Но этому нужно учиться, поэтому за
писывайте комбинации клавиш, которые осваиваете, старым и надежным
способом, используя карандаш и бумагу.
•
В первые дни это заметно скажется на производительности вашего тру
да. Но, учась манипулировать текстом так, чтобы не убирать свои руки
из исходного положения на клавиатуре, вы постепенно обнаружите, что
редактируете текст быстрее и свободнее, чем раньше.
Тема 19 • Контроль версий
•
119
Ищите пути для интеграции. Когда Дэйв писал эту главу, его посетила
мысль: а нельзя ли предварительно просмотреть окончательную ее компо
новку (файл формата
PDF)
в буфере редактора. И как только он нашел и
загрузил подходящее расширение, предварительно просматриваемый вид
окончательной компоновки тотчас расположился рядом с текстом рукопи
си в том же самом текстовом редакторе. Итак, составьте список функцио
нальных возможностей, которыми вы хотели бы расширить свой редактор,
а затем поищите их.
•
Если вам не удастся найти подходящее расширение или подключаемый
модуль, напишите его, хотя это более честолюбивая задача. Энди нравит
ся создавать специальные, локальные файловые модули, подключаемые к
его излюбленным редакторам для составления вики-страниц. Если вам не
удастся найти такой подключаемый модуль, создайте его сами!
ltjДjQ КОНТРОЛЬ ВЕРСИЙ
"Прогресс не проявляется лишь в изменениях и зависит
от памятливости. Те, кто не учится на своих ошибках,
обречены повторять их".
Джордж Сантаяна, 3 Жизнь разума
(Life of Reason)
К числу самых востребованных элементов пользовательского интерфейса от
носится кнопка отмены
-
как единственная возможность исправления ошиб
ки. Еще лучше, если в рабочей среде поддерживается несколько уровней отмены
и повтора, чтобы можно было вернуться к тому, что было сделано пару минут
назад.
Но что, если ошибка была совершена на прошлой неделе, и с тех пор компью
тер неоднократно включался и выключался? Именно в таких случаях и прояв
ляется одно из многих преимуществ системы контроля версий как гигантской
кнопки отмены, которая, словно машина времени, позволяет вернуться к той
благополучно завершенной на прошлой неделе стадии проекта, когда исходный
код компилировался и выполнялся.
Многие разработчики ограничиваются именной этой возможностью, поль
зуясь системой контроля версий. Они упускают из виду всю намного более об
ширную область
ошибок и общего взаимодействия членов команды. Поэтому рассмотрим систе
му контроля версий сначала как хранилище изменений, а затем как центральное
место встреч, где члены команды встречаются со своим исходным кодом.
3
George Santayana - американский философ и писатель ХХ века испанского происхож
- Примеч. пер.
дения.
120
Глава 3 • Основные инструментальные средства
Совместно ИСПОЛЬЗУЕМЫЕ КАТАЛОГИ - это НЕ СИСТЕМА КОНТРОЛЯ ВЕРСИЙ
Нам до сих пор встречаются иногда такие команды, которые обмениваются
исходными файлами своих проектов по сети: как внутренним образом, так и
с помощью определенного рода облачного хранилища. Но это непрактично.
Команды, поступающие подобным образом, приводят работу друг друга
в полный беспорядок, теряют изменения и нарушают сборки, словно идя
стенка на стенку за место на парковке автомобилей. Это можно сравнить
с написанием параллельного кода с совместно используемыми данными и
без механизма синхронизации. Вместо этого лучше пользоваться системой
контроля версий.
Более того, некоторые разработчики пользуются системой контроля вер
сий, организуя ее основной репозиторий в сети или в облачном хранилище.
Они считают такое решение обоюдовыгодным, поскольку их файлы доступ
ны отовсюду и резервируются в удаленном месте (если речь идет об облач
ном хранилище).
На самом же деле это еще хуже, поскольку есть риск потерять все. В систе
ме контроля версий применяется ряд взаимодействующих файлов и катало
гов, и если изменения вносятся одновременно в два экземпляра, то общее
их состояние может быть нарушено, а о степени нанесенного ущерба ниче
го ·не сообщается. Вряд ли кому-нибудь будет приятно видеть, как разработ
чики воют от отчаяния.
ВСЕ НАЧИНАЕТСЯ С ИСХОДНОГО КОДА
Системы контроля версий следят за каждым изменением, вносимым в исход
ный код и документацию . Настроив такую систему надлежащим образом, мож
но всегда вернуться к предыдущей версии своего программного обеспечения .
Но возможности системы контроля версий далеко не ограничиваются отме
ной ошибок. Хорошая система контроля версий позволяет отслеживать вноси мые изменения , отвечая на такие вопросы, как, например, следующие: кто внес
изменения в конкретной строке кода, чем текущая версия отличается от той,
что была на прошлой неделе, какие файлы изменяются чаще всего? Такого рода
сведения бесценны для целей отслеживания программных ошибок, ревизии, по
вышения производительности и качества .
Кроме того, система контроля версий позволяет идентифицировать выпуски
программного обеспечения . Указав конкретную выпускаемую версию, можно
всегда вернуться и сформировать ее снова, сделав это независимо от внесен
ных впоследствии изменений. Системы контроля версий позволяют отслежи-
Тема 19 • Контроль версий
121
вать файлы, хранящиеся в центральном репозитории, вполне подходящем для
архивирования.
Наконец, системы контроля версий дают двум или большему количеству
пользователей возможность работать параллельно над одним и тем же рядом
файлов и даже вносить одновременные изменения в один и тот же файл. Систе
ма контроля версий сама объединит эти изменения, когда файлы будут отправ
лены обратно на хранение в репозиторий. Несмотря на кажущийся риск, такие
системы вполне пригодны для практического применения в проектах любых
масштабов.
Gфt§fj:I
Всегда пользуйтесь системой контроля версий
Делайте это всегда, даже если работаете над индивидуальным или краткос
рочным проектом, "одноразовым" прототипом или иным материалом, не явля
ющимся исходным кодом. При этом все версии должны быть под полным кон
тролем, будь то документация, списки номеров телефонов, памятные записки
для поставщиков, сборочные файлы, процедуры сборки и выпуска, небольшой
сценарий оболочки, упорядочивающий журнальные файлы, словом
-
все. Мы
регулярно пользуемся контролем версий практически для всего, что набираем
сами, включая текст этой книги. И даже если мы не работаем над конкретным
проектом, то все равно сохраняем для надежности свою повседневную работу
в репозитории.
ВЕТВЛЕНИЕ
В системах контроля версий не только отслеживается предыстория конкрет
ного проекта. К числу самых эффективных и полезных свойств таких систем
относится возможность выделять отдельные участки разработки в так назы
ваемые ветви. Создать ветвь можно в любой момент предыстории проекта, и
тогда любая работа, выполняемая в данной ветви, будет обособлена от всех ос
тальных ветвей. А в какой-то последующий далее момент свою рабочую ветвь
можно объединить обратно с другой ветвью, чтобы целевая ветвь содержала в
итоге изменения, внесенные в рабочей ветви. Более того, в одной ветви могут
работать несколько человек, и такие ветви становятся похожими в какой-тосте
пени на небольшие клонируемые проекты.
Ветви выгодно отличаются, во-первых, тем, что позволяют работать обособ
ленно. Так, если вы разрабатываете функциональное средство А в одной ветви,
а ваш коллега
-
функциональное средство В в другой ветви, вы не мешаете
друг другу. И во-вторых, ветви, как ни странно, нередко оказываются в центре
процесса работы команды над проектом.
Глава 3 • Основные инструментальные средства
122
Именно здесь и возникает небольшая путаница. У ветвей контроля версий
и орrанизации тестов есть нечто общее: и в тех и в друrих участвуют тысячи
людей, подсказывающих, как нужно делать. Но такие советы по большей части
лишены смысла, поскольку они, по существу, означают прием, который оказался
приrодным для советчика в конкретной ситуации.
Итак, пользуйтесь контролем версий в своем проекте, и если в процессе ра
боты над ним у вас возникнут какие-нибудь затруднения, то поищите возмож
ные пути их разрешения. И не забывайте просматривать и корректировать все,
что вы делаете, постепенно набираясь необходимоrо опыта.
МЫСЛЕННЫЙ ЭКСПЕРИМЕНТ
Вылейте чашку вашего любимого чая на клавиатуру своего компьютера. От
несите его в мастерскую по ремонту вычислительной техники, задав им ра
боту. Если они не сумеют починить ваш компьютер, приобретите новый.
Сколько времени потребуется, чтобы вернуть компьютер в прежнее состо
яние, включая установку и настройку операционной системы, сетевого про
токола, текстового редактора, приложений и т.д., когда вы только подняли
злосчастную чашку чая? Подобный вопрос пришлось недавно решать одно
му из авторов этой книги.
Практически все, что определяло конфигурацию и применение первона
чального компьютера, хранилось в системе контроля версий, в том числе
следующее:
•
Все пользовательские настройки и файлы конфигурации.
•
Параметры настройки текстового редактора.
•
Список программного обеспечения, установленного с помощью утилиты
командной строки типа
Homebrew.
• Сценарий AnsiЫe для конфигурирования приложений.
•
Все текущие проекты.
К вечеру компьютер был восставлен в прежнее рабочее состояние.
КОНТРОЛЬ ВЕРСИЙ КАК ЦЕНТРАЛЬНЫЙ УЗЕЛ ПРОЕКТА
Несмотря на то что контроль версий невероятно удобен для работы над ин
дивидуальными проектами, истинный
ной работе. И наибольшая
размещение репозитория.
ero
ero потенциал проявляется
в коллектив
ценность заключается в том, как орrанизовано
Тема 19 • Контроль версий
123
Многим современным системам контроля версий вообще не требуется ни
какого размещения. Они полностью децентрализованы, и поэтому все разра
ботчики могут на равных работать над совместным проектом. Но даже в таких
системах стоит все же организовать центральный репозиторий. Ведь в этом
случае можно многократно выполнять интеграцию, упрощая ход работы над
проектом.
Многие репозиторные системы доступны в виде открытого исходного кода,
что дает возможность установить их и работать с ними в своей организации. Но
для программистов-прагматиков мы все же рекомендуем размещать репозито
рий системы контроля версий на третьей стороне, где следует искать перечис
ленные ниже возможности.
•
Хорошая защита и управление доступом.
•
Интуитивный пользовательский интерфейс.
•
Возможность выполнять все операции из командной строки на тот случай,
если потребуется автоматизировать их.
•
Автоматическое построение и тестирование.
•
Хорошая поддержка объединения ветвей, иногда еще называемого запро
сами на включение изменений.
•
Разрешение затруднений (в идеальном случае интегрировано в операции
фиксации изменений и объединения ветвей для сохранения количествен
ных показателей).
Удобное общение в команде: уведомления об изменениях по электронной
почте или иными способами, вики-страницы и пр.
Многие команды настраивают свои системы контроля версий таким обра
зом, чтобы отправка изменений в конкретную ветвь автоматически приводила
к построению системы, выполнению тестов, а после успешного завершения
-
к
развертыванию нового кода в условиях эксплуатации. На первый взгляд такая
автоматизация операций вызывает опасение, но в ней нет ничего опасного, если
ясно осознавать сущность контроля версий: любые изменения можно всегда от
катить назад.
Другие разделы, связанные с данной темой
•
Тема
11.
Обратимость, глава
•
Тема
49.
Прагматичные команды, глава
Тема
51.
Начальный набор инструментальных средств программиста-праг
•
матика, глава
9
2
"Прагматичный подход".
9
"Прагматичные проекты".
"Прагматичные проекты".
Гnава 3 • Основные инструментальные средства
124
Задачи
•
Одно дело
-
знать, как произвести откат в предыдущее состояние, ис
пользуя систему контроля версий, а другое
-
уметь это делать. Можете ли
вы произвести такую операцию и знаете ли подходящие для этой цели ко
манды? Овладейте ими сейчас, а не тогда, когда нагрянет беда и придется
принимать срочные меры.
•
Обдумайте, как вы будете восстанавливать рабочую среду на переносном
компьютере после аварийной ситуации. Что именно вам придется восста
навливать? Иногда требуется восстановить лишь текстовые файлы. Если
они не находятся в системе контроля версий, размещаемой в удаленном
месте, найдите способ ввести их в эту систему. Затем подумайте о другом
материале: установленных приложениях, конфигурации системы и т.д. Как
выразить весь этот материал в текстовых файлах, чтобы сохранить и его?
Добившись некоторого прогресса, попробуйте в качестве любопытного
эксперимента отыскать старый компьютер, которым вы больше не поль
зуетесь, и выяснить, можно ли настроить его, используя новую систему
контроля версий.
•
Сознательно подойдите к исследованию тех различных возможностей ва
шей системы контроля версий и хостинга, которыми вы в настоящее вре
мя не пользуетесь. Так, если в вашей команде не применяются функцио
нальные ветви, поэкспериментируйте с их внедрением. Это же относится
к запросам на извлечение или включение изменений, непрерывной интег
рации, сборочным конвейерам и даже к непрерывному развертыванию.
Поищите средства, подходящие для общения в команде, в том числе вики страницы, доски по методу канбан и пр. Пользоваться всем этим совсем
не обязательно, но все же нужно знать, чем они могут помочь в принятии
решений.
•
Пользуйтесь контролем версий и для работы с другим материалом вне
своего проекта.
'•l·Ф*J·I ОТЛАДКА
"Как больно глядеть на свои страданья и знать, что
причинил их ты сам, и никто другой".
Софокл, Анке
Слово
bug (жучок) служит в английском языке для описания "ужасного объ
екта" еще с XIV века. Контр-адмирал д-р Грэйс Хоппер, создатель языка COBOL,
была первым наблюдателем компьютерного "жучка", а по существу, моли, попав-
Тема 20 • Отладка
125
шей в одно из реле, на которых были построены первые ЭВМ. Когда техника из
обслуживающего персонала попросили объяснить, почему машина ведет себя
не так, как следует, он ответил, что обнаружен "жучок в системе", и с сознанием
выполненного долга приклеил насекомое (вместе с крылышками и всем осталь
ным) клейкой лентой к странице регистрационного журнала.
К сожалению, "жучки" до сих пор попадают в вычислительные системы, хотя
они и не летают. Впрочем, их лучше было бы назвать бытующим с
XIV века сло
вом Ьоgеутап и означающим "призрак': поскольку теперь оно уместно в гораздо
большей степени, чем на заре вычислительной техники. Изъяны проявляются в
программном обеспечении по-разному: от Превратно понятых требований до
ошибок программирования. И, к сожалению, современные вычислительные сис
темы способны делать лишь то, что мы им прикажем, но совсем не обязательно
то, что нам хотелось бы, чтобы они делали.
Никому не удается писать идеальные программы, а следовательно, их отладка
занимает львиную долю рабочего времени программиста. Рассмотрим некото
рые вопросы, касающиеся отладки, а также ряд общих стратегий обнаружения
едва уловимых программных ошибок.
Психология ОТЛАДКИ ПРОГРАММ
Для многих разработчиков отладка является довольно щепетильной, чувс
твительной темой. Вместо желания приступить к ней как к требующей разгад
ки головоломке, можно встретить отказ, взаимные упреки, слабые отговорки
и просто безразличие. Следует, однако, иметь в виду, что отладка
-
это всего
лишь средство для разрешения затруднений и их устранения.
Обнаружив чью-нибудь программную ошибку, можно затратить немало вре
мени и труда, возлагая всю вину на того нечестивца, который ее совершил. В не
которых ситуациях и коллективах это оказывается (очистительной) частью об
щей культуры. Но в области техники требуется сосредоточиться на устранении
самого затруднения, а не винить других в его возникновении.
1;.и41р1
Устраните затруднение, а не вините в нем других
И совсем не важно, является ли программная ошибка вашей или чужой оп
лошностью. Она все равно остается вашей проблемой.
МЫСЛЕННАЯ УСТАНОВКА НА ОТЛАДКУ
"Обманывать легче всего самого себя".
Эдвард Булвер-Литтон4, Отверzнуть1й
4
Edward Bulwer- Lytton - английский писатель Х1Х века. - Примеч. пер.
(The Disowned)
126
Глава 3 • Основные инструментальные средства
Прежде чем приступить к отладке, очень важно принять соответствующий
образ мыслей. Для этого необходимо устранить многие преграды, защищающие
ваше самолюбие, избавиться от любого возможного нажима со стороны проек
та и почувствовать себя в уютной обстановке. А самое главное
-
не забывать
первое правило отладки, которое гласит:
IG+ц11.1
Не паникуй!
Впасть в панику очень легко, особенно если поджимают сроки или нервни
чающий начальник либо клиент дышит вам в затылок в то время, как вы пыта
етесь найти причину программной ошибки. И здесь очень важно отступить на
шаг и тщательно обдумать возможную причину тех симптомов, которые, на ваш
взгляд, указывают на программную ошибку.
Если вашей первой реакцией на свидетельство или сообщение о програм
мной ошибке станет фраза "это невозможно", значит, вы совершенно не правы.
Не тратьте ни одного нейрона на ход рассуждений, начинающийся с того, что
этого просто не может быть. Ведь совершенно очевидно, что это может быть,
и так оно и есть.
Стерегитесь близорукости во время отладки. Противьтесь сильному желанию
устранить лишь видимые симптомы, ведь фактическая неисправность может от
стоять на несколько шагов от того, что вы наблюдаете, и быть связанной с це
лым рядом других неполадок. Старайтесь всегда обнаружить корневую причину
возникшего затруднения, а не только его конкретное внешнее проявление.
С ЧЕГО НАЧИНАТЬ ОТЛАДКУ
Прежде чем приступить к анализу программной ошибки, убедитесь, что ра
ботаете над кодом, при построении которого не было никаких предупреждений
компилятора. Нет никакого смысла тратить время, пытаясь выявить неполадку,
которую компьютер может обнаружить автоматически! Вам нужно сосредото
читься на решении более трудных насущных задач.
Пытаясь разрешить любое затруднение, необходимо собрать все уместные
данные. К сожалению, сообщения о программных ошибках для этого не совсем
годятся из-за своей неточности. Ведь совпадения могут очень легко ввести в
заблуждение, а тратить время на отладку совпадений непозволительно. Прежде
всего необходимо быть точным в своих наблюдениях.
Точность сообщений о программных ошибках снижается еще больше, когда
они проходят через стороннее программное обеспечение. Чтобы добиться до
статочного уровня детализации, возможно, придется понаблюдать за действия
ми пользователя, сообщившего о программной ошибке.
Тема 20 • Отладка
127
Однажды Энди работал над крупным графическим приложением. Ближе
к выпуску этого приложения тестировщики сообщили, что оно завершалось
аварийно всякий раз, когда они наносили мазок конкретной кистью. Програм
мист, отвечавший за эту часть приложения, возразил, что в таком поведении
нет ничего неверного. Он попробовал раскрасить участок изображения данной
кистью, и она действовала как следует. Эта полемика продолжалась в течение
нескольких дней, и всякий раз на быстро повышавшихся тонах.
Наконец, мы собрались вместе в одном помещении. Тестировщик выбрал
инструмент кисти и нанес мазок от правого верхнего до нижнего левого угла
экрана, в результате чего приложение перестало работать. Программист удив
ленно воскликнул сдавленным голосом и смущенно признался, что наносил
пробные мазки кистью только от нижнего левого до правого верхнего угла эк
рана, что не приводило к появлению ошибки.
Из этой истории можно сделать следующие выводы.
•
С пользователем, сообщившим о программной ошибке, возможно, придет
ся побеседовать, чтобы получить больше сведений, чем удалось собрать
первоначально.
•
Искусственных тестов вроде единственного мазка, проведенного кистью
снизу вверх, недостаточно для проверки приложения. Необходимо подвер
гнуть безжалостному тестированию как граничные условия, так и реалис
тичные образцы его употребления конечным пользователем. И делать это
следует систематически (см. раздел "Строгое и непрерывное тестирование"
главы
9
"П рагматичные
проекты
") .
СТРАТЕГИИ ОТЛАДКИ
Как только вы определите, что, собственно, происходит, выясните, как это
представляется в самой программе.
Воспроизведение ошибок
Нет, наши ошибки в действительности не размножаются (хотя некоторые из
них, вероятно, достаточно стары, чтобы это было законным). Речь здесь идет о
другом способе размножения.
Чтобы приступить к устранению программной ошибки, ее нужно сделать
воспроизводимой. Ведь если воспроизвести ошибку нельзя, то как выяснить,
была ли она вообще устранена?
Но ведь нам требуется выяснить нечто большее, чем программная ошибка,
которая может быть воспроизведена путем выполнения некоторой длинной пос
ледовательности шагов. Мы хотим, чтобы можно было воспроизвести програм
мную ошибку с помощью единственной команды. Ведь устранить программную
ошибку намного сложнее, если, чтобы дойти до того места, где она проявляется,
придется выполнить
15
шагов. Поэтому самое важное правило отладки гласит:
128
Глава
3,
Основные инструментальные средства
-
Вылавливающий ошибку тест должен предшествовать
ее исправлению
Иногда, пытаясь выделить обстоятельства, при которых проявляется ошиб
ка, можно даже получить ясное представление, как ее устранить. Сам процесс
написания теста подсказывает нужное решение .
ПРОГРАММИСТ В ЧУЖОЙ СТРАНЕ
Все сказанное выше о локализации программной ошибки, конечно, замеча
тельно. Но что делать бедному программисту, если требуется отладить
50 тысяч
строк кода, когда времени явно не хватает?
Прежде всего рассмотрите проблему. Идет ли речь об аварийном завершении
приложения? Когда мы преподаем на курсах, включающих программирование,
нас всегда удивляет, как много разработчиков, увидев появление исключения в
красном поле результатов тестирования, сразу же переходят к исходному коду.
-
Внимательно читайте сообщение об ошибке,
каким бы отвратительным оно ни было
К этому добавить нечего.
плохие результаты
А что, если это не аварийное завершение, а всего лишь плохой результат?
В таком случае перейдите в отладчике к месту его формирования и выполните
тест, чтобы выявить ошибку.
Прежде чем делать что-нибудь другое, непременно выявите неверное зна
чение в отладчике. Мы оба часами пытались отследить программную ошибку
лишь затем, чтобы обнаружить, что данное конкретное выполнение кода завер
шилось удачно.
Иногда ошибка вполне очевидна. Например, значение переменной
rate
равно
4. 5, а должно
быть равно О.
045.
interest_
Но чаще всего ошибку приходит
ся искать глубже, чтобы выяснить, прежде всего, причину, по которой значение
оказалось неверным. Поэтому убедитесь сначала, что знаете, как перемещаться
вверх и вниз по стеку вызовов, а затем проанализируйте окружение стека.
Нередко полезно держать под другой лист бумаги и ручку, чтобы делать за
метки. В частности, мы часто находим ключ к разгадке и, идя по следу, не дости
гаем в конечном итоге успеха. И если не записать место, с которого мы начали
свой поиск, то можно потерять много времени, возвращаясь назад.
Иногда приходится анализировать результаты трассировки стека, прокрутка
которых кажется бесконечной. В таком случае бинарный поиск нередко оказы -
Тема
20
~ Отладка
129
вается более быстрым способом выявить неполадку, чем анализ всех фреймов
стека подряд. Но, прежде чем обсуждать этот способ, рассмотрим две другие
общие ситуации возникновения программных ошибок.
Чувствительность ко входным данным
Эта ситуация должна быть хорошо вам знакома. Сначала ваша программа
нормально работает со всеми тестовыми данными и с честью переживает пер
вую неделю своей эксплуатации, а затем неожиданно терпит крах, когда в нее
вводится некоторый конкретный массив данных.
Вы можете попытаться проанализировать свою программу в месте ее ава
рийного завершения и продвигаться далее в обратном направлении. Сделайте
копию массива данных и введите его в локальную копию своей программы, убе
дившись, что она по-прежнему терпит крах. Затем выполняйте бинарный поиск
до тех пор, пока не дойдете до конкретного места, где вводимые значения при
водят к аварийному завершению.
Регрессии
no
выпускам
Представьте, что вы работаете в хорошей команде, выпускающей програм
мное обеспечение в эксплуатацию. В какой-то момент в исходном коде, который
нормально работал еще неделю назад, обнаруживается программная ошибка.
Не стоит ли в таком случае выявить конкретное изменение, внедрившее данную
ошибку? И, как вы, вероятно, уже догадались, что самое время для бинарного
поиска, о котором речь пойдет далее.
БИНАРНЫЙ поиск
Всякому студенту, изучавшему вычислительную технику, приходилось про
граммировать бинарный поиск, иначе называемый делением пополам. В его осно
ву положена довольно простая идея: найти конкретное значение в отсортирован
ном массиве. Для этого можно было бы, конечно, проанализировать поочередно
каждое значение, но тогда пришлось бы перебрать в среднем около половины
элементов массива до тех пор, пока не будет найдено требуемое или большее
значение. Последнее означает, что искомое значение отсутствует в массиве.
Но найти нужное значение можно намного быстрее, воспользовавшись мето
дом "разделяй и властвуй". С этой целью выбирается значение посредине масси
ва. Если это искомое значение, то поиск прекращается, а иначе массив делится
надвое. Если найденное значение больше искомого, то становится ясно, что оно
должно быть в первой половине массива, а иначе
-
во второй. Данная про
цедура повторяется в соответствующем подмассиве, и очень скоро достигается
искомый результат. (Как поясняется в разделе "Асимптотическое обозначение"
главы
7
нарный
"По ходу кодирования'', линейный поиск имеет сложность О(п), а би
- O(logn)).
Глава 3 • Основные инструментальные средства
130
Таким образом, бинарный поиск позволяет намного быстрее решить любую за
дачу приличных масштабов. А теперь посмотрим, как применить его к отладке.
Когда вы анализируете результаты массивной трассировки стека, пытаясь
выяснить, какая именно функция ошибочно исказила значение, то выполняе
те бинарный поиск, выбрав кадр где-то посредине стека, чтобы посмотреть, не
проявилась ли ошибка до этого места. Если она проявилась, то становится ясно,
что основное внимание следует сосредоточить на предыдущих фреймах; в про
тивном случае следует искать неполадку в последующих фреймах стека. Затем
бинарный поиск повторяется, и даже если в результатах трассировки стека при сутствуют
64
кадра, подобным методом можно найти причину ошибки, сделав
не более шести попыток.
Если вы ищете программные ошибки, проявляющиеся в определенных мас
сивах данных, то можете поступить таким же образом, как описано выше. В час
тности, разделите массив данных надвое и выясните, проявится ли ошибка, если
ввести одну или другую его половину в отлаживаемое приложение. Продолжай
те далее разделять массив данных до тех пор, пока не получите минимальный
массив значений, в котором проявляется искомая ошибка.
Если ваша команда внесла программную ошибку давно, и с тех пор прошло
уже несколько выпусков, то и в этом случае можно воспользоваться тем же са
мым методом. С этой целью создайте тест, который не проходит в текущем вы
пуске, а затем выберите промежуточный вариант между текущей и последней
версией, о которой заведомо известно, что она рабочая. Выполните тест снова,
чтобы решить, каким образом следует сузить поиск. Возможность такого реше
ния
-
одно из многих преимуществ, которые дает наличие качественного кон
-
троля версий в ваших проектах. Безусловно, многие системы контроля версий
позволяют пойти еще дальше и автоматизировать данный процесс, самостоя
тельно выбирая выпуски по результатам тестирования.
Протоколирование и/или трассировка
Как правило, отладчики сосредоточиваются на текущем состоянии програм
мы. Но иногда требуется нечто большее: наблюдать состояние программы или
структуры данных во времени. Просмотр результатов трассировки стека поз
воляет лишь выяснить, как непосредственно дойти до текущего состояния. Он,
как правило, не позволяет выяснить, что именно было сделано до данной цепоч
ки вызовов, особенно в событийно-управляемых системах5 .
Операторы трассировки являются небольшими диагностическими сообще
ниями, выводимыми на экран или в файл и уведомляющими, например, о том,
что выполнение программы дошло до конкретного места или значение перемен
ной х стало равным
2.
И хотя это довольно примитивный метод по сравнению
с возможностями отладчиков в интегрированных средах разработки, он все же
5 Хотя
в языке Elm имеется отладчик, допускающий перемещение во времени.
Тема 20 • Отладка
131
особенно эффективен для диагностики нескольких классов ошибок, выявить
которые отладчики неспособны. Трассировка неоценима в любой системе, где
важным фактором в одновременно выполняющихся процессах, системах реаль
ного времени и событийно-управляемых приложениях является само время. Ис
пользуя операторы трассировки, можно подробно анализировать исходный код
вглубь, т.е. вводить их, продвигаясь вниз по дереву вызовов.
Сообщения трассировки должны быть представлены в обычном согласован
ном формате, чтобы их можно было анализировать автоматически. Так, если
требуется проследить утечку ресурсов (например, неравномерность открытий и
закрытий файлов), с этой целью можно протрассировать каждый оператор
и
close
open
в журнальном файле. Обрабатывая журнальный файл инструменталь
ными средствами для обработки текста или по командам оболочки, можно лег
ко определить место, где появился оператор
open,
нарушивший равномерность
открытий и закрытий файлов.
МЕТОД РЕЗИНОВОГО УТЕНКА
Самый простой, но особенно полезный способ найти причину неполадки
-
просто объяснить ее кому-то другому. Он должен глядеть на экран через ваше
плечо, постоянно кивая головой, как резиновый утенок, ныряющий и всплы
вающий в ванной. Не говоря ни слова, а просто показывая шаг за шагом, что
именно должен делать код, нередко можно дойти до того, что неполадка выныр
нет на экран и проявится сама6 •
Казалось бы, все просто, но, объясняя возникшее затруднение другому чело
веку, вам приходится растолковывать ему то, что может быть само собой разуме
ющимся для вас, когда вы просматриваете исходный код сами. Выражая слова
ми свои предположения, вы можете неожиданно получить новое представление
о возникшем затруднении. А если вам некому объяснить свое затруднение, то
вполне подойдет и резиновый утенок, плюшевый медвежонок или растение в
горшке.
Процесс исключения
В большинстве проектов отлаживаемый прикладной код может состоять из
фрагментов, написанных вами и другими членами команды, работающей над
проектом, сторонних программных продуктов (базы данных, средств подклю
чения к сети, каркаса веб-приложений, специальных протоколов связи или ал-
6
Почему данный метод носит название "резинового утенка"? Когда Дэйв учился в Им
перском колледже Лондона, он много работал с младшим научным сотрудником Грегом
Пафом (Greg Pugh), одним из самых лучших из всех известных ему разработчиков. Грег
целыми месяцами носил с собой небольшого желтого резинового утенка и ставил его на
свой терминал, когда программировал. И лишь некоторое время спустя Дэйв отважился
спросить, зачем Грег это делает ...
Глава 3 • Основные инструментальные средства
132
горитмов и т.д.), а также платформенного окружения (операционной системы,
системных библиотек и компиляторов).
Вполне возможно, что программная ошибка присутствует в операционной
системе, компиляторе или стороннем программном продукте, хотя это и не долж
но быть вашей первой мыслью. Ведь намного более вероятно, что программная
ошибка присутствует в разрабатываемом прикладном коде. Как правило, предпо
ложить, что в прикладном коде неверно вызывается библиотека, целесообразнее,
чем допустить, что нарушена сама библиотека. И даже если неполадка кроется
в стороннем программном продукте, то нужно все равно устранить неполадки в
своем коде, прежде чем предоставить отчет о программных ошибках.
Нам как-то пришлось работать над проектом, где старший инженер был
убежден, что системный вызов
ме
Unix. И
select нарушался
в самой операционной систе
никакие убедительные доводы или логические обоснования не моrли
изменить его мнение, а тот факт, что все остальные сетевые приложения работа
ли на данной платформе нормально, не принимался во внимание. Он потратил
не одну неделю, изобретая обходные пути, которые по какой-то странной при
чине все же не устраняли неполадку. И когда ему пришлось в конечном счете
сесть и прочитать документацию на системный вызов
select, он
обнаружил и
устранил неполадку в считанные минуты. С тех пор мы пользуемся выражением
"системный вызов
select нарушен"
в качестве осторожного напоминания, как
только один из нас начинает винить в сбое, который, вероятнее всего, происхо
дит по его вине, саму систему.
Системный вызов
select работает
нормально
Увидев следы копыт, не забывайте подумать прежде всего о конях, а не зеб
рах. Операционная система скорее всего работает нормально, и системный вы
зов
select действует
как следует.
Если вы внесли изменение лишь в какой-то один компонент и система пере
стала работать, то, вероятнее всего, именно этот компонент, прямо или косвен
но, служит тому причиной, какой бы неправдоподобной она ни казалась. Иногда
измененный компонент оказывается вне вашего поля зрения. Это может быть,
например, новая версия операционной системы, компилятор или другое сторон
нее программное обеспечение, способное повредить код, который раньше рабо
тал нормально. Могут проявиться новые программные ошибки, нарушающие
обходные пути, устраняющие обнаруженные ранее ошибки . Изменяются также
API,
функциональные возможности. Короче говоря, возникает совсем новая
ситуация, вынуждающая снова проверять всю систему в этих новых условиях .
Поэтому внимательно следите за графиком выполнения работ, если планируете
модернизацию, которую, возможно, придется отложить до момента после сле
дующего выпуска.
Тема 20 " Отладка
133
ЭЛЕМЕНТ УДИВЛЕНИЯ
Если программная ошибка приведет вас в недоумение, а возможно, даже и к
бормотанию шепотом "этого просто не может быть" так, чтобы никто не услы
шал,
-
в таком случае вам придется переоценить те истины, которыми вы так
дорожите. Выполняя этот алгоритм учета поправки на преувеличение того, что
казалось вам вполне надежным и не могло вызвать эту программную ошибку,
спросите себя: проверили ли вы все граничные условия? И не кроется ли до сих
пор программная ошибка в том фрагменте кода, которым вы пользуетесь года
ми? Возможно ли такое вообще?
Конечно, возможно. Степень удивления, которое вы испытываете, когда что
нибудь не ладится, пропорциональна степени доверия и веры в непогрешимость
выполняемого кода. Именно поэтому, сталкиваясь с "удивительным" сбоем, вы
должны признать, что одно или несколько ваших предположений неверны. Не
обходите стороной подпрограмму или фрагмент кода, связанный с ошибкой,
лишь потому, что твердо уверены в его работоспособности. Убедитесь в том,
что в таком контексте, с такими данными и при таких граничных условиях
проверяемый код действительно работает.
Не предполагайте, а доказывайте
Обнаружив удивительную программную ошибку, необходимо не только ус
транить ее, но и установить причину, по которой ее не удалось перехватить.
Выясните, следует ли исправить модульные или другие тесты, чтобы они могли
выявлять данную ошибку.
А если программная ошибка возникает в результате распространения нека
чественных данных через пару уровней, прежде чем привести к сбою, то вы
ясните, можно ли выделить ее раньше, улучшив проверку параметров в соот
ветствующих подпрограммах. (Подробнее о досрочном аварийном завершении
и утверждениях см. соответственно в разделе "Принцип "поймал-отпустил"
только для ловлирыбы" и в разделе "Тема
ние" главы
4
25.
-
Утвердительное программирова
"Прагматичная паранойя':)
Проверьте также, есть ли какие-нибудь другие места в исходном коде, ко
торые можно подозревать на проявление той же самой ошибки? Самое время
найти их и устранить в них эту ошибку. Убедитесь, что чтобы ни случилось,
если это произойдет вновь, вы будете об этом знать.
Если устранение ошибки отнимает много времени, выясните, почему проис
ходит именно так и можно ли сделать что-нибудь, чтобы упростить устранение
данной ошибки в следующий раз. Возможно, стоит встроить более совершенные
перехватчики для тестирования или написать анализатор журнальных файлов.
134
Глава 3 • Основные инструменtальные средства
Наконец, обсудите возникшее затруднение со всей командой, если проrрам
мная ошибка является результатом чьеrо-то неверноrо предположения. Ведь
если заблуждается один человек, то моrут заблуждаться и многие люди. Если
вы сделаете все написанное выше, то можно надеяться, что в следующий раз
возникающие программные ошибки удивят вас гораздо меньше.
КОНТРОЛЬНЫЙ СПИСОК ВОПРОСОВ ПО ОТЛАДКЕ
Ниже перечислены вопросы, которые следует задавать в процессе отладки
программ.
•
Является ли рассматриваемая неполадка непосредственным результатом
или только симптомом скрытой программной ошибки?
•
Присутствует ли программная ошибка в используемом вами каркасе, опе
рационной системе или же в вашем коде?
•
Если бы вам довелось подробно объяснять возникшее затруднение колле
rе, то что бы вы ему сказали?
•
Если подозрительный код проходит свои модульные тесты, то насколько
они полноценны? Что произойдет, если выполнить эти тесты с конкрет
ными данными?
•
Существуют ли условия, при которых возникает данная проrраммная
ошибка, где-нибудь еще в системе? Находятся ли какие-нибудь другие
скрытые ошибки, ожидающие возможности своего появления на свет?
Другие разделы, связаннь1е с данной темой
•
Тема
24.
Мертвые программы не лrут, глава
4
"Праrматичная паранойя':
Задача
•
Отладка
-
довольно трудная задача.
lij.фfji МАНИПУЛИРОВАНИЕ ТЕКСТОМ
Программисты-праrматики манипулируют текстом таким же образом, как и
столяры, обрабатывающие древесину, придавая ей нужную форму. В предыду
щих разделах упоминался ряд конкретных инструментальных средств (оболоч
ки, редакторы, отладчики), которыми пользуются проrраммисты -праrматики.
Их можно сравнить со стамесками, пилами и рубанками, применяемыми для
выполнения тех или иных столярных работ. Но иноrда требуется выполнить
преобразование, на которое неспособен основной набор инструментальных
средств. И для этой цели требуется универсальное инструментальное средство
манипулирования текстом.
Тема 21 • Манипулирование текстом
135
В программировании языки манипулирования текстом выполняют те же
функции, что и фрезерные станки в столярном деле. Это шумные, тяжелые инст
рументы, применяющие грубую силу. Стоит совершить ошибку, пользуясь ими,
как вся заготовка разлетается на куски. Некоторые клянутся, что таким инстру
ментам нет места в их арсенале. Но в хороших руках как фрезерные станки, так
и языки манипулирования текстом могут оказаться невероятно эффективными
и универсальными инструментами. С их помощью можно быстро обрезать за
готовку, выполнить соединение и вырезать нужную форму. Но для овладения
ими требуется время.
Правда, существует целый ряд отличных языков манипулирования текс
том. Так, разработчики приложений для
Unix,
включая и пользователей
macOS,
нередко любят использовать весь потенциал своих командных оболочек, под
крепленных такими инструментальными средствами, как
awk и sed. А те, кому
больше нравятся структурированные инструментальные средства, могут отдать
предпочтение таким языкам, как
Python
или
Ruby.
Такие языки являются важными базовыми технологиями. С их помощью
можно быстро проработать утилиты и прототипные идеи, т.е. решить те задачи,
на решение которых может потребоваться в пять-десять раз больше времени,
чем с помощью обычных языков. А ведь такая многократная экономия време
ни очень важна для проведения экспериментов. В самом деле, потратить всего
лишь
30
минут на опробование какой- нибудь безумной идеи намного привле
кательнее, чем израсходовать на это целых пять часов. Автоматизацией важных
компонентов проекта вполне приемлемо заниматься целый рабочий день, но
не целую неделю. В своей книге Практика программирования [КР99] Керниган
и Пайк приводят пример создания одной и той же программы на пяти разных
языках. Самой краткой оказалась версия на языке
кода по сравнению со
150
Perl (она состояла из 17 строк
Perl, можно
строками кода на языке С). Используя
манипулировать текстом, взаимодействовать с программами, обмениваться со
общениями по сети, вести веб-страницы, выполнять арифметические операции
с произвольной точностью и писать программы, похожие на символические
реплики Снупи7 .
Изучите язык манипулирования текстом
Чтобы продемонстрировать применимость языков манипулирования текстом
в обширных пределах, приведем ниже ряд примеров приложений, разработан-
7
Snoopy (любопытный) - персонаж в виде песика породы биrль из популярной серии
комиксов
Peanuts (Арахис), созданных американским художником Чарльзом М. Шульцем
в 1950-е годы.
-
Примеч. пер.
Глава 3 • Основные инструментальные средства
136
ных нами на языках
Ruby
и
Python
и непосредственно связанных с написанием
этой книги.
•
Составление книг. Система составления книг для издательства
Bookshelf написана
на языке
Ruby.
Авторы, редакторы, верстальщики и об
служивающий персонал пользуются задачами
цессов составления текста в форматах
•
Pragmatic
PDF
Rake
для координации про
и электронных книг.
Включение и выделение исходного кода. Мы считаем очень важным про
верить сначала любой фрагмент кода, представленный на страницах книги,
что и было проделано со всеми примерами кода из этой книги. Но, следуя
принципу
DRY
(см. раздел "Тема
9. DRY -
пороки дублирования" главы
2
"Прагматичный подход"), нам не хотелось бы копировать и вставлять
строки кода из проверенных программ в текст книги. Ведь это означало бы
дублирование кода и буквально гарантировало бы, что мы забудем обно
вить пример кода, когда соответствующая программа изменится. В некото
рых примерах отсутствует каркасный код, требующийся для компиляции
и выполнения этих примеров, и поэтому мы обратились к услугам
Ruby.
В частности, для форматирования книги вызывается простой сценарий,
извлекающий именованные сегменты из исходного файла, производится
синтаксический анализ выделенного сегмента, выделяется синтаксис и по
лученный результат преобразуется в синтаксис применяемого языка ти
пографского набора.
•
Обновление неб-сайта. Для этой цели у нас имеется простой сценарий,
частично составляющий книгу, извлекающий ее содержание, а затем об
новляющий его на странице нашего веб-сайта, посвященной данной книге.
Кроме того, у нас имеется сценарий, извлекающий отдельные разделы кни
ги и выгружающий их на соответствующую страницу нашего веб-сайта в
качестве образцов текста книги.
•
Включение уравнений. Для этой цели имеется сценарий, преобразующий
разметку математических формул, набранных в редакторе
LaTeX,
в акку
ратно отформатированный текст.
•
Формирование предметного указателя:. Большинство предметных указа
телей к книгам создаются как отдельные документы, что затрудняет их со
провождение при внесении изменений в книrу. Составленные нами пред
метные указатели размечены в тексте самой книги, а по сценарию
Ruby они
автоматически составляются и форматируются по отдельным статьям.
Эти примеры можно продолжить. На практике издания
Pragmatic Bookshelf
построены на манипулировании текстом. И если вы последуете нашему совету
хранить данные в виде простого текста, то, пользуясь языками манипулирова
ния текстом, сможете извлечь для себя немало выгод.
Тема 22 • Технические дневники
137
Другие роэдепы, свнэонные с данной темой
• Тема 16. Сила простого текста.
• Тема 17. Игры в скорлупки.
Упражнения
11.
Допустим, вы переписываете приложение, в котором раньше для конфи
гурирования использовался формат
YAML. А теперь ваша организация
перешла на стандартизированный формат JSON, и поэтому вам придется
преобразовать целый ряд файлов с расширением . yaml в файлы с расши
рением . j son. Напишите с этой целью сценарий, принимающий каталог
и преобразующий каждый файл с расширением . yaml в файл с расшире
нием . j son таким образом, чтобы файл database. yaml стал, например,
файлом database. j son, а его содержимое - достоверно преобразовано в
формат JSON.
12.
Допустим, ваша команда первоначально решила обозначать имена переменных
в ГорбатомРегистре, а затем изменила свое коллективное решение, перей
дя на змеиный_регистр . Напишите сценарий, просматривающий имена в
ГорбатомРегистре во всех исходных файлах и сообщающий о них.
13.
Продолжая предыдущее упражнение, добавьте в написанный сценарий воз
можность автоматически изменять имена переменных в одном или несколь
ких исходных файлах. Не забудьте создать резервные копии оригиналов на
тот случай, если что-то пойдет совсем не так, как предполагалось.
l1j.фffJ ТЕХНИЧЕСКИЕ ДНЕВНИКИ
Дэйв как-то работал в небольшой компании, производившей вычислитель
ную технику. Это означало, что ему пришлось работать вместе с инженерами
электронщиками, а иногда и с инженерами-механиками. Многие из них ходи
ли с бумажной записной книжкой и ручкой, прикрепленной к переплету такой
книжки. И когда они общались с Дэйвом, то доставали свою записную книжку,
открывали ее и что-то записывали в нее.
В конечном счете Дэйв задал им вполне очевидный запрос, и оказалось, что
они приучены вести технические дневники, т.е. своего рода журналы повседнев
ного учета, в которых они записывают все, что сделали, чему научились, наброс
ки идей, показания измерительных приборов, а по существу, все, что связано
с их работой. Как только подобный дневник заполнялся, они надписывали на
корешке интервалы дат ведения дневника и клали его на полку рядом с преды
дущими дневниками. Между инженерами могло даже возникнуть соревнование,
чьи дневники займут больше места на полке.
Глава 3 • Основные инструментальные средства
138
Мы пользуемся техническими дневниками на совещаниях, чтобы записать в
них то, над чем работаем, занести значения переменных во время отладки, ос
тавить памятки, что и где разместить, набросать самые безумные идеи, а иногда
и просто рисовать машинально "чертиков" 8 .
Техническим дневникам присущи следующие достоинства.
•
Они более надежны, чем память. Так, если вас спросят: "Как называлась
компания, к которой вы обращались на прошлой неделе по поводу энер
госнабжения?", вы, пролистав свой дневник на несколько страниц назад,
сможете сообщить название и номер телефона данной компании.
•
В них есть место для хранения идей, которые не сразу оказываются при
годными для решения насущной задачи. Подобным образом вы можете и
дальше сосредоточиться на том, что делаете, зная, что ваша замечательная
идея не будет забыта.
•
Они действуют подобно резиновому утенку, описанному ранее в разделе
"Метод резинового утенка': Как только вы перестанете что-то записывать
в дневник, ваш ум может переключиться на другие мысли, как если бы во
время беседы с кем-нибудь у вас появилась возможность поразмыслить
над сказанным. Вы можете начать запись в дневнике и вдруг осознать, что
сделанная только что запись просто неверна.
У технических дневников имеется еще одно преимущество. Время от време
ни вы можете просматривать свои записи, сделанные много лет назад, в сп о ми
-
ная людей, проекты, ужасные одежды и прически.
Итак, старайтесь вести свой технический дневник, пользуясь бумажной за
писной книжкой, а не файлом или вики-страницей, поскольку в записывающем
действии есть нечто особенное по сравнению с набором текста. Через месяц
ведения такого дневника вы почувствует все его преимущества, перечисленные
выше. Во всяком случае, это упростит написание воспоминаний, когда вы раз
богатеете и добьетесь известности.
Другие раэделы, свяэанные с данной темой
Ваш багаж знаний, глава
•
Тема
6.
•
Тема
37.
1 "Философия
прагматизма".
Прислушивайтесь к своим инстинктам, глава
7
"По ходу кодиро
вания".
8
Имеется ряд свидетельств, что машинальное рисование "чертиков" и прочих каракулей
помогает сосредоточиться и совершенствует познавательные навыки. Примеры тому см.
в книге
What does doodling do? [AndlO].
ГЛАВА
4
,.·. ,···· · · ······' "'··,. ."·· · · ~. 0...е.А.[М.А .I.И.~. l:i.А.В. .. ..О_А."Р.. А . Н..О.Й. В
Написать идеальную программу нельзя
Задевает? А не должно бы. Примите этот совет как аксиому, оценив и при
ветствовав его, поскольку идеального программного обеспечения не существует.
Никому за краткую историю вычислительной техники еще не удавалось напи
сать идеальную программу, и вы вряд ли будете первым. Если же вы не примете
это как данность, то в конечном счете потратите зря время и силы, преследуя
неосуществимую мечту. Так как же программисту-прагматику извлечь выгоду
из этой гнетущей реальности? Именно данной теме и посвящена эта глава.
Каждый считает, что он является самым лучшим водителем на свете, а всем
остальным далеко до такого лихача, проскакивающего запрещающие знаки, ла
вирующего между дорожными полосами, не подавая сигналы поворота, наби
рающего текст сообщений на мобильном телефоне и вообще живущего не по
правилам. А мы вот ездим осторожно, остерегаясь беды еще до того, как она
случится, предвидя неожиданное и никогда не ставя себя в такое положение, из
которого нельзя выпутаться.
Аналогия с программированием вполне очевидна. Мы постоянно имеем дело
с чужим кодом, который может и не соответствовать высоким стандартам, а
также с входными данными, которые могут и не быть достоверными . Поэтому
мы приучены программировать, будучи начеку. И если у нас возникает какое
нибудь сомнение, то мы проверяем всю данную нам информацию. Для выявле
ния некачественных данных мы пользуемся проверками, не доверяя данным,
получаемым от потенциальных атакующих злоумышленников или троллей. Мы
выполняем проверку на согласованность, накладываем ограничения на столбцы
в таблице базы данных и, в общем, чувствуем себя прекрасно.
Но программист-прагматик идет дальше, не доверяя даже себе. Отлично зная,
что никому не дано написать идеальный код, включая и нас самих, программис
ты-прагматики выстраивают бастионы защиты против собственных ошибок.
140
Глава 4 • Прагматичная паранойя
Первая защитная мера описывается в разделе "Проектирование по контракту",
когда клиенты и поставщики должны согласовать права и обязанности .
Затем в разделе "Мертвые программы не лгут" поясняется, что обработка
программных ошибок не наносит никакого вреда. Поэтому следует стараться
производить проверки как можно чаще и прерывать программу, если дело при
-
мет скверный оборот. А в разделе "Утвердительное программирование" опи
сывается простой метод оперативной проверки, который состоит в написании
кода, активно проверяющего предположения программиста.
По мере того как ваша программа становится все более динамичной, вы об
наруживаете, что манипулируете системными ресурсами (оперативной памятью,
файлами, устройствами и т.п.), словно жонглируя шарами . Поэтому в разделе
"Как сбалансировать ресурсы" предлагаются способы не потерять ни одного
такого шара. А самое главное
-
продвигаться к цели мелкими шагами, чтобы
не свалиться в пропасть с края утеса, как поясняется в разделе "Не опережайте
свет фар вашего автомобиля".
В мире несовершенных систем, нелепых временных шкал, забавных инстру
ментов и невыполнимых требований приходится действовать осторожно. Как
однажды сказал известный кинорежиссер Буди Аллен: "Когда все фактически
строят вам козни, единственная хорошая мысль
-
это паранойя':
lйtt*JI ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ
"Ничто так не поражает людей,
как здравый смысл и откровенность".
Ральф Уолдо Эмерсон 1 , Очерки
(Essays)
Обращаться с вычислительными системами нелегко, а иметь дело с людьми
еще труднее. Но как биологический вид мы с давних пор выясняли вопросы
человеческих взаимоотношений. Некоторые решения, к которым мы пришли
за последние несколько тысячелетий, могут пригодиться и для написания про
грамм. И одним из самых лучших решений, гарантирующих прямоту отноше
ний, является контракт. Контракт определяет права и обязанности обеих за
ключивших его сторон. Кроме того, в нем предусмотрено соглашение сторон,
касающееся последствий, если одна из них не выполнит контракт.
Так, вы могли заключить контракт о найме, в котором указано сколько часов
вы должны работать, а также правила, которые вы обязаны соблюдать. В свою
очередь, работодатель платит вам зарплату и остальные надбавки. Если каждая
сторона выполняет свои обязательства, то выигрывают от этого все.
1
Ralph Waldo Emerson - американский эссеист, поэт, философ, пастор, общественный
XIX века. - Примеч. пер.
деятель
Тема 23 • Проектирование по контракту
141
Идея контракта используется во всем мире (формально или неформально)
с целью помочь людям наладить взаимоотношения. А может ли тот же самый
принцип оказать помощь в налаживании взаимодействий между программны
ми модулями? Да, может.
ПРИНЦИП ПРОЕКТИРОВАНИЯ ПО КОНТРАКТУ
Бертран Мейер
(Bertrand Meyer;
Object-Orieпted
Software
Coпstrиctioп [Меу97])
разработал принцип проектирования по контракту для языка Eiffel 2 • Это про
стая, но эффективная методика, направленная на документирование (и согласо
вание) прав и обязанностей программных модулей, чтобы обеспечить правиль
ность программы. А что такое правильная программа? Это такая программа,
которая выполняет только то, что от нее требуется,
-
ни больше и ни меньше.
Документирование и верификация такого требования и составляет саму суть
проектирования по контракту
(Design Ьу Contract, DBC).
Каждая функция и метод в программной системе вьтолняет какое-то дей
ствие. Прежде чем начать это действие, функция может предполагать какое-то
состояние окружающего мира, а по завершении она может сделать заявление о
состоянии окружающего мира. Эти предположения и требования Мейер описы
вает следующим образом.
•
Предусловия. Это требования подпрограммы, которые определяют, что
должно быть истинным для ее вызова. Подпрограмма вообще не должна
вызываться, если ее предусловия будут нарушены. На вызывающий код
возлагается ответственность за передачу качественных данных (см. врезку
"Кто несет ответственность" далее в этой главе).
•
Постусловия. Это состояние окружающего мира по завершении подпро
граммы, т.е. то, что ею гарантируется. Наличие постусловия у подпрограм
мы подразумевает, что она непременно завершится, а следовательно, бес
конечные циклы не допускаются.
•
Инварианты класса. Класс гарантирует, что данное условие для вызыва
ющего кода всегда истинно. В процессе внутренней обработки в подпро
грамме инвариант может и не соблюдаться, но к моменту выхода из под
программы и передачи управления вызывающему коду инвариант должен
быть непременно истинным. (Следует, однако, иметь в виду, что класс не
может предоставить неограниченный доступ для записи к любому члену
данных, принимающему участие в инварианте.)
Таким образом, контракт между подпрограммой и любым потенциально вы
зывающим кодом может быть составлен следующим образом.
Частично на основании прежних трудов Дейкстры (Dijkstra), Флойда (Floyd), Хоара
(Hoare), Вирта (Wirth) и других.
2
Глава 4 • Прагматичная паранойя
142
•
Если все предусловия подпрограммы удовлетворяются вызывающим ко
дом, то подпрограмма гарантирует истинность всех постусловий и инва
риантов при своем завершении.
Если же одна из сторон контракта не выполняет его условия, то вызывается
(предварительно согласованное) средство защиты нарушенных прав, например:
возникает исключение или прерывание программы. Что бы ни случилось, не
сомневайтесь, что несоблюдение условий контракта считается программной
ошибкой. Нет никакой гарантии, что этого вообще не произойдет, именно поэ
тому предусловия и нельзя использовать для выполнения таких операций, как
проверка вводимых пользователем данных на достоверность.
В одних языках эти принципы поддерживаются лучше, чем в других. Напри -
мер, в языке
Clojure поддерживаются
предусловия и постусловия, а также более
обширный инструментарий, предоставляемый по спецификации. Ниже приве
ден пример функции для открытия вклада в банке с помощью пред- и пост
условий.
(defn accept-deposit [account-id amount]
:pre [ (> amount О. 00)
(account-open? account-id) ]
:post [ (contains? (account-transactions account-id) %) ] }
"Accept а deposit and return the new transaction id"
;; Здесь выполняется остальная обработка ...
;; Возвратить вновь созданную транзакцию:
(create-transaction account-id :deposit amount))
Для функции
accept-depos i t ()
здесь заданы два предусловия. Первое со
стоит в том, что сумма вклада должна быть больше нуля, а второе
-
в том, что
счет должен быть открыт и действителен. Последнее определяется путем вызова
функции
account-open?
().Имеется также следующее постусловие: функция
гарантирует, что новая транзакция (возврат из данной функции значения, пред
ставленного в процентах
11
%11 )
может находиться среди прочих транзакций для
данного счета.
Если вызвать функцию
accept-deposi t ()
с положительной суммой для
открытия вклада и действительным счетом в банке, то она создаст далее тран
закцию подходящего типа и выполнит всю остальную требующуюся обработ
ку. Но если в программе имеется ошибка и данной функции каким-то образом
передана отрицательная сумма для открытия вклада, то во время выполнения
возникнет следующее исключение:
Exception in thread "main" ...
Caused Ьу: java.lang.AssertionError:
Assert failed: (> amount О.О)
Кроме того, данная функция требует, чтобы указанный счет был открыт и
действителен. В противном случае появится такое исключение:
Тема 23 • Проектирование по контракту
143
Exception in thread "main" ...
Caused Ьу: java.lang.AssertionError:
Assert failed: (account-open? account-id)
В других языках имеются средства, дающие неплохой результат, несмотря на
то, что они не относятся непосредственно к проектированию по контракту. На
пример, в языке
Elixir
применяются операторы защиты для диспетчеризации
вызовов функции по нескольким имеющимся ее телам:
defmodule Deposits do
def accept_deposit(account_id, amount) when (amount > 10000 0) do
# Вызвать диспетчер!
end
def accept_deposit(account_i d, amount) when (amount > 1000 0) do
# Дополнительные федеральные требования для отчетности
#Здесь выполняется неко т орая обработка ...
end
def accept_deposit(account i d, amount) when (amount > 0) do
#Здесь выполняется некот орая обработка ...
end
end
В данном случае вызов функции
accept_ depos i t ()
с крупной суммой мо
жет потребовать дополнительных шагов и обработки. Но если попытаться вы
звать данную функцию с суммой, меньшей или равной нулю, то возникнет при
веденное ниже исключение, которое извещает, что сделать такой вклад нельзя.
** (FunctionClauseError)
по function clause
matching in Deposits.acc ept_deposit / 2
Это лучше, чем просто проверять входные данные. В данном случае функцию
accept_ deposi t ()
просто нельзя вызвать, если ее аргументы указаны вне за
данных пределов.
Проектируйте по контракту
В разделе "Тема
10.
Ортогональность" главы
2
"Прагматичный подход" мы
рекомендовали писать "скромный" код. А здесь акцент делается на "ленивый"
код, предусматривающий строго относиться к тому, что принимается, прежде
чем начинать что-нибудь делать, а также обещать как можно меньше. Не следу
ет, однако, забывать, что если в контракте вы согласились принимать все, что
угодно, и наобещали на выходе целый мир, то для соблюдения такого контракта
вам придется написать немало кода! При программировании на любом языке,
будь то функциональном, объектно-ориентированном или процедурном, проек
тирование по контракту заставляет вас думать.
Глава 4 • Прагматичная паранойя
144
Инварианmь1 класса и функциональные языки
Все дело в названиях. Язык
Eiffel
является объектно-ориентированным, и по
этому Мейер назвал данное понятие "инвариантом класса". Но на самом деле это
более общее понятие, обозначающее состояние. В объектно-ориентированном
языке состояние связано с экземплярами классов, но ведь состояние имеется и в
других языках. Так, в функциональном языке состояние, как правило, передает
ся функции и принимается обновленным в результате ее выполнения. Понятия
инвариантов оказываются столь же полезными и в этих обстоятельствах.
ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ И РАЗРАБОТКА НА ОСНОВЕ ТЕСТИРОВАНИЯ
Есть ли потребность в проектировании по контракту там, где разработчики
практикуют модульное тестирование, разработку на основе тестирования
(Test-Driven Development -
TDD),
тестирование на основе свойств или за
щитное программирование? Конечно, есть.
Проектирование по контракту и тестирование
-
это разные подходы к
более обширной теме правильности программ. Оба подхода ценны и при
годны в разных ситуациях. Проектирование по контракту дает ряд преиму
ществ по сравнению с иными подходами к тестированию.
•
Оно не требует никакой подготовки или имитации.
•
Определяет параметры удачного или неудачного исхода во всех случа
ях, тогда как тестирование может быть одновременно нацелено лишь на
один конкретный случай.
•
Разработка на основе тестирования и другие разновидности тестирова
ния происходят в цикле сборки лишь во время тестирования, а проекти
рование по контракту и утверждения
-
постоянно: во время проектиро
вания, разработки, развертывания и сопровождения.
• Разработка на основе тестирования не сосредоточена на проверке внут
ренних инвариантов в тестируемом коде, а действует в большей степени
по принципу "черного ящика" для проверки открытого интерфейса.
• Проектирование по контракту более эффективно и соблюдает принцип
DRY точнее, чем защитное программирование, где все должны проверить
данные на достоверность, если этого никто больше не делает.
Разработка на основе тестирования
-
отличная методика, но, как и мно
гие другие методики разработки, она может привести к сосредоточению на
удачном пути, а не на реальном мире, где полно некачественных данных,
плохих исполнителей, неудачных версий и скверных спецификаций.
Тема 23 • Проектирование по контракту
145
РЕАЛИЗАЦИЯ ПРОЕКТИРОВАНИЯ ПО КОНТРАКТУ
Простое перечисление пределов области входных значений, граничных ус
ловий и того, что подпрограмма обещает (а еще важнее то, что она не обещает)
предоставить, перед тем, как писать код,
-
это огромный шаг вперед в разра
ботке более качественного программного обеспечения. Не сформулировав все
эти условия, вы, по существу, возвращаетесь к программированию по совпадению,
рассматриваемому в разделе "Тема
вы
7
38.
Программирование по совпадению" гла
"По ходу кодирования': Именно с этого начинаются, этим заканчиваются
и терпят крах многие проекты.
В тех языках, где проектирование по контракту в исходном тексте не подде
рживается, это может быть все, чего удастся достичь, но и это не так уж плохо.
Ведь проектирование по контракту
-
это всего лишь методика проектирова
ния. Даже не прибегая к автоматической проверке, можно внедрить контракт в
исходный текст в виде комментариев или как модульные тесты и, тем не менее,
извлечь из этого весьма реальную выгоду.
Утверждения
Несмотря на то что документирование подобных предположений служит хо
рошим началом, можно извлечь еще большую выгоду, заставив компилятор авто
матически проверять контракт. Такую проверку можно частично сэмулировать в
некоторых языках с помощью утверждений
(assertions) 25.
условий во время выполнения (см. далее раздел "Тема
проверки логических
Утвердительное про
граммирование"). А почему лишь частично? Нельзя ли с помощью утверждений
добиться всего, на что только способно проектирование по контракту?
К сожалению, нельзя. Прежде всего, в объектно-ориентированных языках
может не поддерживаться распространение утверждений по иерархии наследо
вания. Это означает, что если переопределить в базовом классе метод, имеющий
контракт, то утверждения, реализующие этот контракт, не будут корректно вы
званы, если только не продублировать их вручную в новом коде. И нужно не за
быть вызвать инвариант класса (и все инварианты базового класса) вручную пе
ред выходом из каждого метода. Главная трудность состоит в том, что контракт
не выполняется автоматически. А в других средах исключения, генерируемые из
утверждений, составленных в стиле проектирования по контракту, могут быть
отключены глобально или полностью проигнорированы исходным текстом.
Кроме того, не предусмотрено такое понятие, как "старые" значения, т.е. зна
чения, которые существовали на момент входа в метод. Если вы пользуетесь
утверждениями для проверки контрактов, то должны ввести код в предусловие,
чтобы сохранить любую информацию, которая потребуется в постусловии, если
язык вообще допускает такое. Так, в языке
Eiffel,
где, собственно, зародилось
проектирование по контракту, для этой цели достаточно воспользоваться вы
ражением
old.
Глава 4 • Праrматичная ларанойя
146
Наконец, обычные системы времени выполнения и библиотеки не предна
значены для поддержки контрактов, поэтому подобные вызовы не проверяются.
Это немалая потеря, поскольку на границе между прикладным кодом и приме
няемыми в нем библиотеками обнаруживается большинство затруднений (под
робнее об этом
-
далее в разделе "Тема
24.
Мертвые программы не лгут").
ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ И АВАРИЙНОЕ ЗАВЕРШЕНИЕ
Проектирование по контракту изящно вписывается в понятие досрочного
аварийного завершения (см. далее в разделе "Тема
24.
Мертвые программы не
лгут"). Используя механизм утверждений или проектирования по контракту для
проверки достоверности предусловий, постусловий и инвариантов, можно до
биться досрочного аварийного завершения программы и сообщить более точ
ные сведения о возникшей неполадке.
Допустим, имеется метод, вычисляющий квадратные корни. Этому методу тре
буется предусловие проектирования по контракту, ограничивающее область его
действия положительными числами. Если передать данному методу отрицатель
ное значение параметра
sqrt
в тех языках, где поддерживается проектирования
по контракту, то в конечном итоге будет получено сообщение об ошибке напо
добие
sqrt_arg_must_be_positive
(аргумент для извлечения квадратного
корня должен быть положительным) вместе с результатами трассировки стека.
Это, конечно, лучше, чем альтернатива, имеющаяся в других языках наподо
бие
Java,
С и С++, где в результате передачи методу отрицательного значения
параметра
sqrt
возвращается специальное значение NaN (не число). И если
некоторое время спустя попытаться выполнить в программе какие-нибудь ма
тематические операции над значением NaN, то в итоге будут получены совсем
неожиданные результаты.
Намного проще найти и диагностировать неполадку, досрочно достигнув
аварийного завершения в месте возникновения этой неполадки.
СЕМАНТИЧЕСКИЕ ИНВАРИАНТЫ
Семантические инварианты могут быть использованы для выражения не
изменных требований, нечто наподобие "философского контракта". Нам как-то
пришлось разрабатывать программный коммутатор транзакций по дебетовым
банковским карточкам. Главное требование состояло в том, чтобы пользова
тель дебетовой карточки не мог дважды выполнить одну и ту же транзакцию на
своем счету. Иными словами, какого бы рода режим отказа ни возник, ошибка
должна вызывать запрет обработки транзакции, но только не обработку дуб
лированной транзакции. Это простое правило, вытекающее непосредственно
из требований, оказывается очень полезным, когда приходится разбираться со
сложными случаями устранения ошибок. И оно направляет на путь подробного
проектирования и реализации во многих областях.
Тема 23 • Проектирование по контракту
147
Кто НЕСЕТ ОТВЕТСТВЕННОСТЬ
Кто же отвечает за проверку предусловия: вызывающий код или вызыва
емая подпрограмма? Если проектирования по контракту реализуется как
часть языка, то за такую проверку не отвечает ни то ни другое. Ведь предус
ловие проверяется подспудно после того, как подпрограмма будет вызвана
в вызывающем коде, но до входа в саму подпрограмму. Так, если требуется
выполнить явную проверку параметров, это должно быть сделано в вызы
вающем коде, поскольку самой подпрограмме вообще недоступны пара
метры, нарушающие предусловие. (В тех языках, где отсутствует встроенная
поддержка проектирования по контракту, чтобы проверить подобные ут
верждения, вызываемая подпрограмма должна иметь для этой цели преам
булу и/или заключительную часть.)
Рассмотрим в качестве примера программу, вводящую число с консоли, из
влекающую из него квадратный корень с помощью функции
водящую результат. У функции
sqrt ()
sqrt () и вы
имеется следующее предусловие: ее
аргумент не должен быть отрицательным. Если пользователь введет в кон
соли отрицательное число, то вызывающий код обязан принять меры, чтобы
оно не было передано функции sqrt () . У этого вызывающего кода имеется
много вариантов действий: прервать выполнение, выдать предупреждение
и потребовать ввести другое число в консоли, сделать число положитель
ным, или добавить к результату, возвращаемому функцией sqrt (), символ
мнимой единицы (1). Но какой бы выбор ни был сделан, это совершенно не
касается самой функции
sqrt () .
Выражая область действия функции
sqrt (), извлекающей квадратный ко
рень, в ее предусловии, вы фактически переносите бремя ответственности
за правильность на вызывающий код, где ему и место. И тогда вы можете
благополучно проектировать функцию
sqrt (), твердо зная, что ее вход
ные данные окажутся в пределах, заданных контрактом.
Ни в коем случае не путайте требования, являющиеся фиксированными и
неизменными правилами, с требованиями, представляющими собой лишь стра
тегии, которые моrут измениться вместе с новым режимом управления. Именно
поэтому мы пользуемся здесь термином семантические инварианты, поскольку
ему принадлежит центральное место в определении самой сути предмета, и он
не должен подчиняться прихотям стратегии, которой в большей степени отве
чают более динамичные бизнес-правила.
Когда вы обнаруживаете требование, которое может уточняться, примите
меры, чтобы оно стало хорошо известной частью любой составляемой докумен
тации, будь то маркированный список в документе требований, который под-
148
Глава 4 • Прагматичная паранойя
писывается в трех экземплярах, или же крупная заметка на общей белой доске,
видимой всем. Попробуйте сформулировать это требование ясно и однозначно.
Так, если вернуться к примеру с дебетовыми карточками, то такое требование
можно было бы сформулировать следующим образом:
Ошибка
-
в пользу потребителя.
Это ясная, краткая, однозначная формулировка, применимая на самых раз
ных участках системы. Это наш контракт со всеми пользователями системы и
наша гарантия ее поведения.
ДИНАМИЧЕСКИЕ КОНТРАКТЫ И АГЕНТЫ
До сих пор речь шла о контрактах как фиксированных, неизменяемых специ
фикациях. Но в области автономных агентов это совсем не обязательно должно
быть именно так. По определению автономные агенты вольны отвергать те за
просы, которые они не желают принимать во внимание. Они вольны согласовы
вать контракт заново, заявляя: "Я не могу это предоставить, но если вы дадите
мне то и это, тогда я мог бы предоставить вам что- нибудь другое':
Безусловно, любая система, опирающаяся на технологию агентов, находится
в решающей зависимости от договорных отношений, даже если они генериру
ются динамически.
Представьте: при достаточном количестве компонентов и агентов, способных
согласовывать между собой контракты, чтобы достичь поставленной цели, мы
могли бы просто дать программному обеспечению возможность разрешить кри
зис его производительности вместо нас.
Но если мы не можем пользоваться контрактами вручную, то не сможем
воспользоваться ими и автоматически. Поэтому в следующий раз, когда будете
проектировать какое-нибудь программное обеспечение, спроектируйте для него
контракт.
Другие разделы, связанные с данной темой
•
Тема
24.
Мертвые программы не лгут.
•
Тема
25.
Утвердительное программирование.
•
Тема
38.
Программирование по совпадению, глава
•
Тема
42.
Тестирование на основе свойств, глава
•
Тема
43.
Будьте осторожны, глава
•
Тема
45.
Западня требований, глава
7
7 "По ходу кодирования".
7
"По ходу кодирования".
"По ходу кодирования".
8
"До начала проекта".
Тема 24 • Мертвые программы не пгут
149
Задачи
•
Рассмотрите следующие вопросы для размышления: если проектирова
ние по контракту настолько эффективно, то почему оно не находит более
широкого применения? Трудно ли сформулировать контракт? Заставляет
ли это вас задуматься над теми вопросами, которые вы иначе проигнори
ровали бы? Заставляет ли это вас вообще ДУМАТЬ?! Очевидно, что это
опасное инструментальное средство!
Упражнения
14.
Разработайте интерфейс для кухонного блендера. В конечном итоге это дол
жен быть ориентированный на веб и Интернет вещей блендер, но пока что
требуется лишь интерфейс для управления им. В нем должны быть средства
для установки десяти скоростей, причем О означает выключение блендера.
Работать с блендером вхолостую нельзя, а его скорость можно изменять
лишь по очереди и на единицу, т.е. от О до
1и
от
1 до 2,
но не от О до
2.
Ниже приведены соответствующие методы. Добавьте соответствующие пред
и постусловия и инвариант.
int getSpeed ()
void setSpeed(int
boolean isFull ()
void fill ()
void ernpty ()
15.
х)
Сколько всего чисел в ряду О,
5, 10, 15, "., 100?
lljЫfJI МЕРТВЫЕ ПРОГРАММЫ НЕ ЛГУТ
Приходилось ли вам замечать, что иногда другие люди могут раньше вас об
наружить, что с вами что-то не так? То же самое случается и с кодом. Так, если
с одной из ваших программ случится что-то неладное, то неполадка иногда вы
является в сторонней библиотеке или каркасе. Причина может быть, например,
в том, что в библиотечную функцию было передано пустое значение
nil
или
же пустой список. Возможно, в хеше отсутствует ключ или значение, которое,
как нам казалось, содержит хеш, на самом деле содержит список. А может быть,
в сети или файловой системе произошла ошибка, которая не была перехвачена,
в результате чего были получены пустые или испорченные данные. Логическая
ошибка, совершенная пару миллионов операций назад, означает, что в селекторе
оператора
case больше не
ожидается значение
1, 2 или 3, и поэтому неожидан
defaul t. И это еще одна причина, по которой в
swi tch непременно должна присутствовать ветвь defaul t
но происходит переход к ветви
каждой инструкции
на тот случай, если произойдет нечто "невозможное':
150
Глава 4 • Прагматичная паранойя
Очень легко впасть в ошибку "этого не может произойти". Большинству из
нас приходилось писать код, в котором не проверялось успешное закрытие фай
ла и надлежащее написание оператора трассировки. И при прочих равных ус
ловиях нам это, вероятнее всего, было не нужно, поскольку мы считали, что
наш код не потерпит крах при любых нормальных условиях. Но мы используем
защитное программирование. В частности, проверяем данные на достоверность,
рабочий код
-
на работоспособность, а версии загруженных зависимостей
-
на правильность.
Все ошибки дают какую-то информацию для размышления. Можно, конеч
но, убедить себя, что ошибка не случится и просто проигнорировать ее. Вместо
этого программисты -прагматики говорят себе: если возникла ошибка, значит,
произошло что-то очень и очень скверное. Поэтому не забывайте читать все
эти отвратительные сообщения об ошибках (см. раздел "Программист в чужой
стране" главы
ПРИНЦИП
3).
11 ПОЙМАЛ-ОТПУСТИЛ"
-
только для ловли РЫБЫ
Некоторые разработчики считают хорошим стилем программирования пере
хватывать все исключения или восстанавливатьнормальную работу програм
мы после их возникновения, а также повторно генерировать их после вывода
какого-нибудь сообщения. В их коде можно найти немало таких мест, как в
приведенном ниже фрагменте, где пустой оператор
Logger.error("Can't add score: board is down. Exiting");
raise
rescue StaleTransaction
Logger.error("Can't add score: stale transaction. Exiting");
raise
end
А вот что написал бы программист- прагматик:
add_score_to_board(score);
Мы предпочитаем именно такой стиль по двум причинам. Во-первых, при
кладной код не затмевается обработкой ошибок. Во-вторых, что, вероятно, еще
важнее, прикладной код оказывается менее связанным. В приведенном выше
многословном примере приходится перечислять каждое исключение, которое
может быть сгенерировано в методе
add_ s core _ to _ board () . Если
автор это
го метода введет еще одно исключение, то его код едва заметно устареет. А в
Тема 24 • Мертвые проrраммы не лrут
151
более прагматичном втором примере новое исключение распространяется ав
томатически.
IЗфI§fJ:j Пользуйтесь досрочным аварийным завершением программы
АВАРИЙНОЕ ЗАВЕРШЕНИЕ ВМЕСТО ОТПРАВКИ НА СВАЛКУ
Одно из преимуществ как можно более раннего выявления неполадок состо
ит в возможности досрочного аварийного завершения. И зачастую это самое
лучшее, что можно делать. В качестве альтернативы можно продолжить, записав
испорченные данные в некоторую актуальную базу данных или дав стиральной
машине команду на двадцатом по счету цикле вращения ее барабана с бельем.
Именно такой принцип поддерживается в языках
Erlang и Elixir. Джо Армс
Erlang и автор книги Programmiпg Erlaпg: Software for
World [Arm07], часто говорил следующее: "Защитное программи
тронг, изобретатель языка
а Coпcurreпt
рование
-
это напрасная трата времени. Допускайте аварийное завершение!"
В таких средах предусматривается, что программы могут отказывать, но от
каз находится под управлением супервизора, отвечающего за выполнение кода
и знающего, что именно следует делать, если код откажет. К подобным мерам
относится очистка после сбоя, перезапуск кода и т.д. А что, если откажет сам
супервизор? Этим событием управляет его собственный супервизор, что приво
дит к архитектуре, состоящей из деревьев супервизоров. Такая методика довольно
эффективна и способствует применению упомянутых выше языков в высокона
дежных, отказоустойчивых системах:.
В других средах простой выход из работающей программы может оказать
ся неприемлемым. Ведь в ней могли быть затребованы ресурсы, которые могут
быть и не освобождены. А возможно, придется написать протокольные сообще
ния, очистить открытые транзакции или организовать взаимодействие с други
ми процессами .
Тем не менее основной принцип остается прежним: если в прикладном коде
обнаруживается, что произошло нечто, предполагавшееся невозможным, такой
код больше не считается жизнеспособным. И все, что в таком коде делается
дальше, становится подозрительным, а следовательно, его выполнение следует
прервать как можно скорее. Мертвая программа, как правило, наносит намного
меньше вреда, чем испорченная.
Другие разделы, связанные с данной темой
•
Тема
20.
Отладка, глава
•
Тема
23.
Проектирование по контракту.
3
"Основные инструментальные средства".
Глава 4 • Прагматичная паранойя
152
•
Тема
25.
Утвердительное программирование.
•
Тема
26.
Как сбалансировать ресурсы.
•
Тема
43.
Будьте осторожны, глава
7 "По
ходу кодирования':
ltjЫ;f\j УТВЕРДИТЕЛЬНОЕ ПРОГРАММИРОВАНИЕ
"В самобичевании есть свое наслаждение.
И когда мы виним себя сами, то чувствуем,
что никто другой не вправе винить нас".
Оскар Уайльд, Портрет Дориана Грен
По-видимому, есть такая мантра, которую каждый программист должен за
помнить, едва начав свою карьеру. Это основополагающий постулат, убеждение,
которое мы учимся применять к требованиям, проектам, исходному коду, ком
ментариям и практически ко всему, что мы делаем. И он гласит:
Это никогда не может случиться ...
Примерами тому служат следующие рассуждения: "Это приложение никог
да не будет применяться за рубежом, так зачем его интернационализировать?",
"Переменная
coun t
не может принимать отрицательное значение" или "Прото
колирование не может дать сбой': Старайтесь избегать в своей практике подоб
ного самообольщения, особенно во время программирования.
Gфt§fkl Пользуйтесь утверждениями, чтобы предотвратить невозможное
Всякий раз, когда вы ловите себя на мысли "но этого, конечно, никогда не
сможет случиться", вводите код для ее проверки. И сделать это проще всего с
помощью утверждений. В реализациях многих языков можно обнаружить неко
торую форму утверждений в виде оператора
кое
условие3 .
assert,
где проверяется логичес
Такие проверки моrут оказаться неоценимыми. Так, если параметр
или результат вообще не должен быть пустым
(null),
его следует проверить
явным образом, как показано ниже.
assert (result != null) ;
3
В языках С и С++ утверждения обычно реализуются в виде макрокоманд, а в языке Java
они запрещены по умолчанию. Чтобы разрешить их, следует вызвать виртуальную ма
шину
Java с параметром
решенными.
-enaЫeassertions из командной строки, и оставить их раз
Тема 25 •Утвердительное программирование
В реализации
Java
153
можно (и нужно) ввести в утверждение описательную
строку следующим образом:
assert result != null
&&
result. size () >
О
: "Empty result from XYZ";
Утверждения полезны также для проверки функционирования алгоритмов.
Так, если написать алгоритм изощренной сортировки под названием
my_sort,
проверить его работоспособность можно, например, таким образом:
books = my_sort (find ("scifi"))
assert(is_sorted?(books))
Ни в коем случае не пользуйтесь утверждениями вместо реальной обработки
ошибок. Утверждения позволяют проверить то, что никогда не должно случить
ся. Вряд ли вам захочется написать код, аналогичный приведенному ниже.
цесс, если утверждение не выполняется, не является причиной для того, чтобы
это происходило и в написанных вами версиях программного обеспечения. Так,
если вам требуется освободить используемые ресурсы, перехватите исключение,
возникшее в утверждении, или прервите выход из программы, а затем выполни
те свой обработчик ошибок. Нужно лишь сделать так, чтобы код, выполняемый
в течение этих истекающих миллисекунд, прежде всего не опирался на инфор
мацию, послужившую причиной того, что утверждение не подтвердилось.
УТВЕРЖДЕНИЯ И ПОБОЧНЫЕ ЭФФЕКТЫ
Если код, вводимый для обнаружения ошибок, фактически приводит к но
вым ошибкам, то положение только усугубляется. Такое может случиться и с
утверждениями, если проверка условия имеет побочные эффекты. Например,
написание следующего фрагмента кода вряд можно считать удачной идеей:
Это разновидность неопределенной, едва уловимой программной ошибки
под названием гейзенбаг4 , которая изменяет поведение отлаживаемой системы.
Мы также считаем, что теперь, когда в большинстве языков имеется приличная
поддержка функций, циклически перебирающих коллекции, такого рода явный
цикл не нужен и является неудачной разновидностью их обработки.
ОСТАВЛЯЙТЕ ВКЛЮЧЕННЫМ РЕЖИМ УТВЕРЖДЕНИЙ
В отношении утверждений существует весьма распространенное заблуждение:
Утверждения вносят некоторые издержки в код. Они проверяют то,
что никогда не должно случиться, и поэтому приводятся в действие
только программной ошибкой в коде. И как только код будет проверен
и доставлен потребителю, они больше не потребуются, а следователь
но, режим утверждений можно отключить, чтобы код выполнялся быс
трее. Утверждения являются средством отладки исходного кода.
В приведенном выше рассуждении есть два заведомо ложных допущения. Во
первых, в нем предполагается, что во время тестирования обнаруживаются все
программные ошибки. В действительности в любой сложной программе вряд
ли удастся проверить даже мельчайшую долю всех перестановок, сделанных в
исходном коде. И во-вторых, оптимисты забывают, что их программы выпол
няются в опасной среде. Во время тестирования крысы вряд ли перегрызут ка
бель связи, игрок исчерпает оперативную память по ходу компьютерной игры,
а журнальные файлы заполнят весь раздел запоминающего устройства. Подоб
ные события скорее могут произойти при выполнении программы в реальной
эксплуатационной среде. Поэтому вашей первой линией обороны должна стать
проверка любых возможных ошибок, а второй линией
-
применение утверж
дений, чтобы попытаться обнаружить пропущенные ошибки.
Выключение режима утверждений при запуске программы в эксплуатацию
можно сравнить с хождением по натянутой под куполом цирка проволоке без
страховочной сетки только потому, что это уже однажды удалось сделать. В этом
есть драматичность и зрелищность, но не страховка от смертельного исхода.
Даже если вам приходится решать вопросы производительности, выключайте
лишь те утверждения, которые действительно отрицательно влияют на произ
водительность. Так, приведенный выше пример сортировки может быть крайне
важной частью приложения, которая должна выполняться побыстрее. Добав
ление в нее проверки означает еще один проход данных, что может оказаться
неприемлемым. Поэтому сделайте эту конкретную проверку необязательной, но
оставьте остальные проверки без изменений.
Название rейзенбаr (Heisenbug) происходит от принципа неопределенности Гейзенберга
(bug). Подробнее об этом
см. по адресу http://www. eps .mcgill. ca/j argon/jargon .html#heisenbug или
4
из квантовой механики и, собственно, программной ошибки
https://ru.wikipedia.org/wiki/Гeйзeнбaг.
Тема 25 • Утвердительное программирование
155
ПРИМЕНЕНИЕ УТВЕРЖДЕНИЙ в усnовиях PEAllbHOЙ
зксnnУАТАЦИИ ПРИНОСИТ HEMAllYIO ПРИ&ыпь
Бывший сосед Энди руководил небольшой начинающей компанией, произ
водившей сетевые устройства. Одним из секретов их успеха было решение
оставить утверждения на месте в рабочих версиях. Эти утверждения были
достаточно грамотно составлены, чтобы сообщать всю информацию, име
ющую отношение к сбоям, а также представлены конечному пользовате
лю через изящного вида интерфейс. Такой уровень организации откликов
реальных пользователей в конкретных условиях эксплуатации позволял
разработчикам затыкать дыры в защите и устранять едва заметные, труд
но воспроизводимые программные ошибки, а следовательно, производить
необыкновенно устойчивое, надежное программное обеспечение. Эта не
большая, малоизвестная компания производила настолько добротную про
дукцию, что вскоре была приобретена за сотни миллионов долларов. Но это
так, к слову.
Другие раэделы, свяэанные с данной темой
•
Тема
23.
Проектирование по контракту.
•
Тема
24.
Мертвые программы не лгут.
•
Тема
42. Тестирование
•
Тема
43.
на основе свойств, rлава
Будьте осторожны, глава
7 "По
7 "По
ходу кодирования".
ходу кодирования':
Упражнения
16.
Быстрая проверка на чувство реальности. Какие из перечисленных ниже
"невозможных" событий могут все же произойти?
Месяц, в котором меньше
-
28
дней.
Код ошибки, возвращаемый из системного вызова и обозначающий не
возможность доступа к текущему каталогу.
= 2, Ь = 3,
но (а
+
Ь) не равно
--
В языке С++: а
-
Треугольник, сумма углов которого не равна
Минута, не насчитывающая
-
(а
+
1)
= 0.00)
@balance = @balance.add(transaction_amount,2)
write customer
end
end
Во время тестирования этот код вроде бы ведет себя как следует. Но когда этот
код запускается в эксплуатацию, он терпит крах несколько часов спустя, завер
шаясь предупреждением о том, что открыто слишком много файлов. И оказыва
ется, что при определенных обстоятельствах подпрограмма
wri te _ customer ()
не вызывается. И когда этого происходит, файл не закрывается.
Весьма неудаttным решением данной задачи была бы попытка реализовать
особый случай в подпрограмме
update _ customer ():
def update_customer(transaction_amount)
read customer
if (transaction_amount >= 0.00)
@balance += BigDecimal(transaction_amount, 2)
write customer
else
@customer file.close # Плохое решение!
end
end
И хотя такое решение устраняет затруднение, поскольку файл теперь будет
закрыт независимо от нового баланса на счете, тем не менее, теперь данное
исправление означает, что все три подпрограммы связаны общей переменной
customer_ file,
6 Подробнее об
главы
5.
а слежение за тем, открыт ли файл или закрыт, начинает при-
опасностях, кроющихся в связанном коде, см. в разделе "Тема 28. Развязка"
158
Глава 4 • Прагматичная паранойя
ходить в полный беспорядок. В итоге наш программист попадает в ловушку, и
все дело начнет быстро катиться под откос, если продолжить его в том же духе.
Это и есть признак несбалансированности!
Совет "Завершайте то, что начали" предписывает, что в идеальном случае
подпрограмма, выделяющая ресурс, должна его освободить. Чтобы восполь
зоваться этим советом, реорганизуем немного рассматриваемый здесь код, как
показано ниже.
def read_customer(file)
@balance=BigDecimal(file.gets)
end
def write_customer(file)
file.rewind
file.puts @balance.to s
end
def update customer(transaction_amount)
file=File.open(@name + ".rec", "r+")
read_customer(file)
@balance = @balance.add(transaction_amount,2)
file.close
# >--
#
#
# --
#
#
#
# all_subsets_longer_than_three_characters()
1> as_unique_signatures()
1> find_in_dictionary()
1> group_by_length()
Это всего лишь цепочка преобразований, необходимых для удовлетворения
исходного требования, причем каждое из них принимает входные данные из
предыдущего преобразования и передает выходные данные следующему преоб
разованию. И это как можно более точно приводит непосредственно к коду.
Но дело здесь обстоит несколько сложнее, чем кажется на первый взгляд.
Так, если у вас есть навыки объектно-ориентированного программирования, то
ваши рефлексы требуют скрывать данные, инкапсулируя их в объектах, которые
обмениваются ими, изменяя состояние друг друга. А поскольку это приводит к
внесению в программу связывания, то служит веским основанием считать объ
ектно-ориентированные системы с трудом поддающимися изменениям.
Не накапливайте состояние, а передавайте его по кругу
В преобразовательной модели дело меняется коренным образом. Вместо не
больших массивов, распределенных по всей системе, данные следует уподобить
194
Глава S • Гибкость или ломкость
в рассуждении могучей реке или потоку. Таким образом, данные становятся
сродни функциональным возможностям, где конвейер
-
это последовательность
код~ данные~ код~ данные ... Данные больше не привязаны к конкретной
группе функций, как это обычно делается в определении класса. Напротив, они
свободно представляют постепенно развертывающийся в приложении процесс
преобразования входных данных в выходные. А это означает возможность зна
чительно сократить связывание, поскольку одну функцию можно использовать
(и неоднократно) везде, где ее параметры совпадают с выходом из какой-нибудь
другой функции.
Впрочем, определенная степень связывания все же существует, но, как пока
зывает наш опыт, она легче поддается управлению, чем при объектно-ориенти
рованном программировании. И если вы программируете на языке с проверкой
соответствия типов, то получите предупреждения во время компиляции, если
попытаетесь соединить две несовместимые вещи.
А КАК НАСЧЕТ ОБРАБОТКИ ОШИБОК
До сих пор рассматриваемые здесь преобразования действовали в такой сре
де, где ничего неверного не происходит. Но как выполнить их в реальной обста
новке? Если можно составить лишь линейные цепочки, то как внедрить всю ту
условную логику, которая требуется для проверки ошибок?
Это можно сделать самыми разными способами, но все они основываются на
следующем соглашении: значения ни в коем случае нельзя передавать от одного
преобразования к другому в исходном виде, а вместо этого их следует заклю
чать в структуру (или тип) данных, где можно проверить достоверность содер
жащихся в них значений. Например, в языке
МауЬе, а в языках
F#
и
Haskell такая
оболочка называется
Scala - Option.
Особенности применения данного принципа зависят от конкретного языка
программирования. Но в общем, реализовать его непосредственно в коде мож
но двумя способами: проверять ошибки в самих преобразованиях или же за их
пределами.
В языке
Elixir,
которым мы пользовались в приведенных до сих пор примерах
кода, отсутствует встроенная поддержка обработки ошибок при преобразовани
ях. Но это вполне отвечает нашим целям, поскольку нам нужно продемонстри
ровать реализацию такой обработки ошибок с самого начала. Нечто подобное
должно оказаться пригодным и для программирования на других языках.
Сначала выбирается представление
Нам потребуется некоторое представление оболочки, т.е. структуры данных,
содержащей значение или признак ошибки. Для этой цели можно воспользо
ваться структурами, но в языке
Elixir уже
имеется следующее довольно строгое
соглашение: функции преимущественно возвращают кортеж
{ : о k,
значение}
Тема 30 • Преобразовательное программирование
195
{ : error, причина}. Например, функция File. open () возвращает при
: ok и идентификатор процесса ввода-вывода или же признак : error и код
причины ошибки, как показано ниже. Кортежами с признаками : ok и : error
или
знак
можно воспользоваться в качестве оболочки, передавая результаты преобразо
ваний по конвейеру.
iex(l)> File.open("/etc/passwd")
{:ok, #PID}
iex(2)> File.open("/etc/womЬat")
{:error, :enoent}
Затем обработка ошибок выполняется в каждом преобразовании
Итак, напишем функцию, возвращающую из файла все строки, содержащие
заданную символьную строку, усеченную до
20
первых символов. Эту функцию
требуется написать как преобразование с именем файла и сопоставляемой сим
вольной строкой в качестве входных данных, а также с кортежем, содержащим
признак
: ok
и список строк или же признак
: error
и причину ошибки, в ка
честве выходных данных. В общих чертах такая функция должна выглядеть сле
дующим образом:
function-pipelines/anagra.ms/liЬ/grep.ex
def find_all(file_name, pattern) do
File.read(file_name)
1> find_matching_lines(pattern)
1> truncate_lines()
end
Здесь ошибки не проверяются явным образом, но если на любой стадии
конвейерного процесса возвращается кортеж с признаком ошибки, то обнару
женная ошибка будет возвращена из конвейера, причем последующие функции
далее не выполняются 8 • Это делается языковыми средствами Elixir для сопостав
ления с шаблоном, как показано ниже.
function-pipelines/anagra.ms/liЬ/grep.ex
defp find_matching_lines({:ok, content}, pattern) do
content
1> String.split(-r/\n/)
1> Enum.filter(&String.match?(&l, pattern))
1> ok_unless_empty()
end
defp find_matching_lines(error,
# ---------8 Мы
), do: error
допустили здесь некоторую вольность. Технически последующие функции выполня
find_matching_lines ().Если в качестве
: о k, то содержимое этого
ее первого параметра указан кортеж с признаком
кортежа используется для поиска строк, совпадающих с заданным шаблоном
pattern.
Но если кортеж с признаком
: ok
не указан в качестве первого па
раметра данной функции, то выполняется ее второй вариант, который прос
то возвращает этот параметр. Таким образом, данная функция просто переда
ет ошибку дальше по конвейеру. Аналогичным образом действует и функция
truncate lines().
Мы можем поэкспериментировать с этим в консоли, как показано ниже.
И, как видите, ошибка, возникающая в любом месте конвейера, сразу же стано
вится его значением.
iex> Grep.find_all "/etc/passwd", -r/www/
( :ok, ["_www:*:70:70:World W", "_wwwproxy:*:252:252:"])
iex> Grep.find_all "/etc/passwd", -r/womЬat/
(:error, "nothing found")
iex> Grep.find_all "/etc/koala", -r/www/
(:error, :enoent)
Иначе обработка ошибок выполняется в самом конвейере
Глядя на функции
find_matching_lines ()
и
truncate_lines (),
мож
но подумать, что бремя ответственности за обработку ошибок перенесено на
преобразования. Так и есть. В таком языке, как
Elixir,
где в вызовах функций
применяется сопоставление с шаблоном, последствия подобного переноса смяг
чаются, но они все равно скверные.
Было бы неплохо, если бы в языке
Elixir была
внедрена такая разновидность
конвейерного оператора
1>, которому было бы известно, как обращаться с кор
тежами : ok/: error, чтобы сократить выполнение, когда возникает ошибка 9 .
9
На самом деле такой оператор можно внедрить в Elixir, используя его макросредства.
Примером тому служит библиотека
Monad
в шестнадцатеричной форме. Для этой цели
можно также воспользоваться конструкцией
wi th
языка
Elixir,
но тогда потеряет всякий
смысл программирование преобразований, выполняемых с помощью конвейеров.
Тема 30 ·- Преобразовательное программирование
Но, к сожалению, ничего подобного нельзя сделать в
197
Elixir, причем так, чтобы это
было применимо и в ряде других языков.
Дело в том, что когда возникает ошибка, было бы нежелательно выполнять код
дальше по конвейеру, где совсем не обязательно знать о возникшей ошибке. Это
означает, что выполнение некоторых функций в конвейере придется отложить до
тех пор, пока не станет известно, что предыдущие стадии конвейерного процесса
завершились удачно. И для этого вызовы функций придется заменить значени
ями функций, которые могут быть вызваны позднее. Ниже приведен один из
примеров реализации такого подхода к обработке ошибок в конвейере.
function-pipelines/anaqrams/liЬ/qrepl.ex
defmodule Grepl do
def and_then({ :ok, value ), func), do: func. (value)
def and_then(anything_else, func), do: anything_else
def find_all(file_name, pattern) do
File.read(file_name)
1> and_then(&find_matching_lines(&l, pattern))
1> and_then(&truncate_lines(&l))
end
defp find_matching_lines(content, pattern) do
content
1> String.split(-r/\n/)
1> Enum.filter(&String.match?(&l, pattern))
1> ok_unless_empty()
end
defp truncate_lines(lines) do
lines
1> Enum.map(&String.slice(&l,
1 > ok ()
end
О,
20))
defp ok unless _ empty ( []) ,
do: error ( "nothing found")
defp ok_unless_empty(result), do: ok(result)
defp ok(result),
do:
:ok, result)
defp error(reason), do: { :error, reason)
end
Функция
and_ then ( )
служит примером функции связывания. Она принимает
значение, заключенное в некоторую оболочку, а затем применяет к нему заданную
функцию, возвращая новое значение, заключенное в оболочку. Чтобы восполь
зоваться функцией
and_ then ()
в конвейере, потребуется дополнительная рас
становка знаков препинания, поскольку в языке
Elixir
требуется явно указывать
преобразование вызовов функций в значения функций, хотя эти дополнительные
усилия возмещаются тем, что функции преобразования упрощаются. В частности,
каждая из них принимает значение (и любые дополнительные параметры) и воз
вращает кортеж
{ : ok,
новое_значение} или
{ : error,
причина}.
Глава S • Гибкость 11л11 ломкость
198
ПРЕОБРАЗОВАНИЯ ПРЕОБРАЗУЮТ ПРОГРАММИРОВАНИЕ
Осмысление кода как последовательности (вложенных) преобразований мо
жет стать освободительным подходом к программированию. Чтобы привыкнуть
к этому, потребуется время, но как только вы выработаете в себе такую привыч ку, то обнаружите, что ваш код станет более ясным, функции
а проекты
более краткими,
-
более ровными. Попробуйте!
-
Другие разаель1, связанные с данной темой
•
Тема
8.
Сущность качественного проектирования, глава
2
"Прагматичный
подход':
• Тема 17. Игры в скорлупки, глава 3 "Основные инструментальные сред
ства".
• Тема 26. Как сбалансировать ресурсы, глава 4 "Прагматичная паранойя':
•
Тема
28.
Развязывание.
•
Тема
35.
Акторы и процессы, глава
6
"Параллельность':
Упражнения
21.
Можете ли вы выразить перечисленные ниже требования в виде преобразо
вания верхнего уровня? Определите для каждого из них входные и выход
ные данные.
1)
2)
3)
22.
Налоги на поставку и с продаж добавляются в заказ.
Приложение загружает конфигурацию из именованного файла.
Пользователь входит в веб-приложение, регистрируясь в нем.
Допустим, вы выяснили потребность проверить на достоверность и преоб
разовать символьную строку из поля ввода в целое число, находящееся в
пределах от
18
до
150.
В общих чертах такое преобразование описывается
следующим образом:
field contents as string
---+ [validate & convert]
---+ { : ok, value} 1 { : error, reason}
Напишите код, реализующий отдельные преобразования, включающие про
верку на достоверность и преобразование.
23.
Ранее во врезке "Отсутствие конвейеров в языке Х" был приведен следую
Мноrие разработчики пишут объектно-ориентированный код, составляя
в цепочку вызовы методов. Они моrли бы поддаться искушению написать
приведенный выше фрагмент кода так, как показано ниже.
Чем отличаются оба эти фрагмента кода? Какой из них, на ваш взrляд, явля
ется более предпочтительным?
lijЫfli НАЛОГ НА НАСЛЕДОВАНИЕ
"Вам захотелось бананов, но в итоге вы получили
гориллу, держащую банан, и целые джунгли".
Джо Армстронг 10
Проrраммируете ли вы на объектно-ориентированном языке и пользуетесь
ли вы наследованием? Если так, то остановитесь! Ведь это, вероятнее всего, сов
сем не то, что вам требуется. В этом разделе поясняются причины.
НЕМНОГО ПРЕДЫСТОРИИ
Наследование впервые появилось в языке
Simula 67
в
1969
rоду. Это было
изящное решение задачи упорядочения нескольких типов событий в одном и
том же списке. В подходе к наследованию, принятом в языке
Simula, принялись
так называемые префиксные классы. Это давало возможность написать код, ана
логичный приведенному ниже.
link CLASS car;
... реализация автомобиля
link CLASS bicycle;
... реализация вело сип ед а
В данном коде
link обозначает префиксный класс, внедряющий функцио
нальные возможности связанных списков. Это позволяет ввести автомобили и
велосипеды в список транспортных средств, ожидающих, например, зеленого
света дорожноrо светофора. В современной терминолоrии
link обозначает
ро
дительский класс.
Мысленная модель, применявшаяся программирующими на
в том, что данным экземпляра и реализации класса
лизация классов
car
и Ьicycle, а часть
link
link
Simula, состояла
предшествовала реа
этой модели рассматривалась в
основном как контейнер для хранения автомобилей и велосипедов. Тем самым
10
Joe Armstrong - создатель языка Erlang. - Примеч. пер.
Глава 5 , Гибкость или ломкость
200
программирующие на
Simula
получали в свое распоряжение такую форму по
лиморфизма, в которой автомобили и велосипеды реализовывали интерфейс
link,
поскольку и те и другие содержали код
link.
Вслед за Simula последовал язык Smalltalk. Алан Кей, один из создателей
Smalltalk, отвечает на портале вопросов и ответов Qиora за 2019 год 11 на вопрос,
почему в этом языке имеется наследование, следующим образом:
"Когда я разработал язык Sтalltalk-72 (а зто было сделано шутки ради
по зрелом размышлении о Sтalltalk-71), я подумал, что было бы забавно
воспользоваться Lisр-подобной динамикой для экспериментирования с
"дифференциальным программированием". (Имеются в виду различные
способы осуществить нечто подобное методом исключения.)"
Это, в сущности, означает наследование исключительно для поведения.
Обе эти разновидности наследования, у которых было очень много обще
го, постепенно развивались в течение последующих десятилетий. Принятый в
Simula подход,
который предполагал в наследовании способ объединения типов
данных, был продолжен в таких языках, как С++ и
Smalltalk,
Java.
А направление, взятое в
где наследование считалось динамической организацией видов пове
дения, нашло свое продолжение в таких языках, как
Ruby и JavaScript.
С тех пор выросло целое поколение разработчиков объектно-ориентирован
ных приложений, которые пользуются наследованием по одной из двух причин:
они не любят набирать код на клавиатуре или же им нравятся типы данных.
Те, кто не любит набирать код на клавиатуре, берегут свои пальчики, исполь
зуя наследование для внедрения общих функциональных возможностей из ба
зового класса в порожденные классы. Например, подклассы
являются производными от класса
Acti veRecord: : Base.
User
и
Product
А те, кому нравятся
типы данных, пользуются наследованием для того, чтобы выразить отношение
между классами. Например, класс
Car
реализует автомобиль как разновидность
транспортного средства, реализуемого в классе
Vehicle.
Но, к сожалению, при
менение обеих упоминаемых здесь разновидностей наследования вызывает оп
ределенные трудности.
ТРУДНОСТИ ПРИМЕНЕНИЯ НАСЛЕДОВАНИЯ ДЛЯ
СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ КОДА
Наследование означает связывание. При этом связывается не только порож
денный класс с родительским, но и родительский класс со своим родителем и
т.д. Но исходный код, в котором применяется порожденный класс, связывается
также со всеми своими предками. Ниже приведен характерный тому пример.
См. по адресу https: / /www.quora.com/What-does-Alan-Kay-think-aboutinheritance-in-object-oriented-programming.
11
Тема 31 • Налог на наследование
201
class Vehicle
def initialize
@speed = О
end
def stop
@speed = О
end
def move_at(speed)
@speed = speed
end
end
class Car < Vehicle
def info
"I'm car driving at #{@speed}"
end
end
#
код верхнего уровня
my_ride
=
Car . new
my_ride.move_at(ЗO)
my_са r . move _а t ( ) , вызывается
метод из класса Vehicle, являющегося родительским для класса Car. Теперь,
когда разработчик, отвечающий за класс Vehicle, вносит изменения в API, ме
тод move _а t ( ) превращается в метод s е t _ ve l о с i t у ( ) , а переменная экземп
ляра @speed - в переменную @velocity.
Когда на верхнем уровне делается вызов
Следует ожидать, что изменения в
Vehicle.
API
нарушат поведение клиентов класса
Но этого не произойдет на верхнем уровне
касается применения в нем класса
Car.
-
по крайней мере, что
Ведь то, что делается в классе
Car
с точ
ки зрения реализации, не касается кода верхнего уровня, хотя его функциони
рование все же нарушается. Аналогично имя переменной экземпляра относит
ся исключительно к подробностям внутренней реализации, но когда вносятся
изменения в класс
Car.
Vehicle,
негласно нарушается и функционирование класса
И все это объясняется слишком тесным связыванием.
Трудности применения наследования для построения типов данных
Некоторые разработчики усматривают в наследовании способ определения
новых типов данных. Их излюбленная проектная диаграмма показывает иерар
хии классов. Они рассматривают решаемые задачи так, как викторианские бла
городные ученые рассматривали в свое время природу как нечто, разделяемое
на категории.
Vehice
Car
Bicycle
202
Глава 5 • Гибкость или ломкость
Но, к сожалению, такие диаграммы вскоре, по мере ввода новых уровней
наследования с целью выразить в мельчайших подробностях отличия между
классами, вырастают до чудовищных размеров на всю стену. Такое усложнение
способно сделать приложение более хрупким, как только вносимые в него изме
нения станут распространяться вверх и вниз по уровням наследования.
Еще хуже дело обстоит с множественным наследованием. В частности, авто
мобиль, представленный в классе
Car,
может быть разновидностью не только
транспортного средства, представленного в классе
Vehicle,
но и активом, за
страхованной или закладываемой под ссуду частной собственностью, представ
ленными классами
Asset, Insuredltem и LoanCollateral
соответственно .
Для правильного моделирования такой иерархии классов потребуется множест
венное наследование.
В 1990-е годы множественное наследование получило в языке С++ неудачное
название в силу некоторой сомнительно разрешающей противоречия семанти
ки. В результате во многих современных объектно-ориентированных языках
оно не поддерживается. Это означает, что вам не удастся точно смоделировать
предметную область своего приложения, даже если вас вполне удовлетворяют
сложные деревья типов данных.
Не платите налог на наследование
ЛУЧШИЕ АЛЬТЕРНАТИВЫ
Рассмотрим три следующие методики программирования, которые обознача-
ют, что вы не должны больше пользоваться наследованием.
•
Интерфейсы и протоколы.
•
Делегирование.
•
Миксины и свойства.
Тема 31 • Налог на наследование
203
Интерфейсы и протоколы
В большинстве объектно-ориентированных языков можно указать, что в
классе реализуется один или несколько видов поведения. Например, в классе
Car
реализуются виды поведения DrivaЫe и LocataЫe. Синтаксис, приме
няемый для этой цели, отличается в разных языках. Так, в языке
Java
он может
выглядеть следующим образом:
puЫic
11
11
11
class Car implements DrivaЫe, LocataЫe {
Car. Этот код должен включать
Код для класса
в себя функциональные возможности обоих
интерфейсов DrivaЫe и LocataЫe
DrivaЫe и LocataЫe называются в языке
языках программирования
-
Java
интерфейсами, а в других
протоколами, а в некоторых
-
свойствами
(traits)
(хотя термином "свойство" мы будем в дальнейшем называть нечто иное).
В приведенных выше объявлениях не программируется никаких действий, а
просто извещается, что в любом классе, реализующем интерфейс
Dri vаЫе, обя
getSpeed () и stop (), а в классе, реализующем
интерфейс LocataЫe, - методы getLocation () и locationisValid ().
Это означает, что предыдущее определение класса Car окажется действитель
заны быть реализованы методы
ным лишь в том случае, если в него будут включены эти четыре метода.
Сильной стороной интерфейсов и протоколов является возможность поль
зоваться ими как типами данных, причем любой класс, реализующий соответс
твующий интерфейс, будет совместим с его типом. Так, если оба класса
Phone
Car
и
реализуют интерфейс LocataЬle, то их объекты можно размещать в
списке элементов, определяемых по местоположению, как показано ниже.
В таком случае можно обработать данный список, зная наверняка, что у каж
дого его элемента имеются методы
getLocation ()
и
locationisValid ():
204
Глава 5 • Гибкость или ломкость
void printLocation(Lo c ataЫe item) {
if (item.locationisValid() {
print(item.getLocation() .asString());
11
items.forEach(printLoc ation);
Выражать полиморфизм предпочтительнее
с помощью интерфейсов
Интерфейсы и протоколы обеспечивают полиморфизм без наследования.
Делегирование
Наследование побуждает разработчиков создавать классы, у объектов ко
торых имеется большое количество методов . Так, если в родительском классе
имеется
20
методов, а в его подклассе требуется воспользоваться лишь двумя из
них, то в его объектах все равно будут доступны для вызова
18
остальных мето
дов. Можно сказать, что такой класс потерял контроль над своим интерфейсом,
и это типичное затруднение. Так, многие каркасы хранения и пользовательского
интерфейса требуют, чтобы компоненты приложения осуществляли наследова
ние подкласса от предоставляемого каркасом базового класса:
class Account < PersistenceBaseClass
end
Класс
Account содержит теперь весь
PersistenceBaseClass. Рассмотрим в
прикладной интерфейс
API
класса
качестве альтернативы применение
делегирования, как в приведенном ниже примере.
class Account
def initialize( . . . )
@repo = Persister.for(self)
end
def save
@repo. save ()
end
end
Теперь из прикладного интерфейса
Account.
API
ничто не доступно клиентам класса
Более того, мы не ограничены в своих действиях только
емого каркаса хранения и можем создать новый
API
API
применя
при надобности в таковом .
Разумеется, мы могли бы сделать это и ранее, но всегда есть риск, что напи
санный нами интерфейс может быть обойден, а вместо него использован
каркаса хранения . Теперь же мы полностью контролируем ситуацию.
API
Тема 31 • Налог на наследование
205
Делегируйте полномочия службам: отношение СОДЕРЖИТ
превосходит отношение ЯВЛЯЕТСЯ
На самом деле можно пойти еще дальше. Зачем, например, классу
Account
знать, как сохраняться? Обязан ли он знать и соблюдать бизнес-правила ведения
учетной записи?
class Account
# ничего, кроме
end
сведений об учетной записи
class AccountRecord
# заключает в себе учетную
# извлечения и сохранения
end
запись с возможностями
Теперь развязывание действительно достигнуто, хотя и не бесплатно. Для
этого пришлось написать больше кода, часть которого, как правило, стереотип
ная. И вероятнее всего, что во всех классах записи потребуется, например, ме
тод
find ().Правда,
для этой цели имеются миксины и свойства.
Миксинь1, свойства, категории, расширения протоколов и прочее
Те, кто работают в той же отрасли, где и все мы, любят присваивать разным
понятиям замысловатые названия. И зачастую им присваиваются многие назва
ния. И чем их больше, тем лучше, не так ли?
Именно так и происходит, когда мы рассматриваем понятие миксинов
(mixin).
В их основу положена довольно простая идея: потребность в возможности рас
ширить классы и объекты новыми функциональными возможностями, не при
бегая к наследованию. С этой целью мы создаем ряд функций, присваиваем им
имя, а затем определенным образом расширяем с их помощью класс или объект.
И в этот момент создается новый класс или объект, сочетающий в себе функци
ональные возможности исходного класса и всех его миксинов. Зачастую такое
расширение удается осуществить, даже если отсутствует доступ к исходному
коду расширяемого класса.
Реализация и название этих средств расширения отличается в разных языках.
И хотя они называются здесь миксинами, их лучше рассматривать как средства,
не зависящие от конкретного языка. И самое главное, что все их реализации
обладают способностью объединять существующие и новые функциональные
возможности.
Вернемся снова к примеру класса
AccountRecord.
В том виде, в каком мы
оставили этот класс, ему нужно было знать как об учетных записях, так и о кар
касе хранения. Ему необходимо было также делегировать все методы на уровне
хранения, которые требовалось открыть внешнему миру.
Глава S • Гибкость или ломкость
206
Миксины предоставляют альтернативу. Так, сначала мы могли бы написать
миксин, реализующий, например, два или три стандартных метода поиска, а за
тем добавить его в класс AccountRecord. По мере написания новых классов
для сохраняемых элементов их также можно дополнять миксинами, как пока
зано ниже.
mixin CommonFinders
def find(id) ( ... }
def findAll() ( ... }
end
class AccountRecord extends BasicRecord with CommonFinders
class OrderRecord
extends BasicRecord with CommonFinders
Можно пойти еще дальше. Всем разработчикам, например, известно, что биз
нес-объектам требуется код проверки достоверности, чтобы исключить проник
новение вредных данных в выполняемые вычисления. Но что именно имеется
в виду под проверкой достоверности? Например, для учетной записи имеются,
вероятно, самые разные уровни проверки достоверности, которые можно было
бы применить в следующих целях:
•
совпадение хешированного пароля с тем, который ввел пользователь;
•
проверка правильности данных, введенных пользователем в форму при
создании учетной записи;
•
проверка правильности данных, введенных администратором, обновляю
щим сведения о пользователе;
•
проверка правильности данных, введенных в учетную запись другими
компонентами системы;
•
проверка данных на согласованность перед сохранением.
Типичный и, на наш взгляд, неидеальный подход состоит в том, чтобы увя
зать все проверки на достоверность в единый класс (бизнес-объект/объект со
храняемости), а затем ввести признаки, чтобы управлять выполнением отде
льных проверок в конкретных обстоятельствах.
Лучший, на наш взгляд, способ состоит в применении миксинов для созда
ния специализированных классов, подходящих для конкретных случаев, как по
казано ниже, где в производные классывключаются проверки достоверности,
общие для всех объектов учетных записей.
class AccountForCustomer extends Account
with AccountValidations,AccountCustomerValidations
class AccountForAdmin extends Account
with AccountValidations,AccountAdminValidations
Тема 31 • Налог на наследование
207
Клиентский вариант класса включает для себя также проверки достовернос
ти, пригодные для
API,
взаимодействующих с клиентом, тогда как администра
тивный вариант класса, вероятно, должен содержать (возможно, менее ограни
чивающие) проверки достоверности учетных данных администратора.
Теперь путем передачи экземпляров класса
AccountForAdrnin
AccountForCustomer
или
наш код автоматически обеспечивает правильное приме
нение проверок достоверности.
Пользуйтесь миксинами для совместного использования
функциональных возможностей
НАСЛЕДОВАНИЕ РЕДКО ЯВЛЯЕТСЯ ОТВЕТОМ
В этом разделе был сделан краткий анализ трех следующих альтернатив тра
диционному наследованию классов:
•
интерфейсов и протоколов;
•
делегирования;
•
миксинов и свойств.
Каждая из этих методик может подойти вам лучше в тех или иных обстоя
тельствах, в зависимости от того, преследуете ли вы цель обмениваться инфор
мацией о типах данных, внедрять дополнительные функциональные возмож
ности или пользоваться общими методами. Как и везде в программировании,
задача заключается в том, чтобы пользоваться той методикой, которая лучше
всего выражает ваши намерения.
И постарайтесь вместе с бананом не прихватить заодно целые джунгли.
Другие раздель1, связанные с данной темой
•
Тема
8.
Сущность качественного проектирования, глава
2 "Прагматичный
подход':
•
Тема
10.
Ортогональность, глава
•
Тема
28.
Развязывание.
2 "Прагматичный
подход':
Задачи
•
В следующий раз, когда вам придется создавать подклассы, уделите вре
мя изучению разных альтернатив наследованию. Сможете ли вы достичь
желаемой цели с помощью интерфейсов, делегирования и/или миксинов?
Удастся ли вам подобным образом уменьшить степень связывания?
Глава 5 • Гибкость или ломкость
208
l!Jfфffj КОНФИГУРИРОВАНИЕ
"Уделяйте всем вашим вещам свои места, а каждой
Если прикладной код полагается на значения, которые могут измениться пос
ле запуска приложения, храните эти значения вне данного приложения. И если
приложение выполняется в разных средах и потенциально работает для разных
клиентов, также храните значения для разных сред и клиентов вне данного при
-
ложения. Подобным образом вы параметризируете свое приложение, исходный
код которого приспосабливается к месту его выполнения.
-
Параметризируйте свое приложение, используя внешнюю
конфигурацию
В данные конфигурации, вероятнее всего, придется включить разнообразные
общие сведения.
и т.д.)
•
Учетные данные для внешних служб (баз данных, сторонних
•
Уровни и места назначения протоколирования .
•
Номера портов, IР-адреса, имена вычислительных машин и кластеров, ис
API
пользуемые в приложении.
•
Параметры проверки достоверности, характерные для конкретной среды.
•
Внешне устанавливаемые параметры, например, ставки налогообложе
ния.
•
Особенности форматирования для разных сайтов.
•
Лицензионные ключи.
Словом, найдите все, что может измениться или быть выражено за предела
ми основного кода, и вынесите эту информацию в отдельную конфигурацион
ную "корзину".
СТАТИЧЕСКАЯ КОНФИГУРАЦИЯ
Конфигурация многих каркасов и специализированных приложений хранится
в обычных текстовых файлах или таблицах базы данных. Если конфигурацион
ные данные хранятся в обычном текстовом файле, то для этой цели, как правило,
применяется один из доступных текстовых форматов. В настоящее время для
Тема 32 • Конфиrурирование
этой цели чаще всего применяются такие текстовые форматы, как
209
YAML и JSON.
Иногда в приложениях, написанных на языках сценариев, применяются файлы
исходного кода, специально предназначенные для хранения одной лишь конфи
гурации. Если подобная информация структурирована и, вероятно, будет изме
няться клиентом (например, ставки налога с продаж), ее лучше хранить в таб
лице базы данных. И, разумеется, вы вольны пользоваться обоими способами,
разделяя конфигурационную информацию в соответствии с ее назначением.
Независимо от формы хранения конфигурационной информации она вво
дится в приложение в виде структур данных
-
как правило, при запуске выпол
нения приложения. Эта структура данных обычно делается глобальной, чтобы
упростить доступ к хранящимся в ней значениям из любой части прикладного
кода.
Однако мы не рекомендуем вам поступать таким образом. Вместо этого вы
несите всю конфигурационную информацию в отдельный (тонкий)
API.
Этим
вы развяжете свой код от подробностей представления его конфигурации.
КОНФИГУРАЦИЯ КАК СЛУЖ6А
Несмотря на распространенность статического конфигурирования, в настоя
щее время мы отдаем предпочтение другому подходу. Нам по-прежнему прихо
дится выносить конфигурационные данные за пределы приложения, но вместо
того чтобы хранить их в текстовом файле или базе данных, мы предпочитаем
получать их через
API
отдельной службы. У такого подхода к конфигурирова
нию имеется целый ряд преимуществ, перечисленных ниже.
•
Многие приложения могут обмениваться конфигурационной информа
цией, при этом с помощью аутентификации можно ограничивать доступ,
определяя, какую информацию может видеть каждое из них.
•
Изменения конфигурации могут выполняться глобально.
•
Конфигурационные данные можно сопровождать с использованием специ
ализированного пользовательского интерфейса.
•
Конфигурационные данные становятся динамическими.
Последнее из перечисленных выше преимуществ, предполагающее динами
ческий характер конфигурационных данных, имеет решающее значение для
перехода к приложениям с высокой степенью доступности. Необходимость
остановки и перезапуска приложения для изменения единственного парамет
ра конфигурации безнадежно оторвана от современной действительности. При
использовании службы конфигурирования компоненты приложения могут за
регистрироваться для получения уведомлений об обновлении используемых
ими параметров, и тогда служба могла бы посылать им сообщения, содержащие
новые значения
-
когда и если они изменятся.
Гnава 5 • Гибкость иnи nомкость
210
Какую бы форму ни принимали конфигурационные данные, именно они оп
ределяют поведение приложения во время выполнения. Перестраивать код при -
ложения, когда конфигурационные значения изменяются, нет необходимости.
НЕ ПИШИТЕ МОРАЛЬНО УСТАРЕВШИЙ КОД
В отсутствие внешней конфигурации прикладной код перестает быть на
столько приспосабливающимся и гибким, насколько он мог бы им быть. Плохо
ли это? Если обратиться к примеру из природы, то можно заметить, что в ней
вымирают те виды, которые не могут приспособиться к реальным условиям су
ществования.
Так, птице дронту так и не удалось приспособиться к присутствию людей и
домашнего скота в местах ее обитания на острове Маврикий, и поэтому этот
вид быстро вымер 12 • И это был первый задокументированный случай вымира
ния вида от рук человека. Поэтому не позволяйте своему проекту (или карьере)
И нисколько не улучшило положение то обстоятельство, что поселенцы забивали ду
бинками безмятежных (а по существу, глупых) птиц ради развлечения.
13
Изображение дронта взято из серии OpenClipart-Vectors, доступной на веб-сайте Pixabay
Тема 32 • Конфигурирование
211
НЕ ПЕРЕУСЕРДСТВУЙТЕ
В первом издании данной книги мы предлагали пользоваться конфигура
цией вместо кода подобным же образом. Но мы, очевидно, должны были
точнее давать свои рекомендации. Ведь любой совет можно довести до
крайности или воспользоваться им несообразно. Поэтому ниже даются не
которые предостережения по данному поводу.
Не переусердствуйте. Один из наших прежних клиентов решил, что бук
вально каждое поле в его приложении должно быть конфигурируемым.
В итоге на внесения даже самых мелких изменений уходили целые недели,
поскольку приходилось реализовывать как само поле, так и весь админис
тративный код для сохранения и редактирования его содержимого. А ведь
в этом приложении насчитывалось до
40
тысяч переменных конфигурации,
что превращало кодирование в сущий кошмар для разработчиков.
Не принимайте решения относительно конфигурирования из лени. Если
возникает реальная дискуссия о том, как должно действовать какое-то фун
кциональное средство и следует ли дать пользователю возможность выби
рать режим его работы, попробуйте реализовать один из его вариантов и
получить отзывы о нем, чтобы выяснить, насколько верным оказалось дан
ное решение.
Глдвд б
Пока мы все находимся на одной и той же странице, а не читаем главу па
раллельно, начнем с некоторых определений. Параллельность
(concurrency)
оз
начает такое такое поведение двух или большего количества фрагментов кода,
как будто они выполняются одновременно. А параллелизм
(parallelism)
озна
чает, что они действительно выполняются одновременно. Чтобы добиться па
раллельности, необходимо выполнять код в среде, способной переключать вы
полнение между разными частями данного кода. Зачастую параллельный режим
работы реализуется с помощью таких средств, как нити
ния
(thread)
и процессы
(fiber),
потоки выполне
(process).
Для того чтобы добиться параллелизма, требуется оборудование, способное
выполнять несколько операций одновременно. Это могут быть многоядерные
процессоры, несколько процессоров на одном компьютере или несколько свя
занных между собой компьютеров.
ВСЕ ПАРАЛЛЕЛЬНО
Практически невозможно написать код системы приличных масштабов, не
прибегая к параллельности. Аспекты используемой параллельности могут быть
явно выраженными или скрытыми в библиотеке. Параллельность необходима
тогда, когда приложение должно взаимодействовать с реальным миром, где со
бытия происходят асинхронно: пользователи взаимодействуют с приложением,
извлекаются данные, вызываются внешние службы, и все это происходит одно
временно. Если заставить все это выполняться последовательно, чтобы события
наступали поочередно, то такая система будет работать медленно и не позволит
выгодно использовать истинный потенциал оборудования, на котором она ра
ботает. Поэтому в этой главе будут подробно рассмотрены понятия параллель
ности и параллелизма.
Разработчики нередко рассуждают о связывании, возникающем между фраг
ментами кода. При этом они ссылаются на зависимости и выясняют, насколько
они затрудняют внесение изменений в исходный код. Но ведь имеется и другая
форма связывания. В частности, временное связывание возникает в том случае,
214
Глава 6 • Параллельность
когда прикладной код накладывает ограничение на последовательность выпол
нения действий, требуемых для решения текущей задачи. Может ли, например,
ваш код зависеть от того, что "тик" происходит раньше "так"? Если вы хотите
сохранить его гибкость
-
он не должен демонстрировать такую зависимость.
Следует ли вашему коду обращаться к нескольким серверным службам после
довательно, т.е. к одной за другой? Нет, не следует, если вы хотите сохранить
своих клиентов. Поэтому в разделе "Разрывание временного связывания" будут
рассмотрены способы выявления временного связывания подобного рода.
Почему так трудно писать параллельный код? Объясняется это, в частности,
тем, что мы учились программировать с использованием последовательных сис
тем. Применяемые нами языки обладают средствами, которые надежны, когда
они используются последовательно, но становятся ненадежны, как только два
события могут наступить одновременно. Одним из главных виновников тому
служит общее, или совместно используемое состояние, которое означает не толь
ко глобальные переменные. Такое состояние возникает в любой момент време
ни, когда два или несколько фрагментов кода содержат ссылки на один и тот
же фрагмент изменяемых данных. Но общее состояние является неверным со
стоянием. В соответствующем разделе описывается ряд приемов, позволяющих
обойти общее состояние, хотя все они не вполне надежны и непогрешимы.
Если все сказанное выше опечалило вас, не отчаивайтесь! Ведь имеются спо
собы построения параллельных приложений и получше. К их числу относится
применение модели акторов, где независимые процессы обмениваются данными
по каналам, используя вполне определенную простую семантику. Теория и прак
тика такого подхода рассматривается в разделе ''Акторы и процессы".
И в завершение этой главы будут рассмотрены классные доски, т.е. системы,
действующие как комбинация хранилища объектов и интеллектуального бро
кера "издатель-подписчик': В своей исходной форме они так и не нашли широ
кого распространения, но в настоящее время наблюдается постепенно растущее
количество реализаций на промежуточном уровне программного обеспечения с
семантикой, похожей на классные доски. При правильном использовании такие
системы обеспечивают серьезную степень развязывания.
Когда-то параллельно выполняющийся код считался экзотикой. Сегодня же
он востребован, как никогда ранее.
lljЦfft РАЗРЫВАНИЕ ВРЕМЕННОГО СВЯЗЫВАНИЯ
В связи с темой этого раздела невольно возникает вопрос: ''А что такое вре
менное связывание?" Это связывание, связанное со временем (простите за ка
ламбур).
Время
-
очень часто игнорируемый аспект в архитектурах программного
обеспечения. Единственным временем, которое заботит разработчиков, явля-
Тема 33 • Разрывание временноrо связывания
215
ется срок выполнения работ по графику, т.е. время, оставшееся до выпуска. Но
здесь речь идет не о самом времени , а о его роли в качестве элемента проекти
рования самого программного обеспечения. Для нас важны следующие аспекты
времени: параллельность (события могут происходить одновременно) и упоря
дочение (относительное расположение событий во времени).
Обычно мы подходим к программированию, не принимая во внимание ни
один из упомянутых выше аспектов. Когда разработчики приступают к проек
тированию архитектуры или написанию программы, весь этот процесс проис
ходит в линейном порядке. Ведь большинство людей мыслят именно в таком
порядке: сделать сначала это, а затем то. Такой порядок мышления приводит к
временному связьtванию, т.е. к такому, которое возникает во времени. Так, метод
А должен всегда вызываться прежде метода В; одновременно может быть со
ставлен лишь один отчет; щелкнув на экранной кнопке, нужно подождать до тех
пор, пока не будет перерисовано выводимое на экран графическое изображение;
"тик" хронологически должен предшествовать "таку':
Такой подход негибок и не очень реалистичен.
Необходимо допустить параллельность и подумать о развязывании в любой
момент времени или упорядочить зависимости. Поступая подобным образом,
можно добиться нужной гибкости и снизить любые временные зависимости на
многих стадиях разработки: анализа последовательности выполняемых дейс
твий, построения архитектуры, проектирования и развертывания. В итоге по
лучаются системы, которые леrче осмысливать и которые потенциально быстрее
реагируют и более надежны.
8
ПОИСКАХ ПАРАЛЛЕЛЬНОСТИ
Во многих проектах требуется моделировать и анализировать последова
тельность выполняемых действий в приложении как часть проектирования.
При этом нам хотелось бы выяснить, что может произойти одновременно и
что должно произойти в строгом порядке. С этой целью можно, например, за
фиксировать последовательность выполняемых действий, используя такое обоз
начение, как диаграмма действий 1 •
1
Анализируйте последовательность выполняемых действий
с целью повышения параллельности
Несмотря на то что язык UML постепенно пришел в упадок, многие из его отдельных
диаграмм по-прежнему существуют в той или иной форме, включая и очень полезную
диаграмму действий. Подробнее о типах диаграмм
Gиide
UML см. в книге UML Distilled: А Brief
to the Standard Object Modeling Language [Fow04].
Глава 6 • Параллельность
216
Диаграмма действий состоит из ряда действий, отображаемых прямоугольни
ками со скругленными углами. Стрелка, проведенная от одного действия, ведет
либо к другому действию (которое может быть начато, как только завершится
первое действие), либо же к толстой линии, называемой чертой синхронизации.
И как только завершатся все действия, приводящие к черте синхронизации, пос
троение диаграммы можно продолжить, проводя стрелки от этой черты дальше.
Действие без ведущих к нему стрелок может быть начато в любой момент.
С помощью диаграмм действий можно довести параллелизм до максимума,
выявляя те действия, которые могут быть выполнены параллельно, но таким
образом не выполняются. Допустим, разрабатывается программное обеспече
ние роботизированного аппарата для приготовления коктейлей "пинаколада"
из светлого рома, кокосового молока и ананасового сока. С этой целью разра
ботчики получили следующее поэтапное описание процедуры приготовления
таких коктейлей.
1.
Открыть блендер
7.
Закрыть блендер
2.
Открыть смесь "пинаколада"
8.
Взбалтывать в течение
3.
Поместить смесь в блендер
9.
Открыть блендер
4.
Отмерить полстакана светлого рома
1О.
5.
Налить ром
11 . Взять
6.
Добавить
2 чашки
льда
12.
1 минуrы
Взять высокие бокалы
розовые зонтики
Подать
Но бармен потеряет свою работу, если последует этой процедуре поэтапно.
Несмотря на то что действия по приготовлению коктейля описаны последова
тельно, многие из них могут быть выполнены параллельно. Воспользуемся при веденной ниже диаграммой действий, чтобы зафиксировать и обдумать потен циальную параллельность.
Выявление реально существующих зависимостей может стать полным откро
вением. В данном случае все задачи верхнего уровня
(1, 2, 4, 10
и
11)
-
(одновременно) выполнены в первую очередь, а во вторую очередь
и
6 (также
могут быть
задачи
3, 5
одновременно). Если бы вы принимали участие в конкурсе на лучше
го составителя коктейля "пинаколада", подобные оптимизации данной процеду
ры могли бы оказать вам существенную помощь в достижении желанной цели.
Возможности для ДОСТИЖЕНИЯ ПАРАЛЛЕЛЬНОСТИ
Диаграммы действий показывают потенциальные участки параллельности,
но ничего не говорят о том, стоит ли использовать параллельность. Так, в рас
смотренном выше примере приготовления "пинаколады" бармену потребова
лось бы пять рук, чтобы выполнить все потенциально первоначальные задачи
одновременно.
Тема 33 • Разрывание временноrо связывания
2. 0 ткрыть смесь
1.
з.
6.
Поместить
смесь в блендер
Открыть
217
4. 0 тмеритьром
блендер
Добавить
5.
две чашки льда
7.
Налить ром
Закрыть
блендер
10.
Взять
высокие бокалы
11 .
Взять
розовые зонтики
9.
Открыть
блендер
[ 12 ·
Подать
Именно здесь и наступает стадия проектирования. Глядя на упомянутые
выше действия, мы осознаем, что на действие
(работа блендера) потребуется
8
одна минута. В течение этого промежутка времени бармен может взять высокие
бокалы и розовые зонтики (действия
10 и 11), и, возможно, у него еще останется
время, чтобы обслужить другого клиента.
Именно такие моменты мы и ищем, когда выполняем проектирование с уче
том параллельности. При этом мы надеемся найти действия, отнимающие вре
мя, но не время для выполнения нашего кода. Запрос базы данных, доступ к
внешней службе, ожидание ввода пользователем данных
-
все эти действия,
как правило, приостанавливают выполнение программы до тех пор, пока они не
завершатся. И все они открывают возможности сделать программу более произ
водительной, не заставляя процессор простаивать в холостую.
Возможности для ДОСТИЖЕНИЯ ПАРАЛЛЕЛИЗМА
Напомним главное отличие: параллельность
мный механизм, а параллелизм
(parallelism) -
(concurrency) -
это програм
предмет заботы оборудования.
Если в нашем распоряжении имеется несколько процессоров, доступных ло
кально или дистанционно, то, распределив работу между ними, мы можем со
кратить общее время ее выполнения.
218
Глава б • Параллельность
УСКОРЕННОЕ ФОРМАТИРОВАНИЕ
Эта книга написана простым текстом. Чтобы составить ее версию для печа
ти, электронной книги или иных целей, ее текст был пропущен через кон
вейер процессоров. Одни из них находили конкретные конструкции (ссыл
ки на литературу, статьи предметного указателя, специальную разметку для
советов и т.д.), а другие оперировали рукописью как документом в целом.
Многие процессоры в конвейере должны получать доступ к внешней ин
формации (читать и записывать текст в файлы, обращаться к внешним про
граммам по конвейеру). Вся эта относительно медленно выполняемая рабо
та дает нам возможность поставить себе на службу параллельность: факти
чески каждый этап конвейера выполняется параллельно, получая результа
ты работы предыдущего этапа и передавая другие результаты следующему
этапу работы конвейера.
Кроме того, на некоторых стадиях процесса требуется относительно интен
сивное употребление процессоров. К их числу относится преобразование
математических формул. По разным историческим причинам для преобра
зования каждого уравнения может потребоваться до
500
мс. Чтобы уско
рить дело, можно с выгодой воспользоваться параллелизмом. Каждая фор
мула не зависит от других формул, поэтому ее можно преобразовывать па
раллельно в отдельном процессе, собирая полученные результаты обратно
в книгу, как только они становятся доступными .
В итоге составление книги на компьютере с многоядерным процессором
намного ускоряется. И, разумеется, по ходу дела выявили целый ряд оши
бок параллельности в составленном нами конвейере ...
В идеальном случае разделяемые подобным образом части работы являются
независимыми, т.е. каждая из них может быть продолжена, ничего не ожидая
от других. Типичный шаблон разделяет крупную часть работы на независимые
фрагменты, которые обрабатываются параллельно, а затем полученные резуль
таты объединяются.
Интересным практическим примером может служить принцип действия ком
пилятора в языке
Elixir.
После запуска этот компилятор разделяет проект, ко
торый он строит, на модули, компилируя их параллельно. Иногда один модуль
зависит от другого, и тогда компиляция приостанавливается до тех пор, пока
результаты построения одного модуля не станут доступными для построения
другого модуля. Завершение построения модуля верхнего уровня означает, что
все его зависимости скомпилированы. В итоге процесс компиляции заметно ус
коряется благодаря тому, что задействованы все имеющиеся ядра процессора.
Тема 34 • Общее состояние - неверное состояние
219
Выявить возможности ПРОЩЕ ВСЕГО
Вернемся, однако, к приложениям. Мы выявили в них места, где можно из
влечь выгоду из параллельности и параллелизма. Теперь предстоит самое труд
ное: решить, как все это надежно реализовать. Данному вопросу и посвящена
остальная часть этой главы.
Другие разделы, связанные с данной темой
•
Тема 10. Ортогональность, rлава
•
Тема
26.
Как сбалансировать ресурсы, rлава
•
Тема
28.
Развязывание, глава
•
Тема
36.
Классные доски.
5
2
"Прагматичный подход".
4
"Прагматичная паранойя':
''Гибкость или ломкость".
Задачи
•
Сколько задач вы решаете параллельно, собираясь утром на работу? Не
могли бы вы выразить эту процедуру в виде диаграммы действий на языке
UML?
Можете ли вы найти способ собраться на работу быстрее, увеличив
степень параллельности своих действий?
i1Mtfli ОБЩЕЕ СОСТОЯНИЕ -
НЕВЕРНОЕ СОСТОЯНИЕ
Представьте себя за обедом в своем любимом ресторане. Покончив с основ
ным блюдом, вы спрашиваете официанта, остался ли еще яблочный пирог. Глядя
через плечо, он замечает один кусок на прилавке-витрине и отвечает утверди
тельно. Вы делаете заказ и удовлетворенно вздыхаете.
В это время на другой стороне ресторана еще один посетитель задает офици
анту тот же самый вопрос. Он также смотрит на прилавок-витрину, убеждается
в наличии куска пирога, отвечает утвердительно, и тогда другой посетитель де
лает аналогичный заказ. В итоге один из посетителей ресторана остается разо
чарованным.
Замените прилавок-витрину совместным банковским счетом, а обслужива
ющий персонал ресторана
-
кассовыми терминалами и представьте, что вы и
ваш супруг или супруга решили одновременно купить новый телефон, но денег
на счете у вас хватит лишь на один. В итоге кто-то (банк, магазин или вы) оста
нетесь весьма недовольны.
GФФf*'
Общее состояние
-
неверное состояние
220
Гnава б ,, Пара1111е11ьность
Все дело в совместно используемом общем состоянии. Каждый из официан
тов посмотрел на прилавок-витрину в ресторане, но не друт на друта. И каждый
кассовый терминал проанализировал остаток на счете безотносительно к друто
му кассовому терминалу.
НЕАТОМАРНЫЕ ОБНОВЛЕНИЯ
Рассмотрим пример ситуации в ресторане. Ниже показано, как реализовать
его непосредственно в коде.
pie_count:
/
\
ОФициат 1
if display_case . pie_count >
1
0Фициат2
О
promise_pi e_to_customer()
display_case .take_pie()
give_pie_to_customer()
end
if display_case .pie_count >
О
promise_pie_to_customer()
display_ case.take_pie()
give_pie_to_customer()
end
Оба официанта действуют одновременно, а на практике
-
параллельно. Рас
смотрим код, реализующий их поведение:
if d i splay_case .pie_count > О
promise_pie_to_custome r()
display_case.take_pie()
give_pie_to_customer()
end
В этом коде первый официант получает текущий подсчет количества кусков
пирога и обнаруживает, что он равен единице. И тогда он обещает пирог свое
му клиенту. Но в тот же самый момент действует и второй официант. Он также
обнаруживает, что текущий подсчет количества кусков пирога равен единице, и
обещает тот же самый пирог своему клиенту. В итоге один из двух официантов
берет оставшийся кусок пирога, тогда как друтой официант переходит в некото
рого рода состояние ошибки, что, вероятнее всего, вызовет немало извинений.
Все дело не в том, что два процесса могут записывать данные в одну и ту
же область памяти, а в том, что ни один из них не может гарантировать, что
его представление о данной области памяти согласовано с другими. По су
ществу, когда код, реализующий поведение официанта, выполняет метод
display_ case. pie_ count (), он копирует значение, определяющее количес
тво кусков пирога, из объекта display_case в свою область памяти. Если же
Тема 34
это значение в объекте
display_ case
Общее состояние - неверное состояние
221
изменится, содержимое данной области
памяти, которая используется для принятия решений, окажется неактуальным.
Все это происходит потому, что извлечение и обновление подсчета кусков
пирога не является атомарной операцией, поскольку базовое значение может
измениться посредине данной операции. Так как же сделать ее атомарной?
Семафорь~ и другие формы взаимного исключения
Семафор
-
это просто ресурс, которым может одновременно владеть лишь
кто-то один. Семафор можно создать, а затем воспользоваться им для управ
ления доступом к какому-нибудь другому ресурсу. В рассматриваемом здесь
примере можно было бы создать семафор для управления доступом к прилавку
с пирогом, приняв условие, что всякий, кому требуется обновить содержимое
прилавка, может сделать это лишь в том случае, если он владеет данным сема
фором.
Допустим, проблема пирога в ресторане решается с помощью такого сема
фора. С этой целью на прилавок-витрину поставили пластмассовую фигурку
лепрекона2 • Прежде чем подать пирог, официант должен взять в руку фигурку
лепрекона. Как только он выполнит заказ (что означает доставку пирога на стол
посетителя), он может возвратить фигурку лепрекона на место, где тот охраняет
пирожные сокровища и готов содействовать следующему заказу.
Теперь выясним, как реализовать такой семафор непосредственно в коде. По
классической традиции операция захвата семафора называлась Р, а операция его
освобождения -
v3.
Сейчас для этой цели употребляются такие термины, как
блокировка и разблокировка, захват и освобождение и т.д. Так, в приведенном
ниже коде предполагается, что семафор уже создан и хранится в переменной
case _ semaphore.
case_semaphore.lock()
if display_case.pie_count > О
promise_pie_to_customer()
display_case.take_pie()
give_pie_to_customer()
end
case_semaphore.unlock()
2
Лепрекон - персонаж ирландского фольклора, волшебник, исполняющий желания и
-
традиционно изображаемый в виде небольшого коренастого бородатого человечка.
Примеч. пер.
3
Названия операций Р и V являются производными от начальных букв двух голланд
ских слов, хотя по этому поводу все еще ведется полемика. Изобретатель данного метода,
Эдсгер Дейкстра
(Edsger Dijkstra),
предложил два слова
passering (передать) и prolaag (по
vrijgave (снять запрет) и,
пытаться понизить уровень) для названия операции Р и слово
возможно, слово
verhogen
(повысить уровень) для названия операции
V.
Глава 6 • Параллельность
222
Допустим, фрагменты кода, реализующие действия обоих официантов, вы
полняются одновременно. Они оба пытаются заблокировать семафор, но удает
ся это лишь одному из них. Тот код, который захватывает семафор, продолжа
ет выполняться как обычно, а другой код приостанавливает свое выполнение
до тех пор, пока семафор не освободится (т.е. второй официант ожидает своей
очереди выполнить заказ). Как только первый официант завершит выполнение
своего заказа, он разблокирует семафор, и тогда второй официант продолжит
свою работу. Теперь он видит наличие пирога на прилавке-витрине и приносит
свои извинения посетителям, попросившим пирог.
Такой подход к разрешению конфликтов при одновременном выполнении
операций вызывает некоторые затруднения. И самое, вероятно, существенное
из них состоит в том, что такой подход оказывается работоспособным лишь в
том случае, если все, кто имеет доступ к прилавку-витрине, соглашаются на ус
ловие пользоваться семафором. Если кто-нибудь из них забудет о нем, т.е. если
какой-то разработчик напишет код, не соблюдающий данное условие, то снова
возникнет беспорядок.
Придание ресурсам транзакционного характера
Рассматриваемое здесь проектное решение оказывается неудачным потому,
что ответственность за защиту доступа к прилавку с пирогом возлагается на
тех, кто им пользуется. Изменим это решение таким образом, чтобы центра
лизовать управление доступом к прилавку с пирогом. Для этого нам придется
внести в
API
такие изменения, которые позволят официантам проверять под
счет количества кусков пирога и нарезать пирог в течение одного вызова, как
показано ниже.
slice
=
display_case.get_pie_if
availaЬle()
if slice
give_pie_to_customer()
end
Чтобы сделать приведенный выше код работоспособным, необходимо напи
сать приведенный ниже метод, частично выполняющий функции самого при лавка.
def
get_pie_if_availaЬle()
if @slices.size >
О
update_sales_data(:pie)
return @slices.shift
else
false
end
end
####
#
#
#
#
неверный код!
#
#
####
Данный код наглядно показывает типичное заблуждение.
Тема 34 ~ Общее состояние - неверное состояние
223
Несмотря на то что доступ к ресурсу перемещен в центральное место, объ
являемый метод все равно может быть вызван из нескольких одновременно вы
полняющихся потоков. Следовательно, он должен быть по-прежнему защищен
семафором, как показано ниже.
def
get_pie_if_availaЫe()
@case_semaphore.lock()
if @slices.size > О
update_sales_data ( :pie)
return @slices.shift
else
false
end
@case_semaphore.unlock()
end
Но даже этот код может оказаться неверным. Так, если в методе
sales_data ()
upda te _
будет возбуждено исключение, семафор так и не будет разбло
кирован, и весь последующий доступ к прилавку с пирогом зависнет на неопре
деленное время. Этот недостаток придется исправить следующим образом:
def
get_pie_if_availaЬle()
@case_semaphore.lock()
try {
if @slices.size > О
update_sales_data ( :pie)
return @slices.shift
else
false
end
ensure
@case_semaphore.unlock()
end
Данная ошибка настолько типична, что во многих языках предоставляются
отдельные библиотеки, устраняющие ее автоматически, как показано ниже.
def
get_pie_if_availaЬle()
@case_semaphore.protect() {
if @slices.size > О
update_sales_data ( :pie)
return @slices.shift
else
false
end
end
224
Глава 6 • Параллельность
МНОЖЕСТВЕННЫЕ ТРАНЗАКЦИИ РЕСУРСОВ
В упомянутом выше ресторане только что установили мороженицу. Если по
сетитель закажет яблочный пирог с мороженым, официанту придется проверить
наличие не только пирога, но и мороженого. С этой целью код, реализующий
действия официанта, можно было бы изменить следующим образом:
slice
scoop
=
display_case.get_pie_if_availaЬle()
=
freezer.get
ice_cream_if_availaЬle()
if slice && scoop
give_order_to_customer()
end
Но так не годится. Что, если посетитель потребует кусок пирога, и когда
официант попытается достать шарик мороженого, то его не окажется в нали чии? В итоге он останется держать в руках кусок пирога, не зная, что с ним
делать, поскольку посетителю следует принести яблочный пирог непременно с
мороженым. И тот факт, что официант держит в руках пирог, означает, что его
уже нет на прилавке, а следовательно, его не достанется какому-нибудь другому
посетителю, из принципа не желающего есть яблочный пирог с мороженым.
Это положение можно было бы исправить, введя в объект, представляющий
прилавок с пирогом, метод, позволяющий возвратить кусок пирога. Чтобы не
удерживать используемые ресурсы в том случае, если что-нибудь пойдет не так,
как предполагалось, в данный метод следует ввести обработку исключений:
slice
=
display_case.get_pie_if_availaЫe()
if slice
try {
scoop = freezer.get_ice
if scoop
cream_if_availaЬle()
try {
give_order_to_customer()
rescue {
freezer.give_back(scoop)
end
rescue
display_case.give_back(slice)
end
Но и такое решение отнюдь не идеально. Теперь код выглядит весьма урод
ливо. Выяснить, что он действительно делает, не так-то просто, поскольку биз
нес-логика скрывается в нем за служебными операциями.
Тема 34 • Общее состояние - неверное состояние
225
Ранее подобный недостаток был устранен перенесением кода, обращающе
гося с ресурсом, в сам ресурс. Но здесь задействованы два ресурса. Следует ли
перенести код в реализацию прилавка с пирогом или мороженицы? Мы счита
ем, что не следует ни в одно из этих мест. Прагматичный подход подсказывает,
что яблочный пирог с мороженым следует рассматривать как отдельный ресурс.
Поэтому код лучше перенести в новый модуль, и если посетитель ресторана за
кажет такой десерт, то выполнить его заказ либо удастся, либо не удастся.
Разумеется, в меню настоящего ресторана может быть немало составных
блюд, подобных упомянутому выше, так что вряд ли стоит писать отдельный
модуль для каждого из них. Вместо этого, вероятнее всего, придется сделать в
каждом составном блюде из меню ссылки на его составляющие, а затем объ
явить обобщенный метод
get _ menu_ i tem (),
выделяющий ресурс по каждой
ссылке.
ОБНОВЛЕНИЯ БЕЗ ТРАНЗАКЦИЙ
Общей памяти как источнику осложнений, возникающих в связи с парал
лельностью, уделяется немало внимания, но на самом деле эти осложнения мо
гут возникнуть везде, где прикладной код разделяет общие изменяемые ресурсы:
файлы, базы данных, внешние службы и т.д. Всякий раз, когда два или более
фрагмента прикладного кода могут одновременно получить доступ к некоторо
му ресурсу, следует усматривать потенциальное осложнение.
Иногда ресурс не вполне очевиден. Работая над настоящим изданием дан
ной книги, мы обновили набор инструментальных средств, чтобы выполнить
больше работы в параллельном режиме с помощью потоков выполнения. Это
привело к тому, что сборка завершалась неудачно, но странными способами и
в произвольных местах. Общим для всех ошибок оказалось то, что файлы или
каталоги не удавалось найти, несмотря на то, что они находились именно там,
где им и следовало быть.
Мы проследили эту тенденцию до двух мест в своем коде, где временно изме
нялся текущий каталог. В нераспараллеленной версии кода обратное восстанов
ление каталога было вполне приемлемым, но в распараллеленной версии ката
лог изменялся в одном потоке выполнения, а затем начинал выполняться другой
поток в том же самом каталоге . В этом потоке предполагалось выполнение в
первоначальном каталоге, но этого не происходило, поскольку текущий каталог
совместно использовался в обоих потоках выполнения.
Характер подобной ошибки подсказывает еще один совет:
-
Случайные отказы часто вызваны осложнениями,
возникающими в связи с параллельностью
Гnава 6 • Параnnеnьность
226
ДРУГИЕ ВИДЫ ИСКЛЮЧИТЕЛЬНОГО ДОСТУПА
В большинстве языков программирования имеются библиотеки, поддержи
вающие некоторые виды исключительного доступа к общим ресурсам. Они мо
гут называться мьютексами4, мониторами или семафорами. Все эти средства
поддержки параллельности реализуются в виде библиотек.
Но в некоторые языки поддержка параллельности встроена непосредственно.
Например, в языке
Rust соблюдается принцип владения данными, в
соответствии
с которым лишь одна переменная или параметр может одновременно хранить
ссылку на любой конкретный фрагмент изменяемых данных.
Можно, конечно, утверждать, что реализовать параллельность в языках фун
кционального программирования проще, поскольку им присуще делать все дан
ные неизменяемыми. Но и в них возникают те же самые трудности, поскольку
в какой-то момент им все равно приходится вступать в реальный изменчивый
мир.
Доктор, МНЕ БОЛЬНО •••
Если вы не вынесете для себя ничего полезного из этого раздела, примите
во внимание хотя бы следующее: добиться параллельности в среде с общими
ресурсами нелегко, и попытки сделать это самостоятельно сопряжены с серьез
ными трудностями.
Именно поэтому мы решили завершить этот раздел старой шуткой:
-
Доктор, мне больно, когда я делаю вот так ...
-
Ну так не делайте вот так.
В двух последующих разделах рассматриваются альтернативные способы без
болезненного извлечения выгод из параллельности.
Другие раэделы, свяэанные с данной темой
Тема
10.
Ортогональность, глава
о Тема
28.
Развязывание, глава
Тема
38.
Программирование по совпадению, глава
•
•
4
5
2
"Прагматичный подход':
"Гибкость или ломкость".
7 "По ходу кодирования':
От анг. mutual exclusion - взаимное исключение. - Примеч. пер.
Тема 35 • Акторы и процессы
227
i.jtffJj АКТОРЫ И ПРОЦЕССЫ
"Без писателей никто не напишет истории,
а без актеров никто не воплотит истории в жизнь''.
Анджи-Мари Дельсанте5
Акторы и процессы предоставляют интересные способы реализации парал
лельности, избавляя от бремени синхронизации доступа к общей памяти. Но,
прежде чем перейти к их рассмотрению, необходимо определить их назначение.
И хотя это определение покажется вам несколько академичным, примите его
безбоязненно, а мы подробно растолкуем его вскоре.
•
Актор
(actor) -
это независимый виртуальный процессор с собственным
локальным (или закрытым) состоянием. У каждого актора имеется свой
почтовый ящик. Как только в этом ящике появится сообщение, простаи
вающий в ожидании актор активизируется и обработает его. Завершив его
обработку, актор либо переходит к обработке другого сообщения в своем
почтовом ящике, либо возвращается в неактивное состояние ожидания,
если почтовый ящик пуст. По ходу обработки сообщений актор может со
здавать других акторов, посылать сообщения другим известным ему ак
торам или переходить в новое состояние, которое станет текущим после
обработки следующего сообщения.
•
Процесс
-
это, как правило, более универсальный виртуальный процес
сор, зачастую реализуемый операционной системой в целях содействия
параллельности. На процессы могут условно накладываться ограничения,
чтобы они вели себя как акторы. Именно такой тип процесса имеется
здесь в виду.
АКТОРЫ МОГУТ БЫТЬ ТОЛЬКО ПАРАЛЛЕЛЬНЫМИ
В определении акторовимеется ряд перечисленных ниже положений.
•
Единого контроля за всем происходящим не существует. Что будет выпол
нено следующим, никак не планируется, а передача информации от исход
ных данных к окончательным выводимым данным никак не регулируется.
•
Единственное состояние, имеющееся в системе, содержится в сообщениях
и локальном состоянии актора. Сообщения могут быть проанализированы
только при прочтении их получателем, а локальное состояние за предела
ми актора недоступно.
5
Angie-Marie Delsante - американская писательница в жанре научной фантастики, по
- Примеч. пер.
борница целостного образа жизни.
Глава 6 • Параллельность
228
•
Все сообщения являются однонаправленными, и ответы на них не предус
мотрены. Если же требуется, чтобы актор возвратил ответ, в посылаемом
сообщении следует указать адрес своего почтового ящика, и тогда актор
(в конечном итоге) отправит ответ как обычное сообщение в указанный
почтовый ящик.
•
Актор поочередно полностью обрабатывает каждое сообщение.
Таким образом, акторы выполняются одновременно, асинхронно и не исполь
зуют совместно ничего общего. Если бы в системе было достаточно физических
процессоров, на каждом из них можно было бы выполнять отдельный актор.
При наличии единственного процессора требуется соответствующая выполня
ющая среда, способная переключать контекст с одного актора на другой. Но в
любом случае код, выполняемый акторами, остается одним и тем же.
-
Пользуйтесь акторами, чтобы достичь параллельности без
общего состояния
ПРОСТОЙ АКТОР
Итак, реализуем рассмотренный ранее пример ситуации в ресторане, исполь
зуя акторов. В данном случае у нас будут три актора: посетитель, официант и при
лавок с пирогом. Общий поток сообщений будет выглядеть следующим образом.
•
Мы (подобно некоей внешней богоподобной силе) внушаем посетителю,
что он проголодался.
•
В ответ посетитель заказывает официанту пирог.
•
Официант обращается к прилавку, чтобы взять кусок пирога и принести
его посетителю.
•
Если на прилавке имеется кусок пирога, он будет отправлен посетителю, а
официант уведомлен, что пирог следует внести в счет.
•
Если же пирога на прилавке нет, официант будет уведомлен об этом, ему
придется извиниться перед посетителем.
Мы решили реализовать описанный выше алгоритм на языке
пользовавшись библиотекой
Nact6.
JavaScript,
вос
С этой целью мы ввели в исходный код обо
лочку, позволяющую реализовать акторов в виде простых объектов, где ключи
обозначают типы сообщений, принимаемых актором, а значения
-
функции,
выполняемые при получении конкретного сообщения. (В большинстве систем
акторов имеется аналогичная структура, хотя подробности ее реализации зави
сят от базового языка.)
6
См. по адресу https: / /github. com/ncthbrt/nact.
Тема 35 • Акторы и процессы
229
Итак, начнем с посетителя. Он может принимать следующие сообщения.
•
Он проголодался
•
На столе стоит пирог
•
Приносятся извинения в связи с тем, что пирога больше не осталось
-
это сообщение посылается из внешнего контекста.
-
это сообщение посылается прилавком с пирогом.
-
это
сообщение посылается официантом.
Ниже показано, как все это реализуется непосредственно в коде.
'put on tаЫе': (msg, ctx, state) =>
console.log('$(ctx.self.name) sees
"${msg.food)" appear on the tаЫе'),
'no pie left': (_msg, ctx, state) =>
console.log('$(ctx.self.name) sulks ... ')
Любопытная ситуация возникает в том случае, когда мы получаем сообщение
о том, что посетитель проголодался и жаждет пирога, и посылаем сообщение
официанту. (Ниже будет показано, откуда актору посетителя известно об акторе
официанта.) Ниже приведен код, реализующий актора официанта.
concurrency/actors/index.js
const waiterActor = (
"order": (msg, ctx, state) =>
if (msg.wants == "pie") {
dispatch(state.pieCase,
( type: "get slice", customer: msg.customer,
waiter: ctx.self })
else
console.dir('Don't know how to order $(msg.wants} ');
}'
"add to order": (msg, ctx) =>
console.log('Waiter adds $(msg.food}
to $(msg.customer.name} 's order'),
"error": (msg, ctx) => {
dispatch(msg.customer, { type: 'no pie left', msg: msg.msg }) ;
console.log('\nThe waiter apologizes to
${msg.customer.name): $(msg.msg} ')
);
Глава 6 • Параллельность
230
Получив от посетителя сообщение
'order'
(заказ), официант проверяет, за
прошен ли пирог. Если это именно так, он посылает запрос прилавку с пирогом,
передавая ссылки как на самого себя, так и на посетителя.
Прилавок с пирогом находится в состоянии, содержащем массив всех нахо
дящихся на нем кусков пирога. (Ниже будет показано, как устанавливается это
состояние.) Когда прилавок получает сообщение
'get slice'
(взять кусок пи
рога) от официанта, он выясняет, осталось ли сколько-нибудь кусков пирога.
Если осталось, то он передает кусок пирога посетителю, сообщает официанту о
необходимости обновить заказ и, наконец, возвращает состояние, содержащее
на один кусок пирога меньше. Ниже показано, как все это реализуется непо
средственно в коде.
concurrency/actors/index.js
const pieCaseActor
= {
'get slice': (msg, context, state) => {
if (state.slices.length == 0) {
dispatch (msg. wai ter, { type: 'error', msg: 11 no pie left 11 ,
customer: msg.customer })
return state
else {
var slice
= state.slices.shift() + 11 pie slice 11 ;
dispatch(msg.customer, type: 'put on tаЫе', food: slice });
dispatch(msg.waiter, { type: 'add to order', food: slice,
customer: msg.customer });
return state;
Несмотря на то что одни акторы зачастую динамически запускаются другими
акторами, в данном случае ради простоты это делается вручную. При этом каж
дому актору передается некоторое исходное состояние, как поясняется ниже.
•
Прилавок получает первоначальный список находящихся на нем кусков
пирога.
•
Официанту передается ссылка на прилавок с пирогом.
•
Посетителям передается ссылка на официанта.
concurrency/actors/index.js
const actorSystem = start();
let pieCase
Выполнив приведенный выше код, можно увидеть, как акторы обмениваются
сообщениями 7 . Хотя порядок их действий у вас может оказаться иным.
$ node index. j s
customerl sees "apple pie slice" appear on the tаЫе
customer2 sees "peach pie slice" appear on the tаЫе
Waiter adds apple pie slice to customerl's order
Waiter adds peach pie slice to customer2's order
customerl sees "cherry pie slice" appear on the tаЫе
Waiter adds cherry pie slice to customerl's order
The waiter apologizes to customerl: no pie left
customerl sulks ...
The waiter apologizes to customer2: no pie left
customer2 sulks ... 8
Чтобы выполнить этот код, вам потребуются также функции-оболочки, которые здесь
https: / /media .pragprog. com/titles/
tpp20/code/concurrency/actors/index.js.
8 Первый посетитель видит, как на его столе появляется "кусок яблочного пирога"
7
не показаны. Их можно загрузить по адресу
Второй посетитель видит,
как на его столе появляется "кусок персикового пирога"
Официант вносит кусок яблочного пирога в заказ первого посетителя
Официант вносит кусок персикового пирога в заказ первого посетителя
Первый посетитель видит,
как на его столе появляется "кусок вишневого пирога"
232
Глава б • Параллельность
ОТСУТСТВИЕ ЯВНОЙ ПАРАЛЛЕЛЬНОСТИ
В модели акторов отпадает всякая необходимость писать код, поддерживаю
щий параллельность, поскольку отсутствует общее состояние. Нет также необ
ходимости программировать явным образом логику, реализующую всю после
довательность действий от начала и до конца, поскольку акторы выясняют эту
последовательность сами, исходя из получаемых ими сообщений.
Здесь нет никакого упоминания о базовой архитектуре. Такой набор компо
нентов может быть в равной степени пригодным для однопроцессорных, мно
гоядерных систем или множества подключенных к сети машин.
ERLANG ПОДГОТАВЛИВАЕТ ПОЧВУ
Язык
Erlang и
его выполняющая среда служат характерными примерами реа
Erlang не читали оригиналь
называются в языке Erlang процессами,
лизации акторов, несмотря на то, что изобретатели
ную статью об акторах. И хотя акторы
тем не менее их нельзя считать обычными процессами операционной системы.
Вместо этого процессы в
Erlang,
подобно рассмотренным выше акторам, легко
весны (на одной машине можно выполнять их миллионами) и обмениваются
отправляемыми сообщениями. Каждый такой процесс изолирован от остальных
процессов, а следовательно, у них нет общего состояния.
В выполняющей среде языка
Erlang
реализуется также система контроля над
сроками действия процессов, потенциально перезапускающая один процесс или
ряд процессов в случае отказа. Кроме того, в языке
Erlang
поддерживается "го
рячая" загрузка кода, позволяющая заменять код в системе, не останавливая ее
Erlang выполняет едва ли не самый надежный в
мире код с показателем безотказности порядка 99,9999999%.
Но язык Erlang и производный от него язык Elixir не единственны в своем
работу. Наконец, система языка
роде, поскольку акторы реализованы и в большинстве других языков. Далее они
будут рассмотрены с точки зрения реализации параллельности.
Официант вносит кусок вишневого пирога в заказ первого посетителя
Официант извиняется перед первым посетителем за то, что пирога больше не осталось
Первый посетитель сердится
...
Официант извиняется перед вторым посетителем за то,
Второй посетитель сердится
...
что пирога больше не осталось
Тема
36 • Кnассные доски
233
Другие разделы, связанные с данной темой
•
•
Тема
28.
Тема
30.
Развязывание, глава
5 "Гибкость
или ломкость".
Преобразовательное программирование, глава
5
"Гибкость или
"
ломкость.
•
Тема
36.
Классные доски.
Задачи
•
Имеется ли у вас в настоящее время такой код, в котором взаимное исклю
чение применяется для защиты общих данных? Почему бы вам не опробо
вать прототип того же кода, написанного с помощью акторов?
•
В коде, реализующем акторов для контроля над описанной выше ситуа
цией в ресторане, поддерживаются заказы кусков пирога. Расширьте этот
код таким образом, чтобы дать посетителям ресторана возможность зака
зывать яблочный пирог с мороженым, а отдельным агентам
-
манипули
ровать кусками пирога и шариками мороженого. Устройте все так, чтобы
обрабатывать ситуацию, когда израсходуется пирог или мороженое.
1;;ы1м КЛАССНЫЕ доски
"И писали напротив лампады на извести
чертога царского ..."
Книга пророка Даниила, глава
5
Рассмотрим, каким образом детективы могли бы пользоваться классной до
ской для координирования действий в расследовании убийства. Главный инс
пектор устанавливает для начала крупную черную доску в зале совещаний и
пишет на ней единственный вопрос:
Шалтай-Болтай (мужчина, яйцо): несчастный случай или убийство?
Действительно ли Шалтай упал сам или его толкнули? Каждый детектив мо
жет внести свой вклад в раскрытие тайны этого потенциального убийства, доба
вив факты, показания свидетелей, любые данные судебной экспертизы, которые
могут появиться, и т.д. По мере накопления данных каждый детектив может
заметить во всем этом определенную связь и написать на доске свои наблюде
ния или предположения. И этот процесс продолжается со всеми отклонениями
и участием самых разных людей и посредников до тех пор, пока дело не будет
закрыто. Пример классной доски для данного случая приведен на рис.
6.1.
Глава 6 • Параллельность
234
Детектив Холме
Детектив Спэйд
Детектив Марпл
Рис.
6.1.
Кто-то обнаружил связь между карточными долгами Шалтая-Болтая и
зарегистрированными телефонными звонками. Вероятно, его могли запугивать по телефону
Ниже перечислены основные свойства метода классной доски.
•
Ни одному из детективов совсем не обязательно знать о существовании
любых других детективов. Они просто следят за новой информацией на
классной доске и пишут на ней свои изыскания.
•
Детективы могут иметь подготовку в самых разных дисциплинах, разные
уровни образования и опыта, а возможно, и вообще не работать на одном
и том же участке территории. Они разделяют общее желание раскрыть
преступление, и только.
•
В ходе данного процесса разные детективы могут приходить и уходить,
и работать посменно.
•
На информацию, размещаемую на классной доске, не накладывается ника
ких ограничений. Это могут быть фотографии, свидетельские показания,
вещественные доказательства и т.д.
Классная доска служит в данном случае формой пассивной параллельности,
где детективы являются независимыми процессами, агентами, акторами и т.д.
Одни из них размещают добытые факты на классной доске, а другие берут эти
факты с доски и, возможно, объединяют или обрабатывают их, а также указыва
ют дополнительные сведения на доске. И постепенно доска помогает им прийти
к общему заключению по поводу расследуемого преступления.
Автоматизируемые системы классных досок первоначально применялись
в приложениях искусственного интеллекта, где решались крупные и сложные
Тема 36 • Классные доски
235
задачи, включая распознавание речи, системы формирования рассуждений на
основе базы данных и т.д. Одна из первых таких систем называлась
Linda и была
разработана Дэвидом Гелернтером. Факты хранились в ней в виде типизирован
ных кортежей. Приложения могут записывать новые кортежи в систему
Linda
и запрашивать существующие кортежи, используя определенную форму сопос
тавления с шаблоном.
Позднее появились распределенные системы типа классных досок, например
JavaSpaces
и Т
Spaces.
С помощью этих систем можно сохранять на классной
доске не только данные, но и активные объекты
Java,
а также извлекать их по
частично совпадающим полям (через шаблоны и метасимволы подстановки)
или подтипам. Допустим, имеется тип данных
Author,
являющийся подтипом,
производным от типа
Person. На классной доске, содержащей объекты типа
Person, можно производить поиск, используя шаблон типа Author со значе
нием Shakespeare в поле lastName. В результате такого поиска будет обна
ружен автор Уильям Шекспир, но не садовник Фред Шекспир. Мы считаем, что
такие системы не нашли широкого применения отчасти потому, что так и не
выработалась потребность в определенного рода параллельной коллективной
обработке.
КЛАССНАЯ ДОСКА в ДЕЙСТВИИ
Допустим, требуется написать программу, принимающую и обрабатываю
щую заявки на залог или заем. Законы, регулирующие данную сферу, одиозно
сложны, причем в них имеются расхождения на уровне штатов и федерально
го правительства США. В частности, заимодавец должен подтвердить, что он
владеет некоторыми преданными гласности предметами недвижимости, а также
запросить определенные сведения, но не задавать ряд других вопросов и т.д.
Помимо проблем текущего законодательства, в данном случае придется ре
шать следующие задачи.
•
Ответы могут поступать в любом порядке. Например, обработка запросов
на проверку кредитной истории или правового статуса может отнять не
мало времени, тогда как Ф.И.О. и адрес могут быть сверены немедленно.
•
Сбор данных может выполняться разными людьми, рассредоточенными
по разным учреждениям и в разных часовых поясах.
•
Некоторые данные могут быть собраны автоматически другими система
ми, а также могут поступать асинхронно.
•
Тем не менее одни данные могут быть собраны независимо от других. На
пример, начать проверку правового статуса владельца автомобиля, воз
можно, не удастся до тех пор, пока не будут подтверждены права владения
или страховки.
Гnава 6 • Паралnеnьность
236
•
Поступление новых данных может поднимать новые вопросы и правила.
Допустим, в результате проверки кредитной истории возвращается отнюдь
не блестящий отчет, и поэтому придется заполнить еще пять дополнитель
ных форм и взять образец крови.
Используя систему управления потоком операций, можно попытаться рас
смотреть все возможные сочетания и обстоятельства. И хотя имеется немало
таких систем, они могут быть довольно сложными для проектирования и про
граммирования. Ведь нормативы изменяются, а поток операций может быть
реорганизован. Так, если сменятся технологические процедуры, жестко закоди
рованный код, возможно, придется полностью переписать.
В сочетании с механизмом соблюдения правил, инкапсулирующих законные
требования, классная доска является изящным решением обнаруженных здесь
трудностей. Порядок поступления данных не имеет особого значения: как толь
ко на доске будет размещен некоторый факт, он может привести в действие со
ответствующие правила. Ответная реакция организуется так же легко: результат
соблюдения любого набора правил может быть размещен на классной доске,
приводя в действие другие подходящие правила.
-
Пользуйтесь классными досками для координации
потока выполнения
СИСТЕМЫ 06МЕНА СОО&ЩЕНИЯМИ МОГУТ
6ЫТЬ ПОДО&НЫ КЛАССНЫМ ДОСКАМ
На момент написания второго издания данной книги многие приложения
проектировались с помощью небольших развязанных служб, обменивавшихся
данными через некоторую форму системы обмена сообщениями. Такие систе
мы (например,
Kafka
и
NATS)
способны на гораздо большее, чем просто ор
ганизовывать обмен сообщениями между сторонами А и В. Они, в частности,
обеспечивают сохраняемость (в форме журнала регистрации событий), а также
возможность извлекать сообщения посредством определенной формы сопостав
ления с шаблоном. Это означает, что их можно применять в качестве системы
классной доски и/или платформы для выполнения целого ряда акторов.
Но НЕ ВСЕ ТАК ПРОСТО •••
Подходы к архитектуре с использованием актора, классной доски и/или мик
рослужбы устраняют целый класс потенциальных затруднений, обусловленных
в приложениях параллельностью . Но данное преимущество дается не бесплат
но. Такие подходы труднее осмыслить, поскольку они действуют по большей
части косвенно. Но при этом можно обнаружить, что они помогают организо-
Тема 36 • Классные доски
237
вать и вести центральное хранилище форматов сообщений и/или прикладные
интерфейсы
API,
особенно если в таком хранилище можно автоматически сге
нерировать код и документацию. Потребуется также хороший инструментарий
для отслеживания сообщений и фактов по мере их продвижения через систе
му. (В качестве удобной методики можно ввести однозначный идентификатор
трассировки при инициализации конкретной прикладной функции, а затем рас
пространить его среди всех заинтересованных акторов. Это позволит восстано
вить то, что происходит, из файлов регистрации.)
Наконец, развертывание и сопровождение такого рода системы может ока
заться затруднительным, поскольку в ней немало подвижных частей. Этот не
достаток в какой-то степени уравновешивается тем, что система оказывается
более детализированной и может быть обновлена заменой отдельных акторов,
а не целиком.
Другие разделы, связанные с данной темой
"Гибкость или ломкость".
•
Тема
28.
Развязывание, глава
•
Тема
29.
Манипулирование реальным миром, глава
5
5
"Гибкость или лом
кость".
•
Тема
33.
Разрывание временного связывания.
•
Тема
35.
Акторы и процессы.
Упражнения
24.
Подойдет ли система типа классной доски для перечисленных ниже прило
жений? Объясните, почему она может подойти или не подойти.
--
Обработка изображений. Здесь желательно иметь ряд параллельных
процессов, которые выбирают фрагменты изображения, обрабатывают
их и возвращают готовые фрагменты обратно.
-
Групповое ведение календаря. Здесь требуется запланировать совеща
ние участников проекта, рассредоточенных по всему миру, в разных ча
совых поясах и говорящих на разных языках.
Инструментальное средство текущего контроля сети. Здесь система
собирает статистические данные производительности и отчеты об от
казах, используемые посредниками для обнаружения неисправностей в
системе.
Задачи
•
Пользуетесь ли вы системами классных досок на практике, в том числе
доской семейных объявлений на холодильнике или белой доской на ра
боте? Чем они эффективны? Появляются ли вообще на них сообщения в
согласованном формате и насколько это важно?
ГЛАВА
7
По ходУ кодИРОВАНk'1Я
Житейская мудрость гласит: как только проект доходит до стадии кодиро
вания, работа становится в основном механическим воплощением проектного
решения в выполняемые операторы. На наш взгляд, такое отношение к проекту
служит самой главной причиной его неудачного окончания, а многие спроекти
рованные подобным образом системы оказываются скверными, неэффективны
ми, плохо структурированными, не поддающимися сопровождению или просто
наносящими ущерб.
Кодирование не механично. Если бы это было именно так, то все инструмен
тальные средства
CASE,
на которые возлагались большие надежды еще в начале
1980-х годов, уже давно заменили бы собой программистов. По ходу работы
приходится каждую минуту принимать решения, требующие тщательного об
думывания и оценивания, чтобы написанная в итоге программа работала долго,
надежно и продуктивно.
Не все решения даже просто здравы, поэтому лучше обуздывать себя, при
слушиваясь к своим инстинктам, как поясняется в соответствующем разделе.
В этом разделе будет показано, как прислушиваться к своим инстинктам более
осторожно и анализировать способы активной реакции на иногда пустячные
мысли.
Но необходимость прислушиваться к инстинктам совсем не означает, что
можно просто летать на автопилоте. Те разработчики, которые не обдумывают
активно свой код, программируют по совпадению. Это означает, что написанный
код может работать, но по какой именно причине
-
непонятно. Поэтому в раз
деле "Программирование по совпадению" отстаивается более положительный
подход к процессу программирования.
Несмотря на то что код, который мы пишем, выполняется быстро, мы вре
мя от времени разрабатываем алгоритмы, способные застопорить работу даже
самых быстродействующих процессоров. В связи с этим в разделе "Быстродейс
твие алгоритмов" обсуждаются способы оценивания быстродействия написан
ного кода и даются некоторые рекомендации относительно выявления потенци
альных осложнений в нем еще до того, как они возникнут.
240
Гnава 7 ~ По ходу кодирования
Прагматичные программисты умеют критически осмысливать весь код,
включая и свой собственный. Они постоянно ищут основания для совершен
ствования своих программ и проектов. Поэтому в разделе "Рефакторинг" будут
рассмотрены методики, помогающие постоянно исправлять существующий код
по ходу его написания.
Тестирование означает не столько обнаружение программных ошибок, сколь
ко получение ответной реакции на свой код, включая особенности архитектуры,
прикладного интерфейса
API,
связывания и т.д. Следовательно, основные вы
годы из тестирования проявляются тогда, когда тесты сначала обдумываются,
а затем пишутся, но не лишь тогда, когда они выполняются. Именно этот при
нцип и поясняется в разделе "Тестировать, чтобы кодировать".
Но, безусловно, когда вы тестируете свой код, вы можете привнести в ре
шаемую задачу свои пристрастия. Поэтому в разделе "Тестирование на основе
свойств" показано, как заставить компьютер выполнять обширное тестиро
вание автоматически и обрабатывать неизбежно возникающие программные
ошибки.
Очень важно писать удобочитаемый и понятный код. Окружающий мир по
лон злоумышленников, активно пытающихся взломать действующую систему
и нанести ей ущерб. Поэтому в разделе "Будьте осторожны" рассматриваются
самые элементарные методики и подходы, помогающие организовать надежную
защиту системы от взлома.
Наконец, одну из самых больших трудностей в разработке программного
обеспечения вызывает именование элементов кода. Разработчикам приходится
именовать немало элементов кода, и зачастую выбираемые ими имена определя ют ту реальность, которую они создают. Поэтому по ходу кодирования следует
постоянно иметь в виду любые возможные семантические отклонения.
Большинство из нас водят автомобиль в основном машинально, не давая
явно команду своей ступне нажать педаль или руке повернуть руль. Мы лишь
задумываемся о необходимости притормозить и повернуть направо или налево
в нужный момент. Но грамотные и осторожные водители постоянно оценивают
ситуацию на дороге, упреждая потенциальные осложнения и тем самым оказы
-
ваясь в лучшем положении, даже если произойдет что-нибудь непредвиденное.
Это же относится и к кодированию, которое в основном оказывается рутинным
занятием, но все же не зевайте
неприятности.
-
это поможет вам предотвратить возможные
Тема 37 ' Присnуwивайтесь к своим инстинктам
li@f;fQ
241
ПРИСЛУШИВАЙТЕСЬ К СВОИМ ИНСТИНКТАМ
"Только люди способны непосредственно рассматривать
что-то, имея всю необходимую информацию,
чтобы сделать точный прогноз, а возможно,
даже сделать его моментально и затем сказать,
что дело обстоит иначе".
Гэвин де Беккер, "Дар страха"
Труд всей жизни Гэвина де Беккера помогает людям защищать себя. Свои
взгляды на вопросы защиты от насилия он изложил в книге
Other Survival Signals That Protect Us from Violence [de 98).
The Gift of Fear: And
Одна из главных тем
этой книги касается того обстоятельства, что люди как высокоразвитые сущес
тва научились пренебрегать своей животной сущностью, своими инстинктами и
первобытными повадками. Он утверждает, что большинство людей, на которых
нападают на улице, чувствуют себя неуютно или нервничают перед нападением.
И эти люди просто внушают себе, что не стоит вести себя так глупо. И тогда из
темного прохода возникает чужая фигура ...
Инстинкты являются попросту реакцией на образцы поведения, хранящиеся
в нашем бессознательном. Одни из них врожденные, другие приобретены через
повторение. По мере накопления опыта программирования в уме незаметно от
кладываются слоями знания о том, что пригодно и что непригодно, о вероятных
причинах типов ошибок и обо всем, что подмечается изо дня в день. Эта часть
ума действует подобно экранной кнопке сохранения файла, которую вы нажима
ете, когда прекращаете интерактивную переписку с кем-нибудь в оперативном
режиме, даже не осознавая того, что делаете.
Независимо от происхождения инстинктов, им присуща одна общая особен
ность: они безмолвны . Инстинкты вызывают ощущение, а не мысль, и поэтому,
когда возбуждается инстинкт, вы не видите никакой вспыхивающей лампочки с
крупным заголовком вокруг. Вместо этого вы начинаете нервничать, испытыва
ете недомогание и просто чувствуете, что предстоит слишком много работать.
Вся хитрость здесь в том, чтобы сначала заметить, что это происходит, а за
тем выяснить причину. Рассмотрим для начала пару типичных случаев, когда
внутренний инстинкт пытается нам что-то подсказать, а затем обсудим, как вы
зволить свой инстинктивный ум из его защитной оболочки.
Боязнь пустой стРдницы
Все испытывают страх перед пустым экраном, где одиноко мигает курсор.
Начало нового проекта (и даже нового модуля в уже существующем проекте)
242
Глава 7 • По ходу кодирования
может стоить немалых нервов. Поэтому многие из нас предпочитают отсрочить
первоначальное обязательство приступить к делу. На наш взгляд, это связано с
двумя затруднениями, для которых имеется одно и то же решение.
Одно затруднение связано с тем, что наш инстинкт пытается нам что-то под
сказать. Но под самой личиной восприятия скрывается какое-то сомнение, что
очень важно. Всякому разработчику приходится опробовать разные подходы,
чтобы выяснить, какие из них годятся, а какие непригодны. И подобным обра
зом накапливаются знания и опыт. Так, если вы чувствуете неотвязное сомнение
или испытываете нежелание решать какую-то задачу, то вполне возможно, что
это вам подсказывает ваш опыт. Прислушайтесь к нему. Не спешите совершать
явно неверный шаг, а подождите, пока ваши сомнения не оформятся в нечто
более ощутимое, чтобы их можно было разрешить. Дайте волю вашим инстин
ктам, чтобы они способствовали вашим поступкам.
Другое затруднение более прозаично. Вы можете просто бояться совершить
ошибку. И это вполне обоснованное опасение. Ведь разработчики немало вкла
дывают в свой код и поэтому могут воспринимать ошибки в нем как отражение
их компетентности. В этом, вероятно, есть также элемент синдрома самозванца.
Разработчикам может показаться, что данный проект им не под силу. Они не в
состоянии найти способ довести его до конца. Зайдя слишком далеко, они вы
нуждены признать, что потерялись.
БОРЬБА С СОБОЙ
Иногда код просто вылетает из вашего ума прямо в текстовый редактор, а
идеи воплощаются в код без всяких усилий.
А порой кодирование воспринимается как ходьба в гору по колено в грязи.
Каждый шаг требует громадных усилий, а через каждые три шага вы соскаль
зываете на два шага назад.
Но, будучи профессионалом, вы упорно продвигаетесь по этой грязи шаг за
шагом вперед, поскольку вам нужно делать свое дело. К сожалению, это, веро
ятно, именно то, чего вам не следует делать.
Ваш код пытается вам что-то подсказать. Он говорит, что его можно было бы
написать проще, чем это сделано. Возможно, структура или архитектура была
выбрана неверно, а может быть, неверной оказалась сама решаемая задача или
же вы просто создаете нечто, подобное муравейнику, достойному обитающих в
нем насекомых. Независимо от конкретной причины, ваши инстинкты воспри
нимают ответную реакцию написанного кода, отчаянно пытающегося обратить
на себя ваше внимание.
Тема 37 " Прислушивайтесь к своим инстинктам
243
КАК ПРИСЛУШИВАТЬСЯ К СВОИМ ИНСТИНКТАМ
Мы уже не раз подчеркивали, что необходимо прислушиваться к своим ин
стинктам, к своему бессознательному, первобытному уму. А существующие для
этого методы всегда одинаковы.
Прислушивайтесь к своим внутренним чувствам
Прежде всего, приостановитесь в своей работе. Уделите время и место, что
бы позволить вашему мозгу самоорганизоваться. Перестаньте думать о коде и
займитесь на время чем-нибудь откровенно бездумным и далеким от мысли о
клавиатуре. Прогуляйтесь, пообедайте, побеседуйте с кем-нибудь, а может быть,
даже вздремните немного. Дайте мыслям самим непринужденно проникнуть
сквозь слои вашего ума. И когда они в конечном счете достигнут уровня вашего
сознания, вы переживете один из моментов озарения.
Если этот способ не сработает, попытайтесь облечь возникшее затруднение
во внешнюю форму. Сделайте зарисовки о написанном вами коде или объясни
те его своему коллеге (желательно не программисту) либо своему резиновому
утенку. Раскройте разные участки своего ума для возникшего затруднения и
выясните, какой из них лучше всего подойдет для того, чтобы разрешить дан
ное затруднение. Мы уже потеряли счет беседам, в ходе которых один из нас
объяснял другому возникшее у него затруднение и неожиданно восклицал: "Ах,
да! Конечно!", сразу прерывая беседу, чтобы немедля устранить обсуждавшееся
затруднение.
Вполне возможно, что вы уже опробовали описанные выше способы на прак
тике и все равно не вышли из затруднения. В таком случае время действовать,
и мы должны сказать вашему уму, что все, что вы собираетесь делать, не имеет
никакого значения. И для этого мы прибегнем к прототипированию.
ВРЕМЯ ИГРАТЬ!
Авторам этой книги не раз приходилось часами глядеть на чистый экран
текстового редактора. Сначала мы набирали какой-нибудь код, затем глядели
в потолок, делали очередной глоток кофе, снова набирали немного кода, после
этого читали забавный рассказ, например, о коте с двумя хвостами, опять наби
рали еще немного кода и, наконец, выделив весь исходный текст, удаляли его,
начиная все с самого начала. И все это повторялось снова и снова.
С годами у нас выработался вполне работоспособный, на наш взгляд, метод
взлома сознания . Внушите себе, что вам требуется создать прототип чего-ни
будь. Если перед вами пустой экран, найдите такую особенность своего про
екта, которая требует исследования. Это может быть, например, новый каркас,
Гnава 7 " По ходу кодирования
244
применяемый в вашем проекте, и вам нужно выяснить, каким образом в нем
осуществляется привязка данных; или же новый алгоритм, который требуется
испытать на работоспособность в крайних случаях. А возможно, вам требуется
опробовать два разных стиля взаимодействия с пользователем. Если, работая с
существующим кодом, вы испытываете сопротивление с его стороны, сохраните
его где- нибудь и создайте прототип, выполняющий аналогичные функции.
С этой целью выполните следующие действия.
1. Напишите фразу "Я создаю прототип" на клейкой бумажке для заметок и
прикрепите ее к боковой стороне экрана своего монитора.
2.
Напомните себе, что прототипы обречены на неудачу и выбрасывание,
даже если они окажутся удачными. А самое главное, что в этом не следует
усматривать никакого недостатка.
3.
Создайте в пустом буфере текстового редактора комментарии, описыва
ющие одним предложением, что именно вам требуется изучить или сде
лать.
4.
Начните программировать.
Если вас начнут мучить сомнения, посмотрите на бумажку на мониторе.
А если по ходу кодирования неотвязное сомнение неожиданно оформится в яс
ный вопрос, то разрешите его. Если же, дойдя до конца своего эксперимента,
вы все еще будете испытывать неловкость, начните все с самого начала, сделав
перерыв на прогулку, беседу и отдых.
Но, как показывает наш опыт, в какой-то момент по ходу создания первого
прототипа вы с удивлением обнаружите, что, напевая под музыку, с удовольс
твием пишете код. Ваша нервозность исчезнет без следа, вытесненная неуемным
желанием создать нечто конкретное. На этой стадии вы уже будете знать, что
нужно делать. В таком случае
-
удалите код прототипа, выбросите бумажку для
записей в мусорную корзину и заполняйте экран текстового редактора блестя
щим новым кодом.
НЕ ТОЛЬКО СВОЙ КОД
Львиная доля обязанностей разработчиков приходится на работу с уже су
ществующим кодом, нередко написанным другими людьми. У этих людей были
не такие инстинкты, как у вас, и поэтому их решения были иными. И хотя эти
решения совсем не обязательно неудачные, они все же иные.
Чужой код можно читать механически, скрупулезно делая заметки, которые
кажутся важными. Хотя это и рутинный, но все же работоспособный метод.
С другой стороны, можно попытаться провести эксперимент. Если вы обна
ружите, что код кажется странным
-
сделайте соответствующие заметки. Затем
продолжите дальше и поищите возможные шаблоны. Если вам удастся выяс-
Тема 38 • Проrраммирование по совпадению
245
нить, чем руководствовались программисты при написании анализируемого
кода именно так, а не иначе,
-
возможно, вам будет легче его понять. И тогда
вы сможете вполне осознанно применять шаблоны, которые подразумевались
при разработке данного кода. Более того, вы даже можете узнать что-то новое
для себя, анализируя чужой код.
НЕ только код
Умение прислушиваться к своим инстинктам при программировании являет
ся важным навыком, который стоит приобрести . Но такой подход применим и
к более общей картине. Иногда проектное решение кажется просто неверным, а
какое-нибудь требование вызывает ощущение неловкости. В таком случае сле
дует остановиться и проанализировать свои ощущения. Если вы работаете в
благоприятной для этого среде, выразите свои ощущения явно и исследуйте их.
Скорее всего, что-нибудь да промелькнет в темном углу. Прислушайтесь к своим
инстинктам, чтобы избежать осложнений до того, как они на вас навалятся.
Другие разделы, связанные с данной темой
•
Тема
13.
•
Тема
22.
Прототипы и памятные записки, rлава
Технические дневники, rлава
3
2 "Прагматичный
подход".
"Основные инструментальные
средства".
•
Тема
46.
Решение неразрешимых головоломок, глава
8 "До начала проекта':
Задачи
•
Есть ли что-нибудь такое, что, на ваш взгляд, должно быть сделано, но
вы отложили его реализацию на 'время, поскольку чувствуете боязнь или
предчувствуете трудности? В таком случае примените методы, описанные
в этом разделе, уделив им один или два часа и дав себе слово, что, когда
прозвенит звонок, удалите все, что было сделано за это время. Чему вы в
итоге научились?
i.Jl&*J:) ПРОГРАММИРОВАНИЕ ПО СОВПАДЕНИЮ
Приходилось ли вам когда-нибудь смотреть старые черно-белые фильмы о
войне? Усталое лицо солдата осторожно высовывается из-за кустов. Впереди
-
открытая полянка, но не зарыты ли на ней противопехотные мины или же ее
можно пересечь безопасно? Ничто не указывает на минное поле: никаких предуп
реждающих знаков, колючей проволоки или воронок от взорвавшихся мин. Сол
дат прощупывает штыком землю перед собой и отшатывается, ожидая взрыва.
246
Глава 7 • По ходу кодирования
А поскольку ничего не происходит, то он шаг за шагом продвигается по полю,
протыкая землю штыком и ощупывая местность. В конечном счете он убеждает
ся, что поле безопасно, и тогда выпрямляется и гордо ступает вперед лишь для
того, чтобы быть разорванным на куски взорвавшейся миной. Выходит, перво
начальные поиски мин ничего не выявили, и солдату просто везло. В конечном
счете это привело его к ложному заключению и злополучному исходу.
Разработчики работают в условиях, которые весьма напоминают такие мин ные поля. Каждый день их ожидают сотни ловушек, в которые они могут по
пасть. Памятуя о злополучной участи солдата, они должны делать выводы очень
осторожно. Им, в частности, следует избегать программирования по совпаде
нию, полагаясь на удачу и случайный успех, а лучше программировать осто
рожно.
КАК ПРОГРАММИРОВАТЬ ПО СОВПАДЕНИЮ
Допустим, Фред получил определенное задание. Он набирает некоторый код,
тестирует его и делает вывод, что код, по-видимому, работоспособен. Далее Фред
набирает еще немного кода, опробует его и снова находит его работоспособным.
Через несколько недель программирования в таком стиле получившаяся в ко
нечном итоге программа неожиданно перестает работать. Потратив на попытки
устранить неполадки не один час, Фред все еще не знает причин, по которым
его программа не работает. Он может потратить немало времени на выявление
сбойного фрагмента кода, так и не сумев исправить положение. И что бы он ни
делал, его программа так и не работает нормально.
Фреду оказались неизвестны причины сбоев в программе потому, что он не
выяснил, почему она работала прежде. После ограниченного тестирования Фре
ду показалось, что программа работает нормально, но это произошло лишь по
случайному совпадению. Подбодрившись ложной уверенностью, Фред ринулся
вперед, забыв об осторожности, и наткнулся на мину. Многим умным людям,
вероятно, известны такие личности, как Фред, а нам известно кое-что получше.
Мы не полагаемся на случайные совпадения, но так ли это на самом деле? Иног
да мы можем поступить таким образом. Ведь часто очень легко спутать счастли
вое совпадение с преднамеренным планом действий. Поэтому рассмотрим ряд
конкретных примеров.
Случайности реализации
Они происходят просто потому, что код написан в данный момент именно
так, а не иначе. И в конечном счете приходится полагаться на недокументиро
ванную ошибку или граничные условия.
Допустим, подпрограмма вызывается с неверными данными. Подпрограмма
дает некоторый ответ, и вызывающий код опирается на него. Но автор подпро
граммы не предусмотрел именно такой режим работы подпрограммы и даже не
Тема 38 • Программирование по совпадению
247
рассматривал его. Если внести в подпрограмму требующиеся поправки, работа
вызывающего кода может просто нарушиться. В самом крайнем случае вызы
ваемая подпрограмма может быть даже не предназначена делать то, что от нее
требуется в вызывающем коде. Тем не менее она, по-видимому, вполне работос
пособна. Аналогичное затруднение возникает при вызовах не в том порядке или
же не в том контексте.
Это похоже на отчаянные попытки Фреда вывести что-нибудь на экран, используя конкретный каркас
GUI:
paint ();
invalidate () ;
validate () ;
revalidate () ;
repaint();
paintimmediately();
Но перечисленные подпрограммы никогда не создавались для вызова таким
образом; хотяони выглядят работоспособными, на самом деле это всего лишь
совпадение.
Положение усугубляется еще больше, когда окончательный вывод выглядит
нормально, и Фред даже не попытается вернуться назад и устранить ложные
вызовы. Он считает, что его программа работает нормально и лучше не трогать
то, что и так работает.
Такая нить рассуждений может ввести в заблуждение. В самом деле, зачем
рисковать, приводя в беспорядок то, что уже работает? Что ж, рассмотрим не
сколько следующих причин, дающих ответ на этот вопрос.
•
Программа может на самом деле не работать, а только делать вид, что нор
мально работает.
•
Граничное условие, на котором вы основываетесь, может оказаться прос
той случайностью. Это означает, что при разных обстоятельствах (разном
разрешении экрана или количестве ядер процессора) программа может
работать по-разному.
•
Недокументированное поведение может измениться в следующем выпуске
библиотеки.
•
Дополнительные и излишние вызовы могут замедлить работу программы.
•
Дополнительные вызовы увеличивают риск добавления новых програм
мных ошибок.
Для кода, который пишется с расчетом быть вызванным из другого кода, мо
гут вполне пригодиться основные принципы модуляризации и сокрытия реали
зации за небольшими хорошо документированными интерфейсами. А грамот
но составленный контракт (см. раздел "Тема
23.
Проектирование по контракту"
248
Гnава 7 • По ходу кодирования
главы
4
"Прагматичная паранойя") может оказать помощь в устранении недо
разумений. Что же касается вызываемых подпрограмм, то следует полагаться
на документированное поведение. Если же это по какой-нибудь причине невоз
можно, то следует задокументировать свое допущение.
Недостаток точности
Однажды нам пришлось работать над крупным проектом, выводившим дан
ные из очень большого количества запоминающих устройств непосредственно
в поле. Эти устройства были рассредоточены по разным штатам и часовым по
ясам, и каждое из них по различным логистическим и историческим причинам
было настроено на местное время 1 • В результате конфликтов в интерпретации
часовых поясов и несогласованности правил перехода на летнее время результа
ты почти всегда получались неверными, хотя и отличались всего лишь на еди
ницу. Разработчики данного проекта решили просто прибавлять или отнимать
единицу, чтобы получить правильный ответ, полагая, что в данной конкретной
ситуации он будет отличаться всего лишь на единицу. И когда следующая фун кция обнаружит, что значение сместилось на единицу в другую сторону, она
возвратит его обратно.
Но смещение результатов "всего лишь" на единицу оказалось совпадением, за
которым скрывался более глубокий и основательный изъян. В отсутствие надлежа
щей модели интерпретации времени вся крупная кодовая база превратилась со вре
менем в совершенно непригодную массу операторов
+1
и
-1. И в конечном счете
ни один из них не оказался верным, а проект пришлось отправить на свалку.
Ложные закономерности
Человеческие существа предрасположены усматривать закономерности и
причины даже в том случае, когда это всего лишь совпадение. Например, в Рос
сии всегда чередовались то лысые, то волосатые правители: на протяжении
200
лет лысый (или явно лысеющий) государственный деятель сменялся волосатым,
т.е. совсем не лысым, и наоборот2 •
Но если никому не придет в голову написать код в зависимости от того, будет
ли следующий правитель России лысым или волосатым, то в некоторых пред
метных областях разработчики все время рассуждают именно таким образом.
Игроки выдумывают закономерности в лотерейных номерах, бросаемых костях
или крутящихся рулетках, когда на самом деле это статистически независимые
события. Аналогично в финансовой сфере биржевые операции с акциями и об
лигациями полны совпадений, а не вполне различимых закономерностей.
Примечание стреляного воробья: используйте всемирное координированное время
(UTC).
1
См. по адресу https: //en. wikipedia. org/wiki/Correlation_ does _not_ imply_
causation.
2
Тема 38 • Проrраммирование по совпадению
Журнальный файл, в котором ошибка появляется через каждые
1000
249
запро
сов, может представлять труднодиагностируемое состояние гонки, а возможно,
просто результат старой программной ошибки. Тесты, которые вроде бы прохо
дят на одной машине, моrут не пройти на сервере, выявив тем самым отличия в
обеих средах. А может быть, это простое совпадение. Словом, не допускайте, а
убеждайтесь.
Случайности контекста
Вполне возможны и так называемые "случайности контекста". Допустим,
требуется написать служебный модуль. Следует ли полагаться на обязательное
наличие графического интерфейса пользователя только потому, что этот модуль
разрабатывается в настоящий момент для GUI-cpeды? Рассчитан ли этот модуль
на англоязычных пользователей? На обладающих специальной подготовкой? На
что еще не стоит полагаться, если оно не гарантируется?
Следует ли полагаться на то, что текущий каталог доступен для чтения? На
личествуют ли определенные переменные окружения или файлы конфигурации?
Будет ли сервер со временем работать точно и с каким допуском? Стоит ли по
лагаться на доступность и быстродействие сети?
Скопировав исходный код, полученный по первому же ответу, найденному в
сети, можно ли быть уверенным, что он имеет тот же контекст? Не разрабаты
вается ли код в стиле карго-культа, просто выполняя имитацию без контекста? 3
Найти подходящий ответ на все эти вопросы еще не означает получить правиль
ный ответ.
Не программируйте по совпадению
Ненвнь1е аопущениR
Совпадения моrут вводить в заблуждение на всех уровнях: от составления
требований до тестирования. В частности, тестирование чревато ложными при
чинными зависимостями и случайными следствиями. Ведь очень легко предпо
ложить, что Х приводит к У, но, как упоминалось ранее в совете
"Тема
20.
Отладка" главы
3 "Основные инструментальные
34
из раздела
средства': не предпо
лагайте, а доказывайте.
Люди на всех уровнях оперируют в своем уме многими предположениями,
но эти предположения редко документируются и зачастую вызывают споры у
разных разработчиков. Предположения, не основывающиеся на точно установ
ленных фактах, являются бедой любых проектов.
3
С м.
раздел
"...,~ема 50 . Кокосами не об оитись
•
" в главе 9, "Прагматичные проекты".
250
Глава 7 ,, По ходу кодирования
КАК ПРОГРАММИРОВАТЬ ОБДУМАННО
Всем нам хотелось бы уделять меньше времени исправлению кода, выявляя и
устраняя ошибки на как можно более ранней стадии разработки, а также внося
в код как можно меньше ошибок. Этого можно добиться, программируя обду
манно, следуя приведенным ниже рекомендациям.
s
Старайтесь всегда понимать, что вы делаете. Упоминавшийся ранее Фред
медленно пустил дело на самотек до тех пор, пока не ошпарился как ля
гушка, о которой речь шла в разделе "Тема
лягушки" главы
•
1 "Философия
4.
Суп из камней и вареные
прагматизма".
Сможете ли вы подробно объяснить код менее опытному программисту?
Если вам это не удается, значит вы, вероятнее всего, полагаетесь на сов
падения.
•
Не программируйте в темноте. Стоит вам написать приложение, в котором
вы сами не разобрались до последней буквы, или воспользоваться техно
логией, которую не полностью понимаете, как вы тотчас будете ужалены
совпадениями. И если вы не знаете причин, по которым программа рабо
тает,
•
-
значит, вы не знаете причин, по которым она может отказать.
Действуйте на основе плана, будь то составленного в вашем уме, начертан -
ного на салфетке или написанного на доске.
•
Полагайтесь только на надежные факты, а не на предположения. Если вы
не знаете, надежно ли что-нибудь,
•
-
допустите самое худшее.
Документируйте свои предположения. Материал раздела "Тема
тирование по контракту" главы
4
23.
Проек
"Прагматичная паранойя" поможет вам
как самому прояснить свои предположения, так и поделиться ими с дру
гими.
•
Не ограничивайтесь только тестированием своего кода, тестируйте и свои
предположения. Не гадайте
-
испытайте их. Напишите утверждение для
проверки своих предположений (см. раздел "Тема
граммирование" главы
4
25. Утвердительное про
"Прагматичная паранойя"). Если ваше утверж
дение окажется верным, значит, вы улучшили документирование своего
кода. А если оно окажется неверным, то можете считать себя везунчиком.
•
Расставьте приоритеты в своей работе. Уделите время самым важным ее
аспектам. Более чем вероятно, что эти аспекты окажутся и самыми труд
ными. В отсутствие прочных и верных основ или инфраструктуры любые
излишества неуместны.
•
Не привязывайтесь к истории, позволяя существующему коду диктовать
условия будущему коду. Можно заменить весь код, если он больше не го-
Тема 38 • Проrрамммрованме по совпадению
251
дится. И даже в одной программе не позволяйте тому, что уже сделано,
накладывать ограничения на то, что предстоит сделать. Будьте готовы к
рефакторингу кода (см. далее раздел "Тема
40.
Рефакторинг"). Такое ре
шение может повлиять на календарный план работы над проектом. При
этом предполагается, что принятие этого решения приведет к меньшим
затратам, чем его не принятие4 •
Таким образом, в следующий раз, когда что-нибудь покажется вам работос
пособным, но вы не знаете, почему - непременно убедитесь, что это не просто
совпадение.
Допустим, данные предоставлены поставщиком в виде массива кортежей, со
стоящих из пар "ключ-значение". В частности, для ключа
значение
содержит
символьную
строку с
номером
Deposi tAccount
счета,
как
показано
ниже.
{:DepositAccount, "564-904-143-00"}
Такая структура данных показала себя идеально при проверке, проведен
ной на компьютерах разработчиков с 4-ядерными процессорами, а также
на сборочной машине с 12-ядерным процессором. Но на рабочих серверах,
работающих в контейнерах, постоянно получаются неверные номера счетов.
Что происходит?
4 Здесь
можно зайти слишком далеко. Мы как-то познакомились с одним разработчиком,
переписавшим весь переданный ему исходный код только потому, что у него были свои
соглашения по именованию.
Глава 7 • По ходу кодирования
252
26.
Допустим, требуется запрограммировать автоматический номеронабиратель
для голосовых предупреждений и вести базу данных контактной информа
ции. По спецификации Международного союза электросвязи (IТU) телефон ные номера не могут быть длиннее
15
цифр, так что вы сохраняете номер
телефона в числовом поле, гарантированно хранящем как минимум
15 цифр.
Данное устройство было тщательно испытано на всей территории Северной
Америки, и все было нормально". но неожиданно из других частей света
устремился поток жалоб. Почему так произошло?
27.
Допустим, вы написали приложение, которое масштабируется для ресторана
круизного судна на
5000 посадочных мест. Вы получаете жалобы на то, что
преобразования неточны. Вы проверяете прикладной код, в котором приме
няется формула преобразования
1i@tfQ
16 чашек в галлон. Правильно это или нет?
БЫСТРОДЕЙСТВИЕ АЛГОРИТМОВ
В разделе "Тема
15.
Оценивание" главы
2
"Прагматичный подход" речь шла о
том, как оценить, сколько времени отнимет прогулка по городу или завершение
проекта. Но имеется и другая разновидность оценок, которой программисты
прагматики пользуются ежедневно. Речь идет об оценке таких используемых
в алгоритмах ресурсов, как, например, время, процессор, оперативная память
и т.д.
Такого рода оценка нередко имеет решающее значение. Так, если имеются два
способа сделать что-нибудь, то какой из них лучше выбрать? Известно, за какое
время программа обрабатывает
до
1000000
1ООО записей,
но если ее нужно масштабировать
записей? Какие ее части при этом необходимо оптимизировать?
Оказывается, что на все эти вопросы можно ответить, призвав на помощь
здравый смысл, произведя некоторый анализ и воспользовавшись способом за
писи аппроксимаций, именуемых асимптотическим обозначением, или обозна
чением "О большое".
Что ПОДРАЗУМЕВАЕТСЯ под ОЦЕНКОЙ АЛГОРИТМОВ
В большинстве нетривиальных алгоритмов обрабатываются переменные
входные данные некоторого рода; например, сортируются п символьных строк,
преобразуется матрица т х п или сообщение расшифровывается с помощью
п-разрядного ключа. Как правило, объем входных данных оказывает влияние на
работу алгоритма: чем больше этот объем, тем дольше обрабатываются данные
и больше оперативной памяти для этого требуется.
Если бы такое соотношение всегда было линейным (т.е. чтобы время уве
личивалось прямо пропорционально величине п), то этот раздел не стоило бы
Тема 39 • Быстродействие алгоритмов
253
даже писать. Но большинство важных алгоритмов не линейны. Хорошая но
вость
-
среди них имеется немало сублинейных алгоритмов. Например, алго
ритму бинарного поиска не требуется просматривать все элементы для обна
ружения нужного. Плохая новость в том, что другие алгоритмы значительно
уступают в быстродействии линейным алгоритмам, поскольку время их выпол
нения и требования к оперативной памяти возрастают быстрее, чем п. Такой
алгоритм, которому для обработки десяти элементов требуется минута, может
потребовать целой жизни для обработки ста элементов.
Всякий раз, когда мы пишем какой-нибудь код, содержащий циклы или ре
курсивные вызовы функций, мы неосознанно проверяем требования ко време
ни выполнения и оперативной памяти. Такой процесс редко носит формальный
характер и скорее служит для быстрого подтверждения правильности того, что
мы делаем в определенных обстоятельствах. Но иногда нам все же приходится
выполнять более подробный анализ. Именно тогда и приходит на помощь асим
птотическое обозначение.
АСИМПТОТИЧЕСКОЕ ОБОЗНАЧЕНИЕ
Асимптотическое обозначение, записываемое как О(), является математичес
ким средством обращения с аппроксимациями. Так, если сортировка п записей
в конкретной подпрограмме отнимает время О(п 2 ), такое обозначение означает,
что в худшем случае время сортировки записей будет изменять как квадрат п.
Стоит удвоить количество записей, как время их сортировки увеличится при
близительно в четыре раза. Обозначение О, по существу, означает "около ..." или
мой величины (времени, объема оперативной памяти и т.д.). Так, если говорят,
что для выполнения функции требуется время О(п 2 ), то известно, что верхний
предел времени ее выполнения не будет расти быстрее, чем п 2 • Иногда прихо
дится иметь дело с довольно сложными функциями О(), но поскольку по мере
увеличения п преобладает член высшего порядка, то обычно удаляются все чле
ны низкого порядка, а также все постоянные множители, как показано ниже.
о(п: +Зп) представляет собой то же, что и 0(~2 ). и то же, что и О(п2 ).
Таково свойство асимптотического обозначения О() - один алгоритм О(п 2 )
может действовать в 1000 раз быстрее, чем другой алгоритм О(п 2 ), но это никак
нельзя узнать из самого асимптотического обозначения. Конкретные числовые
значения времени, объема оперативной памяти или иных величин из асимпто
тического обозначения получить нельзя. Оно просто показывает, каким обра
зом эти величины будут изменяться по мере изменения входных данных.
Глава 7 "' По ходу кодирования
254
На рис.
7.1
показано несколько типичных асимптотических обозначений О()
наряду с графиком для сравнения времени выполнения алгоритмов каждой ка
тегории. Очевидно, что алгоритм выходит из повиновения, как только преодо
левается предел О(п 2 ).
со
a:i
1--
(.)
ф
ЭЕ
о
:I:
::?;
ig;
:s::
:с
ф
:с
i:;:
о
с
:i
ID
ф
:s;
1--
2i
Q.
:..:
о
r::
с-
(.)
о
g;
::Е
ф
а.
111
0(1 ):
обращение к элементу массива
п---+
Рис.
7.1.
Время выполнения различных алгоритмов
Допустим, имеется подпрограмма, которой требуется одна секунда для об
работки
100
записей. Сколько времени отнимет обработка
1000
записей? Если
имеется алгоритм О( 1), то для этой цели потребуется одна секунда. Если же
это алгоритм
O(lgn), то
ждать, вероятно, придется около трех секунд. Алгоритм
О(п) покажет линейное увеличение времени обработки до десяти секунд, тог
да как алгоритм
O(nlgn) -
до
33
секунд. Если же неудачно выбрать алгоритм
О(п 2 ), то окончания обработки придется ждать уже 100 секунд. А если восполь
зоваться алгоритмом 0(2п), то можно смело сделать перерыв на чашку чая или
кофе, поскольку обработка должна завершиться приблизительно через 10 263 лет,
и мы узнаем, каким окажется конец существования вселенной.
Асимптотическое обозначение О() применяется не только ко времени. С его
помощью можно представить любые ресурсы, используемые в алгоритме. На
пример, зачастую оказывается полезно смоделировать потребление оперативной
памяти (см., например, упражнения в конце этого раздела).
Тема 39 • Быстродействие аnrоритмов
255
Ниже перечислены типичные алгоритмы и их асимптотическое обозначе
ние.
0(1)
Постоянная зависимость (доступ к элементу массива, простые опе
РАЗУМНОЕ ОЦЕНИВАНИЕ АЛГОРИТМОВ
Многие простые алгоритмы можно оценить, руководствуясь здравым смыс
лом, как поясняется ниже.
•
Простые циклы. Если простой цикл выполняется от
1 до
п, то ему, вероят
нее всего, соответствует алгоритм О(п), где время увеличивается линейно
по мере увеличения п. Характерными тому примерами служат исчерпыва
ющий поиск, нахождение максимального значения в массиве и вычисление
контрольных сумм.
•
Вложенные циклы. Если один цикл вложен в другой, то ему соответствует
алгоритм О(тхп), где тип -
два предела выполнения циклов. Это обыч
но происходит в таких простых алгоритмах сортировки, как, например,
пузырьковым методом, где во внешнем цикле каждый элемент массива
просматривается по очереди, а во внутреннем цикле обнаруживается мес
то, где следует разместить данный элемент в отсортированном результате.
Такие алгоритмы сортировки обычно являются алгоритмами О(п 2 ).
•
Бинарный поиск делением пополам. Если алгоритм на каждом шаге делит
множество элементов пополам, то он, вероятнее всего, имеет логарифми ческое время выполнения
O(lgn).
Ту же сложность имеет бинарный поиск
в отсортированном списке, обход бинарного дерева и обнаружение перво
го установленного бита в машинном слове.
Глава 7 • По ходу кодирования
256
•
Декомпозиция. Алгоритмы, сначала разделяющие входные данные на две
независимые половины, обрабатывающие их по отдельности, а затем объ
единяющие результат, обычно являются алгоритмами
O(nlgn).
Классичес
ким примером служит быстрая сортировка, разделяющая данные на две
половины и рекурсивно сортирующая каждую из них. И хотя формально
это алгоритм О(п 2 ), поскольку в наихудшем случае, когда на вход посту
пают отсортированные входные данные, его работа сильно замедляется,
среднее время быстрой сортировки все же составляет
•
O(nlgn).
Перестановка. Всякий раз, когда в алгоритмах начинается анализ пере
становок элементов, время их выполнения может выйти из-под контро
ля. Объясняется это тем, что в перестановках задействованы факториалы
(например, 5!=5х4х3х2х 1=120 перестановок цифр от
1 до 5).
Для пере
становки шести элементов по сравнению с пятью потребуется в шесть раз
больше времени, а для перестановки семи элементов
-
в
42
раза. Харак
терными примерами применения алгоритмов перестановки служат такие
признанные трудно разрешимыми задачи, как задача коммивояжера, оп
тимальная упаковка товаров в контейнер, разбиение множества чисел та
ким образом, чтобы получить одинаковую сумму в каждом подмножестве,
и т.д. Нередко для сокращения времени выполнения подобных алгоритмов
в конкретной предметной области применяется эвристический анализ.
БЫСТРОДЕЙСТВИЕ АЛГОРИТМА НА ПРАКТИКЕ
Вы вряд ли будете тратить много времени на то, чтобы писать подпрограм
мы сортировки. Доступные в библиотеках подпрограммы, вероятно, превзойдут
все, что вы могли бы написать без существенных усилий. Тем не менее время от
времени приходится встречаться с описанными выше типами алгоритмов. Вся
кий раз, когда вам приходится писать простой цикл, знайте, что вы имеете дело
с алгоритмом О(п). Если же этот цикл содержит внутренний цикл, значит, перед
вами алгоритм О(тхп). И тогда вы должны задаться вопросом: насколько круп
ными могут оказаться массивы сортируемых значений? Если они ограничены,
то можно оценить, сколько времени потребуется для выполнения сортирующе
го кода. Но если размеры зависят от внешних факторов (например, количества
записей для пакетной обработки ночью или количества имен в списке людей),
то вам, возможно, придется остановиться и рассмотреть влияние, которое боль
шие входные данные могут оказать на время выполнения программы или объем
потребляемой ею оперативной памяти.
Gфt§iil Оценивайте порядок производительности своих алгоритмов
Тема 39 • Быстродействие аnrоритмов
257
Имеется ряд подходов, которые можно предпринять для разрешения по
тенциальных затруднений. Так, если у вас имеется алгоритм О(п 2 ), попытай
тесь воспользоваться подходом "разделяй и властвуй", чтобы найти алгоритм
O(nlgn).
Если вы не знаете, как долго будет выполняться ваш код или сколько опера
тивной памяти ему потребуется, попробуйте сначала выполнить его для неболь
ших количеств входных данных (того, что, вероятнее всего, оказывает влияние
на время выполнения), а затем нанесите полученные результаты на график. По
виду кривой этого графика вы сможете сразу же судить о зависимости времени
выполнения от размера входных данных. Для того чтобы увидеть, изгибается ли
кривая графика вверх, выпрямляется в линию или сглаживается по мере увели
чения объема входных данных, обычно достаточно получить три-четыре точки.
Обратите также внимание на то, что вы делаете в самом коде. Простой цикл
алгоритма О(п 2 ) может проявить себя лучше, чем сложный цикл алгоритма
O(nlgn)
при малых значениях п, особенно если в цикле алгоритма
O(nlgn)
име
ется дорогостоящий внутренний цикл.
Не забудьте и о том, что имеются и практические соображения . Так, при не
больших массивах входных данных время выполнения может возрастать линей
но. Но стоит подать на вход миллионы записей, как время выполнения кода
резко возрастет, а производительность системы
-
упадет. Если вы проверяете
подпрограмму сортировки со случайными входными данными, вас может уди
вить ее поведение, когда она столкнется с упорядоченными входными данны
ми. Постарайтесь учесть как теоретические, так и практические соображения.
В конечном итоге имеет значение лишь проверка быстродействия вашего кода
в реальной производственной среде, с реальными входными данными. Это при
водит к следующему совету:
Проверяйте свои оценки
Если трудно получить точные временные характеристики, воспользуйтесь
профайлерами кода, чтобы подсчитать, сколько раз в вашем алгоритме выпол
няются разные действия, а затем нанесите полученные данные на график зави
симости от размера входных данных.
Лучшее не всеzда лучшее
Прагматиком необходимо быть и при выборе подходящего алгоритма, пос
кольку самый быстродействующий алгоритм далеко не всегда оказывается на
илучшим для решения конкретной задачи. Так, если имеется небольшой массив
входных данных, простая их сортировка методом вставки проявит себя луч
ше, чем быстрая сортировка, не говоря уже том, что для написания и отладки
Глава 7 • По ходу кодирования
258
реализующего ее кода потребуется меньше времени. Необходимо также прояв
лять осмотрительность, если выбираемый алгоритм требует больших затрат на
настройку. При небольших массивах входных данных такая настройка может
нивелировать все преимущества во времени выполнения и сделать алгоритм
непригодным с практической точки зрения.
Кроме того, отнеситесь осторожно к преждевременной оптимизации. Всег
да рекомендуется убедиться, что выбранный алгоритм является узким местом
производительности, прежде чем тратить драгоценное время на его усовершенс
твование.
Другие разделы, связанные с данной темой
•
Тема
15.
Оценивание, глава
2
"Прагматичный подход".
Задачи
•
Каждый разработчик должен знать, каким образом алгоритмы устроены
и как они анализируются. На эту тему Роберт Седжвик
написал целый ряд книг, в том числе
the Aпalysis of Algorithms [SF13].
Algorithms [SWll]
(Robert Sedgewick)
to
и Ап Iпtrodиctioп
Рекомендуем вам пополнить этими книга
ми свою библиотеку и взять себе за правило читать их регулярно.
•
Тем, кто интересуется большими подробностями, чем в книгах Роберта
Седжвика, рекомендуются перечисленные ниже книги из каноничного
издания
Art of Сотриtеr Programming5, где анализируется обширный ряд
алгоритмов.
- The Art of Сотриtеr Programming,
- The Art of
Volиme
1: Fипdameпtal Algorithms
Сотриtеr Programmiпg, Volиme
2:
Seminиmerical
[Кnu98]
Algorithms
[Кnu98a]
-- The Art of Сотриtеr Programmiпg,
Volиme
-- The Art of Сотриtеr Programming,
Part 1 [Knull].
•
Приведенное ниже упражнение
28
3: Sorting апd Searchiпg [Knu98b]
Volиme 4А: ComЬinatorial
Algorithms,
посвящено сортировке массивов длин
ных целых чисел. Какое влияние на их сортировку окажет повышение
сложности ключей и дополнительных издержек на их сравнение? Оказы
вает ли структура ключей воздействие на эффективность алгоритма сор
тировки или же самая быстрая сортировка таковой всегда и остается?
5
Имеется русский перевод этих книг под названием Искусство программирования, выпу
- Примеч. пер.
щенный ИД "Вильяме':
Тема 40 • Рефакторинг
259
Упражненин
28. Мы запрограммировали ряд простых алгоритмов сортировки на языке Rust 6 •
Выполните их на разных доступных вам машинах. Будут ли полученные вами
данные соответствовать предполагаемым кривым зависимостей? Какой вы
вод можно сделать об относительном быстродействии алгоритмов на отде
льных машинах? Каковы последствия оптимизации различных параметров
настройки компилятора?
29. Ранее в разделе "Разумное оценивание алгоритмов" было сказано, что би
нарный поиск делением пополам относится к категории алгоритмов
O(lg
п).
Можете ли вы это доказать?
30. Ранее в разделе "Асимптотическое обозначение" было сказано, что асимпто
тические обозначения
O(ln
п) и
O(log2n)
означают одну и ту же сложность
алгоритма. Можете ли вы пояснить причину?
i1Дti(1) РЕФАКТОРИНГ
"Перемена
и упа д ок во всем, что я вижу
..."
Х.Ф. Лит 7, Ablde With Ме (Пребудь со мной)
По мере развития программы возникает потребность переосмыслить прежние
решения и переделать отдельные части исходного кода. Это совершенно естест
венный процесс. Ведь код должен развиваться, он не является статическим.
К сожалению, самой распространенной метафорой для разработки програм
много обеспечения является построение здания. В своем классическом труде
Object-Oriented Software Construction
[Меу97] Бертран Мейер
(Bertrand Meyer)
употребляет термин "построение программного обеспечения", а скромным
авторам данной книги приходилось даже редактировать колонку
Construction''
(Построение программного обеспечения) в журнале
"Software
IEEE Software
в начале 2000-х годов 8 •
Строительство в качестве руководящей метафоры подразумевает выполнение
следующих действий.
1.
Архитектор чертит чертежи.
2.
Подрядчики углубляют фундамент, возводят стены, проводят канализа
цию и прочие коммуникации и выполняют отделочные работы.
См. по адресу https: / /media-origin. pragprog. com/ti tles/tpp20/ code/
algorithm_speed/sort/src/main.rs.
6
Н. F. Lyte - шотландский англиканский пастор, теолог, поэт XIX века, а также автор цер
- Примеч. пер.
8 И мы, конечно, выражали свою озабоченность по поводу названия этой колонки.
7
ковных гимнов .
Глава 7 • По ходу кодирования
260
3.
Жильцы заселяют дом и счастливо живут в нем, периодически вызывая
для устранения неполадок эксплуатирующий здание персонал
-
электри -
ков, сантехников и др.
Безусловно, программное обеспечение таким способом не разрабатывается.
Его разработку можно сравнить не со стройкой, а скорее с выращиванием, пос
кольку оно более органичное, а не бетонное. Растения высаживаются в саду по
заранее составленному плану и в соответствии с местными условиями. Одни
растения успешно вырастают, а другие в конечном итоге идут на компост. Рас
тения можно пересаживать, чтобы выгодно воспользоваться взаимным влияни
ем света и тени, ветра и дождя. Слишком заросшие растения обрезаются, а те,
что не ласкают взгляд, переносятся в эстетически более привлекательное место.
Кроме того, выпалываются сорняки и удобряются те растения, которые требуют
дополнительного ухода. Здоровое состояние сада требует постоянного контроля
и ухода по мере надобности за почвой, растениями и их размещением.
Для деловых людей более удобной метафорой является построение здания,
поскольку оно более научно, чем садоводство, повторяемо, ему присуща жесткая
иерархия отчетности перед руководством и т.д. Но ведь мы строим не небоскре
бы и не ограничены в своих действиях пределами физики и реального мира.
Метафора садоводства намного ближе к реальностям разработки програм
много обеспечения. Так, одна подпрограмма может слишком разрастись, а по
пытка реализовать слишком крупное функциональное средство может потребо
вать его разделения. Все, что не работает нормально, необходимо искоренить,
выполоть или обрезать.
Переписывание, переработка и переделка архитектуры кода сообща называ
ется реструктуризацией. Рефакторинг представляет собой практическое под
множество такой деятельности.
В своей книге
тин Фаулер
Refactoring: Iтproving the Design of Existing Code 9 [Fow19] Мар-
(Martin Fowler)
определяет рефакторинг следующим образом:
"дисциплинированная методика перестройки структуры существующего
тела кода, изменение его внутренней структуры без изменения его внешне
го поведения".
Самые важные части этого определения таковы.
1.
2.
Деятельность дисциплинирована, а не хаотична.
Внешнее поведение не меняется, а следовательно, при этом не вводятся
новые функциональные средства.
Имеется русский перевод: Мартин Фаулер, Кент Бек, Джон Брант, Уильям Опдайк, Дон
- СПб.: "Диалектика",
2017.
9
Робертс. Рефакторинг: улучшение проекта существующего кода.
Тема 40 • Рефакторинг
261
Рефакторинг не предусмотрен как особый церемониальный вид деятельнос
ти, выполняемый лишь изредка, подобно запашке всего сада для пересадки рас
тений. Напротив, рефакторинг представляет собой повседневную деятельность,
выполняемую мелкими шажками с малым риском что-то испортить, подобно
прополке или поливанию. Вместо глобального переписывания кода применя
ется точно нацеленный, выверенный подход, помогающий упростить внесение
изменений в код.
Чтобы гарантировать неизменяемость внешнего поведения, требуется качес
твенное, автоматизированное модульное тестирование, проверяющее правиль
ность поведения кода.
КОГДА СЛЕДУЕТ ВЫПОЛНЯТЬ РЕФАКТОРИНГ
Рефакторинг выполняется, когда вы что-то изучили, когда понимаете что-то
лучше, чем в прошлом году, вчера или еще десять минут назад.
Вполне возможно, что вы наткнулись на камень преткновения, поскольку
код уже не вполне отвечает исходным требованиям; а может быть, заметили,
что два компонента следует непременно объединить, или обратили внимание
на еще что-нибудь такое, что поражает вас, как "неверное". В таком случае не
колеблясь, измените код. Сделать это лучше всего сразу же, не откладывая на
будущее. Вот только некоторые из причин для рефакторинга кода.
•
Дублирование. Обнаружено нарушение принципа
•
Неортогональный дизайн. Обнаружено нечто такое, что можно сделать
ваше знание решаемой задачи расширилось. В таком случае код необхо
димо сделать актуальным, приведя его в соответствие с произошедшими
изменениями.
•
Применение. По мере того как система эксплуатируется реальными людьми
в реальных условиях, приходит понимание того, что некоторые функцио
нальные средства теперь больше важны, чем предполагалось ранее, тогда
как "обязательные" прежде средства таковыми, вероятно, уже не являются.
•
Производительность. Возникла потребность перенести функциональные
возможности из одного участка системы в другой, чтобы повысить общую
производительность.
•
Прохождение тестов. Да, именно так. Ведь ранее говорилось, что рефак
торинг должен быть мелкомасштабным видом деятельности, и поэтому
он должен поддерживаться грамотно написанными тестами. Так, когда вы
добавляете некоторый код, который проходит еще один дополнительный
тест, у вас появляется отличная возможность углубиться в код и привести
в порядок то, что вы только что написали.
Глава 7 • По ходу кодирования
262
Рефакторинг
-
перемещение функциональных возможностей и обновле
ние прежних решений
-
на самом деле оказывается управлением болью. Будем
откровенны, внесение изменений в исходный код может оказаться довольно
болезненным. Раньше код работал нормально, так что его хочется оставить в
покое. Многие разработчики неохотно снова возвращаются к фрагменту кода
лишь потому, что он не полностью правильный.
Сложности реального мира
Итак, вы обращаетесь к коллегам по работе или клиенту и заявляете: "Этот
код вполне работоспособен, но мне потребуется неделя, чтобы выполнить его
рефакторинг". Из этических соображений мы не приводим их (непечатный)
ответ.
Нехватка времени нередко служит оправданием отказа от рефакторинга. Но
это оправдание не выдерживает никакой критики. Если не выполнить рефак
торинг кода сейчас, то для устранения неполадок позже потребуется затратить
намного больше времени. И чем дальше, тем с большим количеством зависи
мостей придется считаться. Будет ли у вас столько времени вообще? Вряд ли.
Этот принцип, возможно, придется объяснить другим, используя медицин
скую аналогию, рассматривая код, требующий реализации, как "нарост': Что
бы удалить его, потребуется хирургическое вмешательство. Это можно сделать
сразу, удалив нарост, пока он еще невелик. Можно подождать до тех пор, пока
нарост не станет больше и не распространится дальше, но его удаление впос
ледствии может обойтись дороже и быть опаснее. Стоит подождать еще немно
го, и можно вообще потерять пациента.
GФйif1
Выполняйте рефакторинг кода как можно раньше и чаще
Столь же опасно со временем может разрастить и ущерб коду (см. раздел
"Тема
3.
Программная энтропия" главы
1
"Философия прагматизма"). Как и
большинство других методик, рефакторинг проще выполнить, пока трудности
невелики, как просто разновидность деятельности во время программирова
ния. Для рефакторинга фрагмента кода не требуется неделя, в течение которой
можно было бы полностью переписать код. Если уж необходим именно такой
перерыв в основной работе
-
вы можете не иметь возможности приступить
к исправлениям немедленно. В таком случае следует уведомить пользователей,
что на некоторый конкретный срок запланирована переделка кода, а также по
яснить, как это может повлиять на их работу.
Тема 40 • Рефакторинr
263
ПОРЯДОК ВЫПОЛНЕНИЯ РЕФАКТОРИНГА
Первыми рефакторингами кода начали заниматься программисты на языке
Smalltalk.
Когда мы писали первое издание этой книги, данная методика начала
приобретать все больше приверженцев, возможно, благодаря посвященной этой
теме книге
Refactoring: Improving the Design of Existing Code [Fow19]
(у которой
недавно вышло второе издание 10 ).
Рефакторинг, по существу, является
ero
перепроектированием. Все, что проек
тируете вы и ваши коллеги, может быть перепроектировано в свете новых фак
тов, более глубокого понимания, изменения требований и т.д. Но если вы станете
с неистовым рвением бросаться кромсать огромные куски кода, то можете ока
заться в еще худшем положении, чем перед началом данной операции.
Очевидно, что рефакторинг
-
это вид деятельности, который следует выпол
нять медленно, осторожно и внимательно. Мартин Фаулер предлагает следующие
простые рекомендации относительно того, как реорганизовывать код, чтобы не
нанести вреда больше, чем принести пользы 11 •
1.
Не пытайтесь выполнять рефакторинг, попутно добавляя функциональные
возможности.
2.
Прежде чем приступать к рефакторингу, обязательно напишите качест
венные тесты. Выполняйте тестирование как можно чаще. Это позволит
вам быстро выяснить, не нарушили ли что-нибудь внесенные вами изме
нения.
3.
Продвигайтесь короткими, осторожными шагами: перенесите поле из од
ного класса в друrой, разделите метод на части, переименуйте переменную.
Рефакторинг зачастую подразумевает внесение множества мелких лока
лизованных изменений, приводящих в итоге к крупномасштабным пере
менам. Если сохранять темп продвижения мелкими шагами и выполнять
тесты после каждого сделанного шаrа, то можно избежать продолжитель
ной отладки 12 .
Имеется русский перевод: Мартин Фаулер. Рефакторинг кода на JavaScript: улучшение
- СПб.: "Диалектика", 2019.
11 Первоначально они появились в книге UML Distilled: А Brief Gиide to the Standard Object
Modeling Langиage [FowOO].
12 Это, в общем, превосходный совет (см. также раздел "Тема 27. Не опережайте свет фар
вашего автомобиля" главы 4 "Прагматичная паранойя").
10
проекта существующего кода, 2-е изд.
Глава 7 • По ходу кодирования
264
АВТОМАТИЧЕСКИЙ РЕФАКТОРИНГ
В первом издании этой книги отмечалось, что данная методика еще не вы
шла за пределы среды
Smalltalk,
хотя такое положение, вероятнее всего,
изменится. Так оно и произошло, и теперь автоматический рефакторинг
доступен во многих интегрированных средах разработки для большинства
ведущих языков программирования.
Такие интегрированные среды разработки способны автоматически пере
именовывать переменные и методы, разделять длинную подпрограмму на
более мелкие составляющие, распространять необходимые изменения по
коду, помогать переносить код с помощью перетаскивания мышью и выпол
нять прочие полезные действия для рефакторинга кода.
О тестировании на данном уровне речь пойдет подробнее в разделе "Тема
41 .
Тестировать, чтобы кодировать" далее в этой главе, а о крупномасштабном тес
тировании
в разделе "Строгое и непрерывное тестирование" главы
-
9 "Прагма
тичные проекты': Но рекомендация Мартина Фаулера относительно проведения
качественных регрессионных тестов имеет решающее значение для надежного
рефакторинга кода.
Если приходится выходить за пределы рефакторинга кода и в конечном счете
изменять внешнее поведение или интерфейсы, то такие действия могут привести
к преднамеренному нарушению сборки, когда прежним клиентам данного кода
не удастся его скомпилировать. Это позволит выяснить, что именно требуется
обновить. И если в следующий раз вы обнаружите фрагмент кода, работающий
не совсем так, как требуется,
-
исправьте его. Управляйте болью: ведь если она
беспокоит вас теперь, то еще больше будет беспокоить в дальнейшем, так что
лучше вылечить ее сразуи окончательно. Вспомните уроки из раздела "Тема
Программная энтропия" главы
1 "Философия
3.
прагматизма": нельзя жить с раз
битыми окнами.
Другие разделы, связанные с данной темой
Программная энтропия, глава
•
Тема
3.
•
Тема
9. DRY -
•
Тема
12. Трассирующие
•
Тема
27.
1 "Философия прагматизма".
пороки дублирования, глава
пули, глава
2
"Прагматичный подход':
2 "Прагматичный
подход':
Не опережайте свет фар вашего автомобиля, глава
ная паранойя".
•
Тема
44.
Именование.
•
Тема
48.
Сущность гибкости, глава
8
"До начала проекта':
4 "Прагматич
Тема 41 • Тестировать, чтобы кодировать
265
i1J.'itili ТЕСТИРОВАТЬ, ЧТОБЫ КОДИРОВАТЬ
Первое издание этой книги было написано в более простые времена, когда
большинство разработчиков не писали тесты. Он считали, что делать это не
стоит, поскольку все равно в
2000 году наступит конец
света. В первом издании
книги был раздел, посвященный построению кода, который легко тестировать.
Это был хитрый способ убедить разработчиков все же писать тесты.
Теперь же настали более просвещенные времена. Если еще и остались разра
ботчики, которые до сих пор не пишут тесты, то они, по крайней мере, должны
знать, что обязаны это делать.
Тем не менее, когда мы спрашиваем разработчиков, зачем они пишут тес
ты, они смотрят на нас так, как будто мы спросили, пользуются ли они до сих
пор перфокартами, и обычно отвечают: "Чтобы убедиться в работоспособности
кода': хотя и не говорят вслух, что задающий такие вопросы
-
"чайник" в про
граммировании. Но мы все же считаем такой ответ неверным.
Так что же мы считаем самым важным в тестировании и как оно должно про
водиться? Отвечая на эти вопросы, начнем со следующего смелого заявления:
Тестирование предназначено не для выявления
программных ошибок
Мы считаем, что основные выгоды из тестирования извлекаются в том слу
чае, когда тесты обдумываются и пишутся, а не тогда, когда они выполняются.
ОБДУМЫВАНИЕ ТЕСТОВ
Представьте, что в понедельник утром вы приступаете к работе над каким-то
новым кодом. Вам нужно написать код, запрашивающий в базе данных список
людей, просматривающих больше
10 видеофильмов
в неделю на вашем веб-сай
те, где размещаются "самые забавные в мире видеофильмы о мытье посуды".
С этой целью вы запускаете свой текстовый редактор и приступаете к напи
санию следующей функции, выполняющей запрос:
def return- avid- viewers do
# •••
м-да
! ...
end
Постойте! Откуда вы знаете, что поступаете правильно?
Ответ в том, что ни вы и никто другой не можете этого знать. Но это может
стать более вероятным, если думать о тестах. И вот как это делается.
Представьте сначала, что завершили написание упомянутой выше функции
и теперь вам нужно ее проверить. Как это сделать? Ведь для этого потребуются
266
Глава 7 • По ходу кодирования
какие-то тестовые данные, а следовательно, придется обратиться к управляе
мой вами базе данных. В этом вам могут, конечно, помочь некоторые каркасы,
проводящие тесты с помощью некоторой тестовой базы данных. Но в данном
случае вы должны передать своей функции отдельный экземпляр базы данных,
а не нечто глобальное, чтобы во время тестирования можно было внести в нее
какие-то изменения.
def
return_avid_users(dЬ)
do
Затем необходимо подумать о том, как заполнить базу тестовыми данными.
Ведь исходно требуется получить список людей, просматривающих больше
10
видеофильмов в неделю. Следовательно, в схеме базы данных необходимо найти
те поля, которые могут помочь в реализации такого требования. В таблице базы
данных действительно имеются поля
opened_ video
и
completed_ video, ко
торые могут помочь в получении искомого списка. Чтобы сформировать тесто
вые данные, нужно точно знать, каким полем можно воспользоваться. Но в ис
ходном требовании об этом ничего конкретного не сказано, а бизнес-контакты
отсутствуют. Поэтому придется пойти на обман и, чтобы проверить функцию
(а возможно, даже изменить ее в дальнейшем), просто передать ей имя поля.
def
return_avid_users(dЬ,
qualifying_field_name) do
Итак, мы с вами стали думать о тестах. Не написав ни строчки кода, мы уже
сделали два открытия и воспользовались ими с целью изменить
API рассматри
ваемой здесь функции.
КОДИРОВАНИЕ НА ОСНОВЕ ТЕСТОВ
В предыдущем примере, думая о тестировании, мы сумели уменьшить связы
вание в своем коде, передавая разрабатываемой функции подключение к конк
ретной базе данных вместо того, чтобы воспользоваться ее глобальной вереи -
ей, а также повысили степень rибкости, сделав тестируемое поле параметром.
Размышляя о написании теста для рассматриваемой здесь функции, мы сумели
взглянуть на нее снаружи, поставив себя на место клиента, а не автора напи
санного кода.
IЗфI§itfl
Тест
-
первый пользователь вашего кода
На наш взгляд, самое главное преимущество, которое дает тестирование, за
ключается в том, что оно дает жизненно важную ответную реакцию, которая, по
существу, управляет программированием. Функция или метод, тесно связанные
с другим кодом, с трудом поддаются тестированию, поскольку при этом, пре
жде чем выполнять данную функцию или метод, приходится подготавливать
Тема 41 • Тестировать, чтобы кодировать
267
всю необходимую среду. Таким образом, делая свой код легко тестируемым, вы
уменьшаете его связывание с другим кодом.
Прежде чем протестировать какой-нибудь код, его необходимо понимать. На
первый взгляд это кажется нелепым, но на самом деле всем нам приходилось
иметь дело с фрагментами кода, основанными на не полном понимании того,
что мы должны делать. Мы часто уверяем себя, что по ходу дела нам удастся
прояснить ситуацию, а в дальнейшем добавить код для поддержки граничных
условий и обработки ошибок. В итоге код получается в пять раз длиннее, чем
следует, поскольку он наполнен условной логикой и частными случаями. Но до
статочно пролить тестовый свет на такой код, как дело проясняется. Если вы
подумаете о тестировании граничных условий и их пригодности еще до того,
как приступить к программированию, то сможете обнаружить в логике шаб
лоны, упрощающие создаваемую функцию. А если вы подумаете об условиях
возникновения ошибок, которые нужно проверять, то соответственно структу
рируете вашу функцию.
Разработка на основе тестирования
В программировании существует направление, которое задается следующим
вопросом: если все преимущества обдумывания тестов имеют такое первосте
пенное значение, то почему бы не писать в первую очередь именно тесты? При
верженцы этого направления практикуют методику, называемую разработкой
на основе тестирования
(test-driven development - TDD).
Иногда ее еще назы
вают разработкой с предварительным тестированием 13 •
Ниже приведен основной цикл разработки на основе тестирования.
1.
Наметить небольшую часть функциональных возможностей, которые тре
буется добавить.
2.
Написать тест, который будет успешно пройден, как только будет реали
зована данная часть функциональных возможностей.
3.
Выполнить все тесты. Убедиться, что не проходит лишь только что напи
санный тест.
4.
Написать минимальный фрагмент кода, требующийся для прохождения
данного теста, и убедиться, что теперь он благополучно проходит.
5.
Реорганизовать код, выяснив, можно ли каким-то образом усовершенство
вать то, что было только что написано (тест или проверяемая функция).
По завершении убедиться, что тесты по-прежнему успешно проходят.
13
Некоторые утверждают, что разработка на основе тестирования и разработка с предва
рительным тестированием являются разными методиками, говоря, что у них разные цели.
Но исторически сложилось так, что разработка с предварительным тестированием, про
исходящая от экстремального программирования, оказалась идентична тому, что теперь
принято обозначать сокращением
TDD.
Глава 7 • По ходу кодирования
268
Смысл в том, что данный цикл должен быть кратким и выполняться в счи танные минуты. А это означает, что тесты приходится писать постоянно и про
граммировать так, чтобы они в конечном итоге были успешно пройдены. На
наш взгляд, методика
TDD
выгодна в основном тем разработчикам, которые на
чинают работу над своим проектом с тестирования. Если вы будете придержи ваться последовательности операций по приведенной выше методике, то можно
гарантировать, что у вас всегда будут тесты для проверки вашего кода. И это
означает, что вы будете всегда думать о тестах.
Нам, однако, приходилось встречать и таких людей, которые стали букваль
но рабами разработки на основе тестирования. Такое раболепие перед данной
методикой проявляется по-разному.
•
Они тратят непомерно много времени, чтобы обеспечить полное покрытие
написанного кода тестами.
•
У них накапливается много избыточных тестов. Например, прежде чем
написать класс в первый раз, многие приверженцы разработки на основе
тестирования, пишут тест, который просто ссылается на имя этого класса.
Убедившись, что тест сбоит, они пишут определение пустого класса, пос
ле чего данный тест оказывается успешно пройденным. Но ведь этот тест
совершенно ничего не проверяет! В очередном написанном тесте также
делается ссылка на класс, а следовательно, предыдущий тест просто не ну
жен. Если в дальнейшем имя класса изменится, то в тесты придется внести
больше изменений. А ведь это самый простой пример.
•
Их проектирование обычно начинается снизу и продвигается вверх. (См.
далее врезку "Проектирование снизу вверх и сверху вниз. Как это следует
делать".)
Как бы там ни было, непременно применяйте в своей практике разработку на
основе тестирования. Но при этом не забывайте периодически останавливаться,
чтобы оценить общую картину. Ведь очень легко, соблазнившись сообщением
"тест прошел" с зеленым индикатором, написать немало кода, который никак не
приближает вас к решению поставленной задачи.
ПРИМЕНЯЯ РАЗРАБОТКУ НА ОСНОВЕ ТЕСТИРОВАНИЯ
НУЖНО ЗНАТЬ, КУДА ИДТИ
В старой шутке спрашивается: "Как съесть слона?': на что дается лаконичный
ответ: "По частям". Эта идея нередко превозносится как преимущество разра
ботки на основе тестирования. Если нельзя решить задачу целиком, ее можно
решить по частям, предпринимая мелкие шаги, тест за тестом. Но такой подход
может вводить в заблуждение, поощряя сосредоточиваться на простых задачах,
бесконечно оттачивая их решение и в то же время пренебрегая главной причи
ной написания кода.
Тема 41 • Тестировать, чтобы кодировать
Любопытный случай, характеризующий такой подход, произошел в
2006
269
году,
когда Рои Джеффрис, видный активист движения за гибкость в разработке про
граммного обеспечения, опубликовал целый ряд благ-постов, где он описал свой
метод программирования решателя головоломок судаку на основе тестирования 14 •
Пять благ-постов спустя он уточнил представление исходной доски для судаку,
неоднократно выполняя реорганизацию кода до тех пор, пока его не удовлетво
рила объектная модель. Но затем он забросил этот проект. Любопытно прочитать
его благ-посты по порядку, следя за тем, как этот умный человек отвлекался на
незначительные мелочи, будучи зачарованным блеском успешных тестов.
ПРОЕКТИРОВАНИЕ СНИЗУ ВВЕРХ И СВЕРХУ ВНИЗ. КАК ЗТО СЛЕДУЕТ ДЕЛАТЬ
Еще в те времена, когда вычислительная техника была молода и беззабот
на, существовали два направления в проектировании: сверху вниз и снизу
вверх. Приверженцы проектирования сверху вниз говорят, что начинать сле
дует с общей задачи и пытаться решить ее, разбивая на мелкие части, а те
-
на еще более мелкие части и так далее до тех пор, пока не будут достигнуты
настолько мелкие части, что их можно выразить непосредственно в коде.
Приверженцы проектирования снизу вверх предпочитают строить код, как
дом. Они начинают с создания такого уровня кода, который дает им неко
торые абстракции, приближающие их к той задаче, которую они пытаются
решить. Затем они вводят еще один уровень с более общими абстракция
ми. И так продолжают до тех пор, пока не достигнут конечного уровня с аб
стракцией, решающей поставленную задачу.
Ни одна из этих методик проектирования на самом деле не годится, пос
кольку в обеих игнорируется одна из самых важных особенностей разработ
ки программного обеспечения: когда мы начинаем разработку, мы не знаем,
что делаем. Сторонники проектирования сверху вниз считают, что они спо
собны изначально выразить все требование в целом, хотя это сделать не
льзя. А сторонники проектирования снизу вверх считают, что они способны
составить перечень абстракций, который позволит им постепенно прийти к
одному решению на верхнем уровне. Но как им выбрать функциональные
возможности отдельных уровней, если они не знают, куда направляются?
Мы твердо убеждены, что строить программное обеспечением можно толь
ко инкрементно. Создавайте функциональные возможности небольшими
частями, изучая по ходу дела решаемую задачу. Применяйте приобретен
ные знания по мере реализации кода, на каждой стадии привлекайте заказ
чиков, позволяя им направлять данный процесс.
14
См. по адресу https: // ronjeffries. com/categories/sudoku. Выражаем ис
креннюю благодарность Рону за то, что позволил нам привести здесь его историю.
270
Глава 7 • По ходу кодирования
GФI§i§:I
Стройте комплексно, а не сверху вниз или снизу вверх
В противоположность этому Питер Норвиг описывает альтернативный под
ход совсем иного характера 15 . Вместо того чтобы руководствоваться тестами, он
начинает с уяснения, каким образом такого рода задачи решались традиционно
с помощью распространения ограничений, а затем сосредоточивается на своем
алгоритме. В частности, он реализует доску в десятке строк кода, которые выте
кают непосредственно из обсуждения обозначений, принятых в судоку.
Тесты определенно могут помочь в разработке. Но если не иметь в виду ко
нечной цели, то в результате можно просто бесконечно ходить по кругу.
ВОЗВРАТ К КОДУ
Компонентная разработка уже давно стала возвышенной целью проекти
рования программного обеспечения 16 . Ее идея состоит в том, что обобщенные
программные компоненты должны быть доступны и должны объединяться так
же просто, как и большинство интегральных схем (ИС). Но такая методика при
годна лишь в том случае, если заранее известно, что применяемые компонен
ты надежны и соответствуют принятым нормам, таким как общее напряжение,
стандарты соединений, временные характеристики и прочие параметры в про
изводстве ИС.
ИС проектируются с учетом их испытаний, причем не только на заводе-из
готовителе или на месте их установки на печатные платы, но и в месте их экс
плуатации. В более сложных ИС и системах могут быть предусмотрены сред
ства встроенного самоконтроля
(Built-In Self Test - BIST),
выполняющие внут
реннюю диагностику на каком-нибудь элементарном уровне, или же механизм
тестового доступа
(Test Access Mechanism -
ТАМ), предоставляющий средства
тестирования, которые позволяют подавать на ИС заданные воздействия из
внешней среды и собирать их ответные реакции.
То же самое можно сделать и в программном обеспечении. Как и нашим
коллегам, разработчикам электронного оборудования, нам нужно с самого на
чала встраивать тестируемость в разрабатываемое программное обеспечение
и тщательно проверять каждый из его компонентов, прежде чем соединять их
вместе.
15
16
См. по адресу http: / /norvig. сот/ sudoku. html.
Такая методика была опробована еще в 1986 году, когда Кокс (Сох) и Новобильски
(NovoЬilski) изобрели термин "программная интегральная схема", введя его в своей книге
МОДУЛЬНОЕ ТЕСТИРОВАНИЕ
Испытание оборудования на уровне ИС приблизительно равнозначно мо
дульному тестированию программного обеспечения, когда каждый модуль тес
тируется по отдельности для проверки его поведения. Тщательно протестировав
модуль в контролируемых (и даже искусственных) условиях, можно составить
более ясное представление о том, как он отреагирует на окружающий мир.
Модульный тест программного обеспечения представляет собой код, испы
тывающий модуль. Как правило, модульный тест сначала настраивает опреде
ленного рода искусственную среду, а затем вызывает подпрограммы тестируе
мого модуля. Далее он проверяет возвращаемые результаты, сравнивая их с из
вестными значениями или результатами предыдущих прогонов того же самого
теста (регрессионное тестирование).
В дальнейшем, когда модули собираются как "программные ИС" в готовую
систему и есть уверенность, что отдельные ее части работают должным обра
зом, можно воспользоваться теми же средствами модульного тестирования для
испытания всей системы в целом. Подробнее о такой крупномасштабной про
верке системы речь пойдет в разделе "Строгое и непрерывное тестирование"
главы
9 "Прагматичные
проекты".
Но прежде чем зайти в тестировании так далеко, необходимо решить, что
именно следует тестировать на модульном уровне. В исторической перспективе
программисты раньше вводили несколько произвольных битов данных в код,
анализировали операторы вывода и называли это тестированием. Но ведь для
тестирования кода можно сделать намного больше.
ТЕСТИРОВАНИЕ СООТВЕТСТВИЯ КОНТРАКТУ
Мы предпочитаем рассматривать модульное тестирование как тестирование
соответствия контракту (см. раздел "Тема
главы
4
23.
Проектирование по контракту"
"Прагматичная паранойя"). При этом требуется написать такой тест,
который гарантирует, что проверяемый модуль выполняет свой контракт. Такой
тест позволит выяснить следующее: соответствует ли написанный код контрак
ту и отвечает ли сам контракт своему назначению. Требуется также проверить,
предоставляет ли тестируемый модуль обещанные им функциональные возмож
ности в обширном ряде контрольных примеров и граничных условий.
Что же все это означает на практике? Начнем ответ на этот вопрос с просто
го числового примера: функции извлечения квадратного корня. Ее документи
рованный контракт довольно прост:
предусловия:
argument >=
О;
постусловия:
((result * result) - argument) .abs my_sqrt(-4.0) end
Это довольно простой пример, но на практике любой нетривиальный мо
дуль, вероятно, будет зависеть от целого ряда других модулей. Так как же про
тестировать их вместе?
Допустим, имеется модуль А, в котором применяются модули
LinearRegression.
DataFeed
и
В таком случае мы должны выполнить тестирование в
следующем порядке.
1. Контракт модуля DataFeed, полностью.
2.
3.
Контракт модуля
LinearRegression,
полностью.
Контракт модуля А, который полагается на другие контракты, хотя и не
раскрывает их непосредственно.
Для такого рода тестирования требуется, чтобы сначала были проверены мо
дули, подчиненные тестируемому модулю. Как только эти подчиненные модули
будут проверены, можно тестировать и основной модуль.
Если тесты модулей
DataFeed и LinearRegression
пройдут, а тест модуля
А не пройдет, можно с уверенностью сказать, что причина сбоя кроется в моду
ле А или же в применении одного из подчиненных ему модулей. Такая методика
тестирования позволяет существенно сэкономить на отладке, поскольку дает
возможность быстро сосредоточиться на вероятном источнике сбоя в модуле А
и не тратить зря время на перепроверку подчиненных ему модулей.
К чему все эти хлопоты? Прежде всего, требуется избежать создания "бомбы
замедленного действия': которая может оказаться заложенной в исходном коде
и незамеченной, взорвавшись в самый неподходящий момент позже в проекте.
Тема 41 • Тестировать, чтобы кодировать
273
Делая акцент на тестировании соответствия контракту, мы можем попытаться из
бежать стольких бед по ходу дальнейшего выполнения проекта, сколько удастся.
GФI§IOOI
Проектируйте с учетом тестирования
СПЕЦИАЛЬНОЕ ТЕСТИРОВАНИЕ
Тестирование называется специальным
(ad hoc) при ручном дополнении в кон
кретном месте исходного кода. Это может быть простой вызов
console. log ()
или фрагмент кода, введенный в диалоговом режиме работы отладчика, интег
рированной среде разработки или цикле "чтение-вычисление-вывод"
(REPL).
В конце сеанса отладки такой специальный тест требуется формализовать.
Если в коде один раз произошла неприятность
-
их, вероятнее всего, будет
больше. Не отбрасывайте написанный вами специальный тест, а добавьте его в
арсенал своих средств модульного тестирования.
СОЗДАНИЕ ТЕСТОВОГО ОКНА
Даже самые лучшие наборы тестов вряд ли сумеют обнаружить все програм
мные ошибки. Выявить их могут некоторые особые условия эксплуатационной
среды.
Это означает, что как только любой компонент программного обеспечения
будет развернут в реальных условиях его эксплуатации, его обязательно следует
проверить с помощью потока реальных данных. В отличие от печатной платы
или ИС, в программном обеспечении нет контрольных выводов. Тем не менее
можно предоставить различные представления внутреннего состояния модуля,
не прибегая к отладчику, что может быть неудобно или вообще невозможно в
условиях промышленной эксплуатации.
Одним из таких механизмов являются журнальные файлы, содержащие со
общения трассировки. Эти сообщения должны быть представлены в точном,
последовательном формате. Возможно, их придется проанализировать автома
тически, чтобы выявить время обработки или логические пути, которыми пош
ла тестируемая программа. Неудачно или несогласованно отформатированная
диагностическая информация содержит столько лишнего, что ее трудно читать
и бесполезно анализировать.
Еще одним механизмом проникновения в выполняющийся код является пос
ледовательность "горячих" клавиш или "магический"
URL.
Когда нажимается
конкретная комбинация клавиш или осуществляется доступ к веб-ресурсу по
указанному
URL,
появляется окно диагностического контроля с сообщениями
о состоянии и т.д. И хотя это совсем не то, что обычно демонстрируется конеч
ным пользователям, подобная информация может весьма пригодиться службе
Глава 7 • По ходу кодирования
274
технической поддержки. В более общем смысле можно было бы воспользоваться
переключателем функциональных средств, чтобы активизировать дополнитель
ную диагностику для отдельного пользователя или категории пользователей.
КУЛЬТУРА ТЕСТИРОВАНИЯ
Все программы, которые вы пишете, должны быть непременно протестиро
ваны, если не вами и вашей командой, то хотя бы конечными пользователями,
поэтому вы должны тщательно планировать стадию тестирования. Достаточно
проявить немного предусмотрительности, чтобы свести к минимуму затраты на
сопровождение и вызовы службы технической поддержки.
На самом деле у вас имеются лишь следующие возможности .
•
Тестировать предварительно.
•
Тестировать по ходу программирования.
•
Вообще не тестировать.
Предварительное тестирование, включая и разработку на основе тестирования,
вероятно, будет наилучшим вариантом выбора в большинстве случаев, посколь
ку оно гарантирует, что тестирование непременно произойдет. Но иногда оно
оказывается неудобным или бесполезным, и тогда лучше выбрать тестирование
по ходу программирования. В этом случае можно написать фрагмент кода, по
работать с ним, написать для него тесты, а затем перейти к следующему фраг
менту кода. Самый худший вариант выбора нередко называют "протестируем
потом". Не будем себя обманывать, поскольку это, по существу, означает "не
тестировать вовсе':
Культура тестирования означает прохождение всех тестов в любое время .
Если не обращать внимания на те тесты, которые "никогда не проходят", то лег
че пренебречь всеми тестами вообще. И тогда возникнет порочный круг (см .
раздел "Тема
3. Программная
энтропия" главы
1 "Философия
прагматизма").
Уделяйте тестовому коду такое же внимание, как и любому рабочему коду.
Поддерживайте его развязанным, ясным и надежным. Не полагайтесь на такие
ненадежные вещи, как, например, абсолютное положение виджетов в системе
с
GUI,
точность отметок времени в журнале регистрации событий на сервере
или подробности описания ошибок в сообщениях (см. выше раздел "Тема
38.
Программирование по совпадению"). Тестирование такого рода вещей приведет
к тому, что тесты окажутся хрупкими.
Тестируйте свои программы сами, иначе их будут тестиро
вать пользователи
Тема 41 • Тестировать, чтобы кодировать
275
ПРИЗНАНИЕ
Я (Дэйв) однажды заявил, что больше не собираюсь писать тесты. И сделал я
это отчасти для того, чтобы поколебать веру тех, кто пре!!_ратили тестирова
ние в религию, а отчасти потому, что это было в какой-то степени правдой.
Я программирую уже
45
лет и больше
30
лет из них пишу тесты. Думать о
тестах во время программирования уже давно вошло в мою привычку. Мне
так удобно. Но мой внутренний голос подсказывает, что когда я начинаю
чувствовать себя удобно, я должен заняться чем-то другим.
В данном случае я решил на пару месяцев перестать писать тесты, чтобы
посмотреть, как это повлияет на мой код. К моему искреннему удивлению,
ничего особенного не произошло, поэтому я решил уделить время выясне
нию причин.
На мой взгляд, все дело в том, что наибольшая польза от тестирования про
истекает от обдумывания тестов и их воздействия на код. И если практико
вать это долго, то можно научиться думать о тестах, вообще не составляя их.
Мой код по-прежнему оставался тестируемым, он просто не тестировался.
Но при таком подходе во внимание не принимается то обстоятельство, что
тесты служат также средством общения с другими разработчиками. Поэто
му теперь я пишу тесты для кода, общего с другими разработчиками или
опирающегося на особенности внешних зависимостей.
Энди не советовал мне включать эту врезку в книгу. Он предостерегал, что
мое признание может искусить неопытных разработчиков не тестировать
свой код. Поэтому я предлагаю следующее компромиссное решение: долж
ны ли вы писать тесты? Да, должны. Но после такой практики в течение 30
лет можете немного поэкспериментировать, чтобы посмотреть, что вам вы
годнее: писать тесты или не писать.
Не сомневайтесь, что тестирование является неотъемлемой частью проrрам
мирования. Эту стадию процесса разработки нельзя поручать друrим подразде
лениям. Тестирование, проектирование, написание кода
-
все это входит в само
проrраммирование.
Друlие разделы, связанные с данной темой
•
Тема
27.
Не опережайте свет фар вашеrо автомобиля, глава
4
"Праrматич
ная паранойя':
•
Тема
51.
Начальный набор инструментальных средств проrраммиста-праr
матика, глава
9
"Праrматичные проекты".
276
Глава 7 • По ходу кодирования
l1j.ttJfJ ТЕСТИРОВАНИЕ НА ОСНОВЕ СВОЙСТВ
''Доверяй, но проверяй".
Русская пословица
Мы рекомендуем писать модульные тесты для создаваемых функций. Для
этого следует обдумать типичные причины, которые могут вызвать осложнения,
опираясь на знание того, что именно тестируется .
Но здесь возникает небольшое, но потенциально важно затруднение. Если
вы пишете код, а вместе с ним и тесты, то могут ли и там, и там быть выражены
неверные предположения? Код проходит тесты, поскольку он делает именно то,
что и должен делать,
-
исходя из того, как вы это понимаете.
Из этого затруднения можно, в частности, выйти, поручив писать тесты и
проверяемый код разным людям, но нам такое решение не по душе. Как пояс
нялось ранее в разделе "Тема
41.
Тестировать, чтобы кодировать", одно из глав
ных преимуществ обдумывания тестов заключается в том, что оно дает нужные
сведения о написанном коде. Эти сведения теряются, если работа по тестирова
нию и программированию разделяется. Вместо этого мы отдаем предпочтение
автоматизации тестирования на компьютере, который действует, в отличие от
людей, непредубежденно.
КОНТРАКТЫ, ИНВАРИАНТЫ И СВОЙСТВА
В разделе "Тема
23.
Проектирование по контракту" главы
4 говорилось о том,
что у написанного кода имеются контракты, которым он должен соответство
вать. Это, по существу, условия, которым должен удовлетворять код, когда ему
подаются на обработку входные данные, а также определенные гарантии, кото
рые он дает относительно получаемых в нем результатов или выходных данных.
У написанного кода имеются также инварианты, т.е. представления о какой
то части состояния, которые остаются истинными, когда оно проходит через
функцию. Так, если сортируется список, то в результате данной операции в нем
должно оказаться такое же количество элементов, как и первоначально, т.е. дли
на списка инвариантна.
Как только контракты и инварианты будут составлены, а мы склонны на
зывать их вместе свойствами, ими можно воспользоваться для автоматизации
тестирования. И в конечном счете такая методика называется тестированием
на основе свойств.
Пользуйтесь тестами на основе свойств для проверки
правильности ваших предположений
Тема 42 • Тестирование на основе свойств
277
В качестве искусственного примера можно написать ряд тестов для отсорти
рованного списка. Мы уже установили одно свойство: длина отсортированного
списка остается такой же, как и у первоначального. Можно также утверждать,
что ни один элемент результирующего списка не может быть больше следующе
го после него элемента.
Это можно теперь выразить непосредственно в коде. В большинстве языков
программирования имеется особого рода библиотека или каркас для поддержки
тестирования на основе свойств. И хотя данный пример реализован на языке
Python
с помощью инструментального средства
Hypothesis
и каркаса
pytest,
ос
новные принципы остаются теми же и довольно универсальными.
Ниже приведен весь исходный код тестов на основе свойств.
proptest/sort.py
from hypothesis import given
import hypothesis.strategies as some
@given(some.lists(some.integers()))
def test_list_size_is_invariant_across_sorting(a_list):
original_length = len(a_list)
a _ list. sort ()
assert len(a_list) == original_length
@given(some.lists(some.text()))
def test_sorted_result is ordered(a_list):
a _ list. sort ()
for i in range(len(a_list) - 1):
assert a_list[i] 0)
def take_from_stock(self, item_name, quantity):
if quantity
def in_stock(self, item name, quantity):
return (item_name in self.stock)
and (self.stock[item_name] >= quantity)
Кроме того, необходимо внести изменения в функцию
order (),как
приве
дено ниже. И тогда тест на основе свойств будет успешно пройден.
Тесты НА ОСНОВЕ СВОЙСТВ СПОСОБНЫ УДИВЛЯТЬ
В предыдущем примере тест на основе свойств служил для того, чтобы про
верить правильность коррекции уровней запасов. И хотя этот тест обнаружил
программную ошибку, он все же не имел никакого отношения к коррекции
уровней запасов. Вместо этого он обнаружил программную ошибку в функции
in _ stock ().
В этом состоит сила и слабость тестирования на основе свойств. Его сила
состоит в том, что сначала вы устанавливаете ряд правил для формирования
входных данных, задаете некоторые утверждения для проверки достоверности
выходных данных, а затем просто даете ему выполняться. Вы никогда точно не
знаете, чем все закончится. Тест может пройти. Утверждение может не выпол
няться. Код вообще может не суметь обработать предоставленные ему входные
данные.
Глава 7 • По ходу кодирования
282
Слабость же заключается в том, что выяснение причины сбоя может оказать
ся нелегким делом.
Если тест на основе свойств не проходит, мы рекомендуем сначала выяснить,
какие именно параметры были переданы тестовой функции, а затем воспользо
ваться их значениями для составления отдельного обычного модульного теста.
Такой тест автоматически выполняет две функции. Во-первых, он позволяет со
средоточиться на обнаруженной неполадке, не делая дополнительные вызовы
в проверяемом коде с помощью каркаса для тестирования на основе свойств.
И во-вторых, такой модульный тест действует как регрессионный. Тесты на ос
нове свойств формируют произвольные значения, передаваемые данному тесту,
и поэтому нет никакой гарантии, что одни и те же значения будут использо
ваны при выполнении тестов в следующий раз. Наличие же модульного теста,
заставляющего использовать одни и те же значения, гарантирует, что данная
программная ошибка не будет пропущена тестом.
ТЕСТЫ НА ОСНОВЕ СВОЙСТВ ПОМОГАЮТ ПРОЕКТИРОВАТЬ
Обсуждая особенности модульного тестирования, мы отмечали как одно из
главных его преимуществ возможность посмотреть на написанный код и его
API
с точки зрения модульного теста как первого клиента. Это же можно ска
зать и о тестах на основе свойств, хотя и несколько иначе. Они заставляют рас
сматривать написанный код с точки зрения инвариантов и контрактов, т.е. ду
мать о том, что не должно изменяться и что должно оставаться истинным. Такое
дополнительное осмысление оказывает волшебное воздействие на код, устраняя
крайние случаи и выделяя функции, оставляющие данные в несогласованном
состоянии.
Мы полагаем, что тестирование на основе свойств дополняет модульное тес
тирование. Эти методики тестирования решают разные задачи, и каждая из них
приносит свои выгоды. Если вы пока еще не пользуетесь ими, опробуйте их на
практике.
Другие раэдель1, связанные с данной темой
•
Тема
"
23.
Проектирование по контракту, глава
4
"Прагматичная пара-
))
ноия.
•
Тема
25.
Утвердительное программирование, глава
4
"Прагматичная па
ранойя".
•
Тема
45.
Западня требований, глава
8
"До начала проекта".
Упражнения
31.
Обратитесь снова к рассмотренному ранее примеру со складом. Имеются ли
какие-нибудь другие свойства, которые вы могли бы протестировать?
Тема 43 • Будьте осторожны
32.
283
Допустим, ваша компания поставляет машинное оборудование. Каждая ма
шина упакована в ящик, имеющий прямоугольную форму и разные размеры.
Ваша задача
-
написать некоторый код, чтобы упаковать как можно больше
ящиков в одном слое в кузове грузовика. Написанный вами код должен вы
водить список всех ящиков. Из этого списка можно определить место для
каждого ящика в грузовике наряду с шириной и высотой этого ящика. Какие
свойства вывода можно было бы протестировать?
Задачи
•
Подумайте о коде, над которым вы работаете в настоящий момент. Каковы
его свойства
-
контракты и инварианты? Можете ли вы воспользоваться
каркасом для тестирования на основе свойств, чтобы проверить эти свой
ства автоматически?
ii@f;lfl
БУДЬТЕ ОСТОРОЖНЫ
"Хороший сосед начинается с высокого забора".
Роберт Фрост 17, Ремонт стень1
(Mending а Wall)
При обсуждении связывания кода в первом издании этой книги мы сдела
ли смелое и наивное заявление, что разработчикам не следует быть чрезмерно
подозрительными, как шпионы и диссиденты, но мы оказались не правы. На
самом деле разработчикам необходимо не терять бдительность каждый день.
Когда мы работали над вторым изданием этой книги, ежедневные новости
были полны историями об опустошительных взломах информационных систем,
подвергшихся атакам злоумышленников и кибермошенничества. При этом кра
дутся сотни миллионов записей за один раз, наносятся миллиардные убытки, а на
восстановление систем после атак требуются не меньшие затраты, и эти цифры
быстро растут каждый год. В подавляющем большинстве случаев это происходит
не потому, что атакующие злоумышленники оказались особенно смышлеными
или даже компетентными, а потому, что разработчики проявили беспечность.
ДРУГИЕ 90°/о
Во время программирования вы неоднократно проходите путь от "это ра
ботает!" до "почему это не работает?': а иногда и до "каким образом это могло
произойти?".'' 18 • Добравшись до желанной вершины после стольких подъемов и
Robert Frost- один из самых известных американских поэтов, четырехкратный лауре
- Примеч. пер.
18 См. раздел "Тема 20. Отладка" главы 2 "Прагматичный подход':
17
ат Пулитцеровской премии.
Глава 7 • По ходу кодирования
284
падений, можно, вздохнув с облегчением, сказать: "Уф, наконец-то все работает!"
и объявить, что код готов. Разумеется, он еще не готов полностью. Работа выпол
нена на
90%,
но теперь предстоят еще другие
90%.
Далее необходимо проанализировать код на возможные сбои и ввести их ус
ловия в набор тестов. При этом следует рассмотреть такие ситуации, как пере
дача неверных параметров, утечка или недоступность ресурсов и т.п.
В старые добрые времена такого оценивания внутренних ошибок могло быть
достаточно, но сейчас это лишь начало. Ведь помимо ошибок из-за внутрен
них причин, необходимо выяснить, каким образом внешнее действующее лицо
могло бы намеренно вывести систему из строя. На это вы можете возразить:
"Да никого данный код вообще не интересует, он не так важен, и вряд ли кому
нибудь вообще известен этот сервер ..." Но окружающий мир велик и по боль
шей части взаимосвязан, а значит, в нем всегда найдутся изнывающие от скуки
школьники, поощряемые государством террористы, банды преступников, кор
поративные шпионы или даже мстительные бывшие сотрудники, нацеленные
взломать вашу систему. Время выживания устаревшей, давно не обновлявшейся
системы в открытой сети измеряется минутами, если не меньше. Безвестность
никак не защищает.
ОСНОВНЫЕ ПРИНЦИПЫ ЗАЩИТЫ
Программистам-прагматикам присуща изрядная доля здоровой подозритель
ности. Им хорошо известно, что любая система несовершенна и подвержена от
казам, и поэтому атакующие извне злоумышленные готовы проникнуть в любую
брешь, оставленную в защите системы, чтобы вывести ее из строя. Конкретные
среды разработки и развертывания также испытывают потребность в защите, и
в связи с этим ниже приведен ряд основных принципов, которые следует всегда
иметь в виду.
1.
Минимизация площади поверхности атак.
2.
Принцип наименьших привилегий.
3.
Безопасные значения настроек по умолчанию.
4.
Шифрование секретных данных.
5.
Организация регулярного обновления системы безопасности.
Рассмотрим каждый из этих принципов защиты по отдельности.
Минимизация площади поверхности атак
Площадь поверхности атак на систему
-
это суммарное количество всех то
чек доступа, где атакующий злоумышленник может ввести или извлечь данные,
а также вызвать выполнение службы. Ниже приведены характерные примеры
направлений атак.
Тема 43 • Будьте осторожны
•
285
Сложность кода. Чрезмерная сложность кода расширяет поверхность атак,
давая больше возможностей для проявления непредвиденных побочных
эффектов. Сложный код способен сделать такую поверхность более про
ницаемой для атак и открытой для заражения вирусами. И в этом случае
чем проще и компактнее код, тем лучше. Кроме того, чем меньше кода, тем
меньше программных ошибок и возможностей проникновения сквозь бре
ши в защите. Наконец, более простой, краткий и менее сложный код легче
анализировать и находить в нем потенциальные слабости.
•
Входные данные. Никогда не доверяйте данным из внешнего источника и
всегда подвергайте их саночистке, прежде чем передавать их на хранение
в базу данных, воспроизводить для просмотра или обрабатывать 19 • Неко
торые языки программирования могут в этом помочь. Например, в языке
Ruby
переменные, хранящие вводимые извне данные, считаются загряз
неннь~ми, что ограничивает круг операций над ними. Например, в приве
денном ниже фрагменте кода явно используется команда
wc,
выводящая
количество символов в файле, имя которого предоставляется во время
выполнения.
safety/taint.rb
puts "Enter а file narne to count: " 20
narne = gets
systern("wc -с #{narne)")
(}
Бесчестный пользователь мог нанести таким кодом следующий ущерб:
Enter а file narne to count:
test.dat; rrn -rf /
•
Но, если установить первый уровень безопасности
(SAFE),
внешние дан
ные станут загрязненными, а это означает, что их нельзя использовать в
опасном контексте, как показано ниже.
safety/taint.rb
>
$SAFE
=
1
puts "Enter а file narne to count: "
narne = gets
systern("wc -с #{narne)")
--- session $ ruby taint.rb Enter
19
жа веб-комикса, доступного по aдpecyhttps: //xkcd. corn/327}? Пока вы вспоминаете,
зайдите на сайт по адресу https: / /bobby-taЫes. сот, где перечислены способы сано
чистки данных, передаваемых по запросам базы данных.
20
введите имя файла для подсчета
Гnава 7 • По ходу кодирования
286
test.dat; rm -rf /
code / safety/taint.rb:S:in system':
Insecure operation - system (Securi tyError) fr om
code/safety/taint.rb:S:in main' ---21
•
Неаутентифицированные службы. По своей природе любой пользователь
где угодно в мире может вызывать неаутентифицированные службы, и по
этому запрет или ограничение доступа к таким службам сразу же создает
возможность, по крайней мере, для атаки типа отказа в обслуживании .
Появившееся недавно довольно большое число брешей в общедоступных
данных было обусловлено тем, что разработчики ненамеренно размещали
данные в неаутентифицированных, открыто доступных для чтения инфор
мационных хранилищах, организованных в "облаке".
•
Выходные данные. Существует (возможно, апокрифическая) история о
системе, которая прилежно выдавала сообщение об ошибке
is used
Ьу
another user"
"Password
(Этот пароль используется другим пользо
вателем). Не разглашайте секретные данные. Убедитесь, что сообщаемые
вами данные пригодны для авторизации данного пользователя . Обрезайте
или скрывайте потенциально рискованные сведения, например, номер со
циального страхования или другие идентификационные номера.
•
Отладочная: информация. Вряд ли вас обрадует появление на экране
местного банкомата, киоска саморегистрации в аэропорту или на сбойной
веб-странице результатов трассировки стека. Сведения, предназначенные
для упрощения отладки, могут также упростить несанкционированное
проникновение в систему. Поэтому убедитесь, что любое "тестовое окно"
(см. выше раздел "Построение тестового окна") и сообщение об исключе
нии во время выполнения защищено от любопытных глаз соглядатаев22 .
1е+ц111
Не усложняйте код и минимизируйте поверхности атак
Принцип наименьших привилегий
Еще один важный принцип состоит в использовании наименьших приви
легий в кратчайший период времени. Это означает, что пользователю не пре
доставляется наивысший уровень привилегий, например
Administrator
root
(корневой) или
(административный). Если же требуется столь высокий уро-
Небезопасная операция в системе (SecurityError) из файла code/safety/ taint.
rb:S:in main' --22 Данная методика оказалась успешной на уровне микросхем процессоров, где хорошо
21
известные взломы эксплуатировали отладку и средства администрирования. Как только
машина взломана, она оказывается полностью доступной злоумышленнику.
Тема 43 • Будьте осторожны
287
вень привилегий, он предоставляется для выполнения минимального объема
работы, а затем быстро освобождается с целью сократить риск. Появление та
кого принципа относится к началу 1970-х годов.
"Всякая программа и каждый привилегированный
пользователь системы должны работать, пользуясь
наименьшими привилегиями, требующимися для
выполнения конкретного задания".
журнал
Возьмем, например, программу
login
Джером Зальтцер
(lerome Saltzer),
Communications ofthe АСМ, 1974 г.
в производных от
Unix
системах. Она
выполняется с корневыми привилегиями. Но, как только эта программа завер
шает аутентификацию правильно установленного пользователя, она сразу сбра
сывает привилегии высокого уровня до пользовательских привилегий.
Данный принцип распространяется не только на уровни привилегий в опе
рационной системе. Так, если в приложении реализуются разные уровни досту
па (например, "администратор" и "пользователь"), следует предусмотреть более
мелкие градации уровней доступа, где уязвимые ресурсы разделены на разные
категории, а отдельные пользователи наделяются привилегиями только для не
которых из этих категорий.
Такая методика придерживается того же принципа минимизации площади
поверхности атак, когда пределы направлений атак сокращаются как по време
ни, так и по уровню привилегий. И в данном случае, действительно, соблюдает
ся правило "лучше меньше, да лучше':
6еэопаснь1е значения настроек по умолчанию
Значения настроек по умолчанию приложения или веб-сайта для пользова
телей должны быть самыми безопасными. И хотя такие значения могут быть
не особенно удобны или пригодны для пользователей, тем не менее каждому
пользователю должна быть предоставлена возможность самостоятельно найти
компромисс между безопасностью и удобством.
Например, вводимый пароль по умолчанию может скрываться, когда вместо
вводимых с клавиатуры символов на экране отображаются звездочки. Такой ре
жим благоразумно установить для ввода пароля в общественных людных местах
или для демонстрации приложений в большой аудитории. Но тем категориям
пользователей, которым требуются специальные возможности, вероятно, при
дется указывать вводимый пароль прописью.
Шифрование секретных данных
Удостоверяющие личность сведения, информация о финансовом состоянии,
пароли и прочие учетные данные нельзя хранить в формате простого текста,
Глава 7 • По ходу кодирования
288
будь то в базе данных или в каком-нибудь другом внешнем файле. Чтобы такие
данные не были раскрыты, их следует зашифровать, обеспечив тем самым до
полнительный уровень их защиты.
В разделе "Тема
19. Контроль
версий" главы
3 "Основные инструментальные
средства" настоятельно рекомендовалось ставить все или nottmи все, что требу
ется для проекта, под систему управления версиями. Из этого правила имеет
ся одно важное исключение: не регистрировать секретные данные, ключи
ключи сетевого протокола
SSH,
API,
зашифрованные пароли и прочие учетные дан
ные вместе с исходным кодом, когда он возвращается после правки в систему
контроля версий. Управление ключами и секретными сведениями должно осу
ществляться отдельно через файлы конфигурации или переменные окружения
как отдельная стадия процесса сборки и развертывания.
Организация регулярного обновления системы безопасности
Обновление вычислительных систем может доставить немало хлопот. Так,
вставка "заплаты" для обновления системы безопасности может нарушить в ка
честве побочного эффекта нормальную работу какой-нибудь части приложения.
В таком случае можно было бы принять решение отложить обновление до более
удобного момента. Но такое решение никуда не годится, поскольку приложение
остается уязвимым к известной эксплуатирующей попытке взлома до тех пор,
пока не будут обновлены его системы безопасности.
-
Устанавливайте обновления системы безопасности
незамедлительно
Такой совет касается любого подключенного к сети устройства, включая
пьютеры, компьютеры для разработки и сборки программ, рабочие серверы и
"облачные" образы
-
одним словом, все. И если вы думаете, что это не так уж
и важно, запомните, что самые крупные взломы данных в истории происходили
потому, что информационные системы своевременно не обновлялись. Не дово
дите того, чтобы нечто подобное случилось и с вами.
3дРАВЫЙ СМЫСЛ И КРИПТОГРАФИЯ
Очень важно иметь в виду, что здравый смысл может вас подвести, когда
речь идет о криптографии. Первое и самое главное правило в отношении крип
тографии гласит: никогда не реализуйте ее самостоятельно23 .
23
Если, конечно, вы не обладаете ученой степенью в области криптографии. Но даже в
этом случае вы не должны этого делать без проверок со стороны коллег по работе, об
ширных эксплуатационных испытаний с поощрениями за обнаружение уязвимых мест в
защите проверяемой системы и выделения средств на долгосрочное ее сопровождение.
Тема 43 • Будьте осторожны
289
Антишд&ЛОНЫ для ПАРОЛЕЙ
Одно из самых главных затруднений, связанных с обеспечением безопас
ности, состоит в том, что качественная защита нередко пр_отиворечит здра
вому смыслу или обычной практике. У вас может, например, возникнуть
мысль, что требования к строгости паролей повысят безопасность прило
жения или веб-сайта. Но вы окажетесь не правы.
Правила соблюдения строгости паролей на самом деле снижают уровень
безопасности. Ниже перечислены вкратце неудачные идеи и некоторые
рекомендации по обеспечению безопасности от Национального института
стандартов и технологий США (NIST) 24 •
•
Не ограничивайте длину паролей меньше чем
мендует в качестве предельной длины пароля
64 символами. NIST
256 символов.
•
Не обрезайте выбранные пользователями пароли.
•
Не ограничивайте применение специальных символов, таких как
реко
[ J () ; &
%$# или /.Если специальные символы в пароле способны скомпромети
ровать вашу систему
NIST требует принимать
все печатные АSСll-символы, пробел и символы Unicode.
-
у вас большие проблемы.
• Не предоставляйте подсказки для паролей неаутентифицированным
пользователям или приглашения для ввода конкретных типов информа
ции (наподобие "Как звали ваше первое домашнее животное?")
• Не отменяйте функцию paste в своем браузере. Нарушение функций
браузера и диспетчеров паролей не делает вашу систему более безопас
ной и фактически побуждает пользователей составлять более простые и
краткие пароли, которые намного проще разгадать.
•
Не устанавливайте дополнительные правила составления паролей. На
пример, не запрещайте использовать в паролях какие-нибудь конкрет
ные сочетания прописных и строчных букв, цифр, специальных знаков
или повторяющихся символов.
•
Не заставляйте волевым порядком пользователей изменять свои пароли
по истечении некоторого периода времени. Делайте это лишь при веских
основаниях (например, в случае взлома).
Поощряйте употребление длинных, произвольных паролей с высокой сте
пенью энтропии. Наложение искусственных ограничений сдерживает эн
тропию и порождает скверные привычки в отношении паролей, оставляя
учетные записи пользователей уязвимыми к овладению чужими.
24 См. специальное издание NJST Special PuЬlication 800-бЗВ: Digital ldentity Guidelines
Authentication and Lifecycle Management, свободно доступное по адресу https: / /
doi.org/10.6028 /N IST.SP.800- бЗb .
Гnава 7 • По ходу кодирования
290
Общие нормы практики неверны даже для таких простых вещей, как пароли
(см. врезку "Антишаблоны для паролей"). Обратившись к криптографии, имейте
в виду, что даже мельчайшая и едва заметная ошибка способна все нарушить:
ваш изощренный доморощенный алгоритм шифрования может оказаться разга
данным опытным взломщиком в считанные минуты. Поэтому ни в коем случае
не занимайтесь шифрованием самостоятельно.
Как упоминалось ранее, полагаться следует лишь на то, что действительно на
дежно: хорошо проверенные, тщательно изученные, регулярно сопровождаемые,
часто обновляемые библиотеки и каркасы
-
желательно с открытым исходным
кодом. Если речь не идет о простых задачах шифрования, тщательно про ан али зируйте другие связанные с безопасностью функциональные возможности свое
го веб-сайта или приложения (например, аутентификацию пользователей).
Чтобы самостоятельно реализовать функции регистрации с помощью паро
ля или биометрической аутентификации, вам придется как следует разобраться
в принципе действия и назначении хеш-кодов и "соли" для шифрования; по
нять, каким образом взломщики пользуются такими средствами, как радужные
таблицы; выяснить причины, по которым нельзя пользоваться алгоритмами
шифрования
MDS
и SНAl; а также разрешить немало других криптографичес
ких вопросов. И даже если вы сделаете все это правильно, то в конечном счете
именно вам придется отвечать за безопасное хранение данных, учитывая появ
ление новых законодательных норм и правовых обязательств.
С другой стороны, вы можете выбрать прагматичный подход и возложить
бремя ответственности на кого- нибудь, обратившись, например, к стороннему
поставщику услуг аутентификации. Это может быть служба, функционирующая
в вашей организации, или же сторонняя служба, присутствующая в "облаке''.
Услуги аутентификации нередко предоставляются поставщиками услуг электрон
ной почты, телефонной связи или социальных сетей и могут (или не могут) быть
пригодны для вашего приложения. Но в любом случае поставщики услуг аутен
тификации постоянно занимаются подержанием своих систем в безопасном со
стоянии и лучше вас разбираются в этих вопросах. Итак, будьте осторожны!
Другие связанные с данной темой разделы
•
Тема
-"
23.
Проектирование по контракту, глава
4
"Прагматичная пара-
ноия.
•
•
Тема
24.
Мертвые программы не лгут, глава
Тема
25.
Утвердительное программирование, глава
4
"Прагматичная паранойя''.
4
"Прагматичная па
ранойя''.
•
Тема
38.
Программирование по совпадению.
•
Тема
45.
Западня требований, глава
8
"До начала проекта''.
Тема 44 • Именование
291
i•Mti(i ИМЕНОВАНИЕ
«Называть вещи своими именами
-
начало мудрости".
Конфуций
Что значит имя? В процессе программирования оно значит "все, что угодно"!
Разработчики придумывают имена приложениям, подсистемам, модулям, фун
кциям, переменным, ведь они постоянно создают что-нибудь новое и каким-то
образом его называют. Следовательно, имена крайне важны, поскольку они в
немалой степени выявляют намерения и убеждения разработчиков.
Мы считаем, что разрабатываемые компоненты должны именоваться в соот
ветствии с той ролью, которую они играют в прикладном коде. Это означает, что
всякий раз, когда вы создаете какой-нибудь компонент, вы должны остановить
ся на время и подумать над следующим вопросом: "Для чего я это создаю?"
И это своевременный и важный вопрос, поскольку он заставляет вас от
влечься от решения непосредственной задачи и бросить взгляд на общую кар
тину. Рассматривая роль переменной или функции, вы размышляете, для чего
она предназначена, что она может сделать и как с ней взаимодействовать не
посредственно в коде. И зачастую вы осознаете, что предполагаемые вами даль
нейшие действия не имеют никакого смысла просто потому, что вам не удалось
придумать подходящее имя.
Мысль о том, что имена имеют глубокий смысл, имеет свое научное обосно
вание. Оказывается, мозг человека может читать и понимать слова очень быст
ро, причем быстрее, чем выполнять многие другие действия. Это означает, что
слова приобретают определенный приоритет, когда мы пытаемся что-то осмыс
лить. И это можно продемонстрировать на примере эффекта Струпа25 •
Взгляните на приведенную ниже панель, где показаны названия цветов и от
тенков, выделенных черным или белым цветом либо оттенком серого, хотя на
звания и цвета совсем не обязательно совпадают. И вот вам задача: произнести
вслух название каждого цвета так, как оно написано26 .
См. Studies of Interference in Serial Verbal Reactions [Str35].
Имеются два варианта данной панели. В одном из них употребляются разные цве
та, а в другом - оттенки серого. Здесь приведен черно-белый вариант данной панели,
25
26
но если вам потребуется цветной ее вариант или же если вы плохо различаете оттенки
серого, перейдите на веб-страницу, доступную по адресу
the-pragmatic-prograпuner/stroop-effect.
https: / / pragprog. сот/
Гnава 7 • По ходу кодирования
292
БЕЛЫЙ
БЕЛЫЙ
СЕРЫЙ
ЧЕРНЫЙ
БЕЛЫЙ
БЕЛЫЙ
ЧЕРНЫЙ
Повторите описанные выше действия, но вместо этого произнесите вслух назва
ние цвета, которым написано каждое слово. Сделать это труднее, не так ли? Бегло
прочитать названия цветов проще, чем попытаться распознать сами цвета. Наш
мозг интерпретирует написанные слова как нечто важное, поэтому нам следует
сделать так, чтобы употребляемые нами имена отвечали данному наблюдению.
Рассмотрим ряд примеров.
•
Допустим, на веб-сайте, продающем ювелирные изделия, изготовленные из
бывших в употреблении графических плат, мы аутентифицируем людей,
посещающих этот сайт. Это делается следующим образом:
let user
=
authenti cate (credentials)
u s е r,
Переменная
хранящая результаты аутентификации, называется
поскольку она всегда обозначает пользователя. Но почему перемен
user,
ная называется именно так? Ведь с тем же успехом ее можно было бы на
звать
customer
или
buyer?
Присвоив ей имя
user,
мы тем самым пос
тоянно напоминаем себе по ходу программирования, что именно данное
лицо пытается сделать и что это означает для нас самих.
•
Допустим, имеется следующий метод экземпляра, в котором рассчитыва
ется скидка на заказанные товары:
puЫic
void
deductPercent(douЫe
arnount)
! ! ...
Здесь употребляются два имени. Во-первых, имя метода
deduct Percent
обозначает, что именно он делает, а не почему он это делает. И во-вторых,
имя параметра
amount, по меньшей мере, вводит в заблуждение. Что имен
но оно обозначает: абсолютную величину или долю в процентах?
Возможно, было бы лучше написать следующую строку кода:
puЫic
void applyDi scount (Percentage discount)
! ! .. .
Ведь имя данного метода теперь ясно обозначает его назначение. Кроме
того, мы изменили тип параметра с douЫe на заранее определяемый ссы
лочный тип
Percentage.
Нам ничего неизвестно о намерениях пользова
теля данного метода, и поэтому, оперируя долями в процентах, мы можем
Тема 44 • Именование
293
только гадать, в каких именно пределах будет задано значение параметра
от О до
discount:
100
или же от О. О до
1. О.
Поэтому указанный тип
документирует здесь предполагаемое значение параметра данного метода.
•
Допустим, имеется модуль, оперирующий числами Фибоначчи. В одной из
его функций вычисляется п-е число Фибоначчи. При этом возникает воп
рос: как назвать такую функцию? Большинство разработчиков скажут, что
этой функции следует присвоить имя f
ib.
Такое имя, на первый взгляд,
вполне обосновано, но не следует забывать, что эта функция будет вызы
ваться в контексте данного модуля, например, так:
быть, этой функции следует присвоить имя
of
или
Fib. fib (n). А
nth и вызывать
может
ее так,
как показано ниже.
#=>О
Fib . of(O)
Fib . nth(20) # => 4181
Присваивая имена компонентам, вы постоянно ищете способы прояснить,
что именно вы имеете в виду, и такое прояснение приведет вас к лучшему по
ниманию своего кода по ходу его написания. Тем не менее далеко не все имена
способны претендовать на соискание литературной премии.
ИСКЛЮЧЕНИЕ, ПОДТВЕРЖДАЮЩЕЕ ПРАВИЛО
Несмотря на стремление сделать исходный код более ясным, необходимо
также принимать во внимание и фирменную символику, а это уже совсем
другой вопрос.
По установившейся традиции проектам и их командам принято присваивать
малопонятные, но "умные" названия, например: "Покемон'; "Замечательные
супергерои'; "Крутые мачо'; имена персонажей из серии фильмов "Власте
лин колец" в буквальном смысле слова.
УВАЖЕНИЕ К КУЛЬТУРЕ
В программировании есть только две трудные вещи:
инвалидация кеша и именование переменных.
В большей части литературы по основам программирования читателей пре
достерегают никогда не присваивать переменным однобуквенные имена вроде
i, j или k. 27 Мы считаем, что они не совсем правы.
27
Знаете ли вы, почему переменная цикла обычно обозначается как i? Дело в том, что
более 60 лет назад в первоначальной версии языка FORTRAN (на синтаксис которого ока
зала большое влияние алгебра) переменные, имена которых начинались на буквы от
N, были целочисленными.
I
до
Глава 7 • По ходу кодирования
294
На самом деле это зависит от культуры программирования на конкретном язы
ке или его выполняющей среды. Так, в языке С имена
i, j
или
k
традиционно
употребляются в качестве переменных для увеличения шага цикла, а именем
s
обозначаются символьные строки и т.д. Если вы программируете именно в такой
среде, то, именуя элементы кода, следуйте принятым нормам. Иначе вы, по сущест
ву, нарушаете эти нормы, а следовательно, поступаете неверно. Уважая сложивши
еся традиции, вы вряд ли напишете нечто, подобное приведенному ниже фрагмен
ту кода на языке
написанию имен вроде camelCase, где употребляются прописные буквы в
средине имени (так называемый "горбатый регистр"), тогда как в других со
обществах
-
"змеиный регистр" вроде snake _ case, где слова, составляющие
имя, разделяются знаком подчеркивания. В самих языках программирования,
безусловно, приняты обе разновидности написания имен. Но это не позволяет
уладить все вопросы, поскольку приходится уважать локальную культуру про
граммирования. Так, в некоторых языках в именах компонентов допускается
использовать символы Юникода. Но, прежде чем употреблять в исходном коде
такие "заумные" имена, как Jasn или E~EPXETaL, необходимо подумать, как это
будет воспринято в сообществе программистов.
СОГЛАСОВАННОСТЬ
Ральф Уолда Эмерсон однажды написал: "Безрассудная согласованность
-
это путало для маленьких умов': но ему не посчастливилось работать в команде
программистов. В каждом проекте вырабатывается свой словарь терминов
-
жаргонных словечек, имеющих особое значение для членов команды. Так, тер
мин
order
означает "заказ" для команды, разрабатывающей интернет-магазин,
тогда как для команды, создающей приложение, графически отображающее про
исхождение религиозных групп,
-
"орден". В связи с этим очень важно, чтобы
все члены команды знали эти термины и пользовались ими согласованно.
С одной стороны, можно поощрять активное общение в команде разработ
чиков. Так, если программы пишутся парами, и эти пары часто меняются, то
терминология усваивается быстро. С друтой стороны, можно составить словарь
проекта, перечислив в нем термины, имеющие особое значение для команды.
Это неформальный документ, который может поддерживаться в форме вики страниц или карточек для записей, вывешиваемых где-нибудь на стене.
Со временем терминология проекта станет жить своей жизнью. И как толь
ко словарь терминов станет привычным для всех, им можно пользоваться как
скорописью для точного и краткого обозначения сложных понятий. (На этом,
собственно, основывается язык шаблонов.)
Тема 44 • Именование
295
ПЕРЕИМЕНОВЫВАТЬ ЕЩЕ ТРУДНЕЕ
В программировании есть только две трудные вещи:
инвалидация кеша, именование переменных
и ошибки выхода за границы массивов
Сколько ни прилаrай усилий, все равно все течет и изменяется. В частнос
ти, код реорrанизуется, акценты применения смещаются, а смысловое значение
немноrо меняется. И если не проявить бдительность в отношении обновления
имен по ходу проrраммирования, то можно очень быстро дойти до запутанных
имен, вызывающих еще большие проблемы, чем имена бессмысленные. Прихо
дилось ли вам коrда-нибудь слышать такое объяснение несоrласованностей в
исходном коде: "Подпрограмма
getData на самом деле записывает данные в
архивный файл"?
Как пояснялось в разделе "Тема
3.
Проrраммная энтропия" главы
1 "Фило
софия прагматизма", обнаружив ошибку, ее необходимо безотлаrательно устра
нить. Так, если вы обнаружите имя, больше не выражающее ваше намерение
или вводящее в заблуждение,
ero нужно исправить.
Имея в своем распоряжении
полный набор реrрессионных тестов, выявите все экземпляры этого слова, ко
торые вы могли пропустить.
Именуйте правильно;
а по мере надобности переименовывайте
Если по какой-то причине вы не можете изменить неверное в настоящий мо
мент имя, значит, у вас возникло более серьезное затруднение: нарушен при
нцип леrкости изменения (см. раздел "Тема
рования" rлавы
2 "Праrматичный
8. Сущность качественного
проекти
подход"). Сначала разрешите это затруднение,
а затем измените указавшее на него имя. Упрощайте переименование и делайте
это почаще. В противном случае вам придется объяснить новым членам своей
команды, что подпроrрамма
getData
на самом деле записывает данные в файл,
причем делать это с невозмутимым видом.
Другие разделы, связанные с данной темой
•
Тема
3.
Программная энтропия, rлава
•
Тема
40.
Рефакторинг.
•
Тема
45.
Западня требований, rлава
8
1 "Философия
прагматизма':
"До начала проекта".
Глава 7 • По ходу кодирования
296
Задачи
•
Если вы обнаружите функцию или метод со слишком общим именем,
попробуйте изменить это имя, чтобы точнее выразить назначение данной
функции или метода. И тогда вам будет легче реорганизовать свой код.
•
В одном из рассмотренных выше примеров предлагалось употребить более
конкретные имена вроде
buyer или customer вместо более традицион
user. Какими еще именами вы обыкновенно
ного и обобщенного имени
пользуетесь как наиболее подходящими в данном случае?
•
Согласуются ли имена в вашей системе с пользовательскими терминами
из предметной области? Если не согласуются, то почему? Вызвано ли это
когнитивным диссонансом вроде эффекта Струпа для вашей команды?
•
Трудно ли изменять имена в вашей системе? Что можно сделать, чтобы
устранить нарушенное в итоге отображение конкретного окна?
ГЛАВА
8
До НАЧ . АЛА ПРОЕКТА
В самом начале проекта вам и вашей команде требуется изучить исходные
требования. Просто приказание, что нужно делать, или выслушать объяснения
пользователей явно недостаточно, поэтому прочитайте раздел "Западня требо
ваний': чтобы научиться избегать общих ловушек.
Обыкновенной мудрости и управлению ограничениями посвящен раздел
"Решение неразрешимым головоломок". Трудности появятся в любом случае,
удовлетворяете ли вы требования, выполняете ли анализ, программируете или
тестируете. Зачастую они бывают еще более серьезными, чем казались вначале.
Если по ходу проекта перед нами встают неразрешимые трудности, мы лю
бим прибегать к своему секретному оружию: работать вместе. Под работой
вместе мы подразумеваем не коллективный труд над массивным документом
с требованиями, интенсивный обмен рассылаемыми по электронной почте со
общениями или проведение бесконечных совещаний, а совместное разрешение
затруднений во время программирования. В разделе "Совместная работа" мы
покажем, как приступить к такой работе, кто и что для этого требуется.
Несмотря на то что в Манифесте гибкой разработки, в частности, заявле
но: "Люди и взаимодействие важнее процессов и инструментов", буквально все
"гибкие" проекты начинались с иронического обсуждения процессов и инстру
ментальных средств, которые предстоит применять. Но как бы тщательно ни
был рассмотрен этот вопрос и какие бы нормы передовой практики ни приме
нялись, ни одна методика не может заменить способность мыслить. Следова
тельно, требуется не конкретный процесс или инструмент, а осмысление самой
сущности гибкости, как поясняется в соответствующем разделе.
Разобрав все самые важные вопросы до начала проекта, можно лучше под
готовиться к работе над ним, чтобы избежать "аналитического паралича", когда
много мыслей, да мало толку, и фактически начать, а затем успешно завершить
проект.
298
Гnава 8 • До начаnа проекта
li@ti&j ЗАПАДНЯ ТРЕБОВАНИЙ
"Совершенство достигается не тогда, когда нечего
добавить, а когда нечего отнять ..."
Антуан де Сент-Экзюпери, Планета людей,
1939 г.
Во многих книгах и учебных пособиях сбор требований объясняется как ран
няя стадия проекта. Слово "сбор" здесь, по-видимому, означает племя счаст
ливых аналитиков, собирающих повсюду крупицы мудрости под звуки "Пасто
ральной симфонии" Людвига ван Бетховена, исполняемой на заднем плане. Кро
ме того, слово "сбор" подразумевает, что требования уже существуют, остается
лишь найти и разместить их в своей корзине и беззаботно идти своим путем.
В действительности все обстоит совсем иначе. Ведь требования редко лежат на
поверхности. Как правило, они зарыты глубоко под слоями допущений, недоразу
мений и убеждений. Хуже того, требования зачастую вообще не существуют.
Никто точно не знает, чего он хочет
МИФ О ТРЕБОВАНИЯХ
На заре истории разработки программного обеспечения ЭВМ были более цен
ными (с точки зрения амортизированной стоимости часа работы), чем люди, кото
рые на них работали. Поэтому программисты экономили средства, пытаясь сделать
свои программы работоспособными сразу. В ходе этого процесса они старались
точно указать, что должна делать ЭВМ. И с этой целью составлялась специфика
ция требований, которая превращалась сначала в проектную документацию, а за
тем в блок-схемы и псевдокод и, наконец, в исходный код. Но, прежде чем ввести
исходный код в ЭВМ, программисты тщательно проверяли его за столом.
Такой подход к разработке программного обеспечения обходится очень доро
го. И столь большие затраты послужили причиной того, что программисты стара
лись автоматизировать что-нибудь лишь тогда, когда они точно знали, чего хотят
добиться. А поскольку вычислительные возможности первых ЭВМ были очень
скромными, круг решаемых задач был весьма ограниченным. В частности, можно
было полностью понять задачу еще до того, как приступить к ее решению.
Но в реальном мире все обстоит совсем иначе. В нем царит беспорядок, кон
фликты и много неизвестного . В таком мире точные спецификации чего-нибудь
редки, если они вообще возможны.
И здесь вступают в действие программисты. Их задача
-
помочь людям по
нять, чего они хотят на самом деле. И это, вероятно, самое ценное преимущест
во программистов, так что повторим еще раз:
Тема
-
45 • Западня требований
299
Программисты помогают людям понять,
чего они не хотят на самом деле
ПРОГРАММИРОВАНИЕ КАК ТЕРАПИЯ
Назовем клиентами тех людей, которые просят нас написать программу.
Типичный клиент приходит к нам со своей нуждой, которая может быть как
стратегической, так и тактической потребностью отреагировать на возникшее
затруднение. Это может быть потребность изменить существующую систему
или создать новую. Иногда она выражается в деловых терминах, а порой
-
в
технических.
Ошибка, которую часто совершают разработчики, состоит в том, что они
воспринимают сформулированную их клиентами потребность как задачу и ре
ализуют ее решение. На самом деле это лишь приглашение к исследованию, хотя
клиент может этого и не осознавать.
Рассмотрим простой пример. Допустим, что вы работаете в издательстве,
выпускающем книги как в печатном, так и в электронном виде. Вам поставили
новое требование, сформулированное следующим образом:
Доставка должна быть бесплатной по всем заказам стоимостью свы
ше
50
долларов.
Призадумайтесь на секунду и поставьте себя на место заказчика. Какие мысли придут вам сразу на ум? Скорее всего, у вас возникнут следующие вопросы:
•
Включает ли сумма заказа
50 долларов
•
Включает ли сумма заказа
50
•
Распространяется ли сумма заказа
налог?
долларов текущие транспортные расходы?
50
долларов только на печатные изда-
ния или же может охватывать и электронные книги?
•
Какой вид доставки имеется в виду? Срочная? Наземным транспортом?
•
А как насчет международных заказов?
•
И как часто предельная сумма заказа
50 долларов будет изменяться в даль
нейшем?
Когда вам дают простое задание, рассматривайте крайние случаи, докучая
тем, кто вам его дал, подробными вопросами, чтобы прояснить дело. Скорее
всего, клиент уже думал о некоторых из этих крайних случаев и лишь подразу
мевал, что они будут учтены в реализации. Задавая наводящие вопросы, можно
выведать все эти сведения.
Но другие вопросы могут, вероятнее всего, касаться того, о чем клиент рань
ше даже не задумывался. Именно здесь и начинается самое интересное, а
rpa-
300
Глава 8 • До начала проекта
мотный разработчик учится быть дипломатом, как демонстрируется в приве
денном ниже диалоге с клиентом.
Вы: У нас возникли вопросы по поводу итоговой суммы заказа
50
долла
ров. Входят ли в эту сумму обычно взимаемые транспортные расходы?
Клиент: Конечно. Это все, что заказчики должны заплатить.
Вы: Заказчики должны ясно и просто усмотреть в этом привлекатель
ность такого предложения. Но мне представляется, что некоторые
менее добросовестные заказчики попытаются обойти эти правила на
шей системы заказов.
Клиент: Каким образом?
Вы: Допустим, они покупают сначала книгу за
25
долларов, а затем
выбирают ночную доставку как самый дорогой вариант. В таком слу
чае доставка книги будет, вероятнее всего, стоить около
а общая сумма заказа составит
55
25
долларов,
долларов. Если мы делаем доставку
бесплатной, то за ночную доставку книги стоимостью
заплатили бы всего
30
25 долларов
они
долларов.
(В этот момент опытный разработчик делает многозначительную
паузу. Он изложил факты, а решение принимать клиенту.)
Клиент: Ой, да это совсем не то, что я предполагал! Ведь мы понесем
убытки на таких заказах. Есть ли какие-то пути выхода из этого по
ложения?
Именно здесь и начинается исследование исходных требований. Ваша роль
-
интерпретировать то, что говорит клиент, и в ответ пояснить ему возможные
последствия. Это одновременно интеллектуальный и творческий процесс, пос
кольку вы обдумываете требования и в то же время способствуете принятию
такого решения, которое, скорее всего, окажется лучше, чем то, что могло бы
быть принято вами или клиентом по отдельности.
ТРЕБОВАНИЯ -
ЭТО ПРОЦЕСС
В приведенном выше примере разработчик принял требования и в ответ
объяснил их последствия клиенту, что и послужило началом для их исследова
ния. В ходе этого исследования вы, вероятно, придумаете еще множество воп
росов, реагируя на предлагаемые клиентом варианты решений . Это реальность
любого сбора требований.
с;+цв•
Требования изучаются с помощью обратной связи
Тема 45 • Западня требований
301
Ваша задача - помочь клиенту лучше понять последствия сформулирован
ных им требований. Для этого вы образуете цепь обратной связи, пользуясь
которой клиент может обдумывать и уточнять свои требования.
В приведенном выше примере выразить обратную связь словами было не
трудно, но так бывает далеко не всегда. Иногда вы просто недостаточно знаете
особенности предметной области для этого.
В подобных случаях программисты-прагматики полагаются на методику от
ветной реакции вроде наводящего вопроса: "Вы имели в виду именно это?" Они
создают макеты и прототипы и дают клиентам возможность поэкспериментиро
вать с ними. В идеальном случае макеты и прототипы получаются достаточно
гибкими, чтобы их можно было изменять прямо во время бесед с клиентами и
реагировать на их замечания вроде "это не то, что я имел в виду" репликами
типа "а вот так больше похоже на то, что вы хотели?':
Иногда такие макеты и прототипы могут быть отвергнуты в течение часа или
около того. Очевидно, что они являются лишь поделками, подсказывающими
общий замысел.
Но на практике вся работа, которую разработчикам приходится выполнять,
на самом деле является некоторой формой макетирования. И даже в конце про
екта мы все еще интерпретируем таким образом пожелания своих клиентов.
Фактически к этому времени количество клиентов только возрастает, включая
сотрудников отделов контроля качества, эксплуатации, сбыта, а возможно, и
тестовых групп потенциальных пользователей.
Таким образом, программист-прагматик рассматривает весь проект как
большое упражнение в сборе требований. Именно поэтому мы предпочитаем
краткие, но частые беседы с клиентами, чтобы получать их непосредственную
реакцию. Это дает нам возможность быть в курсе дела и быть уверенными, что
в том случае, если мы пойдем по неверному пути, потраченное на него время
сведется к минимуму.
ПОСТАВЬТЕ СЕБЯ НА МЕСТО КЛИЕНТА
Чтобы лучше понять ход мыслей клиента, достаточно воспользоваться прос
тым, но нечасто применяемым методом: поставить себя на место клиента. Так,
если вы разрабатываете систему для службы технической поддержки, проведите
пару дней рядом с опытным сотрудником этой службы, следя за тем, как он от
вечает на звонки. А если вы автоматизируете систему ручного контроля запасов,
поработайте с неделю на складе 1 •
1
Целая неделя - не слишком ли это долrо? Нет, не слишком, особенно в том случае, если
требуется проанализировать производственные процессы, где руководители и исполнители
работают в разных условиях. Руководители поделятся с вами одним (зачастую самым общим)
представлением о производственных процессах, а когда вы опуститесь на землю, то столк
нетесь с совершенно иной реальностью, на усвоение которой также потребуется время.
302
Глава 8 • До начала проекта
Помимо ясного понимания, каким образом проектируемая система будет
применяться на практике, вы будете приятно удивлены тем, как ваша просьба
понаблюдать за производственными процессами непосредственно на рабочих
местах поможет установить доверие и создать прочный фундамент для общения
с вашими клиентами. Только не мешайте людям работать!
IЗФIJfi:I Работайте с пользователем, чтобы мыслить как пользователь 1
Во время сбора ответной реакции стоит начать выстраивать тесные отноше
ния со своей клиентурой, изучая ожидания и надежды клиентов в отношении
проектируемой вами системы. Подробнее об этом см. в разделе "Тема
ляйте своим пользователям удовольствие" rлавы
9 "Прагматичные
52. Достав
проекты':
ТРЕБОВАНИЯ И ПРАВИЛА
Представьте, что в беседе с сотрудниками отдела кадров клиент заявит: "За
писи о работниках моrут просматривать только их непосредственные начальни
ки и сотрудники отдела кадров". Следует ли считать такое заявление истинным
требованием? Возможно, в настоящий момент так и стоит поступать, но оно
включает в себя определенный набор бизнес-правил.
Отличия бизнес-правил от требований едва заметны, но тем не менее они
могут иметь глубокие последствия для разработчиков. Так, если требование
сформулировано следующим образом: "Только непосредственные начальники и
сотрудники отдела кадров моrут просматривать записи о работниках': то разра
ботчик может в конечном счете запрограммировать и проверять это требование
явным образом всякий раз, когда приложение получает доступ к данным. Но
если требование сформулировано таким образом: "Записи о работниках моrут
быть доступны только уполномоченным пользователям': то разработчик, ве
роятнее всего, спроектирует и реализует некоторого рода систему управления
доступом. И если бизнес-правила изменятся (а это неизбежно), то обновить
придется только метаданные такой системы. Фактически сбор требований ес
тественным образом приводит к системе, хорошо приспособленной к поддержке
метаданных.
В действительности общее правило таково:
Бизнес-правила
-
это метаданные
Реализуйте общий случай, приняв во внимание сведения о бизнес-правилах
в качестве примера того, что должно поддерживаться в системе.
Тема 45 • Западня требований
303
ТРЕБОВАНИЯ И РЕАЛЬНОСТЬ
В статье из журнала Wired, вышедшей в январе 1999 года2 , продюсер и музыкант
Брайан Эно описал невероятную на то время технологию окончательного микши
рования звука на одном пульте. Однако эта технология только мешала творческо
му процессу вместо того, чтобы дать музыкантам возможность создавать более
качественную музыку, а звукорежиссерам
-
записывать ее быстрее и дешевле.
Чтобы стали понятнее причины, выясним, каким образом работают звуко
режиссеры. Они выполняют сведение звука, руководствуясь своей интуицией.
С годами у них вырабатывается внутренняя цепь обратной связи между их уша
ми и пальцами, перемещающими ползунки регуляторов громкости, вращающи
ми рукоятки балансировки звуковых каналов и т.д. Тем не менее все эти про
фессиональные способности звукорежиссеров в упомянутом выше микшерском
пульте учтены не были. Вместо этого его пользователи вынуждены были вводить
данные с клавиатуры или щелкать кнопками мыши. Пульт обеспечивал все не
обходимые для звукозаписи функции, но они были реализованы незнакомым и
чуждым звукорежиссерам образом. Зачастую очень нужные звукорежиссерам
функции этого микшерского пульта были скрыты за непонятными названиями
или же становились доступными через неинтуитивные комбинации основных
функциональных средств.
Данный пример наглядно иллюстрирует наше убеждение, что удобные инс
трументы должны быть приспособлены к рукам мастера, который ими пользует
ся. Обычно это положение учитывается при удачном сборе требований. И поэ
тому ранняя ответная реакция, достигаемая с помощью прототипов или методом
трассирующих пуль, приводит к реакции клиентов "Да, система делает то, что
мне требуется, но не так, как я хочу':
ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ
Мы считаем самой лучшей и, возможно, единственной документацией тре
бований рабочий код. Но это совсем не означает, что можно обойтись без доку
ментирования своего понимания того, что требуется клиенту. Это простоозна
чает, что такие документы не выпускаются, т.е. не даются клиентам на подпись.
Вместо этого они просто служат вехами, помогающими направить процесс реа
лизации требований в нужное русло.
Требованив докуменmируютсв не длв клиентов
В прошлом мы оба работали над проектами, в ходе которых составлялись
невероятно подробные требования. Такие основательные документы существен
но расширяли исходное двухминутное пояснение клиентом его требований к
проекту до образцового произведения толщиной с целый дюйм, испещренного
2
См. по адресу https: / /www.wired.com/1999/01/eno/.
304
Глава 8 • До начала проекта
диаграммами и таблицами. В подобных документах требования уточнялись на
столько, что их реализация почти не допускала никакой неоднозначности. Если
бы можно было применить к такому документу современные довольно эффек
тивные инструментальные средства, его можно было бы сразу превратить в го
товую программу.
Составление таких документов было ошибкой по двум причинам. Во-первых,
как обсуждалось ранее, клиенту на самом деле неизвестно, что ему, собственно,
требуется. Следовательно, превращая то, что заявлено клиентом, в едва ли не
нормативно-правовой документ, разработчики пытаются построить невероятно
сложный замок на зыбучих песках.
На это вы могли бы возразить: "Но ведь когда мы приносим документ кли енту на подпись, то получаем его ответную реакцию". И это приводит нас ко
второй причине, по которой такое документирование требований ошибочно:
клиент вообще не читает спецификации требований к программному обеспе
чению.
Клиенты прибегают к услугам программистов потому, что программисты
вникают в мельчайшие подробности, тогда как клиента интересует лишь общее
решение не совсем ясно поставленной им задачи. Документация на требования
составляется для разработчиков и содержит подробные сведения, которые иног
да непонятны, а зачастую неинтересны самому клиенту.
Выпустите документацию требований объемом
200
страниц, и клиент, веро
ятнее всего, решит: если она столь объемистая, значит, достаточно важная. Он
может позволить себе прочитать два первых ее абзаца (именно поэтому они и
называются резюме для руководства) и бегло просмотреть все остальное, изред
ка останавливаясь на аккуратно построенной диаграмме.
Документация не подавляет клиента. Но предоставить ему крупную техни -
ческую документацию
-
это все равно, что дать разработчику средней квали-
ф икации экземпляр "И лиады " r
1омера и попросить его написать на ее основе
видеоигру.
Требования документируются для планирования
Итак, мы не верим в монолитную и настолько тяжелую, что ею можно оглу
шить и быка, документацию требований к проекту. Но мы знаем, что требова
ния должны быть написаны просто потому, что разработчикам нужно знать,
что им делать в команде.
Какую же форму должна принимать такая документация? Мы предпочитаем
нечто, способное уместиться на реальной (или виртуальной) карточке для запи
сей. Столь краткие записи обычно называются пользовательскими историями,
описывающими, что именно должна делать небольшая часть приложения с точ
ки зрения его пользователя. Если требования написаны именно таким образом,
их можно разместить на доске и переставлять их, чтобы показать состояние и
приоритетность их выполнения.
Тема 45 • Западня требований
305
Вы можете, конечно, возразить, что на одной карточке для записей нельзя
уместить все сведения, необходимые для реализации компонента приложения, и
будете совершенно правы. Но это лишь частичный довод. Стремясь к краткости
формулировки требований, вы побуждаете разработчиков задавать уточняю
щие вопросы. И в то же время усиливаете процесс ответной реакции клиентов и
программистов на взаимные действия до и во время создания фрагмента кода.
ИЗЛИШНЕ ПОДРОБНАЯ СПЕЦИФИКАЦИЯ
Еще одна немалая опасность документирования требований состоит в том,
что они могут оказаться слишком подробными. Грамотно составленные требо
вания абстрактны. Простейшая формулировка, точно отражающая потребности
в конкретной предметной области, подходит в качестве требования лучше все
го. Это совсем не означает, что требования могут быть неопределенными. В их
формулировке необходимо зафиксировать исходные семантические инварианты
и задокументировать конкретные или текущие нормы практики выполнения ра
бот в виде набора правил. Требования не имеют никакого отношения к архитек
туре, конструкции или пользовательскому интерфейсу. Требования отражают
потребность.
"ЕЩЕ ОДНУ МЯТНУЮ ВАФЕЛЬНУЮ ПЛАСТИНКУ•• •"
3
Многие неудачи в проектах объясняются расширением их границ, иначе име
нуемым раздуванием либо расползанием функциональных возможностей или
требований. Это похоже на синдром сваренной лягушки (см. раздел "Тема
Суп из камней и вареные лягушки" главы
1 "Философия
4.
прагматизма"). Что же
можно сделать, чтобы избежать расползания требований?
Ответ снова кроется в обратной связи. Так, если вы работаете с клиентом
в режиме последовательных итераций с обратной связью, то клиент будет на
собственном опыте испытывать воздействие "еще одного функционального
средства". Увидев, как очередная карточка с пользовательской историей пере
местилась вверх по доске, он поможет выбрать следующую карточку, чтобы пе
рейти к следующей итерации и освободить место на доске. И в обоих случаях
срабатывает обратная связь.
ВЕДЕНИЕ СЛОВАРЯ ТЕРМИНОВ ПРОЕКТА
Как только вы начнете обсуждать требования, пользователи и знатоки пред
метной области тотчас воспользуются определенными терминами, имеющими
для них конкретный смысл. Они, например, могут проводить различие между
Кульминационный момент интермедии Мистер Креозот в исполнении англий
https: / /www.youtube.com/
wa tch ?v=GxRnenQYG7 I.
3
ской группы комиков "Монти Пайтон"; см. по адресу
Гnава 8 • До начаnа проекта
306
понятиями "клиент" и "заказчик", поэтому в системе нецелесообразно пользо
ваться тем или иным из этих понятий случайно.
Во избежание подобных недоразумений рекомендуется создать и вести сло
варь терминов проекта как единое место, где определяются все конкретные
термины, употребляемые в проекте. Все участники проекта, от конечных поль
зователей до персонала технической поддержки, должны пользоваться этим
словарем ради согласованности своих действий. При этом подразумевается, что
словарь терминов должен быть широко доступным, что служит веским доводом
в пользу онлайн-документации.
GФI§IФI
Пользуйтесь словарем терминов проекта
В проекте нельзя достичь успеха, если пользователи и разработчики назы
вают один и тот же предмет по-разному (или, что еще хуже, называют разные
предметы одинаково).
Другие разделы, связанные с данной темой
•
Тема
5.
Подходящее программное обеспечение, глава
1 "Философия
праг
матизма':
•
Тема
7.
Общайтесь!, глава
1 "Философия
•
Тема
11.
•
Тема
13. Прототипы
•
Тема
23.
Проектирование по контракту, глава
•
Тема
43.
Будьте осторожны, глава
7 "По
•
Тема
44.
Именование, глава
ходу кодирования':
•
Тема 46. Решение неразрешимых головоломок, глава 8 "До начала проекта':
•
Тема
Обратимость, глава
2
прагматизма':
"Прагматичный подход".
и памятные записки, rлава
52. Доставляйте
7 "По
2 "Прагматичный
4 "Прагматичная
подход".
паранойя':
ходу кодирования".
своим пользователям удовольствие, глава
9
"Праг
матичные проекты".
Упражнения
33.
Какие из перечисленных ниже требований, вероятнее всего, окажутся ис
тинными? Переформулируйте, если это возможно, не истинные требования,
чтобы они стали более полезными.
1)
2)
Время реакции должно быть меньше
3)
Приложение должно быть организовано в виде целого ряда внешних про
-500
мс.
У модальных окон должен быть серый фон.
цессов и внутреннего сервера.
Тема 46 • Реwение неразреwимых головоломок
4)
307
Если пользователь введет нечисловые символы в числовое поле, начнется
мигание фона этого поля, а введенные данные будут отвергнуты.
5)
Код и данные для данного встроенного приложения должны вписываться
в пределы
32 Мбайт.
Задачи
•
Можете ли вы сами воспользоваться программой, которую пишете? Мож
но ли иметь ясное представление о требованиях без возможности самому
пользоваться написанной программой?
•
Выберите задачу, не связанную с вычислительной техникой и требующую
безотлагательного решения в настоящий момент. Составьте требования
для решения этой задачи.
li@fpt@
РЕШЕНИЕ НЕРАЗРЕШИМЫХ ГОЛОВОЛОМОК
Гордий, царь Фригии, однажды завязал такой узел,
который никому не удавалось развязать. Считалось,
что тот, кто разгадает тайну гордиева узла, будет
править Азией. И вот явился Александр Македонский
и разрубил гордиев узел мечом на куски. Это была всего
лишь иная интерпретация требований. И в конечном
счете он действительно правил большей частью Азии.
Время от времени вы обнаруживаете, что оказались посредине проекта, и
вам приходится решать по-настоящему трудную головоломку
-
техническую
задачу, с которой вы не можете справиться, или фрагмент кода, написать кото
рый оказалось труднее, чем вы думали. Разрешить возникшее затруднение вроде
бы невозможно, но так ли это трудно сделать, как кажется на первый взгляд?
Рассмотрим настоящие головоломки, состоящие из фигурных кусочков де
рева, ковкого металла или пластмассы, которые обычно дарят детям на Рождес
тво или которые можно найти среди распродаваемых домашних вещей. Чтобы
решить такую головоломку, достаточно снять кольцо, разместить Т-образные
кусочки в коробке или сделать что-нибудь друтое.
Итак, вы тянете за кольцо или пытаетесь разместить Т-образные кусочки в
коробке и тотчас убеждаетесь, что очевидные решения здесь не годятся. Решить
головоломку таким способом нельзя. Но очевидность этого вывода не останав
ливает людей в их попытках делать то же самое снова и снова, надеясь, что та
ким способом удастся разгадать головоломку.
308
Глава 8 • До начала проекта
Решение, конечно, лежит где-то в другом месте. Секрет решения любой голо
воломки состоит в том, чтобы выявить настоящие (а не мнимые) ограничения и
найти решение с их учетом. При этом одни ограничения абсолютны, а другие
-
лишь предубеждения. Абсолютные ограничения должны непременно учитывать
ся, какими бы неугодными или нелепыми они ни были. Но, с другой стороны,
некоторые очевидные ограничения могут вообще оказаться не настоящими (что
и доказал на деле Александр Македонский). Такими же коварными могут ока
заться и многие задачи в разработке программного обеспечения.
СТЕПЕНИ СВО60ДЫ
Модное выражение "творческое, нешаблонное мышление" побуждает нас
распознавать ограничения, которые могут оказаться не таковыми, и пренебречь
ими. Но эта фраза не совсем точна. Так, если шаблон
-
это граница ограниче
ний и условий, то нужно найти такой шаблон, который может оказаться значи
тельно большим, чем кажется на первый взгляд.
Самое главное в разгадывании головоломок
-
уметь распознавать наклады -
ваемые ограничения и имеющиеся степени свободы, поскольку именно в них
находится решение. Некоторые головоломки столь эффективны именно потому,
что, разгадывая их, можно слишком легко отклонить потенциальные решения.
Например, сможете ли вы соединить все точки на приведенном ниже рисун
ке таким образом, чтобы вернуться в исходную точку, проведя всего лишь три
прямые линии, не поднимая ручку от бумаги и не возвращаясь по своим следам
назад (см.
Math
Pиzzles
&
Gaтes [Но192])?
• •
• •
Необходимо преодолеть любые предубеждения и проверить, являются ли
они настоящими, незыблемыми ограничениями . И дело не в том, мыслите ли
вы шаблонно или нешаблонно, а в том, как найти шаблон, выявив тем самым
настоящие ограничения.
Вместо того чтобы мыслить нешаблонно, находите шаблон
Столкнувшись с трудноразрешимой задачей, перечислите все возможные
пути, которые опробовали прежде. Не отвергайте ни одного из этих путей, ка
ким бы бесполезным или нелепым он ни казался. Затем пройдитесь по списку
всех путей и поясните, почему нельзя выбрать тот или иной путь. Насколько вы
в этом уверены и сможете ли вы это доказать?
Тема 46 • Решение неразрешимых головоломок
Обратимся к троянскому коню
-
309
эпическому примеру решения труднораз
решимой задачи. Как войску проникнуть незаметно в укрепленный стенами
город? Можно побиться об заклад, что решение пробиться через ворота было
сразу отвергнуто как самоубийственное.
Разделите свои ограничения по категориям и приоритетам. Когда столяры
приступают к работе, они отрезают сначала самый длинный кусок, затем из ос
тавшегося дерева
-
куски покороче. Аналогично требуется выявить сначала са
мые жесткие ограничения и подогнать под них все остальные. Между прочим,
решение упомянутой выше головоломки с четырьмя точками, соединяемыми
тремя прямыми линиями, приведено в конце приложения с решениями неко
торых задач.
Идите своим путем!
Иногда приходится работать над задачей, которая кажется намного труднее,
чем думалось изначально. Возможно, при этом возникает ощущение, что был
выбран неверный путь и должно быть какое-то более простое решение! А мо
жет быть, трудноразрешимая задача возникла на завершающей стадии работы
над проектом, и вы уже отчаялись довести свою систему до работоспособного
состояния.
Это идеальный момент отвлечься немного на что- нибудь другое, например,
пойти на прогулку с собачкой или просто поспать.
Ваш мозг осознает стоящую перед вами задачу, но на самом деле он немного
глуповат (только без обид). Поэтому самое время задействовать ваш настоящий
ум
-
эту поразительную ассоциативную нейронную сеть, скрывающуюся в под
сознании. И вы будете удивлены, как часто в вашем уме возникает ответ, когда
вы намеренно отвлекаетесь от мучающей вас задачи.
На первый взгляд, все это кажется слишком таинственным, но на самом деле
это совсем не так. В журнале Psychology Today4 по этому поводу сообщается сле
дующее:
Откровенно говоря, люди, отвлекавшиеся от решения сложной задачи,
добивались больших успехов, чем люди, которые прилагали для этого
сознательные усилия.
Если вы по-прежнему стремитесь отложить на время решение задачи, то сле
дующий наилучший шаг, вероятно, состоит в том, чтобы найти кого-нибудь и
пояснить ему свои трудности. И зачастую отвлечение просто на беседу с кем
нибудь приводит к прозрению.
4
См. по адресу https: / /www.psychologytoday.com/us/Ыog/your-brain-work/
201209/stop-trying-solve-proЫems.
Глава 8 • До начала проекта
310
Беседуя с кем-нибудь, дайте ему возможность задать вопросы, аналогичные
перечисленным ниже.
•
Почему вы решаете эту задачу?
•
Какие преимущества дает ее решение?
•
Связаны ли возникшие у вас трудности с крайними случаями? Можно ли
их исключить?
•
Есть ли более простая родственная задача, которую вы могли бы решить?
Это еще один характерный пример употребления на практике метода рези нового утенка.
СУДЬБА БЛАГОВОЛИТ ПОДГОТОВЛЕННОМУ УМУ
Известный французский ученый-микробиолог Луи Пастер как-то сказал:
"Что касается наблюдения,
то судьба благоволит подготовленному уму".
Это высказывание справедливо и для решения задач. Чтобы дойти до момен
тов прозрения, необходимо бессознательно накопить немало сырого материала;
предыдущий опыт может способствовать выработке правильного решения.
Чтобы дать своему уму необходимую пищу для размышлений, лучше всего,
когда вы выполняете свою повседневную работу, проанализировать отзывы о
том, что работает и что не работает. Для этого удобно вести технический днев
ник, как пояснялось в разделе "Тема
22.
Технические дневники" главы
3 "Основ
ные инструментальные средства". И никогда не забывайте совет, начертанный
на обложке книги The Hitchhiker's Guide to the Galaxy5: НЕ ПАНИКУЙ!
Другие раэдель1, связанные с данной темой
На эту тему Энди написал целую книгу под названием
45.
Pragmatic Thinking
and Learning: Refactor Your Wetware [Hun08].
5
Научно-фантастический роман английского писателя Дугласа Адамса (Douglas Adams;
в русском переводе
-
Автостопом по галактике), по мотивам которого была создана
одноименная компьютерная игра и целый телесериал.
-
Примеч. пер.
Тема 47 • Совместная работа
311
Задачи
•
Тщательно проанализируйте любую трудную задачу, которую вам прихо
дится решать в настоящее время. Удастся ли вас разрубить этот гордиев
узел? Вынуждены ли вы поступать именно таким образом и следует ли это
вообще делать?
•
Представляли ли вы себе все множество ограничений, когда отдавали на
подпись свой текущий проект? Применимы ли они до сих пор и верна ли
по-прежнему их интерпретация?
l1@fiQ
СОВМЕСТНАЯ РАБОТА
"Мне никогда не встречался человек, желающий
прочитать
17 тысяч
страниц документации,
и если бы такой человек нашелся, я бы его убил,
чтобы удалить его из генофонда".
Джозеф Костелло, президент компании Саdепсе Desigп Systeтs
Это был один из тех "невозможных" проектов, о которых вам, вероятно, при
ходилось слышать как о воодушевляющих и одновременно ужасающих. Сущест
вование морально устаревшей системы приходило к концу, а оборудование было
физически изношено, и поэтому совершенно новая система была призвана заме
нить старую в точном соответствии с (зачастую недокументированным) режи
мом ее работы. Через эту систему проходили многие сотни миллионов долларов
чужих людей, а ее новая версия должна была быть создана от начальной стадии
проектирования и до конечной стадии развертывания в считанные месяцы.
Именно тогда и познакомились Энди и Дэйв
-
авторы этой книги как участ
ники столь невозможного проекта с нелепыми предельными сроками выполне
ния. Шумному успеху этого проекта способствовало лишь одно обстоятельство:
специалист, который должен был управлять данной системой годами, сидел в
своем кабинете прямо напротив нашего похожего на чулан для метел помеще
ния, где мы занимались разработкой. Так что он был постоянно доступен для
вопросов, уточнений, решений и демонстраций промежуточных результатов
нашей работы.
На страницах данной книги мы уже не раз рекомендовали работать в тесном
контакте с пользователями, считая их частью команды разработчиков. В своем
первом совместном проекте мы практиковали то, что теперь можно было бы
назвать парнь1м или групповым программированием, когда один программист
набирает исходный код, тогда как другой программист или несколько членов
команды комментируют, анализируют и решают задачи вместе с ним. Это весь-
312
Глава 8 • До начала проекта
ма эффективный способ совместной работы, заменяющий бесконечные сове
щания, памятные записки и раздутую до бюрократических размеров докумен тацию, которая может похвалиться лишь своим весом, а не полезностью . Под
совместной работой мы подразумеваем следующее: не просто задавать вопросы,
вести дискуссии и делать замечания, но делать все это непосредственно по ходу
программирования.
Здкон Конвея
В 1967 году Мелвин Конвей выдвинул в своей статьей How do Coтmittees
lnvent? [Con68] следующую идею, которая затем стала называться законом
Кон вея:
"Организации, проектирующие системы, ограничиваются проектны
ми решениями, копирующими структуру связей в этих организациях'~
Таким образом, социальные структуры и каналы связи команды разработчи
ков с их организацией отражаются в проектируемом приложении, веб-сай
те или ином программном продукте. Различные исследования эмпирически
подтвердили эту идею. И мы можем засвидетельствовать, что неоднократно
наблюдали действие закона Конвея на практике. Например, в одних коман
дах, члены которых вообще не общаются друг с другом, проектируются ра
зобщенные системы, а командах, разделенных надвое, получаются проекты
типа "клиент-сервер'~
Исследования эмпирически подтвердили и обратный принцип: структуру
своей команды можно сознательно организовать по аналогии с требующей
ся структурой исходного кода. Например, в географически распределенных
командах проявляется тенденция к разработке программного обеспечения,
носящего более модульный и распределенный характер.
Но самое главное
-
команды разработчиков, включающие в себя пользо
вателей, будут производить программное обеспечение, ясно отражающее
их непосредственное участие в разработке. И это будет отражаться даже на
тех командах, которые не особенно заботятся о привлечении пользовате
лей к разработке программного обеспечения.
ПАРНОЕ ПРОГРАММИРОВАНИЕ
Парное программирование является одной из тех норм практики экстремаль
ного программирования, которые нашли широкое распространение за его пре
делами. При парном программировании один разработчик вводит исходный код
на клавиатуре, а другой анализирует введенный код. Они совместно работают
над решением одной задачи и могут по мере надобности периодически меняться
своими обязанностями .
Тема 47 • Совместная работа
313
Парное программирование дает немало преимуществ. Разные люди привно
сят в него разную подготовку и опыт, различные методы и подходы к решению
задач с разной степенью сосредоточенности внимания на любой конкретной за
даче. В частности, разработчик, вводящий исходный код с клавиатуры, должен
быть сосредоточен на рядовых подробностях синтаксиса и стиля программи
рования, тогда как другой разработчик волен рассматривать общие вопросы в
пределах решаемой задачи. И хотя такое различие может показаться незначи
тельным, не следует забывать, что умственные способности каждого человека в
той или иной мере ограничены. Так, возня с ключевыми словами и оператора
ми, неохотно принимаемыми компилятором, отнимает немало вычислительной
мощности мозга. Работа же в паре с другим разработчиком позволяет в немалой
степени задействовать его умственные способности в процессе решения задачи.
Как говорится, один ум хорошо, а два
-
лучше.
Присущее данной методике давление со стороны коллеги в паре помогает
преодолевать моменты слабости и бороться с дурными привычками присваи
вать переменным имена вроде
foo.
Когда за вашими действиями активно на
блюдают, вы в меньшей степени склонны прибегать к потенциально постыдным
ухищрениям ради достижения цели кратчайшим путем. И это также приводит в
итоге к повышению качества программного обеспечения.
ГРУППОВОЕ ПРОГРАММИРОВАНИЕ
Но если два ума лучше, чем один, то не привлечь ли с десяток разных людей
к решению одной задачи, поручив одному из них набирать исходный код на
клавиатуре? Групповое программирование, несмотря на свое название, не под
разумевает толпы людей с факелами и кольями. Оно просто расширяет парное
программирование, чтобы в совместной работе принимали участие не только
два разработчика. Поборники данной методики сообщают о замечательных ре
зультатах группового решения трудных задач. В такие группы можно без особо
го труда ввести людей, которые не являются членами команды разработчиков, в
том числе пользователей, спонсоров проекта и тестировщиков.
На самом деле в нашем первом "невозможном" совместном проекте, о ко
тором речь шла ранее в этом разделе, мы считали привычным явлением, когда
один из нас набирал исходный код, а другой обсуждал текущий вопрос со спе
циалистом в предметной области данного проекта. По существу, мы работали
группой из трех человек. Групповое программирование можно рассматривать
как тесное сотрудничество при активном программировании.
Что СЛЕДУЕТ дЕЛАть?
Если в настоящий момент вы программируете индивидуально, опробуйте
методику парного программирования. Выделите на это как минимум две не
дели, по несколько часов в день, поскольку эта методика может показаться вам
Глава 8 • До начала проекта
314
поначалу непривычной. Для выработки новых идей в режиме мозгового штур
ма или решения щекотливых вопросов можно опробовать методику группового
программирования. Если вы уже практикуете парное или групповое програм
мирование, то привлекаете ли вы к совместной работе только разработчиков
или же допускаете участие в ней пользователей, спонсоров, тестировщиков и
прочих лиц?
Как и при всяком другом сотрудничестве, необходимо руководствоваться как
техническими, так и человеческими особенностями. В приведенных ниже неко
торых рекомендациях поясняется, с чего следует начать.
•
Пишите код, не выпячивая свое "я". Тут дело не в том, кто самый лучший,
поскольку у каждого из нас свои достоинства и недостатки.
•
Начинайте с малого. Привлеките к совместной работе
4-5
человек или же
начните лишь с нескольких пар, работающих вместе в течение коротких
периодов времени.
•
Критикуйте написанный код, а не его автора. Фраза "рассмотрим этот блок
кода" звучит намного лучше, чем фраза "ты ошибся':
•
Внимательно слушайте, пытаясь понять чужую точку зрения. Отличие от
вашей точки зрения еще не означает ее неправоту.
•
Почаще проводите ретроспективы, чтобы постараться работать лучше в
дальнейшем.
Программирование в одном и том же помещении или в удаленном режиме
индивидуально, в парах или группах
-
все это эффективные методы совместной
работы для решения насущных задач. Если вам и вашей команде приходилось
когда-нибудь применять какой-нибудь из этих методов на практике, попробуйте
поэкспериментировать с другими методами. Но не подходите прямолинейно к
внедрению выбранного метода. Ведь для каждого стиля разработки имеются оп
ределенные правила, предположения и руководящие принципы. Например, при
групповом программировании рекомендуется менять набирающего исходный
код разработчика через каждые
5-1 О
минут.
Почитайте литературу, а также изучите прочие материалы на данную тему,
чтобы уяснить преимущества и недостатки каждой упоминавшейся в этом раз
деле методики программирования. Возможно, стоит начать с простого упраж
нения в программировании, а не просто сразу опробовать выбранную методику
на самом трудном рабочем коде. Но, как бы вы ни поступили, примите к сведе
нию еще один завершающий совет.
Не вникайте в исходный код в одиночку
Тема 48 • Сущность гибкости
315
l1@фJi:) СУЩНОСТЬ ГИБКОСТИ
"Вы все еще пользуетесь этим словом, но я не думаю,
что оно означает именно то, что вы подразумеваете''.
Иниго Монтойя6
Прилагательное "гибкий" обозначает, как именно сделать что-нибудь. Так,
можно быть гибким разработчиком или членом команды, в которой приняты
нормы практики гибкой разработки, или же команды, гибко реагирующей на
перемены и провалы. Гибкость
-
Гибкость -
-
это ваш стиль, а не вы сами.
это не существительное, а порядок
выполнения действий
На момент написания данной книги прошло почти двадцать лет после при
нятия Манифеста гибкой разработки программного обеспечения 7 , и с тех пор
многие разработчики успешно применяют его ценные положения на практике.
Мы наблюдаем немало чудесных команд, находящих способы принять ценности
гибкой разработки и руководствоваться ими в том, что они делают и как они
изменяют то, что делают.
Но мы также наблюдаем и обратную сторону гибкости: явное стремление ко
манд и компаний к готовым решениям, где гибкость упакована в привлекатель
ную обертку. И многие консультанты и компании будут только рады продать
то, что хотят их клиенты. Мы видим, что в компаниях принимается все больше
уровней управления, формальной отчетности, узкой специализации разработ
чиков и должностей с забавными названиями, которые просто означают чьи-то
обязанности следить за работой других с папкой-планшетом и хронометром8 .
И мы считаем, что многие просто утратили ясное представление об истинном
назначении гибкости, поэтому нам хотелось бы вернуть их к основным ценнос
тям гибкой разработки.
Напомним основные положения Манифеста гибкой разработки программного
обеспечения, где перечисленные приведенные ниже ценности.
"Мы раскрываем лучшие способы разработки программного обеспече
ния, выполняя ее сами и помогая делать это другим. В своей работе мы
пришли к признанию следующих ценностей.
6
Inigo Montoya - вымышленный персонаж романа The Princess Bride (Принцесса-невес
та) современного американского писателя Уильяма Голдмана.
См. по адресу https: / /agilemanifesto. org.
о том, насколько неудачным может оказаться такой подход к разработке про
граммного обеспечения, см. The Tyranny of Metrics [Mull8] .
7
8 Подробнее
Глава 8 • До начала проекта
316
•
Отдельные личности и взаимодействия превыше процессов и инструмен тальных средств.
•
Работоспособное программное обеспечение превыше всеобъемлющей до
кументации.
•
Сотрудничество с заказчиками превыше согласования контрактов.
•
Реагирование на перемены превыше следования плану.
Это означает, что, несмотря на ценность элементов, указанных спра
ва в каждом из перечисленных выше положений, мы больше ценим эле
менты, указанные слева".
Всякий, предлагающий нечто, явно повышающее важность элементов, ука
занных справа в каждом из положений Манифеста гибкой разработки програм
много обеспечения, по сравнению с элементами, указанными слева, на самом
деле не разделяет ценности наших и авторов этого документа. А всякий, пред
лагающий готовое решение, просто не читал вводную часть этого документа.
К заявленным в нем ценностям побуждает и извещает о них действие, раскры
вающее лучшие способы производства программного обеспечения. Это не ста
тический документ, а предложения относительно порождающего процесса.
ГИБКИЙ ПРОЦЕСС ВООБЩЕ НЕВОЗМОЖЕН
В действительности всякий раз, когда кто-нибудь говорит "сделайте это
-
и это и будет гибко", он не прав по определению. Гибкость, как в физическом
мире, так и в разработке программного обеспечения,
-
это своевременное ре
агирование на неизвестность и перемены, возникающие тотчас, как только вы
приступаете к делу. Газель не бежит по прямой линии, а гимнаст каждую се
кунду вносит сотни корректив в свои движения, реагируя на изменения в ок
ружающей его среде, чтобы допустить минимум ошибок в расположении своих
конечностей.
Это же относится к командам и индивидуальным разработчикам. Для разра
ботки программного обеспечения не существует единого плана. Об этом упорно
твердит упомянутый выше манифест и перечисленные в нем ценности, и все
они имеют отношение к сбору ответной реакции и реагированию на нее. Эти
ценности сообщают не о том, что нужно делать, а о том, к чему следует стре
миться, решившись что-то делать.
Такие решения всегда принимаются в определенном контексте, поскольку
они зависят от вас самих, характера вашей команды, разрабатываемого прило
жения, применяемых инструментальных средств, вашей организации, вашего
заказчика, внешнего мира и невероятно большого числа других фактов, одни из
которых более важны, чем другие. Никакой фиксированный, статический план
действий не позволит преодолеть подобную неопределенность.
Тема 48 • Сущность гибкости
317
Что ЖЕ тогдА дЕлАть?
Никто не скажет вам, что нужно делать. Но мы думаем, что можем подска
зать вам общее направление, в котором следует двигаться к желанной цели. Все
сводится к тому, как справиться с неопределенностью. В упомянутом выше ма
нифесте предлагается собирать ответную реакцию и действовать соответствен
но. Итак, рецепт гибкой работы состоит в следующем.
1.
Выясните, где находитесь.
2.
Сделайте наименьший значимый шаг в нужную сторону.
3.
Оцените, где вы оказались, и исправьте все, что нарушили.
Повторяйте приведенные выше действия до тех пор, пока не завершите на
меченную работу. Пользуйтесь данным рецептом рекурсивно на каждом уровне
всей своей деятельности. Иногда даже самое тривиальное на первый взгляд ре
шение становится важным, когда вы собираете ответную реакцию, как показано
в приведенном ниже примере.
"Теперь мне нужен код, чтобы получить владельца счета.
let user = accountOwner(accountID);
М-да". имя
user кажется бесполезным. Изменю-ка я его owner.
let owner = accountOwner(accountID);
Но теперь это кажется несколько избыточным. Что я на самом деле
пытаюсь здесь сделать? В пользовательской истории говорится, что
этому лицу следует отправить сообщение по электронной почте, по
этому мне нужно найти адрес его электронной почты. Может быть,
сам владелец счета мне вообще не нужен?"
let email = emailOfAccountOwner(accountID);
Применив эту цепь обратной связи на довольно низком уровне именования
переменной, мы фактически улучшили архитектуру всей системы, сократив свя
зывание данного фрагмента кода с фрагментом, который оперирует счетами.
Цепь обратной связи применима и на наивысшем уровне проекта. Одна из
наших наиболее успешных работ была сделана, когда мы приступили к прора
ботке требований клиента, предприняли один шаг и осознали, что все, что мы
предполагали делать,
-
не нужно, и что самое лучшее решение вообще не тре
бовало программного обеспечения.
Применение цепи обратной связи можно расширить за пределы одного про
екта. Команды должны применять ее для анализа своих процессов и того, на
сколько хорошо они работают. Те команды, которые не экспериментируют пос
тоянно со своими процессами, нельзя считать гибкими.
Глава 8 • До начала проекта
318
И ЭТО ДВИЖЕТ ПРОЕКТ
В разделе "Тема
8.
Сущность качественного проектирования" главы
2 "Праг
матичный подход" утверждалось, что мерой качества проектирования может
служить простота изменения его результата: грамотное проектирование дает
нечто, что изменить легче, чем при неграмотном проектировании. И в этом об
суждении гибкости поясняется, почему это именно так.
Сначала вы вносите изменения, а затем обнаруживаете, что они вам не нра
вятся. Как пояснялось в п.
3
приведенного выше рецепта, вам придется испра
вить все, что вы нарушили. Чтобы цепь обратной связи действовала эффективно,
такое исправление должно быть как можно более безболезненным. В противном
случае возникнет искушение оставить все как есть, без исправления. Подробнее
о последствиях такого решения речь шла в разделе "Тема
ропия" главы
1 "Философия
3.
Программная энт
прагматизма': Для того чтобы вся рассматриваемая
здесь методика гибкой разработки оказалась пригодной, следует практиковать
качественное проектирование, поскольку именно оно способствует простоте
изменений. Если внести изменения нетрудно, то можно, не колеблясь, вносить
соответствующие коррективы на каждом уровне. Это и есть гибкость.
Другие разаелы, связанные с аанной темой
•
Тема
27.
Не опережайте свет фар вашего автомобиля, rлава
4 "Прагматич
ная паранойя".
•
Тема
40.
Рефакторинг, rлава
7 "По
ходу кодирования".
•
Тема
50.
Кокосами не обойтись, в rлаве
9
"Прагматичные проекты':
зааачи
Простая цепь обратной связи подходит не только для разработки програм
много обеспечения. Обдумайте другие решения, которые вам приходилось
принимать в последнее время. Можно ли было бы их улучшить, размыш
ляя над тем, как бы удалось их отменить, если бы дело приняло нежела
тельный оборот? Можете ли вы придумать способы улучшить то, что дела
ете, собирая ответную реакцию и соответственно реагируя на нее?
Глдвд
9
По ходу работы над проектом разработчикам приходится отступать от воп
росов, связанных с индивидуальными философскими воззрениями и принципа
ми программирования, переходя к обсуждению более общих вопросов масштаба
целого проекта. Мы не собираемся здесь вдаваться в особенности управления
проектами, но все же рассмотрим ряд очень важных областей, способствующих
удачному или неудачному завершению любого проекта.
Как только над проектом станет работать не один человек, а команда, придет
ся установить ряд основных правил и поручить выполнение соответствующих
частей проекта конкретным лицам. В разделе "Прагматичные команды" будет
показано, как это делается с учетом прагматичной философии.
Назначение конкретной методики разработки программного обеспечения
-
помочь людям работать вместе. Делаете ли вы и ваша команда то, что вам под
ходит, или же только размениваетесь на тривиальные поверхностные артефак
ты, не извлекая настоящих выгод для себя и своей команды? Ответы на этот
и другие насущные вопросы разработки программного обеспечения даются в
разделе "Кокосами не обойтись", где раскрываются также секреты успешной ра
боты над проектами.
И, разумеется, ничто из этого вообще не важно, если вы не в состоянии вы
пускать программное обеспечение согласованно и надежно. А этому способс
твует волшебная троица: контроль версий и тестирование исходного кода, а так
же автоматизация процесса разработки, как поясняется в разделе "Начальный
набор инструментальных средств программиста-прагматика".
В конечном счете успешность завершения проекта оценивается с точки зре
ния его спонсора. И здесь важно понимать, что значение имеет прежде всего
восприятие успеха. Поэтому в разделе "Доставляйте своим пользователям удо
вольствие" показывается, как удовлетворить каждого спонсора проекта.
Последний совет, приведенный в данной книге, является прямым следствием
всех остальных советов. В разделе "Гордость и предубеждение" поясняется, как
сдавать проект заказчику на подпись с гордостью за проделанную работу.
Глава 9 • Прагматичные проекты
320
l1MtJQ) ПРАГМАТИЧНЫЕ КОМАНДЫ
"В группе
L Штоффель
надзирает за шестью
первоклассными программистами.
Трудности руководства ими можно грубо сравнить
с выпасом выводка котов".
Washington Post Magazine
Даже в
1985
от
9
июня
1985 г.
году шутка по поводу выпаса выводка котов считалась уста
ревшей. А ко времени выхода в свет первого издания данной книги под конец
столетия она вообще стала анахронизмом, хотя до сих пор остается расхожей,
поскольку в ней есть доля правды. Программисты действительно похожи чем-то
на котов: они образованы, своевольны, самоуверенны, независимы и зачастую
прославлены в сети.
В этой книге до сих пор рассматривались прагматичные методики, помога
ющие отдельным программистам стать лучше. Могут ли эти методики приго
диться командам, пусть даже состоящим из своевольных и независимых людей?
Однозначно могут! Преимущества быть прагматичным программистом много
кратно усиливаются, когда программист работает в прагматичной команде.
На наш взгляд, команда
-
это небольшая, самостоятельная и в основном ус
тойчивая организационная единица. Пятьдесят людей
па 1•
-
это не команда, а тол -
Команды, члены которых постоянно привлекаются к выполнению чужих
заданий и не знают друг друга, вообще не считаются командами. Они похожи на
незнакомых людей, временно столпившихся под козырьком автобусной останов
ки в дождливый день.
Прагматичная команда невелика и состоит не более, чем из
10-12
человек, ко
торые редко приходят и уходят. Все хорошо знакомы и полагаются друг на друга.
Поддерживайте небольшие, устойчивые команды
В этом разделе будет вкратце показано, как применять прагматичные мето
дики к командам в целом. Приведенные здесь заметки служат лишь отправной
точкой. Как только образуется группа прагматичных разработчиков, работаю
щих в благоприятных условиях, они быстро выработают и уточнят пригодную
для них динамику работы в команде. Итак, изложим материал предыдущих глав
иначе с точки зрения команд.
1
По мере увеличения численного состава команд связи между программистами растут
со скоростью О(п 2 ), где п - число членов команды. В крупных командах связь начинает
ослабевать и становится неэффективной.
Тема 49 • Прагматичные команды
321
НИКАКИХ РАЗБИТЫХ ОКОН
Качество
-
это дело всей команды. Даже самому прилежному разработчику,
работающему в беспечной команде, будет трудно поддерживать свой энтузиазм,
необходимый для решения пустячных задач. Трудности еще больше усугубляют
ся, если команда активно отговаривает такого разработчика не тратить время
на такие пустяки.
Команды в целом не должны мириться с разбитыми окнами, т.е. с теми мел
кими несовершенствами, которые некому устранить. Команда обязана взятьна
себя ответственность за качество разрабатываемого ею программного продук
та, поддерживая тех разработчиков, которые ясно понимают принцип "никаких
разбитых окон", описанный в разделе "Тема
3.
Программная энтропия" главы
1
"Философия прагматизма': а также помогая уяснить данный принцип тем, кто
еще не открыл его для себя.
В некоторых командных методологиях предусматривается "ответственный за
качество': которому команда поручает отвечать за качество выпускаемого про
граммного продукта. Но это нелепо, поскольку качество может быть достигнуто
лишь в результате индивидуального вклада всех членов команды. Качество за
кладывается как основание, а не прикрепляется болтами.
СВАРЕННЫЕ ЛЯГУШКИ
Помните, как в разделе "Тема
4.
Суп из камней и вареные лягушки" главы
1
"Философия прагматизма" упоминалось о вымышленной лягушке в кастрюле с
водой? Она не замечает постепенное изменение своего окружения и в конечном
итоге оказывается сваренной. То же самое может произойти и с отдельными
людьми, потерявшими бдительность. Ведь не так-то просто следить за всем ок
ружением в самый разгар работы над проектом.
Команды могут очень легко свариться целиком, как лягушки. Ее члены могут
посчитать, что возникший вопрос должен решить кто-то другой, а отвечать за
внесение запрашиваемого пользователем изменения должен руководитель ко
манды. И даже команды с наилучшими намерениями могут предавать забвению
существенные изменения в своих проектах.
С подобными явлениями следует бороться, поощряя всех членов команды
активно и постоянно контролировать изменения в окружающей их среде. Необ
ходимо быть начеку, следя за расширением рамок проекта, сокращением сроков
выполнения работ, внедрением дополнительных функциональных возможнос
тей, появлением новых сред
-
другими словами, за всем, что первоначально
не было ясно и понятно. Кроме того, необходимо следить за количественными
показателями новых требований 2 • Команда не должна отвергать изменения с по2
Для этой цели диаграмма выгорания подходит лучше, чем диаграмма сгорания. Пользу
ясь диаграммой выгорания, можно ясно видеть, как дополнительные функциональные
средства меняют цели и намерения по ходу проекта.
Гnава 9 • Прагматичные проекты
322
рога, а должна осознавать, что они все равно происходят. В противном случае
она рискует свариться в кипящей воде, как лягушка.
ПЛАНИРОВАНИЕ ПОПОЛНЕНИЯ БАГАЖА ЗНАНИЙ
В разделе "Тема
6.
Ваш багаж знаний" главы
1
"Философия прагматизма"
были рассмотрены способы своевременного пополнения багажа индивидуаль
ных знаний. Команды, стремящиеся к успеху, должны анализировать и попол
нять багаж своих знаний и умений.
Если ваша команда серьезно относится к усовершенствованиям и нововве
дениям, их следует планировать. Попытка сделать что-нибудь, когда настанет
удобный момент, означает, что это не произойдет никогда. С каким бы видом за
дела, списка задач или порядка работ ни приходилось иметь дело, его не следует
откладывать на будущую стадию разработки. Ведь команда работает не только
над новыми функциональными средствами. Ниже перечислены некоторые из
возможных путей пополнения командой своего багажа знаний.
•
Сопровождение прежних систем. Несмотря на то что всем нравится ра
ботать в новой с иголочки системе, вполне возможно, что придется пора
ботать и над сопровождением старой системы. Нам встречались команды,
пытавшиеся отложить такую работу в долгий ящик. Если команда обязана
выполнять такие задачи, она должна выполнять их точно и в срок.
•
Обсуждение и уточнение процессов. Непрерывное совершенствование
может происходить только в том случае, если есть время оглянуться и
выяснить, что работает и что не работает, а затем внести необходимые
изменения (см. раздел "Тема
48.
Сущность гибкости" главы
8
"До начала
проекта"). Слишком много команд оказываются настолько занятыми вы
черпыванием воды из тонущей лодки, что не имеют времени на устране
ние течи. Планируйте работы по выявления и устранению неполадок.
•
Экспериментирование с новыми технологиями. Не внедряйте новые
технологии, каркасы или библиотеки только потому, что это делают все,
или же на основании увиденного на конференции либо прочитанного в
Интернете. Технологии, претендующие на внедрение, следует проверять с
помощью прототипов. Поставьте соответствующие задачи в график вы
полнения работ, опробуйте новые технологии и проанализируйте получен
ные результаты.
•
Обучение и совершенствование навыков. Личное обучение и совершенс
твование навыков служит отличной отправной точкой, хотя многие навы
ки оказываются более эффективными, если применяются на уровне ко
манды. Планируйте подобные мероприятия, будь то в виде неформальных
встреч или более формальных учебных занятий.
Тема 49 • Прагматичные команды
323
Gфt§l:r1 Планируйте и воплощайте в жизнь пополнение багажа знаний
ВНЕШНЕЕ ОБЩЕНИЕ КОМАНДЫ
Очевидно, что разработчики могут общаться друг с другом в своей команде.
Свои рекомендации по поводу того, как облегчить общение, мы дали в разделе
"Тема
7.
Общайтесь!" главы 1 "Философия прагматизма': Но при этом очень лег
ко забыть, что команда сама присутствует в конкретной организации. Поэтому,
как организационная единица, команда должна свободно общаться с остальным
миром.
Для посторонних наихудшими являются замкнутые и скрытные проектные
команды. Они проводят совещания без всякого порядка, и на них никто не хо
чет говорить. Их обмен сообщениями по электронной почте и проектные доку
менты беспорядочны: у них нет двух одинаковых документов и единой употреб
ляемой терминологии.
Хорошие проектные команды заметно отличаются своей индивидуальнос
тью. Другие люди стремятся встретиться с такими командами на совещаниях,
поскольку они знают, что придут на хорошо подготовленное мероприятие, где
все участники чувствуют себя уютно. Такие команды составляют ясную, точную
и согласованную документацию и говорят одним голосом 3 • У них даже может
быть чувство юмора.
Имеется простой маркетинговый прием, помогающий командам общаться как
единое целое. Он состоит в том, чтобы сформировать фирменный стиль. Начи
ная проект, придумайте ему подходящее название
-
в идеальном случае взяв его
с потолка. (В прошлом мы называли свои проекты, например, попугаями-убий
цами, охотящимися на овец, разными оптическими иллюзиями, песчанками,
персонажами мультфильмов и мифическими городами.) Уделите полчаса, чтобы
придумать забавный логотип, а затем воспользуйтесь им в своем проекте. На
первый взгляд, такая рекомендация кажется нелепой, но на самом деле она дает
вашей команде возможность создать свою индивидуальность, а окружающему
миру
-
запомнить нечто, связанное с вашей работой.
НЕ ПОВТОРЯЙТЕСЬ
В разделе "Тема
9. DRY -
пороки дублирования" главы
2
"Прагматичный
подход" речь шла о том, как трудно исключить дублирование работы отдельны
ми членами команды. Такое дублирование приводит к напрасным затратам тру-
3
Команда говорит одним голосом с внешним миром; внутри команды настоятельно ре
комендуется проводить живые, активные дебаты. Ведь грамотные разработчики обычно
относятся весьма ревностно к своей работе.
Глава 9 • Прагматичные проекты
324
да и способно превратить сопровождение программного обеспечения в сущий
кошмар. В тех командах, где это происходит, зачастую проектируются разроз
ненные системы, у которых мало общего, но много дублирующихся функцио
нальных возможностей.
Хорошо налаженное общение в команде служит главным средством, помога
ющим избежать подобных осложнений. Под фразой "хорошо налаженное" здесь
понимается мгновенное и свободное общение без всяких трений. Это означает
возможность задать членам команды вопрос и почти мгновенно получить ответ.
Так, если команда совместно размещается в одном месте, для этого достаточно
высунуть голову из своей кабинки или в коридор. В командах, работающих в
удаленном режиме, возможно, придется полагаться на систему обмена сообще
ниями или другие электронные средства.
Если вам приходится целую неделю ждать совещания в команде, чтобы за
дать вопрос или поделиться положением своих дел, это может вызвать немало
трений 4 . Свободное общение без всяких трений означает простую и нецере
монную атмосферу в команде, позволяющую задавать вопросы, делиться своими
достижениями и затруднениями, открытиями и знаниями, а также оставаться в
курсе того, что делают ваши коллеги. Поддерживайте свою осведомленность обо
всем, что происходит в команде, чтобы соблюдать принцип
DRY.
ТРАССИРУЮЩИЕ ПУЛИ В КОМАНДЕ
Проектной команде приходится выполнять много разных заданий в различ
ных областях проекта, касающихся самых разных технологий. Для этого необ
ходимо уяснить исходные требования, спроектировать архитектуру, запрограм
мировать и протестировать клиентскую и серверную части разрабатываемой
системы. Существует типичное недопонимание, состоящее во мнении, что эти
виды деятельности и задания можно выполнять по отдельности и обособлен но,
-
хотя в действительности делать этого нельзя.
Некоторые методологии поддерживают самые разные роли и должности в
команде или создание совершенно отдельных специализированных команд. Но
недостаток такого подхода заключается в том, он вносит шлюзы и сдачи. И тогда
вместо плавного перехода от разработки к развертыванию образуются искусст
венные шлюзы, где работа команды останавливается. А сдачи работ вынуждены
ждать своего приема, утверждения, бумажной волокиты. Бережливые люди на
зывают это расточительством и поэтому стремятся активно исключить его.
Все эти разные роли и виды деятельности фактически являются разными
представлениями одной и той же задачи, и поэтому их искусственное разделе
ние может вызвать немало хлопот. Например, те программисты, которые отде
лены двумя или тремя уровнями от фактических пользователей написанного
4
Энди встречались команды, проводившие свои "ежедневные" летучки по пятницам.
Тема 49 • Прагматичные команды
325
ими кода, вряд ли понимают контекст, в котором используются результаты их
трудов. В итоге они не могут принимать обоснованные решения.
Мы рекомендуем пользоваться методом трассирующих пуль (см. раздел
"Тема
12.
Трассирующие пули" главы
2
"Прагматичный подход"), разрабатывая
отдельные, пусть небольшие и первоначально ограниченные функциональные
средства, которые проходят сквозь всю систему. И для этого потребуются все
ваше умение и опыт, чтобы применить данный метод в команде, где всем ее
членам (проектировщику
GUI
и взаимодействия с пользователем, администра
тору базы данных, контролеру качества и прочим) удобно и привычно работать
вместе. Применяя метод трассирующих пуль, можно довольно быстро реали
зовать очень мелкие фрагменты функциональных средств, чтобы немедленно
получить ответную реакцию, позволяющую судить, насколько хорошо команда
взаимодействует и доставляет результаты своих трудов. Благодаря этому созда
ется среда, в которой можно быстро и просто вносить изменения и настраивать
команду и процесс разработки.
Организовывайте полнофункциональные команды
Создавайте команды таким образом, чтобы разрабатывать код комплексно,
постепенно и итерационно.
АВТОМАТИЗАЦИЯ
Чтобы обеспечить согласованность и точность, лучше всего автоматизи
ровать все, что делает команда. Зачем, например, разбираться со стандартами
форматирования кода, если текстовый редактор или интегрированная среда раз
работки может сделать это автоматически? Зачем проводить тестирование вруч
ную, если это можно делать автоматически в процессе непрерывной сборки?
Наконец, зачем выполнять развертывание вручную, если этот процесс можно
автоматизировать, чтобы надежно повторять его всякий раз, когда в этом воз
никнет потребность?
Автоматизация является существенной составляющей работы каждой про
ектной команды. Поэтому следует позаботиться о том, чтобы у команды было
достаточно навыков комплектации инструментальных средств для построения
и развертывания инструментальных средств, автоматизирующих разработку
проектов и развертывания в условиях эксплуатации.
ЗНАЙТЕ, КОГДА ОСТАНОВИТЬСЯ
Помните, что команды состоят из индивидуальностей. Дайте каждому члену
возможность проявить себя, а также обеспечьте их поддержу и возможность
вклада в проект. И тогда вам останется лишь бороться с искушением нанести
Глава 9 • Праrматичные проекты
326
еще немного краски, как художнику, упоминавшемуся в разделе "Тема
дящее программное обеспечение" главы
1 "Философия
5.
Подхо
прагматизма':
Другие разделы, связанные с данной темой
•
Тема
2.
Кот съел мой исходный код, глава
•
Тема
7.
Общайтесь!, глава
е Тема
12.
1 "Философия
Трассирующие пули, глава
глава
1 "Философия
прагматизма':
прагматизма".
2 "Прагматичный
подход':
•
Тема
19. Контроль версий,
3 "Основные инструментальные средства':
•
Тема
50.
Кокосами не обойтись.
•
Тема
51.
Начальный набор инструментальных средств программиста-праг
матика.
Задачи
•
Поищите успешные команды вне области разработки программного обес
печения. В чем причина их успешности? Пользуетесь ли вы какими-нибудь
процессами, обсуждавшимися в этом разделе?
•
Приступая к проекту в следующий раз, попытайтесь убедить его участни
ков сформировать свой особый фирменный стиль. Дайте своей организа
ции время привыкнуть к этой идее, а затем проведите быструю проверку,
чтобы выяснить, какие отличия внес новый фирменный стиль как в самой
команде, так и за ее пределами.
•
Вам, вероятно, приходилось решать задачи вроде следующей: "Если четы
рем рабочим требуется шесть часов, чтобы вырыть канаву, то сколько вре
мени для этого потребуется восьми рабочим?" Но какие реальные факты
могут повлиять на решение подобной задачи, если речь идет не о рабочих,
а о программистах? И сколько имеется вариантов фактически сократить
время выполнения подобной работы?
•
Прочитайте книгу Фредерика Брукса
ский человеко-месяц)
[Bro96] . В
The Mythical
Мап
Month
(Мифиче
качестве дополнительного задания приоб
ретите два экземпляра этой книги, чтобы читать ее в два раза быстрее.
Туземные обитатели одного острова никогда не видели прежде самолет и не
встречались с прилетевшими на нем чужеземцами . В обмен на право пользо
ваться их землей чужеземцы предоставили островитянам возможность наблю
дать за этими механическими птицами, которые целый день то прилетали, то
улетали со "взлетной полосы", принося на их родной остров невероятные мате
риальные ценности, иногда перепадающие туземцам. Чужеземцы упоминали о
Тема 50 • Кокосами не обойтись
327
чем-то вроде войны и сражения. Однажды все это кончилось тем, что чужезем
цы покинули остров, прихватив с собой свои чудесные богатства.
Отчаянно пытаясь вернуть подарок судьбы, островитяне восстановили ко
пию аэродрома с диспетчерской вышкой и прочим оборудованием, используя
местные материалы: лианы, скорлупы кокосового ореха, пальмовые ветки и т.п.
Но по какой-то непонятной им причине самолеты не прилетали, несмотря на то,
что островитяне все расставили по своим местам. А дело в том, что они сыми
тировали форму, а не содержание. Антропологи называют это карго-культом.
Разработчики программного обеспечения слишком часто оказываются в
роли этих незадачливых островитян. Ведь очень легко попасться в западню
карго-культа, вложив средства и труд в построение чисто внешней имитации,
надеясь вызвать скрывающиеся под ней волшебные силы, способные привести
ее в действие. Но, как и в первобытных карго-культах Меланезии 5 , бутафорский
аэродром, построенный из скорлупы кокосовых орехов, не может заменить со
бой настоящий аэропорт.
Нам, например, приходилось лично встречаться с командами, заявлявшими,
будто бы они пользуются методикой
Scrum
в своей работе. Но при более внима
тельном рассмотрении оказалось, что они проводили стоя ежедневные летучки
лишь один раз в неделю, а четырехнедельные повторяющиеся циклы нередко
превращались у них в шести - и даже восьминедельные циклы. Они считали это
нормальным, поскольку пользовались весьма распространенным инструмен
тальным средством "гибкого" планирования работ. На самом же деле они вкла
дывали средства и труд лишь в искусственные артефакты, суеверно твердя как
заклинание такие термины, как "летучка" или "итерация". Не удивительно, что
им не удавалось вызвать к жизни по-настоящему волшебные силы.
ВСЕ ДЕЛО В КОНТЕКСТЕ
Приходилось ли вам или вашей команде попадать в подобную западню?
Спросите себя: почему вы вообще пользуетесь данной конкретной методикой
разработки, каркасом, библиотекой или методикой тестирования? Действитель
но ли все это подходит для выполнения текущего задания и вам лично? А может
быть, все это было принято лишь потому, что применялось в каком-нибудь не
давнем проекте, история успеха которого была почерпнута из Интернета?
Ныне наблюдается тенденция внедрять у себя правила и процессы таких ус
пешных компаний, как
Spotify, Netflix, Stripe, GitLab
и пр. У каждой из них свой
взгляд на разработку программного обеспечения и руководство ею. Но давайте
рассмотрим контекст: разве вы работаете на тот же рынок, с теми же ограниче
ниями и возможностями, имеете аналогичный опыт и масштабы организации, у
вас аналогичные подходы к руководству и такая же культура, пользовательская
база и требования?
5 См.
по адресу https: / /ru. wikipedia. org/wiki/Kapгo-кyльт.
328
Гnава 9 • Праrматичные проекты
Не попадайтесь на эту удочку! Определенных артефактов, внешних структур,
правил, процессов и методов явно недостаточно .
Делайте то, что пригодно, а не то, что модно
А как узнать, что именно пригодно? Для этого достаточно воспользоваться
одним из самых основных прагматичных приемов, а именно:
Пробуйте!
Опробуйте саму идею в небольшой команде или ряде команд. Оставьте то,
что годится, и откажитесь от всего остального как расточительства или наклад
ных расходов. Никто не сможет принизить вашу организацию только потому,
что она действует иначе, чем компании
Spotify или Netflix,
и не следует приня
тым в них процессам, которые способствовали их успешному росту. Ведь через
несколько лет эти компании, созрев, упрочившись и продолжая расти дальше,
станут в очередной раз делать нечто иное. Именно в этом и кроется секрет их
успеха.
Один и тот ЖЕ ПОДХОД годится НЕ ВСЕМ
Назначение методологии разработки программного обеспечения
разработчикам работать вместе. Как пояснялось в разделе "Тема
гибкости" главы
8
48.
-
помочь
Сущность
"До начала проекта", не существует единого плана, которого
можно придерживаться, разрабатывая программное обеспечение, и особенно
того плана, который был составлен кем-то чужим в другой организации.
Многие обучающие программы на самом деле оказываются еще хуже, пос
кольку они основываются на способностях учащихся запоминать и соблюдать
правила. Но вам требуется совсем не это, а способность видеть дальше сущест
вующих правил и выгодно пользоваться имеющимися возможностями. Это сов
сем иной образ мышления, чем мнение вроде "так принято в методике
Lean, Kanban,
Scrum,
экстремального программирования, гибкой разработки .. ." и т.д.
Вместо этого следует взять все самое лучшее из любой методологии и при
способить к применению в своей практике. Не существует такого единого под
хода, который годился бы всем. Современные методы разработки программного
обеспечения далеки от совершенства, и поэтому вам придется рассмотреть не
только один широко распространенный метод. Например, в методике
Scrum оп
ределяется ряд норм практики управления проектами, но сама эта методика не
может служить достаточным руководством к действию команд на техническом
уровне или же на уровне портфеля заказов либо организации управления для
высшего руководства. Так с чего же начать?
Тема 50 • Кокосами не обойтись
329
БУдьтЕ кдк они!
Нам часто приходится слышать, как начальство, руководящее разработкой
программного обеспечения, говорит своим подчиненным:_ "Мы должны дей
ствовать как Netflix" (или одна из ведущих компаний в данной отрасли). Ра
зумеется, вы могли бы это сделать, но прежде вам пришлось бы установить
несколько сотен серверов и привлечь десятки миллионов пользователей".
ГЛАВНАЯ ЦЕЛЬ
Безусловно, главная цель состоит не в том, чтобы действовать по методике
Scrum, Lean, "гибко" или по иной
выбранной вами методологии разработки про
граммного обеспечения, а также иметь все необходимые возможности, чтобы
выпускать работоспособное программное обеспечение, дающее пользователям
новые возможности уже теперь, а не через недели, месяцы или годы. Многим
командам и организациям непрерывная поставка программного обеспечения
кажется слишком возвышенной, недостижимой целью, особенно если они об
ременены процессом, ограничивающим поставку месяцами или даже неделями,
как показано ниже. Но какова бы ни была конечная цель, самое главное
result = TIМE_RE.match(string)
if result
result[:hour] .to_i * 60 +
(result [ :minute] 11 "0"). to i +
(result[:ampm] == "pm" ? 12*60 : 0)
end
end
В приведенном выше коде применяется специальный прием сначала для оп
ределения именованных шаблонов в начале регулярного выражения, а затем
для обращения к ним как к подшаблонам при фактическом сопоставлении.
Ответ на упражнение
9
Наш ответ должен быть основан на нескольких предположениях.
•
Информация, которую требуется передать, хранится в запоминающем устройстве.
•
Нам известна скорость ходьбы человека.
•
Нам известно расстояние между компьютерами.
•
Мы не учитываем время, требующееся для передачи информации как в
запоминающее устройство, так из него.
•
Издержки на хранение данных приблизительно равны издержкам на от
правку данных по линии связи.
Ответ на упражнение
10
С учетом допущений, сделанных в предыдущем ответе, на накопителе на маг
нитной ленте емкостью 1 Тбайт хранится 8х2 40 , или 243 бит, поэтому данные
равнозначного объема могут быть переданы по линии связи с пропускной
способностью
1
Гбит/с приблизительно за
9000 секунд, или около 2,5 часа.
5,6 км/час, то компьютеры долж
почти 14,5 км, чтобы линия связи
Если человек ходит с постоянной скоростью
ны отстоять один от другого на расстоянии
превзошла человека по скорости передачи данных, а иначе он превзойдет ее.
Ответ на упражнение
14
Приведем ниже сигнатуры функций на языке
в комментариях.
Последние комментарии
12 часов 5 минут назад
13 часов 14 секунд назад
13 часов 3 минут назад
23 часов 54 минут назад
23 часов 56 минут назад
1 день 12 часов назад