О дизайне и сложностях перевода

Вы когда-нибудь бросали чтение классической книги после прочтения двух десятков страниц, толком не понимая, почему же ее так хвалят и что же со мной не так? При этом я не говорю за книги, типа банды четырех, о которой говорят на каждом шагу, но при этом есть лишь четыре человека в мире, которые прочитали ее от начала до конца. И я тем более не говорю за книги Дональда Кнута на прочтение которых нужно потратить минимум 3 жизни. Я говорю о чем-то попроще, типа DDD Эванса или Корпоративных Шаблонов Фаулера.

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

Именно такая ситуация у меня была с книгами Эванса «Предметно-ориентированное проектирование» и «Проектирование процесса проектирования» Брукса. Я начинал читать классику о DDD дважды, но каждый раз бросал через 20 страниц; тогда я думал, что у меня не было нужного настроя, но в этот раз я, кажется, понял, в чем была причина.

Architecture, Design, Project

Когда я занимался переводом статей или научным редактированием нескольких книг, то самую большую проблему вызывал перевод термина design. Что означает этот термин? Проект, проектирование, дизайн? Проблема заключается в том, что перевод этого термина зависит от контекста:

• Design (как процесс) – это проектирование
• To design (как действие) – проектировать
• Designer (как человек) – проектировщик, дизайнер
• The design (как артефакт процесса проектирования) – проект? архитектура? дизайн?

Как не сложно догадаться именно последнее значение почти всегда выносит мозг переводчику. Что использовать: Проект? Так тут будет путаница с понятием проектное деятельности. Архитектура? А что тогда делать с термином architecture? дизайн? Так это же не дизайн пользовательского интерфейса.

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

Понятно, что самые большие сложности в плане этого термина испытывают переводчики книг, посвященных проектированию, таких как “The Design of Design” Фреда Брукса или DDD Эрика Эванса.

The Design of Design

Я уже писал в Г+ о том, что перевод последней книги Брукса не задался и причина этому – сложность темы. Дизайн, проектирование (или что там лучше использовать для этого понятия в данном контексте), процесс непростой сам по себе и для качественного перевода нужно четко понимать, что же именно имел ввиду автор.

Давайте рассмотрим такой пример из русского перевода:

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

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

«For designers to get the most learning from each design experience, they need to document how it evolves: not only the whats of the design, but also the whys by which it was reached. Moreover, such a rationale document is a priceless aid to system maintainers; it prevents many ignorant mistakes.»

Во-первых, бросается в глаза, что оригинал без малого в два раза короче (хотя это естественная закономерность), но самое главное, в оригинале заключены очень важные мысли, которых нет в переводе. Брукс подчеркивает (да, слова “whats” и “whys” выделил автор, а не я, чего в переводе нет вообще) важность документирования причин наших решений. Не «способы решения задач проектирования», а то почему мы выбрали тот или иной способ.

Все любители блога Эрика Липперта скажут, что главной изюминкой его постов является не столько глубина изложения, сколько описание причин, побудивших команду разработчиков принять то или иное решение при разработке конкретных возможностей языка C#. И именно по этой же причине столь интересно читать книгу Страуструпа «Дизайн и эволюция С++»: многие возможности языка С++ кажутся весьма сомнительными сейчас, но зная, почему они были приняты, отношение к ним сильно изменяется.

“Domain-Driven Design” Эванса

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

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

В целом, все нормально, однако вот что пишет Эрик Эванс на самом деле:

«Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features.»

Во-первых, бросается в глаза «стратегия архитектурного проектирования». В оригинале имеется ввиду “approach to design”, но почему-то во всей книге design, как артефакт, переводится именно как архитектура. Это особенно сбивает с толку, когда в оригинале автор начинает говорить именно об архитектуре (architecture). Но термины, это дело десятое. В чем главная мысль автора?

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

Подобных проблем в переводе книги Эванса существенно меньше, чем в переводе книги Брукса, но они есть и представлены скорее в виде неприятных мелочей, типа «архитектуры» в качестве “design”, «правилах делового регламента» в качестве “business rules” и другими заумными фразами, за которыми очень сложно понять емкую мысль автора.

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

З.Ы. В качестве бонуса вот перевод и оригинал одной фразы из книги “The Design of Design” Брукса. Интересно, что обе фразы очень любопытны и полезны, хотя и не имеют друг к другу никакого отношения:

Выбирайте как можно тщательнее слова, описывая то, что вам непонятно.

Be careful how you fix what you don't understand.