Любая переменная, даже если никто не использует ее глобально. (Еще один предложил помечать глобальные переменные.) Еще один произвел причудливую схему типов, параллельную собственным составным типам языка, и потребовал включения информации об этих типах в имена. Зачем -- мы не знаем. Еще один опубликовал список сокращений имен модулей кода, известных менеджеру конфигурации и сказал, что это тоже необходимо включить в каждое имя переменной. И т.д. Наступило настоящее веселье, когда оказалось, что все эти обязательные штучки плюс пометка типа "указатель на функцию, возвращающую указатель на запись" превысили 31 символ. Создатели Законов просто сказали, эта конструкция очень сложна и ее не следует использовать, хотя это было главным для архитектуры, и топтались вокруг описывания промежуточных переменных и приведения типов во время присваивания им значений, что совершенно не помогало ни ясности ни эффективности. Поэтому, наконец, пузырь лопнул и мы разработали некоторые прагматические стандарты, которые хорошо выглядели и говорили нам, как с помощью словаря проекта быстро образовать имя и некоторые разумные сокращения. Если посмотреть с точки зрения картостроитель/паковщик, мы видим, что ситуация развивалась подобным образом потому, что Создатели Законов были Объявителями Полезных Правил, что Хорошая Вещь, но цена, цена...
      Третий момент -- о природе строительных кирпичей. Для целей сохранения хорошего порядка руководство по стилю, содержащее многослойный винегрет из соглашений об именовании, идиом и примеров модулей для разработчиков будет служить служить вам лучше, чем коллекция императивных (обязательных к исполнению) инструкций, ограничивающих способность программиста искать элегантность самостоятельно. Если вы не можете доверить команде самостоятельно решить, когда заключать блок в скобки, а когда нет, как вы можете доверить ей написать ваш суперпроект?
      Четвертый момент -- об этих императивах. Есть некоторые средства, которые вообще не стоило изобретать, например scanf() и gets()в UNIX. Указания никогда не использовать их в разрабатываемом коде разумны. Но есть цели, которых просто невозможно безопасно достичь другим, лучшим путем. И всегда остается проблема баланса ясности. Мы рассмотрим два конкретных примера, из которых станет видно, что в Си все же существует хороший повод для использования goto -- хотя вам могли говорить, что таких поводов нет.
      Вот первый, здесь нет другого способа. Представьте рекурсивный обход двоичного дерева:
      void Walk(NODE *Node) { // Do whatever we came here to do... // Shall we recurse left? if(Node->Left) Walk(Node->Left); // Shall we recurse right? if(Node->Right) Walk(Node->Right); }
      По мере обхода дерева, мы начинаем делаем вызовы, ведущие нас влево, влево, влево, влево ... и так до самого низа. Затем просматриваем каждую комбинацию влево, влево, вправо, вправо, влево... и т.д., до тех пор, пока не просмотрим все ветви, и не проделаем все возвраты из нашего последнего визита, который был вправо, вправо, вправо, вправо....
      Каждый шаг влево или вправо включает в себя открытие нового кадра стека, копирование аргумента в этот кадр стека, выполнение вызова и возврат. Для некоторых задач с многочисленной навигацией, но небольшой обработкой в узле, эти накладные расходы могут оказаться чрезмерными. Но посмотрите на такую мощную идиому, известную как устранение хвостовой рекурсии:
      void Walk(NODE *Node) { Label:// Do whatever we came here to do... // Shall we recurse left? if(Node->Left) Walk(Node->Left); // Shall we recurse right? if(Node->Right) { // Tail recursion elimination used for efficiency Node = Node->Right; goto Label; } }
      Мы используем стек для отслеживания того, куда мы попали слева, но после того, как мы обошли левую часть, переход на правую ветвь не требует хранения положения. Поэтому мы устраняем 50% вызовов и накладные расходы на возвраты. Это может изменить ситуацию при выборе между реализацией на Си или добавлением ассемблерного модуля. Чтобы увидеть другой пример, посмотрите на конструкцию Даффа (Duff's Device) в книге Страуструпа "Язык программирования C++" (Stroustrup's The C++ Programming Language).
      Второй пример касается чистоты стиля -- вообще нет необходимости применять язык ассемблера. Помните, что когда Дейкстра посчитал goto вредным, он имел в виду привычку использовать goto для организации управления в неструктурированном коде 60-х годов. Идея заключалась в том, что меньше используя goto мы могли бы улучшить ясность. Идея не состояла в жертвовании ясностью избегая goto любой ценой. Представьте программу, которой нужно открыть порт, инициализировать его, инициализировать модем, установить соединение, зарегистрироваться (logon) и загрузить файл (download). Если что-то не так, в любом месте, нам нужно вернуться обратно в самое начало. Доморощенный структуралист мог бы написать нечто вроде:
      BOOL Done = FALSE; while(!Done) { if(OpenPort()) { if(InitPort()) { if(InitModem()) { if(SetupConnection()) { if(Logon()) { if(Fetch()) { Done = TRUE; // Ouch! Hit the right hand side! } } } } } } }
      Что нам кажется просто глупым. Есть более понятная альтернатива, использующая то, что оператор && прекращается сразу, как только встречается выражение, принимающее значение FALSE -- "неправильное использование" языка, обычно запрещаемое в большинстве стандартов кодирования:
      while(!(OpenPort()&& InitPort()&& InitModem()&& SetupConnection()&& Logon()&& Fetch()));
      Здесь все ясно и удобно, поскольку мы можем инкапсулировать каждый шаг в функцию. Проблема в коде такого рода заключается в том, что требуется правильно сделать целый ряд ужасных вещей, например инициализацию строк и т.п., и чтобы работать с таким кодом, нужно выполнить его в очень похожем на скрипт виде. Например, так:
      Start: if(!OpenPort())goto Start; if(!InitPort())goto Start; if(!InitModem())goto Start; if(!SetupConnection())goto Start; if(!Logon())goto Start; if(!Fetch())goto Start;
      Это в точности то, что позволяют нам делать специализированные скриптовые языки, разработанные для такого вида работ!
      Не забывайте, если вы хотите, чтобы предмет вашего обожания понял ваше любовное письмо, вы не позволите педантизму правописания и грамматики исказить письмо, а если вы хотите, чтобы ваши коллеги поняли вашу программу, не перекручивайте ее структуру во имя "чистоты".

Значимые метрики

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

Надежда на инструменты

      Использует ли разработчик социально нормальную стратегию паковщика, или хорош в картостроении, он будет подвержен сильному влиянию надежды на инструменты. Паковщик смотрит на инструмент как на машину, которая выполняет работу, как копир в углу офиса. Действительно, таким образом большинство из нас использует компиляторы -- засунь исходник с одной стороны, исполнимый код выйдет с другой. Обычно здесь все нормально, хотя день, проведенный за чтением руководств по компилятору и компоновщику, многократно окупится.
      Паковщики любят большие дорогие инструменты со сложным интерфейсом и неимоверно сложным внутренним состоянием. Они обещают делать все и требуют недель на установку и настройку. В них содержится множество сложных технологий. Все эксперименты заканчиваются плачевно. Среди шума легко потерять этот замалчиваемый глянцевыми рекламными проспектами факт. Программирование - это операция по обработке данных, которую этот продукт автоматизирует для вас, поэтому вы можете носить галстук, много улыбаться и быть "профессионалом" -- вот что написано в рекламе.
      Картостроители не рассматривают инструменты как копиры, они рассматривают их как протезы ума. Они -- мыслительный эквивалент Рипли из фильма "Чужие" (Ripley in Aliens), взятой в рубку космического корабля, чтобы победить главное чудовище. Картостроители оставляют за собой ответственность за все и используют инструменты для расширения своего кругозора и силы мысли. Картостроители не любят помещать все свои штучки в один инструмент, где их другой и не найдет. Им нравятся коллекции инструментов и чтобы ввод/вывод был текстовым и анализируемым (parseable), так чтобы они могли объединять (соединять) инструменты вместе.
      Картостроители считают разумным писать небольшие программы на лету, чтобы манипулировать исходным текстом. Они отдают себе полный отчет в том, что делают хорошо они, а что хорошо делают компьютеры, используя свои собственные суждения, когда проверяют каждый вызов, скажем, функции, чье определение они изменяют, а компьютер гарантирует, что они проверили каждое появление вызова функции в тексте.
      Имеются великолепные инструменты картостроителя -- браузеры, инструменты восстановления исходного текста (reverse engineering - дизассемблеры), даже некоторые "интегрированные среды разработки" (IDE). Однако, стоит держать в уме, чего можно достичь на большинстве систем просто с помощью нескольких скриптов и системного редактора. Одна команда пришла в волнение, когда им показали инструменты, которые давали им все возможности для просмотра и средства получения перекрестных ссылок. Но отличия между этими инструментами и пучком скриптов, которые у них уже были, и на написание которых понадобилось одно утро заключались в том, что:
      Инструменты нельзя было модифицировать.Инструменты стоили 20,000 фунтов стерлингов плюс 5,000 фунтов стерлингов за рабочее место.Инструменты требовали несколько недель на установку и настройку.Инструменты были с графическим интерфейсом.
      Когда кто-то с энтузиазмом рассказывает о новом продукте, остановитесь на минутку и проверьте, может быть правильной реакцией будет: "Ну и что?"

Структуры программы - структуры проблемы

      Можете себе вообразить Марго Фонтейн (Margot Fonteyn) с ногами и руками в гипсе и парой кандалов на лодыжках? Очень не грациозно.
      Одна из наигрустнейших вещей -- позволить молодым разработчикам начать работу с пошагового подхода, который позволяет им начать создание программы, а затем по мере работы знакомить их с идиомами, позволяющими отобразить проблему на язык и подход. Основной момент в том, что используемые ими языки и подходы предназначаются для отражения предметных областей. С большим удивлением наблюдаешь, как они начинают рассматривать и описывать проблемы в терминах программных структур. Черта, разделяющая хороший способ описания проблемы и хороший способ ее решения, размыта, а использование объектных подходов и языков максимизируют это размытие.
      Но как раз в момент, когда они могут стать умелыми и изобретательными, эти разработчики начинают чувствовать себя виноватыми, поскольку им следует "видеть проблему, а не решение". Поэтому они начинают своеобразный спектакль, где они утверждают, что не могут видеть сути вещи, о которой они говорят. Если перед ними поставлена специфическая цель, например обеспечение независимости от реализации, этот маневр может быть проделан с большой ловкостью, поскольку они точно знают, что они не знают и это становится упражнением в строгости, но если они просто стараются быть глупее, чем они есть на самом деле, когда они собираются остановиться?
      Если ты хороший, то ты просто находка для своей организации, поскольку можешь сжато изложить, что решение Y хорошо для проблемы X и почему, следующий вопрос, пожалуйста!
      Это не преступление -- быть умелым и квалифицированным.

Разбор полетов

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

Уменьшение сложности и последовательное ужимание

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

Бесконечная деградация "программных архитектур"

      Была команда, которую заказчик попросил создать среду реального времени, которая могла бы поддерживать небольшие процессы, стыкуемые через средства ввода/вывода, что-то типа графической оболочки для управления сложной системой трубопроводов. Если классифицировать эту задачу, это работа по системному программированию. Эта команда решила быть Профессиональной, и стала использовать Надлежащие Методы. Поэтому они пошли и сделали объектно-ориентированную модель этих вещей из Требований Пользователя используя инструменты, автоматизирующие подход Шлера-Меллора (Shlear-Mellor). Но была небольшая трудность, поскольку проблема была из другой области, зато они подогнали ее под Надлежащую Методологию. Они ведь могли использовать генератор кода! Они нажали кнопку и получили целую кучу склеенных классов. Каждый из них просто вызывал процедуру из API из "Программной Архитектуры", слоя, который требовался в подходе, что позволяло приложению работать на определенном типе компьютерной системы. В этом случае Программная Архитектура стала бы системным средством предоставления графического интерфейса для оболочки, работающей со сложной системой трубопроводов!
      Как картостроители, мы можем видеть, что произошло с этим образчиком тупого Профессионализма и Следования Процедуре паковщиков. Команда извлекла не тот пакет знаний и использовала хорошо продуманный и замечательно автоматизированный подход и язык в совершенно неправильном контексте. Подход Шлера-Меллора предназначен для задания функционирования прикладных программ, а не для системного программирования. Говоря простым языком, они не смогли увидеть, что классификация проблемы была проведена неправильно, поскольку у них не было здравого смысла, что есть результат недостатка морали или врожденного идиотизма. Мы предпочли бы сказать, что они были принуждены думать, что им нельзя думать непосредственно о работе, но сначала все смести и найти костыль. Потом они могли видеть проблему только через подход, даже если он плохо соответствовал. Затем подход уровня приложений представил их проблему на прикладном языке. Поэтому им в голову не приходило подумать, какого сорта программу они пишут, и заметить, что это системная оболочка, а не прикладная программа. Для паковщиков Профессионализм всегда означает взять зубную щетку и палочки для еды в руку и не замечать, что зубная щетка попала в нос, хотя все в полном соответствии с церемонией!
      По мере того, как все становилось все более абсурдным, росло напряжение и команда все настойчивее обороняла свой Профессионализм. Один раз на встрече некто, ожидая хотя бы немного прагматизма, представился как "программист компьютеров" (computer programmer). Результат был замечательный. Вся команда глядя в пол бубнила под нос "Программный Инженер... Компьютерный Ученый..." (Software Engineer... Computer Scientist...), как будто тот совершил значительную социальную ошибку. Два члена команды позднее объясняли, что они не нашли создание "просто кода" интересным, и их Профессиональный Интерес заключался в Применении Процесса.
      Очень тяжело заниматься системным программированием применяя некие лежащие перед тобой инструкции к компьютеру. Это ведет к стрессу, поскольку невозможно. Поэтому очень важно многословно демонстрировать свой Профессионализм руководству, чтобы никто не смог отделить зерна от плевел в этом вечном хаосе.
      Вы не сможете писать компьютерные программы, если ваша стратегия состоит в замысловатой игре по передаче пакетов. Даже если придерживаться характерной стратегии паковщиков передавать документ соседу слева "для рецензии". Менеджер проекта, который пишет описание задачи, показывая входы и выходы задачи, часто может держать такие вещи под контролем, но только в том случае, если действия соответствуют атомам познания проекта и хорошо разбиты на части и при условии, что выходы на самом деле ближе к обработчику, либо непосредственно, либо путем информирования другой стороны, чем входы.
      Картостроители тоже могут извлечь интересный урок из подобных историй. Нужно быть предельно осторожным, включаясь в игры по функциональной передаче пакетов. Сложность никуда не исчезает, и функциональность не появляется из ничего. Сложность может быть выражена более просто, если копнуть глубже. Ты узнаешь, когда ты этого добился. Ее можно также избежать, удалив часть сложности. Ты также узнаешь, когда ты этого добился. Когда показалось, что огромная глыба неуклюжести куда-то пропала, вероятно ты просто переместил ее куда-то в другое место своей структуры. И это хорошо, поскольку когда ты обнаружишь ее вновь, то ты получишь две точки зрения на ту же проблему, а это может привести к большим открытиям. Но не питайте привязанность к какому-то решению, которое создает видимость, что вся сложность магически исчезает -- она просто неожиданно проявится в другом месте и испортит весь день. Это проявляется на любом уровне, начиная с выявления требований и заканчивая отладкой. Ошибки никуда не деваются. Те ошибки, которые появились, а потом неожиданно исчезли сами собой -- самые коварные ошибки. Возьми старую реализацию, найди их и убедись, что таких же ошибок нет в последней реализации.
      В качестве практического примера того, что функциональность не появляется по мановению волшебной палочки, рассмотрим проблему атомарности (atomicity). В многозадачных системах многие процессы исполняются без возможности управления временем приостановки, чтобы дать шанс выполниться другим процессам. Иногда двум процессам требуется координация, например для управления периферийными устройствами. Проблема в том, что один из процессов может обнаружить, что периферийное устройство свободно и сделать пометку о его захвате. Но в промежутке между этими двумя событиями второй процесс тоже может сделать проверку и обнаружить, что устройство свободно и тоже начнет делать пометку о захвате. Один процесс просто перепишет пометку другого и оба будут пытаться получить доступ к периферийному устройству одновременно. Не имеет значения, как это организуется в пользовательских процессах, невозможно совместить проверку и установку как единую, "атомарную" операцию, независимо от заумности пользовательского процесса. Ее можно инкапсулировать в функцию GetLock(), но она все равно должна добыть атомарность из операционной системы. Если процессор поддерживает многозадачность на уровне железа, как большинство современных процессоров, нам понадобится атомарная операция, содержащаяся в наборе инструкций, такая как инструкция TAS в процессорах серии 68000 фирмы Motorola.
      Ничего этого нельзя увидеть предполагая, что нельзя переходить на использование расслоения или применять специализированные языки. Действительно, если некто полагается на специфический код операции просто для захвата принтера, то, по-большому счету, необходимо разбиение на слои! Это просто означает, что для достижения максимального упрощения мы используем оптимальный уровень специализации -- мы не делегируем невозможное призрачным ящикам и не основываем дизайн на ложных предпосылках.

Аудит качества

      Для картостроителя процесс -- это протокол взаимодействия со своими коллегами во времени и пространстве, а не предварительно написанный свод правил, исполнение которых контролируется. Он предоставляет средства, а не требует тупого подчинения. Чтобы отчетливо подчеркнуть различие, нам следует в правильном духе рассмотреть аудит качества.
      В обычной модели паковщика аудит -- это суровое испытание. По мере приближения аудита менеджеры работают с мрачным предчувствием, работники стремятся сбежать в отпуск или в командировку, либо прикидываются больными, лишь бы избежать аудита. Когда аудиторы набрасываются как коршуны, они смотрят на членов команды как на врагов, и принуждают их к подразумеваемому подтверждению совершенства процесса и того, что все недостатки, которые они обнаружат, - нарушения, совершенные людьми. Отдельные работники становятся мальчиками для битья, несущими наказание за ошибки организации, которые они не контролируют. Это классическая ситуация, заставляющая людей глотать успокоительное перед приходом на работу. Нет сомнения, что это модель, не смотря на то, что ее редко так характеризуют, поскольку стандартное для менеджеров "Краткое руководство для погонщика" (Bogeyman Briefing) включает советы типа: "Не выдавай информацию добровольно. Формулируй кратко. Если тебя спрашивают, где план управления проектом, скажи, что в Хранилище (Registry)". Адвокат должен давать похожие советы клиенту, подвергаемому перекрестному допросу!
      В ISO 9001 нет абсолютно ничего , что требовало бы оправдать ритуал такого вот пути совершенствования. У нас вообще нет проблем с ISO 9001. В действительности мы говорим, что разговор о "следовании ISO 9001" в то время, когда мы даже не способны применять с положительной мотивацией сам ISO 9001, превращает ту же самую старую глупость в еще один "радикально новый прорыв в науке менеджмента". Ну, а что думает об аудите качества команда счастливых картостроителей?
      Во-первых, объектом пристального внимания однозначно должен стать процесс сам по себе. Мы должны оказать любезность работникам, предполагая, что они делают свое дело добросовестно, поскольку это всегда так, даже когда их держат за полных идиотов. Мы, таким образом, предполагаем, что любая проблема, по умолчанию, -- это системный просчет процесса. Нехорошо сваливать повторяющиеся крушения самолетов на "ошибки пилота" -- очевидно, что нуждается в перепроектировании эргономика кабины.