» Эндрю Ханта и Дэвида Томаса знают, наверное, все, кто занимается программированием, причем многие - в основном из упоминаний в подборках и цитат в более современных статьях. Учитывая, что этот сборник практических советов для разработчиков скоро отметит двадцатилетний юбилей, тот факт, что его до сих пор приводят как источник ценной информации, вызывает уважение. Секрет прост: авторы, хоть и делали акцент на практической применимости своих подсказок, говорили по большей части о фундаментальных принципах построения рабочего процесса. Многие технические моменты, которые упоминаются в тексте, действительно давно устарели, но базовые подходы к разработке, тестированию, взаимодействию внутри команды и с аудиторией остаются актуальными.

Ниже вы найдете конспект первых четырех глав; речь в них идет об авторской концепции самообразования, основах прагматического подхода в программировании и правилах подбора инструментов. Книга очень удобна для «точечного» чтения: материал представляется в виде отдельных параграфов-подсказок, снабженных перекрестными ссылками. За рамками этого конспекта остались примеры из конкретных языков, разбор кейсов из авторской практики, те самые ссылки, упражнения на закрепление и некоторые забавные аналогии, оживляющие текст - так что рекомендую ознакомиться с оригиналом, если какие-то из тезисов вас заинтересуют. Приятного чтения!

Подсказка 1: Позаботьтесь о вашем ремесле

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

Что отличает программиста-прагматика?

Опережающее восприятие и быстрая адаптация. У прагматиков инстинкт на полезные технологии и методы, которые они с удовольствием проверяют на практике. Они способны быстро схватывать новую информацию и объединять ее с уже имеющимися знаниями.
Любознательность. Прагматики задают вопросы, собирают мелкие факты, интересуются чужим опытом.
Критическое осмысление. Прагматики не принимают ничего на веру, не ознакомившись предварительно с фактами.
Реализм. Прагматики пытаются нащупать, где находятся подводные камни в каждой проблеме, с которой приходится сталкиваться.
Универсальность. Прагматики стремятся познакомиться с большим числом технологий и операционных систем и работают над тем, чтобы идти в ногу со временем.

Подсказка 2: Думайте о работе

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

Глава 1: Прагматическая философия

Прагматическое программирование ведет свое начало от философии прагматического мышления. В данной главе приводятся ее основные положения.

Подсказка 3: Представляйте варианты решения проблемы, а не отговорки

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

Принятие ответственности за результат предполагает готовность отчитываться. Если вы допустили ошибку (а мы все их допускаем), признайте ее честно и попытайтесь предложить варианты исправления. Не стоит перекладывать вину на коллег, партнеров, инструменты или выдумывать отговорки - это непродуктивная трата времени. То же относится и к ситуациям, когда вы сталкиваетесь в требованиями, которые не сможете удовлетворить: не говорите просто: «Это невозможно», а объясните, что нужно для спасения ситуации (дополнительные ресурсы, реорганизация и т.д.).

Подсказка 4: Не оставляйте разбитых окон

Энтропия – это термин из физики, обозначающий уровень «беспорядка» в системе. Энтропия во вселенной стремится к максимуму, и в разработке наблюдается та же закономерность. Увеличение степени беспорядка в программах на профессиональном жаргоне называется порчей программ. Существует много факторов, вносящих свой вклад в порчу программ, но наиболее важный из них - культура работы над проектом.

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

Подсказка 5: Будьте катализатором изменений

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

Подсказка 6: Следите за изменениями

Не сводите глаз с общей картины происходящего. Постоянно наблюдайте за тем, что происходит вокруг вас, а не только за тем, что делаете вы лично. Большинство катастроф в коде начинаются с малозаметных вещей, которые копятся, пока в один прекрасный день проект не пойдет вразнос. Шаг за шагом система отклоняется от требований, код обрастает «заплатами», пока от оригинала не остается ничего. Зачастую именно скопившиеся мелочи приводят к разрушению морали и команд. Но если захватить этот процесс на ранних стадиях и немедленно принять меры (см. предыдущий пункт), можно отделаться малой кровью.

Подсказка 7: Сделайте качество одним из пунктов требований

Качество должно быть договорным пунктом в контракте, который вы заключаете с пользователями. Конечно, в идеале оно должно быть максимальным, но часто вы будете оказываться в ситуациях, когда приходится идти на компромисс из-за жестких сроков или нехватки ресурсов. И здесь полезно приучить себя к созданию приемлемых программ. «Приемлемая» не значит «сделанная тяп-ляп»: вы просто даете пользователям право голоса при определении того порога качества, который можно считать допустимым. Удивительно, но многие предпочтут использовать программы с некоторыми недоработками сегодня, вместо того чтобы год ожидать выпуска мультимедийной версии.

Кроме того, иногда программы становятся лучше благодаря сокращению инкубационного периода. В разработке существует проблема «перешлифовки» - внешние ограничения помогают вовремя остановиться в погоне за совершенством.

Подсказка 8: Регулярно инвестируйте в свой портфель знаний

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

Общие принципы таковы:

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

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

Подсказка 9: Критически анализируйте прочитанное и услышанное

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

Подсказка 10: Важно, что говорить и как говорить

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

Принципы эффективного общения:

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

Глава 2: Прагматический подход

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

Подсказка 11: Не повторяйтесь

Каждый фрагмент знания должен иметь единственное, однозначное, надежное представление в системе. Альтернативой является представление одного и того же предмета в нескольких местах. Это доставляет неудобства: если в одном месте что-то редактируется, нужно немедленно внести изменения во всех остальных, иначе программа рухнет под грузом противоречий. Рано или поздно вы что-нибудь забудете, это вопрос времени.

Большинство случаев дублирования подпадает под одну из следующих категорий:

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

Подсказка 12: Сделайте так, чтобы программу можно было легко использовать повторно

Постарайтесь создать среду, где проще находить и многократно использовать существующий материал, чем создавать его самому с нуля. Это помогает снизить риск дублирования. Только имейте в виду: если повторное использование сопряжено с какими-то сложностями, люди не станут этого делать.

Подсказка 13: Исключайте взаимодействие между объектами, не относящимися друг к другу

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

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

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

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

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

Подсказка 14: Не существует окончательных решений

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

Подсказка 15: Пользуйтесь трассирующими пулями, для того чтобы найти цель

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

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

Подсказка 16: Создавайте прототипы, чтобы учиться на них

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

Для прототипирования необязательно создавать полноценное рабочее приложение, иногда достаточно просто схемы на бумаге или доске. Если оно все-таки необходимо, то имеет смысл выбрать для этой цели язык очень высокого уровня – выше уровня языка, который используется остальной части проекта (язык типа Perl, Python или Tel). Язык сценариев высокого уровня позволяет опускать многие детали (включая указание типов данных) и при этом создавать функциональный, хотя неполный и медленный, фрагмент программы.

Подсказка 17: Пишите код с оглядкой на область применения

Языки программирования влияют на то, как вы думаете о проблеме и о взаимодействии с пользователем. В каждом языке имеются свои особенности, которые наталкивают на определенные решения или, наоборот, препятствуют им. Решение, создаваемое в стиле Lisp, отличается от решения, основанного на мышлении приверженца языка С, и наоборот. Верно и обратное – язык, отражающий специфику проблематики, с которой вы работаете, может, со своей стороны, предложить решение в области программирования.

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

Подсказка 18: Проводите оценки во избежание сюрпризов

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

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

Подсказка 19: Уточняйте график ведения проекта, если того требует код

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

Глава 3: Походный набор инструментов

Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше сможете сделать. Начните с универсального, «походного» набора инструментов, который будете использовать для всех базовых операций. Это набор будет пополняться по мере того, как вы копите опыт и сталкиваетесь со специфическими требованиями.

Подсказка 20: Сохраняйте информацию в формате простого текста

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

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

Простой текст - это:

Гарантия того, что данные не устареют
Более короткий путь к цели
Более простое тестирование

Подсказка 21: Используйте сильные стороны командных оболочек

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

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

Подсказка 22: Используйте один текстовый редактор, но по максимуму

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

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

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

Подсказка 23: Всегда используйте управление исходным кодом

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

Система управления исходным текстом дает много больше, чем просто отмену ошибочных действий. Хорошая система позволяет отслеживать изменения и дает ответы на характерные вопросы: «Кто внес изменения в данную строку текста? В чем состоит разница между версией, существующей на данный момент, и версией, существовавшей на прошлой неделе? Сколько строк текста программы были изменены в данной версии? Какие файлы изменяются чаще всего?». Подобная информация бесценна при отслеживании ошибок, аудите, оценке производительности и качества.

Как продвигается дебаггинг?

Подсказка 24: Занимайтесь устранением проблемы, а не обвинениями

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

Подсказка 25: Не паникуйте

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

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

Подсказка 26: Ищите ошибки вне пределов операционной системы

Исходите из предположения, что с операционной системой, базой данных и прочим ПО все в порядке. Если вы «внесли всего одно изменение», и система перестала работать, то, скорее всего, именно оно является причиной случившегося, каким бы абсурдным ни казалось это утверждение. Если не знаете, с чего начать, то всегда можете положиться на старый добрый двоичный поиск.

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

Подсказка 27: Не предполагайте – доказывайте

То удивление, которое вы испытываете, когда что-то идет не так как надо, прямо пропорционально уровню веры в корректность программы. Поэтому, столкнувшись с неожиданным сбоем в работе программы, вы должны смириться с тем, что одно или более ваших предположений неверны. Не доверяйте слепо фрагменту кода, вызвавшему ошибку, только потому, что «знаете», что он работает нормально. Вначале докажите это - в реальном контексте, с реальными данными и с реальными граничными условиями.

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

Подсказка 28: Изучите язык обработки текстов

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

Они также облегчают создание генераторов кода, которые будут рассмотрены далее.

Подсказка 29: Пишите код, который будет писать за вас код

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

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

Активные генераторы кода используются всякий раз, когда возникает необходимость в результатах их работы. Они могут быть крайне полезны для следования принципу «минимум дублирования». С помощью активного генератора кода вы можете использовать представление некоторого фрагмента знания и преобразовать его во все формы, необходимые вашему приложению. Это не является дублированием, поскольку эти формы являются расходным материалом и создаются генератором по мере необходимости. Когда нужно организовывать совместную работу двух совершенно разных сред, стоит подумать об использовании активных генераторов кода.

Глава 4: Прагматическая паранойя

Подсказка 30: Невозможно написать совершенную программу

За всю историю программирования никому не удалось написать ни одного совершенного фрагмента кода. Маловероятно, что вы станете первым. И когда вы примете это как факт, то перестанете тратить время и энергию впустую в погоне за призрачной мечтой.

Подсказка 31: Проектируйте в соответствии с контрактами

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

Контракт между подпрограммой и любой потенциально вызывающей ее программой может быть сформулирован так: «Если вызывающая программа выполняет все предусловия подпрограммы, то подпрограмма гарантирует, что по завершении ее работы все постусловия и инварианты будут истинными». Если одна из сторон нарушает условия контракта, то применяется предварительно согласованная мера, например, добавляется исключение или происходит завершение работы программы. В разработке придерживайтесь классических принципов заключения контракта: прописывая предусловия, будьте крайне въедливы, а в том, что касается постусловий, наоборот, не давайте лишних обещаний.

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

Подсказка 32: Пусть аварийное завершение работы программы произойдет как можно раньше

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

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

Подсказка 33: Если что-либо не может произойти, воспользуйтесь утверждениями, которые гарантируют, что это не произойдет

Всякий раз, когда вы начинаете думать в ключе: «Ну конечно, такого просто не может произойти», удостоверьтесь в этом с помощью кода. Самый простой способ осуществить это – использовать утверждения. В большинстве реализаций языков С и С++ имеется некоторая разновидность макроса assert или _assert, который осуществляет проверку логического условия. Эти макрокоманды могут представлять огромную ценность. Допустим, если указатель, передаваемый к вашей процедуре, ни в коем случае не должен принимать значение NULL, пропишите обязательное выполнение этого условия.

Утверждения не должны использоваться вместо реальной обработки ошибок. Они лишь осуществляют проверку на то, что никогда не должно произойти. Существует точка зрения, согласно которой утверждения нужны только в период отладки, а когда проект сдан, превращаются в мертвый груз. Это чересчур оптимистичный взгляд: тестирование скорее всего не выявит всего, что может произойти в реальных условиях. Даже при наличии проблем с производительностью, отключайте только те утверждения, которые действительно оказывают на нее серьезное воздействие.

Подсказка 34: Пользуйтесь исключениями только в исключительных случаях

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

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

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

Подсказка 35: Доводите до конца то, что начинаете

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

Если нескольким подпрограммам одновременно необходимо более одного ресурса, добавляется еще два правила:

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

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

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

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

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

2. Измерение оценок предполагает приписывание им некоторых численных или лингвистических переменных2.
3. Оценка всегда имеет некоторую размерность, которая определяется природой ценности. Безымянные баллы не обладают научным смыслом. Существуют баллы знаний, умений, красоты, честности и т.д.
4. Шкалы оценок не являются универсальными, о чем свидетельствует широкое использование шкал порядка, прямых и пропорциональных оценок, равных и половинных интервалов, соотносительных попарных оценок и др.
5. Виды измерений также варьируются. Различают прямые, косвенные, совокупные и совместные измерения. При косвенных измерениях значение величины определяют на основании известной зависимости между искомой величиной и величинами, значения которых находят прямыми измерениями. Совокупные измерения предполагают сочетание результатов повторных измерений. Совместные измерения разноименных величин призваны обеспечить нахождение функциональной зависимости между ними, т.е. определенных законов.
6. Понимание процесса измерения оценок не является независимым от содержания теории, более того, оно всецело определяется ею.

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

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

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

Качество программного обеспечения как ценность.

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

Строго говоря, программное обеспечение тем или иным образом стало оцениваться уже с момента его возникновения, но лишь с конца 1960-х гг. этот процесс начал приобретать систематические формы. Во второй половине 1970-х гг. появляются первые монографии1, число которых затем устойчиво возрастает в экспоненциальной прогрессии. Ведется многоплановый и упорный поиск количественных мер признаков ПО, чему посвящены многочисленные работы в области метрики программного обеспечения. Среди таких мер быстро выдвигаются два лидера: во-первых, количество строк кода и, во-вторых, число ошибок на тысячу строк кода. Разумеется, к ним не сводится оценка программного обеспечения. В табл. 4.4 приводятся факторы качества ПО согласно ГОСТ 28195-892.

Таблица 4.4. Качество программного обеспечения

	Фактор качества ПО	Характеризуемое свойство
	Надежность	Характеризует способность ПО в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями
	Сопровождаемость	Характеризует технологические аспекты, обеспечивающие простоту устранения ошибок в ПО и программных документах и поддержания ПО в актуальном состоянии
	Удобство применения	Характеризует свойства ПО, способствующие быстрому освоению, применению и эксплуатации ПО с минимальными трудозатратами с учетом характера решаемых задач и требований к квалификации обслуживающего персонала
	Эффективность	Характеризует степень удовлетворения потребности пользователя в обработке данных с учетом экономических, вычислительных и людских ресурсов
	Универсальность	Характеризует адаптируемость ПО к новым функциональным требованиям, возникающим вследствие изменения области применения или других условий функционирования
	Корректность	Характеризует степень соответствия ПО требованиям, установленным в техническом задании, требованиям к обработке данных и общесистемным требованиям

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

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

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

Американские исследователи С. Канер и У. Бонд подвергают тщательному прагматическому анализу каждый из предлагаемых показателей, в том числе и тот, который так широко пропагандировал Т. Демарко, утверждая: "Я знаю лишь один показатель, который заслуживает собирания воедино раз и навсегда: подсчет дефектов". В этой связи необходимо дать вполне уверенный ответ на 10 вопросов:

1. Какова цель данного измерения?
2. Каковы границы данного измерения?
3. Какой признак мы пытаемся измерить?
4. Какова естественная шкала измерения данного признака?
5. Какова естественная изменчивость признака?
6. Какова метрика (функция, определяющая ценность признака)? Какой инструмент используется для осуществления процесса измерения?
7. Какова естественная шкала для рассматриваемой метрики?
8. Какова естественная шкала инструмента, с которого снимаются показания?
9. Как соотносятся ценности признака и метрики?
10. Каковы естественные и предсказуемые побочные эффекты используемого инструмента?

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

1. Ценности всегда входят в состав теоретических построений. Их оценка в значительной степени определяется задаваемой целью.
2. Окончательным критерием эффективности выступает успешность функционирования теории. В случае неудачи теория пересматривается. Таков механизм роста научного знания в информатике.

В . С . Щепин

CMA Small Systems AB

[email protected]

Ключевые слова: искусственный интеллект, модель окружения, фрактальный объект, фрактальная память, машина Тьюринга, структура исследования, диалог, обмен информацией

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

Введение

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

2. Окружающая среда как фрактальный объект

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

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

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

3. Декомпозиция среды на объекты

3.1. Исследование окружающей среды

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

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

Сканирование воспринимаемой части среды и выделение объектов;
Установление связей между объектами;
Занесение в память структуры объектов и их связей;
Смена "точки стояния" субъекта;
Повторение предшествующих шагов.

3.2. Объекты как опорные точки в среде

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

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

3.3. Связи между объектами

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

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

Связи могут храниться в памяти интеллекта в виде информации, управляющей его органами восприятия, а также в виде фрагментов текстов на ЕЯ.

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

4. Формирование структурной модели среды в памяти интеллекта

4.1. Обход объектов и построение модели в памяти интеллекта

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

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

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

Из принципа параллельного сканирования модели и окружающей среды приведенный выше алгоритм исследования среды запишется несколько иначе:

Найти объект, включая связь с предшествующим объектом.
Если объекта и/или связи нет в модели – включить их в модель.
Вернуться к шагу 1

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

4.2. Требования к модели окружающей среды

4.2.1. Планирование пути . Модель должна обеспечить возможность планирования пути для достижения определенного объекта, уже включенного в модель.

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

4.2.3. Расширение видимого горизонта. При обходе объектов, включенных в модель, повторение сканирования с точек вблизи объектов, может выявить новые объекты. Соответственно модель должна быть расширена в этих точках. Расширения модели привязываются к прежде известным точкам, что позволяет сохранить целостность картины мира.

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

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

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

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

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

4.3. Структура памяти для формирования модели окружения

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

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

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

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

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

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

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

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

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

4.3.4. Аргументы в пользу древовидной фрактальной структуры памяти. Перечислены ниже:

Древовидная структура - простейший вариант, достаточный для построения структурной модели исследования окружающей среды.
Структура нейрона также древовидна.
Поведение ИИ несложно описать в виде дерева действий - ситуаций.

Хорошо структурированные компьютерные программы древовидны.

5. Диалог как процесс обмена информацией

5.1. Диалог с точки зрения прагматики

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

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

5.2. Этапы диалога

Рассмотрим этапы диалога в свете аналогии с этапами исследования:

Выделение общей для обоих субъектам известной части модели окружения. По существу это выбор темы диалога. Задавая вопросы об объектах и связях, присутствующих в его модели, активный субъект находитструктурно совпадающее множество объектов и связей в модели другого участника диалога. Это может напоминать решение задачи Распознавания Неизвестного Окружения.
Поиск в модели пассивного субъекта фрагмента модели части окружения, неизвестной активному участнику диалога. Алгоритм такого поиска сводится к обходу известных объектов совпавшей части модели и исследование возможностей детализации объектов или появления «нового горизонта», на тех объектах, которые не имеют подобных продолжений в модели активного участника диалога. Исследование выполняется посредством соответствующих вопросов.
"Копирование" знаний в модель окружающей среды активного субъекта. Активный участник может выбрать наиболее интересующий его объект, содержащий новую информацию, переместить "курсор" в своей модели к этому объекту, переместить «курсор» другого участника диалога к тому же самому объекту и начать достройку своей модели в режиме диалога, задавая вопросы о новых объектах и связях между ними. При этом могут быть заданы вопросы типа:

Какие объекты есть?
Как связан каждый объект с исходной точкой?
Как связаны объекты между собой?

6. Выводы

1) Принципиальным свойством интеллекта является способность накапливать информацию о внешней среде и упорядочивать на основе этой информации свои действия, свое поведение в среде.

2) Структура памяти интеллекта соответствует структуре возможностей исследования окружающей среды интеллектом. Она должна быть фрактальной и скорее всего древовидной.

3) С точки зрения прагматики процесс исследования окружающей среды субъектом и исследование памяти другого субъекта в процессе диалога между субъектами имеют сходную структуру.

4) В качестве одного из субъектов диалога может рассматриваться ИИ (компьютер). В этом случае структурное построение компьютерной памяти по принципу Фрактальной Машины Тьюринга может оказаться весьма эффективным, так как соответствует структуре памяти человека.

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

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

Structured model of dialog"s pragmatics based on fractal

Intelligence-environment model

V. S. Shchepin

Key words: artificial intelligence, environment model, fractal object, fractal memory, Turing machine, structure of investigation, dialog, information exchange.

The aim of this paper is to investigate the structure of pragmatics in dialog interactions. The following logical scheme was chosen: An Intelligence must first of all percept an environment then build an internal model of this environment and then be capable to exchange information from the model with another Intelligence, natural or artificial. How it could be done? This is a problem. The first suggestion is that environment is fractal i.e. it"s decomposition may be infinite at any point. The second suggestion is that an Intelligence memory should be fractal too. Fractal memory is needed to reflect a fractal reality of an environment.

During his activity in the environment the Intelligence must structure the environment in his memory. A structured model of environment should include objects and object’s relationships descriptions. The object’s description must contain information sufficient for object’s recognition by the Intelligence. The objects relationship’s description must contain information needed for checking the relationship in the environment. In fact relationships between environment’s objects are established by some actions of the Intelligence. In a process of the dialog between two Intelligences two structured environment models are first compared for common fragments and then extended by the unique fragments from both sides ensuring an exchange of experience. An environment is considered as static for simplicity.

The study of these questions may give us a qualitative understanding of what is knowledge, how it can be used and where is a boundary between known and unknown. The structured model proposed by this paper can serve for example as a model of interaction between a programmer and a computer. Hence the ideas expressed here may be useful for a computer memory and computer software perspective design including more powerful languages and operating systems for man-computer and for computer-computer interactions.

Цикл Колба – одна из моделей обучения, основанная на поэтапном формировании умственных действий.

Ее автором является специалист по психологии обучения взрослых Дэвид Колб (David A. Kolb). По его мнению, процесс обучения представляет собой цикл или своеобразную спираль. Это своего рода цикл накопления личного опыта, в дальнейшем – обдумывания и размышления, и в итоге – действия.

Основные 4 этапа модели Колба таковы:

1) Непосредственный, конкретный опыт (concrete experience) – любой человек должен уже иметь некоторый опыт в той области или сфере, которой хочет обучиться.

2) Наблюдение и рефлексия или мыслительные наблюдения (observation and reflection) – данный этап предполагает обдумывание и анализирование человеком имеющегося у него опыта, знаний.

3) Формирование абстрактных концепций и моделей или абстрактная концептуализация (forming abstract concepts) – на этом этапе происходит выстраивание некой модели, описывающей полученную информацию, опыт. Генерируются идеи, выстраиваются взаимосвязи, добавляется новая информация относительного того, как все работает, устроено.

4) Активное экспериментирование (testing in new situations) – последний этап предполагает экспериментирование и проверку на применимость созданной модели, концепции. Результатом этого этапа является непосредственный новый опыт. Далее круг замыкается.

Название этапа	Сущность	Результат
Полученный опыт	Человек пробует сделать что-либо из того, чему учится, на практике, причем так, как умеет сейчас, вне зависимости от того, являются ли его навыки достаточными.	Понимание необходимости дальнейшего обучения (не получилось или получилось не слишком хорошо) либо вывод о том, что и так все хорошо Очевидно, что в последнем случае дальнейшие шаги не нужны.
Рефлексия	Анализ плюсов и минусов приобретенного опыта, выводы о том, что было сделано удачно, а что можно было бы сделать лучше или по-другому.	Подготовленность к необходимости изменений и обучению, в ряде случаев – полное или частичное знание того, как действовать правильно.
Теория	Получение теоретических знаний о том, как действовать правильно в связке с приобретенным опытом и его анализом.	Получены правильные алгоритмы действий на будущее.
Закрепление на практике	Отработка теории, перевод знаний в умения и навыки, корректировка со стороны руководителя.	Полностью или частично отработаны и закреплены необходимые навыки.

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

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

конкретный опыт (Concrete Experience);
рефлексивное наблюдение (Reflection);
абстрактное моделирование (Abstract Conceptualisation);
активное экспериментирование (Active Experimentation).

Английские психологи П. Хоней и А. Мамфорд (P. Honey, A. Mumford) описали различные стили обучения , а также разработали тест для выявления предпочитаемого стиля обучения (Honey Mumford Preferred Learning Style Test).

Выделили следующие четыре стиля обучения :

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

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

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

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

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

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

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

«Если бы вы писали книгу о переменах и хотели передать будущим читателям максимум знаний, вам бы понадобилось:

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

Ниже примерно приведена одна из самых распространенных структур интерактивного урока , построенного согласно принципам Колба:

1. Мотивация и объявление новой темы
2. Закрепление (повторение) пройденного – 20 % времени от общей длительности урока;
3. Изучение нового материала – 50 % времени от общей длительности урока;
4. Оценивание – 10 % времени от общей длительности урока;
5. Подведение итогов урока (дебрифинг, рефлексия) – 10 % времени от общей длительности урока.

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

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

Табл. 1. Типы обучающихся и их предпочтения

Процесс совершенствования навыков, повышения профессионального мастерства никогда не прекращается: его можно представить в виде бесконечной спирали развития компетентности (рис. 4).

Спираль развития компетентности

Специалист в сфере управленческого консультирования Рег Реванс сформулировал своего рода закон успешной бизнес-адаптации : «Компания (и сотрудники) будет процветать до тех пор, пока темп обучения в ней будет выше (или равен) темпу изменения внешней среды».

Есть мнение, что модель Д. Колба является перепевом классической теории поэтапного формирования умственных действий, разработанной отечественным психологом П.Я. Гальпериным с сотрудниками ещё в начале 1950-х гг. Впоследствии данная теория получила развитие работами специалистов по дидактике – в первую очередь, Н.Ф. Талызиной (Талызина Н.Ф., Теоретические проблемы программированного обучения. Изд-во МГУ, 1969).

Историю термина «прагматика» (греч. «прагма» – дело, действие) принято вести от Ч.Морриса, выделившего в семиотике, теории знаковых систем, область прагматики наряду с областями семантики и синтактики .Как любая наука, прагматика имеет свой объект, предмет, субъект и метод исследования. Объектом исследования прагматики может быть речевой акт, слово, текст или совокупность текстов. Позже термин «прагматика» стал употребляться в языкознании, но не получил в среде лингвистов однозначного толкования.

Прагматика понималась как наука об употреблении языка , наука о языке в контексте, или наука о контекстуальности языка как явления , исследование языка (или любой другой системы коммуникации) с точки зрения преследуемых целей, различных способов их достижения и условий, при которых эти цели достигаются , теория интерпретации речевых актов , изучение языковых средств, служащих для обозначения различных аспектов интеракционального контекста, в котором выражается пропозиция . В отечественной лингвистике прагматика также понимается как теория, изучающая прагматические параметры литературной коммуникации [Арутюнова 1981], а также текста в его динамике, соотнесенного с «я» творящего текст человека [Степанов 1981, 1985].

Прагматика рассматривается как «значение минус условия истинности» ; это область изучения тех аспектов значения, которые не охватываются семантической теорией . Прагматика понимается как теория речевого воздействия [Киселева 1978]. Назначение прагматики видится в изучении языка как орудия общественной практики человека [Сусов 1974].

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

Серьезная трудность заключена во взаимоопределении понятий прагматики и семантики. По мнению Г.В.Колшанского: «…Любое речевое образование есть результат понятийной обработки какого-либо познавательного акта, что неизбежно и придает любому осмысленному высказыванию когнитивный характер, относимый обычно к семантике в широком смысле слова. В этом плане вполне понятно устремление лингвистов не отрывать фактор прагматического функционирования языка в целом от его содержательного характера и включать, таким образом, прагматику лишь как компонент в единую семантику языковых коммуникативных единиц» [Колшанский 1985: 175].

Как бы ни были разнообразны варианты определения прагматики, основным в них можно считать то, что они исходят из схемы Ч.Морриса. Одним из свойств знака является отношение между знаком и его пользователем – человеком. Человеческий фактор признается в качестве ведущего понятия прагмалингвистики [Арутюнова 1981 ; Булыгина 1981; Гак 1982; Степанов 1981, 1985 и другие]. Прагматика изучает все те условия, при которых человек использует языковые знаки. При этом под условиями пользования понимаются условия адекватного выбора и употребления языковых единиц с целью достижения конечной цели коммуникации – воздействия на партнера.

В современных исследованиях прагматики все большее значение приобретает субъект деятельности, который в прагматике понимается как «абстрактный индивид (виртуальный коммуникант), являющийся носителем комплекса характеристик: психологических, социальных, географических, национально-культурных и т.д.» [Багатурия 2004: 4]. Эта возрастающая роль субъекта определяет выбор методов исследования предмета прагматики. Если рассматривать прагматику как науку, изучающую язык с точки зрения «использующего его человека в аспекте выбора языковых единиц, ограничений на их употребление в социальном общении и эффекта воздействия на участников коммуникации» , следует отнести эту науку к категории практических, основанных на индуктивных методах познания действительности.

Деятельность по передаче человеком знакового сообщения изучается прежде всего как процесс коммуникации – всем циклом научных дисциплин, изучающих коммуникацию, и первые трудности в выделении собственно предмета прагматики возникают именно в этом отношении. Как считает В.Г.Колшанский: «Прагматика как отрасль, изучающая отношение человека к языковому знаку, вообще теряет свой смысл по той причине, что отношение к знаку не может выявляться в языке помимо пользования самим языком, что и является по определению коммуникацией» (выделено нами – А.Ш.) [Колшанский 1985: 131].

Нередко прагматику определяют посредством акцентуации на отдельном аспекте процесса коммуникации, а именно – на воздействии или коммуникативном воздействии : «…Независимо от определения прагматического аспекта языка, лейтмотивом остается, как правило, идея о воздействии на поведение человека с помощью вербальных средств речевых актов» [там же: 139].В настоящее время коммуникативное воздействие понимается достаточно широко. Например, Ю.К.Пирогова выделяет «…Воздействие на сознание путем выстраивания рациональной аргументации (убеждение), или воздействие на сознание через эмоциональную сферу, или воздействие на подсознание (суггестия), воздействие с помощью вербальных (речевое) или невербальных средств» [Пирогова 2001: 541]. Речевое воздействие в лингвистике изучается в связи с социальной стороной речевого общения [Федорова 1991: 46-50]. В теории речевой коммуникации речевое общение представляется в виде двухуровневого образования, включающего социологический и коммуникативный уровни. Под содержанием коммуникативного уровня понимается обмен информацией между собеседниками, а содержание социологического уровня предполагает социальное взаимодействие участников коммуникации, то есть их влияние на поведение, образ мыслей и чувства друг друга. Речевое воздействие определяется как речевая форма социального воздействия говорящего на слушающего в процессе общения [там же: 46].

Нам представляется, что выделение предмета прагматики текста СМК не может целиком строиться на понятии «воздействие». Ряд материалов СМК действительно имеет цель воздействовать на знания, отношения и намерения адресата, цель добиться нужной для адресанта оценки определенного объекта – например, в рекламе или в призыве проголосовать на выборах. Однако в текстах СМК можно найти и другие цели, например, ведущую цель «развлечь» или увлечь реципиента (привлечь его внимание). В этом случае издание удовлетворяет психическую потребность субъекта в развлечении, стимулируя потенциального покупателя приобретать все новые и новые выпуски развлекательных материалов издания. Так, в материалах «желтой» прессы в субъекте-реципиенте инициируются те состояния, за которые тот готов платить: страх, удивление, негодование, умиление и другие. Аналогичным образом художественно-публицистические тексты апеллируют к «чувству прекрасного», пониманием которого, с достаточной степенью вероятности, обладает аудитория этих текстов. В подобных случаях оснований говорить о «воздействии на знания, отношения и намерения адресата...» примерно столько же, сколько в случае трансляции по каналу СМК футбольного матча. Можно ли в развлекательных или в художественно-публицистических материалах найти признаки коммуникативного воздействия? В широком смысле, безусловно, можно. При этом мы рискуем опять вернуться к всеобъемлющим определениям (в данном случае – понятия воздействия) и потерять предмет исследования, необходимый нам для реализации в первую очередь методических задач. Например, по мнению Г.Г.Матвеевой: «…Воздействие, или управление поведением, является целью всякого (выделено нами – А.Ш.) общения. Общение – это социальная ориентация, в которой реализуется приспособительная функция человека. Она сводится к функциональным регулирующим целям. Цели эти имеют прямое и непрямое воздействие. При последнем тоже происходит управление, например при информировании, при выражении оценки, отношения, на основании которых тоже может быть принято решение о регуляции поведения» [Матвеева 1984: 44].

На наш взгляд, недопустимо смешивать понятия воздействия и пафоса СМК. Как отмечает Ю.В.Рождественский: «…Пафос массовой информации состоит в том, чтобы сделать сообщения о событиях (в принципе, не касающихся получателя) интересными для него, так чтобы он стал вовлеченным в эти события духовно. Поэтому массовая информация подбирает сообщения о событиях и комментирует их так, чтобы ее материалы вызывали интерес. Это достигается вызыванием эмоций, любознательности, страха и сострадания. Цель формирования такой эмоции состоит в том, чтобы включить получателя информации в массовые действия» [Рождественский 1997: 593].

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

Таким образом, понятие коммуникативного воздействия на практике эффективнее связывать с теми текстами СМК, содержание которых призвано сформировать картину мира реципиента, понимание им действительности в отношении избранного объекта или группы объектов. Как мы покажем в дальнейшем, данные тексты можно сгруппировать по общим целям: они могут быть направлены на убеждение, побуждение или рекламирование. В этих случаях (текстах) прагматика текста СМК связана с воздействием, однако как понятие имеет под собой собственную предметную реальность. Доказательством этого может служить, например, прагматика текстов СМК с ведущими целями по информированию или развлечению аудитории, не имеющих явно выраженного потенциала воздействия.

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

Такие единицы выделяет Л.А.Киселева: «…Прагмемы – единицы разных уровней языка, обладающие прагматической заданностью: они предназначены для регуляции человеческого поведения. К ним относятся прежде всего те языковые единицы, которые отражают явления эмоционально-волевой сферы психики адресата и через нее – его интеллектуальной сферы (путем эмоционального внушения, заражения, убеждения) с целью регуляции его поведения. Это те единицы, которые принадлежат к ядру прагматического поля (например эмоциональные, эмоционально-оценочные и побудительные междометия, а также эмоционально-оценочные слова типа отвратительный, чудный, голубчик, прелесть и т. п.)» [Киселева 1978: 106].

Подобное направление исследования критикуется, в основном, за изолированность рассмотрения языковых единиц, за невыраженность связи знака с реципиентом. Как отмечает В.Н.Комиссаров: «…Нельзя привести никаких доказательств того, что так называемые эмоциональные слова (типа приводимых в подобных работах – безобразный, восхитительный и т.д.) непосредственно обращены к чистой психике, минуя нормальное интеллектуальное восприятие подобных единиц, имеющих очевидное понятийное содержание, относящееся к разряду так называемых оценочных как продукта мыслительной деятельности человека» [Комиссаров 1990: 140–141].

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

Итак, определим нашу собственную позицию в исследовании предмета прагматики : исследованию подлежит скорее не прагматический аспект языка, а прагматический аспект конкретного текста, входящего в совокупность текстов, в нашем случае – СМК. В совокупности текстов СМК необходимо выделить авторские интенции, имеющие устойчивый характер, повторяющиеся уровни воздействия и, безусловно, языковые средства, успешно реализующие установленный комплекс целей и задач. Фактор успешности языкового знака в условиях реализации комплекса целей и задач конкретного текста позволяет оставаться в рамках отношения «знак – реципиент», а не ограничиваться сугубо абстрактными отношениями знаков в системе языка.

Сама по себе логика выделения предмета прагматики в зависимости от сферы употребления текста (в социальной практике) не нова. Как пишет Г.В.Колшанский: «…Если понимать под прагматикой речевого общения достижение какой-либо цели – практической, теоретической, физической, интеллектуальной и т. д., то можно в какой-то степени говорить о характеристике использования человеком языкового знака, но только, видимо, в смысле «успешно» или «неуспешно» была осуществлена коммуникативная цель. Такой успех вербальной коммуникации может быть определен как для индивидуального речевого акта, так и в целом для некоторого социального коллектива. Вопрос о целесообразности разработки критериев «прагматической успешности» речевого акта может быть решен только в чисто прикладном плане и применительно к конкретным областям языкового общения человека » (выделено нами – А.Ш.) [Колшанский 1985: 149].

Цикл обучения Дэвида Колба: введение. Структурная модель прагматики диалога на основе фрактальной модели "интеллект–окружающая среда"