КУЛЬТУРА
Почему пишутся "програмы па-руски"
В статье "Писать по-русски" (см. PC Week/RE, N 46/2006, c. 52) профессор А. А. Шалыто написал о том, что ИТ-специалисты зачастую плохо владеют русским языком, чем в немалой степени объясняется и низкое качество программной документации. Косвенно была затронута и тема взаимозависимости логики мышления и дисциплины оформления технических и научных документов.
На мой взгляд, проблема невысокой грамотности ИТ-кадров выходит далеко за рамки создания программной (технической) документации и заслуживает более пристального внимания. Обвиняя программистов в том, что они-де оформляют свои работы абы как и пишут романы, а не инженерные/научные документы, мы вряд ли заставим их изменить свое отношение к родному языку. Для этого нужны весьма мощные стимулы, нужно понимание того, что разработка качественного программного обеспечения, особенно сложного, не в последнюю очередь зависит от уровня владения русским языком.
На первый взгляд взаимосвязь эта неочевидна. Подавляющему большинству команд разработчиков всегда был свойственен раздельный подход к созданию собственно программы (программного кода) и технической документации с явным перекосом в пользу первой: мол, программа - это главное, а "дока" - так, для "ламеров" и "чайников". (Имеет место и элементарное недомыслие. Как бы работали апологеты минимума комментариев в коде и куцей документации, например, при системном программировании, не имей они сегодня соответствующей литературы и баз знаний типа MSDN? Им бы жизни не хватило на изучение исходников и трассировку кода.) Так стоит ли удивляться тому, что низкое качество программной да и другой технической (на АСУ, ИС) документации стало притчей во языцех? Кого-то "сочинения" программиста о его программном шедевре посмешат, кого-то огорчат, ну и что с того? Ну неполная, малоинформативная документация, ну кривая, малопонятная - и что?
Формально каждая более-менее приличная фирма-разработчик имеет подразделение технических писателей, которые не даром свой хлеб едят. Во многих из этих фирм даже есть подразделения типа ОТК. Принимая программы в архив, они трогательно проверяют комплектность, качество документации, соответствие ее оформления ГОСТам, стандартам предприятия (если таковые имеются) и т. д. Наконец, есть группа "горячей" поддержки; пусть юзеры звонят, коли чего неясно... Программистское же дело - код, функциональность и соблюдение срока. Лишь бы заказчик финансовый акт подписал.
Такой простой и, увы, примитивной логики придерживаются многие российские ИТ-фирмы. Если бы ей следовали только программисты, было бы полбеды. Но беда в том, что обычно культура (как и бескультурье) создания ПО во многом определяется отношением к этому вопросу руководства компании и отделов разработки. Не последнюю роль в этом играют и методы управления проектами, уровень производственной культуры и отношение к заказчикам, стиль сотрудничества с ними, а также подход к оплате труда программистов, к организации бизнес-процессов разработки и инвестициям в технологии.
При написании данной статьи автор базировался на личном пятнадцатилетнем опыте разработки разных систем (АСУ, ПО, ИС) в различных отраслях (газотранспортной, машиностроительной, в создании ПО), в том числе на десятилетнем опыте составления технической документации на эти системы. Наконец, последние три года я трудился в крупной региональной ИТ-компании в качестве начальника отдела разработки и сопровождения технической документации, а также был главным редактором и техническим писателем по совместительству. Работа велась с пятью группами разработчиков разных возрастов - от 21 года до 50 лет. Анализ результатов их деятельности и коллег на предыдущих местах работы убедил меня в том, что при прочих равных обстоятельствах те, кто хорошо владеет русским языком, создают куда более качественные и эффективные программы и информационные системы, нежели их "малограмотные" коллеги. Эту закономерность я наблюдал и продолжаю наблюдать как у современных молодых специалистов, так и у разработчиков советской "закалки".
| Повышать культуру русского языка можно и нужно не столько в контексте создания программной документации, сколько в контексте качества разработки программы в целом. |
Убедился я и в том, что повышать культуру русского языка можно и нужно не столько в контексте создания программной документации, сколько в контексте качества разработки программы в целом. Разумеется, это возможно только там, где и качество программной продукции, и культура разработки на деле, а не на словах поощряются руководством. (Мне хочется предостеречь многих технических писателей и коллег, переживающих за язык технической документации, от бессмысленной траты нервов и времени на многочисленные чистки и правки документов после разного рода "код-мейкеров" и прочих, простите, "ИТ-художников". Не лезьте из кожи вон, чтобы выпустить достойную документацию, если условия ее создания неудовлетворительные: нет смысла делать документацию лучше, чем сама программа. Каждая компания заслуживает того имиджа, которому соответствуют методы и результаты ее деятельности. Не пишите руководству больше двух служебных записок о проблемах качества: именно двух вполне достаточно, чтобы понять реакцию и политику начальства, по крайней мере в отношении документации.)
Взгляд на проблему извне
Чтобы уяснить взаимосвязь культуры разработки ПО с культурой речи, вспомним о таком понятии, как дисциплина. Начнем с достаточно очевидного.
Разработка и производство любого продукта, будь то ПО, здание, одежда, вино или сыр, опирается на соблюдение производственной и технологической дисциплины (качество исходного сырья и материалов в данном контексте не в счет). Именно от этого зависит, какой продукт мы получим - качественный или некачественный. Говоря, что "при создании ПО была нарушена технология", мы имеем в виду игнорирование разработчиком тех или иных правил, предписанных бизнес-процессами и стандартами создания ПО, что может привести как к серьезным техническим ошибкам (в архитектуре программы, программных механизмах, программном коде), так и к срыву производственных процессов (нарушению плана-графика работ, невозможности автоматизации процессов тестирования и сборки документации и т. д.).
Вывод очевиден: пока хотя бы на уровне конкретного проекта не будут приняты формальные правила разработки в соответствии с какой-либо методологией (будь то RUP, XP, SCRUM или иная, в том числе и оригинальная) и не будет налажена дисциплина их соблюдения, ни о серьезной автоматизации разработки, ни о стабильном качестве программ не может быть и речи. Поэтому разработчику следует понимать и помнить, что и методология, и технология не есть модные романы, прочитав которые вы имеете право говорить, что владеете ими как дисциплиной (примечательно, что предметы обучения ранее именовались дисциплинами!).
Теперь посмотрим, как дисциплина русского языка влияет на дисциплину разработки ПО.
И программный код, и "естественный код" (документация) являются отображением мыслей программиста. Подобно тому, как простота и ясность архитектурных конструкций, программных механизмов и кода зависят от того, насколько хорошо разработчик владеет своим ремеслом, так структура, простота и ясность документации отражают его уровень владения родным языком. Владения не только в смысле знания орфографии и грамматики (обычные ошибки могут быть исправлены корректором, а частично и текстовым процессором), но прежде всего в смысле умения грамотно донести свои мысли до коллег и будущих пользователей программы. Если вы плохо владеете языком (и русским, и алгоритмическим), много ли пользы от вашей писанины, будь то документация или программа? Если ваша речь туманна, запутанна и витиевата, как быстро вы обсудите ваши проблемы с коллегой или поймете, почему эти "бестолковые пользователи" не могут правильно работать с вашей программой? Так кто же "ламер"? Юзер является "ламером" вашей программы, или это вы "ламер", не способный установить нормальный контакт с юзером ни на языке пользовательского (!) интерфейса, ни даже на общем с ним естественном языке (посредством той же пресловутой документации)? Может, пора ввести понятие Russian-programmer guide и издать "The communication guide for Russian programmers"?
Вывод: цель программиста - не только создание работоспособного кода, но и установление эффективных коммуникаций пользователя с программой или, если хотите, программы с пользователями. Не решив этой задачи, не удивляйтесь, если покупатель предпочтет вашей программе другую, пусть менее функциональную, но зато хорошо документированную и удобную.
Другую связь между дисциплиной русского языка и дисциплиной разработки позволит прояснить пример, хорошо известный из области создания надежного ПО и автоматического его тестирования: чтобы обеспечить надежность и автоматизацию тестирования ПО (как правило, сложного), программный код должен быть написан с соблюдением четко определенных правил, начиная с соглашений о пространстве имен, порядке применения указателей, работе с памятью и т. д. и заканчивая правилами записи программного кода. Эти правила делают ваш код доступным для "понимания" компилятором и в некоторой мере являются гарантом надежности. Если провести параллель с культурой русской речи, это означает необходимость употребления в тексте программного проекта определенной лексики (правильной терминологии), свободной от слов-паразитов, двусмысленных выражений, запутанных фраз и речевых оборотов. Следуя этим правилам, вы сделаете ваши мысли и речь (как устную, так и письменную) понятными для ваших коллег. Только в таком случае вы можете рассчитывать на адекватную реакцию сотрудников.
Взгляд на проблему изнутри
Приведенные примеры иллюстрировали взгляд на проблему взаимосвязи культуры русской речи и культуры разработки ПО извне, на уровне коммуникаций и взаимопонимания создателей и пользователей программы. Теперь рассмотрим проблему изнутри. Суть ее заключается в том, что с детских лет механизмы мышления человека, его понятийное и логическое пространство в значительной степени опираются на семантику естественного языка, гибкость его семантических конструкций. Возникающие при этом ассоциативные связи формируются неосмысленно, на уровне подсознания. При этом активно задействуются вербализация (всем хорошо известный эффект проговаривания про себя своих мыслей), проявляются особенности естественного языка и уровень владения им при построении рассуждений. Язык здесь используется в качестве своеобразного смыслового лего-конструктора. Так у человека вырабатывается индивидуальный стиль мышления, который закрепляется в его речи.
Вербализация мыслительных образов характерна для процесса создания ПО, не связанного с материальными ассоциациями и естественными законами, в отличие, например, от работы инженеров-машиностроителей, которые могут прибегнуть к реалистичному представлению образов физических предметов и их поведения. Поэтому программист в большей степени вынужден опираться на ассоциации, порождаемые его индивидуальным стилем. Вербализация мыслительных образов неосознанно переносится программистом на его разработки, формируя уникальный стиль, если хотите, почерк программирования.
На качество разработки ПО влияют такие особенности естественного языка, как его сложность (число словоформ и правил их образования, фразеология, а также многозначность слов и понятий) и гибкость (инвариантность одинаковых по смыслу синтаксических конструкций). В этом отношении русский язык в сравнении, например, с английским более труден для изучения. Однако такая сложность и гибкость в некоторой степени мешают при создании программ. Именно из-за них речь, которой мы привыкли пользоваться в повседневной жизни, при коллективной разработке ПО не всегда пригодна. Стиль мышления разработчика через вербализацию транслируется на его алгоритмические построения, его программный код. Добавьте сюда наше традиционное отношение к разработке ПО как к искусству, творчеству, а не как к инженерной дисциплине, и становится ясным, почему не только документация, но и архитектура, и код программ отечественных разработчиков в массе своей являются одними из самых сложных и запутанных даже для них самих (отсюда и небезосновательные анекдоты о коллективной разработке российских программистов).
Все вышесказанное подтверждает анализ и программного кода, и документации ПО: те, кто хорошо владеет речью, создают более ясный, четко структурированный и совершенный с точки зрения коллективной разработки и программной инженерии код, нежели те, кто с родным языком не в ладах. Об этом свидетельствует следующий пример: большинство известных гуру программирования, особенно разработчики методологий, пишут хорошо структурированные и стилистически выдержанные книги (хотя, безусловно, в них есть большая доля труда переводчиков, редакторов и корректоров)!
Вывод: вербализация может быть как помощником, так и врагом. Помощником, когда помогает мыслительному процессу правильно формировать понятийное пространство решаемой задачи, устанавливать взаимосвязи и взаимодействия между понятиями, а в дальнейшем правильно переносить результаты мыслительного процесса в базу знаний проекта и пространство коммуникаций. Врагом - если делает результаты понятными только вам и недоступными для других. В этом случае вы уподобляетесь пресловутой собаке, которая все понимает, а сказать не может. Очевидно, что эффективность вербализации и, следовательно, мышления в значительной степени определяется уровнем владения родным языком.
Управление проектами и инженерные решения
Еще в 80-х годах прошлого века Дж. К. Джонс в своей известной книге "Методы проектирования" (Пер. с англ. Изд. 2-е, доп. М.: Мир, 1986) недвусмысленно заметил: "Проектировщики не осознают, что им надо научиться отличать утверждение, которое они считают истиной, от утверждения, истинность которого может быть доказана". Этот постулат можно с успехом применить не только к техническим специалистам и техническим аспектам проектирования, но и к специалистам таких областей ИТ-инженерии, как управление проектами, управление требованиями, бизнес- и системный анализ.
Упомянутый выше аспект эффективного использования естественного языка в разработке ПО является одним из важнейших в дисциплине управления проектами. Сегодня почти любая сложная программа или автоматизированная/информационная система является результатом труда целого коллектива. Управление разработкой, управление проектом при любой степени использования PM-инструментов и степени формализации плана-графика работ опирается на естественные коммуникации и естественный язык. И чем сложнее проект, чем сложнее им управлять, тем большую роль играет качество естественных коммуникаций, в том числе и культура речи.
Всем хорошо известно, что умение просто и доступно излагать свою точку зрения - одно из главных качеств лидера, необходимое при решении вопросов как со своими подчиненными, так и с вышестоящим начальством. Речь не только о "хорошо подвешенном языке", но и о том, что мы называем "железной" аргументацией. Той, что помогает всем быстро и с минимальным риском принимать верные решения. Однако часто специалисты с "железной" аргументацией лишены "хорошо подвешенного языка" и наоборот. В результате нередко руководитель или специалист, не испытывающий затруднений с изложением своих мыслей, выигрывает у своего коллеги, если тот, несмотря на все приводимые им доводы, плохо владеет родной речью. А последний, в свою очередь, может так запутать руководителя, принимающего решения, что он или предпочтет найти другого специалиста, или вовсе не станет принимать каких-либо решений. И будет по-своему прав!
Таким образом, неумение ясно изложить и защитить свое видение проблемы может приводить к принятию неверных решений, как управленческих (например, при выборе методологии разработки, исполнителей, состава работ, оценке их трудоемкости), так и технических (ошибки в выборе платформы, архитектуры системы и др.).
Культура речи очень важна и в таких проектах, где части системы создаются конкурирующими группами разработчиков. Мне неоднократно приходилось быть участником и свидетелем совещаний, больше напоминающих птичьи базары, в результате которых вместо выработки согласованной точки зрения на проблему и принятия ответственных решений каждая группа идет своим путем, не сообразуясь с коллективными интересами. Характерный итог подобных совещаний - непринятие мер по коррекции проекта. В таких случаях принятые ранее решения зависают, а сам проект подвергается риску провала даже при наличии нужного времени и ресурсов.
Что делать?
Сегодня, когда сложность ПО постоянно повышается, довольно отчетливо проявляется тенденция роста доли писательского труда в общем объеме работы программиста. Особенно если создаваемое им ПО предназначено для другого ИТ-специалиста. Характерный пример - создание различных операционных систем, middleware, ПО с открытым исходным кодом. Очевидно, что разработчику волей-неволей приходится быть отчасти и техническим писателем. Эту тенденцию также подтверждает непрерывное увеличение выпуска сложных ИТ-систем и литературы по программированию.
В таких условиях проблема культуры речи будет все острее вставать перед программистом, и она не может быть решена за счет технических писателей. Сформировать культуру речи у программиста (будь то студент или уже состоявшийся специалист), даже N-кратно решив задачу хорошо написанной документации какими-либо изощренными методами (вроде тех, о которых пишет А. А. Шалыто), невозможно, если он сам не осмыслит проблему. Одно дело избавить текст документа от орфографических и грамматических ошибок, другое - создать по-настоящему ясную и дружественную по отношению к пользователю документацию (usability). То же самое относится и собственно к программе, начиная от удобного интерфейса пользователя и заканчивая программными модулями с элегантной архитектурой и интерфейсами, легко понимаемыми всеми, кто будет работать с вашей программой в дальнейшем.
Поэтому стимулами к повышению культуры русского языка и русской речи у специалиста могут быть:
- уважение к родному языку (основывается на воспитании, культурных традициях и эстетически развитом вкусе);
- улучшение навыков коллективной разработки, предполагающее уважение к коллегам и самому себе;
- осознание и восприятие русского языка как мощнейшего средства повышения своего интеллекта и качества мышления.
Для инженеров и научных работников это означает возможность профессионального, карьерного и личностного роста, удовлетворенность достигнутыми результатами.
Анализируя влияние устной и письменной речи на свое мышление и сознательно повышая грамотность, программист может существенно улучшить качество не только программ, но и собственного мышления как такового. Дисциплина изложения результатов размышлений позволит разработчику избавиться от неверного направления и развития мыслей (не случайно в русском языке есть такое понятие, как "криво мыслить"), а также сократить число итераций для достижения необходимого качества работы. А это означает более качественное проектирование с меньшими умственными и временными затратами, заслуженное уважение в коллективе и, наконец, больший заработок. Полагаю, такая перспектива должна явиться хорошим стимулом для улучшения своего русского и культуры речи, по крайней мере для будущих ИТ-специалистов.
Руководители же подразделений разработки и проджект-менеджеры должны иметь ясное представление о важности культуры русского языка и о том, насколько хорошо им владеют подчиненные. Это даст возможность точнее распределять задания между исполнителями, более четко осуществлять постановку задачи на стыках областей ИТ-инженерии (обследование, бизнес- и системный анализ, проектирование, кодирование, тестирование) и грамотно снижать проектные риски, связанные с коммуникациями специалистов этих областей.
С автором можно связаться по адресу: mgolovko@yandex.ru.
