«Трудности» перевода в IT-проектах и как их преодолеть

0
Фрагмент нашел исследователь Амир Афендин2/17/2025

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

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

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

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

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

Необходимость в переводе затрудняет коммуникацию и ослабляет интенсивность переработки знаний.

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

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

Словарь этого ЕДИНОГО ЯЗЫКА состоит из имен классов и основных операций. Язык содержит термины для обсуждения правил, явно сформулированных в модели. Дополнением к ним служат термины из принципов высокоуровневой организации, которым подчинена модель (например, КАРТЫ КОНТЕКСТОВ и крупномасштабные структуры, рассматриваемые в главах 14 и 16). Наконец, этот язык обогащается названиями шаблонов, которые группа разработчиков применяет к модели.

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

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

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

Может показаться, что возникает замкнутый круг. Но процесс переработки знаний может породить и более качественную модель, если разработчики в достаточной мере привержены единому языку на основе модели. Настойчивое употребление ЕДИНОГО ЯЗЫКА обязательно выявит слабые места в модели, и группа путем эксперимента найдет альтернативу неуклюжим понятиям или соотношениям. По мере обнаружения пробелов в языке будут появляться новые слова. Изменения в языке следует принимать как изменения в модели соответственно группа разработчиков должна вносить изменения в диаграммы классов, переименовывать классы и методы в исходном коде или даже изменять функции программы при изменении значения того или иного термина.

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

Разумеется, специалисты в предметной области будут общаться не только на ЕДИНОМ ЯЗЫКЕ; это нужно для целей объяснения или создания более широкого контекста. Но в пределах области действия модели они должны пользоваться этим языком и бить тревогу, если язык оказывается неудобным или неполным, а то и неправильным. Постоянно пользуясь языком на основе модели и неустанно его совершенствуя, мы приближаемся к модели одновременно полной и доступной пониманию, составленной из простых элементов, сочетание которых способно выражать сложные идеи.

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

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

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

При наличии ЕДИНОГО ЯЗЫКА модель перестает быть просто придатком к архитектуре, а становится естественной средой для любых совместных действий программистов и специалистов. Язык есть носитель динамической формы знания. Дискуссии на этом ЯЗЫКЕ извлекают «‎на поверхность» смысл, заключенный в диаграммах и коде.

Источник: Э. Эванс. Предметно-ориентированное проектирование. Структуризация сложных программных систем. – М. СПб. Киев: Издательский дом «Вильямс», 2011. – С. 45-47. Автор иллюстраций – Максим Жильцов.

ЧТО ТАКОЕ БАЗА ЗНАНИЙ?

Концентрированная книга издательства LIVREZON складывается из сотен и тысяч проанализированных источников литературы и масс-медиа. Авторы скрупулёзно изучают книги, статьи, видео, интервью и делятся полезными материалами, формируя коллективную Базу знаний. 

Пример – это фактурная единица информации: небанальное воспроизводимое преобразование, которое используется в исследовании. Увы, найти его непросто. С 2017 года наш Клуб авторов собрал более 80 тысяч примеров. Часть из них мы ежедневно публикуем здесь. 

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

📎 База знаний издательства LIVREZON – только полезные материалы.

Следующая статья
Бизнес и экономика
Уставы Пахомия: переход от индивидуальной практики к зачаткам корпоративной культуры в IV веке
В начале нашей эры в Египте зародилось так называемое «пустынное монашество» Святого Антония, которое дало толчок развитию движения святого Пахомия. Оно начинает свою историю в древней Византии с основания монастыря в Тавене на берегу Нила в 323 году н. э. (сегодня – территория Судана). Тавена служила сборным пунктом монахов и монахинь набирающего известность движения.  ЦИТАТА. «В это время Египет в массе своей ещё только обращался в христианство, и для христиан, воспитанных на Библии, пустыня могла казаться менее страшной, а в некоторых аспектах даже и п...
Бизнес и экономика
Уставы Пахомия: переход от индивидуальной практики к зачаткам корпоративной культуры в IV веке
Бизнес и экономика
Иллюзия работы, или почему не работает самодиагностика процессов на предприятии
Бизнес и экономика
Junior UX/UI собеседование: как произвести впечатление на будущих коллег?
Бизнес и экономика
Как соревнование и конкуренция ведут общество вперёд
Бизнес и экономика
Один в поле не воин, или как собирать рацпредложения на предприятии
Бизнес и экономика
Чем полезно разделение труда: выдержки из Адама Смита
Бизнес и экономика
Как фиксировать и внедрять лучшие практики в компании – инженер Гаррингтон Эмерсон
Бизнес и экономика
Концептуальная целостность по Фредерику Бруксу – на примере интерфейса WIMP
Бизнес и экономика
Как спровоцировать клиента на импульсивные покупки
Бизнес и экономика
Как и когда появились первые кредитные карты
Бизнес и экономика
Что делать, если не получилось делегировать? Схема передачи работы другому сотруднику
Бизнес и экономика
Решает ли бизнес-проблемы теория ограничений системы Элияху Голдратта?
Бизнес и экономика
«Производственная система Тойоты. Уходя от массового производства» – реферат: самое главное из книги Тайити Оно
Бизнес и экономика
Конвергенция как основа для инноваций – Питер Друкер
Бизнес и экономика
Почему одни профессии оплачиваются выше других: взгляд Адама Смита