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

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

      Редко бывает достаточно, что наши системы работают. Обычно нам также нужно знать, что они работают хорошо. Это положение может показаться тривиальным, но из него есть следствия для того, как нам организовать свою работу.
      На уровне выявления требований мы можем обследовать определенный участок проблемной области, который, как мы предполагаем, может стать источником проблем, даже не зная, собрали ли мы всю относящуюся к проблеме информацию. Для повышения уверенности, что мы ничего не упустили, нам нужно пристально посмотреть пошире, чтобы увидеть, куда что уходит, и откуда что приходит. Мы должны найти способ представления этих потоков, чтобы можно было охватить одним взглядом большую картину. Стопки прозы или толстые папки Диаграмм Потоков Данных здесь совсем не помогут (хотя они могут пригодиться где-то в другом месте проекта), поскольку они не позволят нам увидеть одним взглядом, что нет потерянных концов. Если мы можем убедиться, что нет потерянных концов, то мы с основанием можем быть уверены, что здесь нет скрытых ужасов, которые мы обнаружим во время реализации. Это пример технологии картостроителя для очерчивания проблемы.
      На архитектурном и детальном уровнях проектирования применяется та же идея. Рассматривая наш проект, мы представляем себе наши идеи как можно большим числом способов и проверяем, сможем ли мы их разрушить. Это важно, что мы используем некоторые черты проекта, такие как число возможных состояний на входе, чтобы показать, что система, которую мы проектируем, будет устойчива во всех случаях, показав, что мы рассмотрели все случаи. Это не означает, что мы пытаемся просмотреть все варианты -- вместо этого мы находим средства сгруппировать эти варианты, и показать, что мы рассмотрели все группы.
      При пошаговой отладке с помощью символьного графического отладчика в каждой точке принятия решения нам следует рассмотреть все обстоятельства, при которых принят путь, который мы выбираем, и также следует проследить все другие варианты путей.
      Во всех этих ситуациях проектирование для тестирования начинается с разбиения нашей работы на уровни так, чтобы ее корректность была доступна для проверки. В свете этого интересно рассмотреть, что мы подразумеваем под математическим доказательством. Предназначение доказательства обычно описывают как то, что показывает, что утверждение имеет место. Это действие-центрический взгляд на вещи, присущий паковщикам. Описание предназначения доказательства с точки зрения картостроителя состоит в том, что оно показывает нам утверждение в новом свете, в котором истинность утверждения очевидна для проверки. Для картостроителей доказательство не просто устанавливает факт, оно так же увеличивает наше понимание. Недавно мы видели полученные с помощью компьютера доказательства, которые удовлетворяют целям паковщика, но не дают ничего для целей картостроителя. Эти доказательства, поскольку они не используют силу, которая приходит от понимания, слабее. Так ли необходимо, чтобы корректность кода (оставим в стороне архитектуру компьютера), который выполняет поиск, была очевидна для проверки?
      Мудрые архитекторы обычно разделяют свои проекты на уровни так, что прослеживаются отдельные дискретные стадии при переходе от кода, взаимодействующего с пользователем, к коду, взаимодействующему с операционной системой. Каждый из этих уровней предоставляет возможность написать небольшое тестовое приложение. Обычно этими возможностями следует воспользоваться, поскольку хотя это, как может показаться, и вызывает рост стоимости, выявление ошибок, которые не имеют хорошо определенных тестовых точек, может неимоверно осложнить фазу окончательного тестирования и отнимет кучу времени. Чтобы полностью воспользоваться этими тестовыми возможностями, нам следует предусмотреть тестирование при определении 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 часов вечера, когда они все еще на работе, но не могут получить исправляемый файл, чтобы прочитать и разобраться. Это не только напрямую тормозит ваш проект: это также дает печальный эмоциональный опыт, который вы навьючиваете на самое высокомотивированное животное в коммерческом мире -- программиста в Режиме Глубокого Хака. Чем он вас так обидел?
      И наконец, не позволяйте затуманить ваши мозги ни одному элементу из веры паковщиков, в то, что мы должны знать точно кто, когда и что абсолютно обо всем. Если ваш проект -- это команда, координируемая этикетом и формализованная по необходимости, у вас есть шанс. Если это базар, регулируемый детальными инструкциями, то вы обречены.

Перегрузка мозга

      Как мы уже сказали в самом начале, картостроение и паковка отличаются. Это отличие можно увидеть в организации рабочего места и в поведении человека на нем. Организация паковщиков видит всю работу состоящей из механической последовательности действий, выполняемых в определенном месте. Дело не в том, будто циничные менеджеры верят в то, что рассаживание всех в офисы с открытой планировкой, лишая таким образом возможности сконцентрироваться и, следовательно, губя продукт, не имеет значения, поскольку их цели более краткосрочные -- дело в том, что они не верят, что есть такая вещь как концентрация (как ее знают картостроители), которая должна стоять на первом месте!
      Некоторые рабочие среды могут быть настолько ориентированы на паковщика, что деятельность картостроителя в них невозможна. Там будут постоянные отвлечения, не дающие картостроителю возможности сосредоточиться. Собрания будут построены из серии докладов в стиле "положение обязывает", делаемых людьми, подсчитывающими очки в поиске победивших и проигравших, что никак не связано с произносимым. В этой ситуации, картостроитель, для выражения мысли которого может потребоваться два, ну три, отчетливо произнесенных предложения, будет выглядеть как трогательный неудачник.
      Хуже того, эта самая неэффективность когнитивной стратегии паковщиков ведет к тому, что ее приверженцы становятся в яростную оборонительную позицию, когда критике подвергается скрывающий весь недостаток понимания паковщиков этикет. Если в коллективе мала пропорция картостроителей (или даже велика, но они не знают, что происходит), то могут возникнуть напряженные ситуации.
      Ключевой момент в этой картинке состоит в том, что нет смысла в попытках картостроителей убедить своих коллег-паковщиков в значении строгого и полного подхода даже с помощью более осторожных аргументов -- проблема в том, что паковщики с самого начала не готовы принять любой вид детализованного рассуждения! Поэтому картостроитель может просто устать, пытаясь доказать что-то людям, которые просто не слушают.
      Можно на самом деле переутомиться, занимаясь картостроением, и очень важно это заметить и избежать. Первое, что нужно сделать -- это распознать ситуации, где интенсивный подход картостроителя наиболее подходящ.
      Картостроение в целом можно рассматривать как поиск, а особенность поиска состоит в том, что неизвестно, где это искомое лежит. Поэтому необходимо продолжать поиск до тех пор, пока объект не будет найден. Это гораздо легче сделать, если есть уверенность, что объект поиска действительно существует! В противном случае нужно предусматривать некоторый искусственный ограничитель, например, лимит времени. Тут приходит упоминавшаяся в начале "вера картостроителя" -- картостроители снова и снова открывают, что мир вокруг нас всегда проще, чем он кажется, при условии, что на него смотрят правильно. Иногда приходится раскрывать и изучать огромную скрытую сложность, но простота, необходимая достаточность "плато качества" в конце концов будет достигнута. Во всех ситуациях, которые можно найти в реальном мире, инвестиции картостроителя будут небесполезными, поскольку чем глубже видится скрытое, тем более ст оящим (мощным) будет результат. Ситуации, которые не включают "естественный мир" в этом смысле (в конце концов, все в этом мире "естественное") -- это те ситуации, где сознание пытается создать локальную область иррациональности. Другими словами, где вы играете против другого ума, который случайно или осознанно старается привести вас в растерянность, стараясь показать только части всей системы (которая рациональна) так, что она выглядит для вас полной, но иррациональной. Поэтому паковщики, используя тот же самый язык, что и картостроители, при разговорах о мышлении, но подразумевая нечто другое, оказываются иррациональными. Когда картинка дополняется барьером картостроитель/паковщик, то мы снова возвращаемся в естественный мир, который включает противодействующий разум, и рациональность восстанавливается.
      Есть такая игра на радио, Mornington Crescent, правила которой по некоторым соображениям никогда не публиковались. Если кто-то слушает эту игру и подразумевает, что существует лежащая в ее основе рациональная система правил, то он может быстро свихнуться. Нет таких правил. На самом деле игра состоит в ловкости, с которой игроки делают вид, что правила все же существуют, и это придает игре своеобразный характер.
      Итак, если в рассматриваемой ситуации присутствует еще один ум, всегда нужно учитывать его потенциальное противодействие (капризность, извращенность), чтобы гарантировать, что ситуация остается естественной. Может показаться, что нас как компьютерных программистов это повергает в паралич паранойи, поскольку многие проблемы, с которыми мы имеем дело, включают пользователей. Но дела не настолько плохи, поскольку если бизнес просуществовал столько времени, то это полностью естественное явление, которое подвластно картостроительному анализу, даже если никто из игроков на самом деле не понимает, что же на самом деле происходит. Однако помните, что короткоживущие транзакции бизнеса, такие как выставляемые на биржах только в короткий период быстрого изменения рынка заявки, не могут быть источником существования, и потому могут рассматриваться как продукт извращенных умов. Это не означает, что такие транзакции нельзя автоматизировать, -- просто это означает, что единственное, что приходится делать в этом случае -- это кодировать с помощью 4GL, или какое там еще средство быстрой разработки (RAD) вы используете, глупость, раз уж биржевые игроки просят вас это сделать, и пусть они беспокоятся о восстановлении собственного нормального поведения по отношению к таким же извращенным коллегам. Иногда организации, занимающиеся такими вещами, просят картостроителей взглянуть на ситуацию в целом и посмотреть, могут ли они найти какую-нибудь логику, если границы достаточно широки. Эти работы могут оказаться исключительно интересными и благодарными.
      Идентифицировав ситуации, где нам следует отказаться от картостроения или переопределить проблему, мы остаемся с проблемой того, как долго мы будем идти к пониманию. Опыт картостроения приносит причудливую интуицию относительно интуиции, которая дает хорошее чутье на эти вещи. Не высказывайте оценки до того, как вы сами лично не убедитесь, что набрались достаточно опыта в их получении. Запишите вашу личную оценку перед началом картостроительной работы, и посмотрите потом, правильной ли она оказалась. Вы можете ошибиться несмотря на десятилетия опыта. Если бы работа была понята, то был бы создан автоматизирующий эту работу коммерческий продукт (COTS), не правда ли?
      Картостроители часто сталкиваются с проблемами за много лет до их решения -- исследования, собранные в этой работе, заняли тридцать или шесть лет, в зависимости от того, как установить границы! Важно, что хотя есть ограничение на силы, которые можно направить на решение проблемы, нет ограничения на нахождение в состоянии готовности к этой проблеме, увеличивающем продолжительность жизни картостроителя. Нет позора в осознании длительности решения проблемы и уменьшении интенсивности попыток ее решения. Эта мотивация -- один из наиболее забавных примеров коммуникационного барьера картостроитель/паковщик. Для паковщика проект состоит из последовательности действий, которые требуется выполнить. Скорость, с которой выполняются действия, индицирует эффективность работающего. Работа над проблемой, от которой приходится отказываться (оставлять в покое), есть доказательство неорганизованности части работников. Следовательно, паковщики способны посмеиваться над "курьезными проектами" картостроителей, осознавая и, тем не менее, одновременно отвергая выдающиеся творческие результаты, которые картостроители регулярно выдают, поскольку им ясно, что они не были достигнуты "правильно", хотя у паковщиков нет предположений о том, каким должен быть "правильный" подход. Плохи дела. Образование за это в большом ответе.
      Руководствуясь интересами дела, мы должны обратить внимание на то, что при интенсивном занятии картостроением нужно себя беречь. Основы физического здоровья могут быть подорваны двумя способами. Во время интенсивной работы некоторые картостроители обнаруживают, что без должного внимания оказываются еда и необходимые упражнения. Гордитесь тем, кто вы и что вы можете делать, но перед тем, как войти в это состояние, убедитесь, что поблизости лежит много свежих фруктов и холодильник полон. Тогда поесть -- это не проблема. Каждый картостроитель, похоже, в состоянии хорошо работать, прогуливаясь в одиночку, поэтому прогуливайтесь.
      Второй способ подорвать свое здоровье -- перегрузить свой мозг. Следующий совет не нужно воспринимать буквально, поскольку у нас нет нейрологического основания для него, но это то, что происходит с картостроителями, которые столкнулись с трудностями. Если проблема очень большая, то ее сложность, которую нужно поместить в ум, перед тем как произойдет ее коллапс, старается заполнить весь мозг картостроителя и занять те части, которые содержат образ тела картостроителя. Когда это происходит, физическое состояние за несколько дней может ухудшится, человек очень быстро может стать похожим на высохшую картофелину. Мы не собираемся советовать не делать этого -- это само приходит к вам. Но если вы остановитесь посреди недели из-за внезапно появившейся беспомощности и попытаетесь восстановить образ своего тела физической работой или получив некую обратную связь, то вы сможете восстановить свое состояние так же быстро, как и потеряли его. Если выгрузить образ своего тела надолго, то восстановить его будет гораздо труднее.
      Помните, что мы говорили о напрасности трат энергии на повторяющиеся непродуктивные циклы размышлений.
      Помните, что кое-что также происходит и во внешнем мире. Нужно поддерживать ваши личные взаимоотношения, и хотя кое-кто возле вас знает о вашем состоянии и ждет вашего возвращения, другие будут нуждаться в некотором внимании. Практикуйтесь работать в фоновом режиме, используя ранее описанную технику "верчения тарелки". Со временем вы обнаружите, что можете менять объем сознания, выделяемый на размышление над проблемой, и объем, оставляемый свободным для поддержания учтивой беседы. Если вы находитесь в стадии, когда требуется мобилизовать весь ум, и вы не хотите останавливаться, поскольку потребуется неделя на восстановление той частичной картины, которая у вас уже есть, и у вас есть функция, которую вы предполагаете применить, вы всегда можете перейти в состояние счастливого идиота. Вы знаете, что вы не обращаете внимание на болтовню вокруг вас, но, что невероятно, болтуны редко это замечают!
      Не обращайте внимание на мнения паковщиков о ваших вредных для здоровья способах. Такие комментарии -- пустяки по сравнению с теми советами о здоровье, которые мы обсудили в этом разделе. Для паковщиков "думать слишком много" -- это расстройство (болезнь) само по себе!

Переутомление мозга

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

Переработка

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

Управление межкультурным интерфейсом

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