Комментарии 26
Есть ещё одно требование именно к техническому переводу - перевод обратно на английский, в том числе сделанный на среднем уровне владения обоими языками, должен давать удобный гуглу результат. Архитектурные решения в этом смысле идеальны, но да, не без обременения. Я бы дальше «решений по архитектуре» не отходил.
Выборка среди носителей языка - грубая ошибка, допустима и даже необходима выборка среди специалистов влияющих на выбор архитектуры проектов. Заменить её можно посмотрев не переводились ли раньше architecture decisions в солидных источниках.
К слову - кнопка Start в углу рабочего стола Windows вызывает две ассоциации - начало как действие и место где собрались все к этому действию готовые. Поэтому перевод Старт лучше чем Пуск, но уже ничего не изменить.
При таком требовании придется отказаться от описательного перевода и ряда переводческих трансформаций, а это далеко не всегда возможно в принципе.
Выборка (нерепрезентативная!) среди носителей языка — это всего лишь повод для размышлений. Мне хотелось получить свободные ассоциации, вне контекста статьи. Кстати, архитекторы ПО в этой выборке тоже были. Впрочем, опираться на мнение одних только профильных специалистов я бы тоже не стала. По крайней мере, при написании текстов для широкой аудитории.
Про солидные источники — резонно. Microsoft, например, перевел ADR как «решение об / по архитектуре». Но я не знаю, обращался ли там кто-нибудь к первоисточнику и пытался ли выяснить, почему не solution. То есть при других вводных вариант «решение по архитектуре» действительно может быть окончательным. Я же описала перевод термина именно в контексте конкретной статьи, и на этом примере очень хорошо видна роль этого самого контекста.
Про кнопку интересно было бы получить комментарии переводчиков. Я нашла, что в одной ОС (не Windows) эта кнопка называлась Launch.
Хороший пример и постановка проблемы. Я не переводчик, но пока учился в школе, довелось проходить практику в бюро перевода, работая со статьей по нейрохирургии и обсуждая ее с родственником врачом. Некоторые переведённые термины, одобренные переводчиком бюро, вызывали острую реакцию родственника) Потом столкнулся с трудностями перевода руководства по ОС TSX с термином task swapping - тогда не существовало понятия виртуальной памяти, и подобрать что то эквивалентное свопу было крайне затруднительно..Ну и последний сильно проблемный устоявшийся пример - это перевод pointer dereference))
Насколько я слышал, проблема называется проблемой переадресации перевода. Связана с тем, что в рамках двух языков смысл слов и сочетаний может быть разный. И несмотря на то, что architecture deсision по правилам дословного тех перевода следует переводить как решение архитектуры)), такой перевод нуждается в переадресации, которую Вы и проделали. Ну а некоторые вещи вообще невозможно перевести, если в целевом языке нет схожих понятий. Тогда только кофе, файл..))
Да, похоже, что процесс перевода мало кого может оставить равнодушным :)
Перевод «решение архитектуры» не подойдет, здесь родительный падеж указывает на принадлежность, а в словосочетании architecture decision связь другого типа. Пример, когда связь основана на принадлежности: management decision — решение руководства.
Вы пишете о проблеме эквивалентности перевода :) Когда значения не совпадают полностью или частично, это называется «неполная эквивалентность». Например, значения словосочетаний architecture solution или architecture decision частично совпадают со значениями словосочетания «архитектурное решение» в сфере ИТ. В строительной сфере частично совпадают значения пары «архитектурное решение» и architecture design.
Насчет переадресации я в "вульгарном" исполнении слышал это у Гоблина когда то давно. А потом случайно узнал, как Пруст перевёл Раскина и комментарии кого то великого типа Зализняка или Мамардашвили на этот счёт
Конечно не подойдёт, но в институте преподаватель требовала именно такой вариант как дословный и корректный.
Как архитектор могу ответить кратко. Правильное значение: архитектурное решение :)
Прделоженный вариант «выбор элементов и принципов архитектуры» выглядит странно и выглядит попыткой ограничить скоуп решений, которые принимает архитектор. Либо попыткой объявить все "элементом" или "принципом", но зачем?
К примеру, на проекте, целью которого была фактически замена существующего решения, одно из architecture decision фактически был покомпонентный расклад, что и как делать. Что-то переписать, что-то пересмотреть (возможно выживет какая-то часть), что-то останется и будет использовано. Можно конечно это назвать решением касательно компонентов, но скорее это процессное решение, которое влияет на то, как делать проект
Пример другого решения - как мигрировать "по живому". Это тоже архитектурное решение. И там 100500 деталей может быть
Поэтому мой совет - не стоит :)
Архитектурное решение [системы] — это всё же architecture solution.
Architecture decision — это решение, связанное с архитектурой, то есть выбор конкретных средств и технологий. Совокупность сделанных decisions приводит к появлению architecture solution.
То есть для создания или изменения архитектурного решения (architecture solution) вы принимаете какое-то решение (decision) или несколько. Но нельзя сказать, что вы принимаете архитектурное решение, вы принимаете просто решение. Чтобы уточнить, что это решение влияет на архитектуру, можно сказать, что вы приняли, например:
- решение по архитектуре;
- решение изменить архитектуру;
- решение изменить архитектурное решение системы и т. д. :)
И, как я написала выше, можно было бы остановиться на варианте «решение по архитектуре», если пожертвовать точностью и не углубляться в контекст.
Давайте не усложнять
Solution -> просто Архитектура, либо Архитектура Системы/Решения/Продукта
Decision -> конкретное решение, оно же "выбор"
Так сложилось на практике. Хотя вот на текущем месте работы сам документ предпочитают называть Architecture Vision :)
------------------------------
Но нельзя сказать, что вы принимаете архитектурное решение, вы принимаете просто решение.
Когда я принимаю решение купить вечером пивка или нет, я принимаю просто решение :) А вот на работе я принимаю архитектурные решения, потому что "архитектор".
Architecture decision — это решение, связанное с архитектурой, то есть выбор конкретных средств и технологий.
Я уже пояснил на примере, почему решения архитектора шире :) Та же процедура миграции - эти и средства, и процедура, и еще что-то.
Есть наиболее точное и полное определение, которое по совместительству яляется конструктивным. Архитектурное решение == решение принятое архитектором в рамках выполнения рабочих обязанностей. Просто и идально :)
Если почитать исходную статью, то... прочитав, можно понять что статья про Документирование решений по архитектуре, а не про Документирование архитектурных решений - там аджайл, вальюз и прочее
Принимать архитектурное решение может, например, приемная комиссия. И здесь другое значение слова «принимать».
Решение, принятое архитектором, это архитекторское решение :) не архитектурное.
ОК, решение принятое персоной либо группой лиц в рамках выполнения обязанностей роли архитектора :)
Э, какая приемная комиссия в обсуждении архитектуры? И нет, ADR никак не связан с принятием решения, только с документированием процесса принятия решения.
Это же просто формат документа. Если уж буквально переводить, то "Запись про принятые решения касающиеся архитектуры"
В этой ветке мы в основном разбираемся с прилагательными: архитектура — архитектурный, архитектор — архитекторский. И со словосочетанием «принять решение».
Но раз уж зашла речь, как и почему в переводе ADR появилось слово «принятые»? Если оставаться в контексте статьи М. Найгарда, там, кроме accepted, есть proposed и deprecated, например. А если есть accepted и proposed, то разве не может быть declined или rejected?
С моей точки зрения, предлагаемый перевод искажает смысл, имеющийся в исходном тексте. Статья, о которой идет речь, обсуждает документацию именно что решений - то есть да, выбора, но выбора в широком смысле, не только компонентов и принципов, но и действий, стратегии, методологии и т.п. Слово "решение" прекрасно передает именно это значение; зачем его заменять - решительно непонятно. Ваш вариант создает впечатление, что речь идет о процессе в начале разработки проекта, когда делается выбор. В статье же говорится о более универсальном процессе, который - как это говорится в статье - может происходить на протяжении всей жизни проекта.
На месте автора я бы вообще назвала эти события «изменениями архитектуры» или «изменениями в архитектуре». Но такой вариант не очень подходит для описания процессов в начале разработки проекта.
С формальной точки зрения «выбор» не является заменой, это тоже вариант перевода слова decision, просто менее частотный, чем «решение». Я выбрала этот вариант, чтобы точнее передать мысль автора. В статье есть и decision, и solution — и мне показалось важным подчеркнуть это различие.
Вопрос личного восприятия, конечно, тоже важен, но мне не кажется, что «выбор» ассоциируется только с началом разработки. Думаю, вполне можно представить, что вся история проекта связана с цепочкой выбора альтернатив при возникновении различных ситуаций.
Нет никакого architecture decision
Есть ADR architecture decision records
И сразу акцент с архитектуры как законченного документа уходит на выбор, записи.
Если хотите перевод, то это
Документально зафиксированный выбор варианта архитектуры
Нет там "вариантов архитектуры", так как ADR не про "выбор варианта", а про решение одного конкретного tradeoff или про обсуждение одного конкретного изменения.
Поэтому предложенный в статье перевод - ужасен, так как полностью теряет реальный смысл фразы.
Можно перевести как "решения по поводу архитектуры" или даже "Результат обсуждения архитектуры". Или вообще не переводить, так как зачем?
Ваш перевод «решение по поводу архитектуры» полностью совпадает по смыслу с моим промежуточным вариантом «решение по архитектуре» и «решение, касающееся архитектуры». Да, на этом можно было остановиться, но мне важно было показать влияние контекста на процесс перевода.
Вы не могли бы пояснить, что подразумеваете под решением одного конкретного tradeoff? Хочу понять, в чем здесь противоречие с «выбором варианта (элементов, принципов) архитектуры».
И еще интересно, как получился перевод «результат обсуждения архитектуры»?
Неа, "решение по архитектуре" - это "решение про всю архитектуру", а ADR - про небольшие части архитектуры системы, а не про всю. "Решение, касающееся архитектуры" - да, гораздо лучше.
Никакого "выбора вариантов архитектуры" в ADR просто нет, документ не про "какие архитектуры можно выбрать", а про "как решить конкретную задачу-проблему, как-то касающуюся архитектуры".
А "результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие и ничего хорошего из этого не получится.
"решение по архитектуре" - это "решение про всю архитектуру"
Попробуете обосновать? Или останется мнением на уровне личного восприятия?
ADR - про небольшие части архитектуры системы, а не про всю
Насколько небольшие? А если это ADR, в котором выбирается фреймворк? А если инструмент для форматирования кода?
"выбора вариантов архитектуры"
Случайно или нет, но вы снова изменили эту фразу, при этом исказился смысл.
«Выбор варианта архитектуры» можно трактовать так, что в результате получится вот такая разновидность устройства системы; система видоизменится определенным образом. Да, это будет сделано в рамках решения задачи или проблемы. Всё еще не понимаю, в чем здесь противоречие.
"результат обсуждения архитектуры" - это перевод смысла ADR. Так как переводить без понимания предметной области - бесполезное занятие
В целом согласна, но о какой предметной области идет речь: архитектура ПО, переводоведение, русский язык?
Не, не буду обосновывать. Но именно так это читается носителем русского языка.
Выбор фреймворка или инструмент форматирования кода - это как раз очень небольшие части архитектуры. Впрочем, инструмент форматирования кода к архитектуре вообще отношения не имеет, заводить на это ADR достаточно странно
Ну, если не понимаете - то и ладно, вы же не архитектор, вам это не обязательно. Главное - не используйте свой перевод, так как он не соответствует понятию ADR
Архитектура ПО, разумеется. Хотя про переводоведение у меня тоже есть сомнения.
Да, хороший вариант, спасибо. Мне кажется, допустимо рассматривать «вариант архитектуры» как видоизменение устройства системы, включая ее окружение.
А почему вы перевели record как «документально зафиксированный»? Не проще ли перевести как «запись», особенно с учетом существующей практики объединять множество ADR в журнал (log)?
Да потому, что стоило к прямому переводу architecture обратиться , а не только decision. И перестать лепить архитектуру к программированию .
Ловушка семантики и атрибутивных конструкций, или Почему architecture decision — это не архитектурное и не решение?