Текст книги "The Programmers' Stone (Программистский камень)"

Автор книги: Alan Carter

Соавторы: Colston Sanger
сообщить о нарушении

Текущая страница: 9 (всего у книги 13 страниц)

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

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

Избегайте избыточности представления

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

Дело в том, что концепция нормализации базы данных из тех же соображений применима везде. Никогда не храните одну вещь и, отдельно, еще одну неподсоединенную вещь, которая полагается на то, что первая существует. Пусть данные управляют своей собственной структурой, и не появится никаких перекосов. Ритуальное использование структур данных часто включает претензию на управление держа зубную щетку и палочки для еды в одной руке. Если мы создаем структуру финансовых отчетов в Ящике А, а сложное описание Ящика А в Ящике В, то мы можем провести много времени копаясь в Ящике В, и ни разу не обратим внимания на тот факт, что на самом деле мы вообще не понимаем того, что происходит в Ящике А!

Не попадайте в эту ловушку. Пусть данные представляют сами себя, или, как сказал Лори Андерсон (Laurie Anderson) в книге "Большая наука" (Big Science)

Let X = X

Посмотри на состояние всего этого!

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

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

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

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

Или, крепко возьмитесь левой рукой прежде чем отпустить правую!

Реальность системы как объекта

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

Объектные проекты нацелены на создание формализованного Хода Конем ("вилки") с использованием подхода, который явно связывает объекты реального мира с жизнеспособной семантикой системы посредством объектных языков программирования (будь это Eiffel или генератор кода UML). При разработке этих проектов их создатели стремятся представить все, что есть сейчас в реальном мире, а не будет завтра, когда система будет использоваться. Главное отличие в том, что завтра система будет существовать в мире пользователя – сегодня это не так. Поэтому аналитики регулярно создают маленькие картинки мира пользователя в будущем, которые содержат все, кроме самой компьютерной системы, которая является центром всего сценария.

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

Вот два глубоких вопроса, возникающих при поиске объектов и попытках найти их взаимосвязи:

Кто кого порождает? Кто чьи методы использует?

Имея в проекте чистый класс System (Система), гораздо легче построить иерархию наследования и увидеть, откуда приходят такие вещи как GUI и ввод/вывод на ленту, не говоря уже о событиях, запускаемых по таймеру! Это не означает, что на более поздней стадии проектирования функциональность нельзя поместить в специализированные классы, но в проекте это дает реальности мира пользователя равный вес с реальностью системы, поэтому результат будет удовлетворять обоим критериям.

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

Конечно, потребность в классе System (Система) исчезает, если кому-то нужно просто моделирование, а не автоматизация бизнес-процессов, в которых не представлены управляющие системы. Каким мог бы быть подход в таком случае? Здесь мы напираем на то, что проектирование, формируемое стратегией картостроения, включает в себя больше, чем просто набор процедурных действий. Это означает очерчивание проблемы, прояснение желаний, нахождение точки оптимального приложения сил между динамикой проблемы и семантикой системы. Если ваш проект не получает преимуществ от класса System (Система), не используйте его!

Детекторы утечки памяти

На рынке имеется ряд продуктов, которые на основе различных стратегий обнаруживают утечки памяти в приложениях. Утечка памяти – это то, что случается, когда программа запрашивает блок памяти из кучи (используя, например, malloc() в Cи под UNIX или DOS , или оператор new в C++), а затем забывает вернуть его обратно по своему завершению. Иногда это приводит к нарушению работы других процессов, работающих на той же платформе, поскольку некоторые операционные системы позволяют одному процессу захватить всю имеющуюся память системы и файл подкачки.

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

Поэтому утечки памяти – это Плохая Вещь.

Это причина того, почему люди продают, и покупают, детекторы утечки памяти. Неприятность в том, что утечки – это симптом проблемы, а не причина проблемы. Не так трудно вызвать free() или удалить объекты, которые больше не нужны. Применение delete к коллекции указателей на активные объекты – вот опасное занятие, как и перезаписывание их адресов. Что если эти объекты, скажем, зарегистрировали функции обратного вызова (callbacks) в GUI ? Как же их освободить? Деструкторы вне контроля – это программист вне контроля. Если программист не может продемонстрировать контроль над объектами, которого достаточно для избежания утечек памяти, то как мы можем думать, что правильно еще хоть что-нибудь?

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

Таймауты

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

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

Коммуникационные уровни часто обязаны использовать таймауты, поскольку когда приходит время их работы, единственный способ обнаружить, что удаленное устройство готово к взаимодействию – послать ему сообщение и дождаться, посылает ли оно ответ. Как долго нужно ждать? "Проблема Византийских полководцев" (`Byzantine Generals' Problem') это иллюстрирует. Поэтому в большинстве современных систем есть таймауты на уровне коммуникации, но нет никакого оправдания использовать их повсюду, и там, где они должны использоваться, они должны быть сокрыты внутри инкапсулирующего объекта, который для целей отладки может быть заменен на детерминированный генератор событий (например, нажатие клавиши).

Проектируй для тестирования

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

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

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

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

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

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

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

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

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

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

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

Контрольные проверки и прогон автоматизированных тестов снизу доверху не следует рассматривать как помеху в работе – это очень дешевый путь получения подтверждения прочности фундамента. Как дополнительное преимущество, такие события становятся праздниками команды, по мере того как модуль за модулем, уровень за уровнем говорят об успешной компиляции и прохождении теста на рабочей станции менеджера. На таких праздниках команда может естественным образом взглянуть на все, чего они достигли к этому моменту, поскольку самый первый праздник может состоять просто в компиляции и запуске программы `Hello, world!' и доказательстве, что компилятор работает правильно, а последний дает в результате работающий продукт, который поставляется заказчику и в котором достигнуты все цели.

Даты, деньги, единицы измерения и проблема Y2K

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

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

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

Трудности, ассоциирующиеся с проблемой 2000 года, постоянно создают порог, о который то и дело вновь и вновь спотыкаются программисты. Языки программирования предоставляют типы данных, поскольку внутри типа имеется произвольный набор операций, которые можно использовать или нет, и если приходится читать код, а операции там встречаются, то их можно увидеть. Объектно-ориентированные языки расширяют эти средства для любых данных, которыми мы желаем таким образом управлять, предоставляя Абстрактные Типы Данных (ADT). Реальная трудность с 2000 годом не в том, что многие программисты кодировали год двумя цифрами – в те времена требовалось экономить память, а многие дошедшие до 2000 года программы очень старые. Проблема в том, что некоторые программисты берут эти две цифры и вставляют их где ни попадя без использования подходящей подпрограммы, макроса или даже фрагмента кода, чтобы сделать поправку. Это означает, что для того, чтобы решить проблему 2000 года в этих ужасно переплетенных старых программах требуется прочитать и понять каждую отдельную строку.

Безопасность

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

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

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

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

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