Read IT Club: как мы повышаем качество русскоязычной ИТ-литературы

Привет, Хабр! На связи Тимур Напреев, ведущий аналитик компании КРОК. Уже 3 года мы с командой рецензентов — книжных дебагеров занимаемся повышением качества переводов книг по темам ИТ. Но обо всём по порядку. 

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

Так в КРОК появился Read IT Club — Клуб книжных дебагеров. Мы стали рецензентами и переводчиками 20+ книг от издательств «БХВ» и «Питер», а команда разрослась до 30+ экспертов-рецензентов. Мы хотим, чтобы специалисты говорили на едином языке, не встречая «жирных и тощих клиентов», «микрослужб» и «многоразового кода». С нами работают не только ИТ-специалисты КРОК, мы также приглашаем друзей из других известных компаний и мечтаем сделать нашу инициативу глобальной. К слову, мы делаем это не за деньги, но с целью сделать литературу лучше для всех нас, и готовы сотрудничать с новыми издательствами.

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

Путь Ани

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

6d6fff6ba5c7a2e6a582aca2c9c4f800.jpg

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

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

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

Что встречается в работе:

  1. Наиболее часто встречающаяся история: предложение есть, написано грамотно и по-русски, а смысл не клеится; идешь в оригинал, а автор имел в виду совершенно другое, идет полная калька по терминам, дословный перевод. Примеры, особенно покорившие моё сердце:

    • «Высокая математика» — тут я прямо чаем поперхнулась. Высокое искусство, оно такое.

    • «Машинные определения живут в системе контроля версий».

    • «Сервисная сетка для зацепления сервисов» — тут мозг просто завис.

    • Framework: вместо использования «фреймворк» переводят как «рамка»

    • «Функционал» и «функциональность» путают практически все.

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

  3. Особенное внимание — к аббревиатурам. Конфиденциальность (confidentiality), целостность (integrity) и доступность (availability) — триада CIA. Перевели, как «триада ЦРУ», переводчика ничего не смутило :)

Рецензированные мной книги:

  1. «Прикладные алгоритмы и структуры данных», Джей Венгроу

  2. «Эволюционная архитектура», Нил Форд

  3. «Построение безопасных и надежных систем», Ройал Хансен

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

Советы будущим поколениям рецензентов:

  • Старайтесь грамотно перекладывать игру слов на русский язык. Зачастую встречается дословный перевод. Прямо как в идиомах: «piece of cake» не всегда означает «кусок пирога».

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

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

Путь Димы

Привет! Меня зовут Дима Иванов, я DevOps-инженер в КРОК. Я вступил в клуб потому, что меня не устраивало качество ИТ-литературы, прошедшей через мой стол в последние несколько лет. Так как сфера моих интересов затрагивает DevOps, системное администрирование и вопросы разработки, то к стэку относятся: Linux, Системы контейнеризации и оркестрации: Docker, Podman, Kubernetes, CI/CD: GitLab, Jenkins и прочие товарищи. 

a70fae6f8f59c76b8e4ff0fe14b0eeb1.jpg

Выходит книга, и там встречается перевод слов, давно взятых в оборот на английском языке. Помню, не сразу понял: что за «модуль», которым обозвали pod в Kubernetes. Или «тема», которая topic в Kafka. Никто так не говорит. И ты понимаешь, что смысл истолкован неверно, а обычный переводчик с лингвистическим образованием навряд ли может знать тему и думает, что переводит правильно. Возникает путаница. Поэтому я решил взять неожиданную для себя и коллег работу — перевод книги от корки до корки.

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

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

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

Доверяй, но проверяй

Иногда встречались откровенные ляпы, например, «мы добавили Podman в Kubernetes Frontend» — слова знакомые, но вместе не имеют ровно никакого смысла. Допустим, это какой-то web-интерфейс, но технология ведь вообще не о том. Подумал-подумал, ничего не придумал. В итоге нашел почтовый адрес самого автора, собрался с мыслями, написал. Автор ответил и ответственно заявил, что перепутал, имея в виду Backend. Поэтому всегда стоит перепроверять информацию, ошибки встречаются и в первоисточниках.

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

Бывало так, что брал перевод в отпуск — работал в поезде где-то на перегоне Транссибирской магистрали, без интернета.

51ee074157a39c0c07d9746c6fb5c257.jpg

Что я понял:

  • Я отношусь лояльнее к переводам ИТ-литературы. Если мне было трудно лишь из-за неточностей автора, английской грамматики и прочего, то не стоит требовать чего-то большего от человека, если он не знаком с технологией.

  • Рецензирование переводов — исключительное добро для конечного читателя. Косячат даже авторы, а переводчик может усилить путаницу.

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

  • Не стоит бояться использовать нейросети в качестве ассистента. Например, нейросеть предположила, что автор сделал ошибку в куске с «Kubernetes Frontend» — так и оказалось по итогу.

Путь Саши

Привет! Меня зовут Саша Петраки, я эксперт по web-технологиям в КРОК, процессингу больших и потоковых данных. В ходе профессиональной деятельности часто встречаюсь с совершенно разными направлениями. Хочется постоянно быть в курсе того, что происходит в мире ИТ: искать лучшие решения, сравнивать, изучать. С поиском помогают медиаресурсы по типу Хабра, но если ты решил перенести что-либо из сёрчинга в активное пользование, для погружения понадобятся книги. Из последнего прочитал пару книг по Kafka и высоконагруженным приложениям, а также талмуд по Jive.

86eca36c303b8c3b6859bb2b9704b4aa.jpg

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

На моем счету уже 5 книг:  

  1. Learning Opentelemetry, Ted Young & Austin Parker

  2. Acing the system design interview, Zhiyong Tan

  3. Микросервисы и API, Перальта Хосе Антонио Аро

  4. Нечеткое сопоставление данных в SQL, Джим Лемер

  5. Антипаттерны SQL. Как избежать ловушек при работе с базами данных, Билл Карвин

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

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

Что нужно, чтобы начать заниматься рецензированием:

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

  • Навыки коммуникации, чтобы корректно и оперативно общаться с издателем и переводчиками. Бывает так, что автор вводит собственный термин, и вы вместе думаете, что имелось в виду — профессиональная шутка или научный термин. В этом случае необходимо проводить свое небольшое расследование.

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

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

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

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

© Habrahabr.ru