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

Read IT Club — инициатива, которую мы запустили в КРОК, чтобы сделать ИТ-литературу более доступной и понятной русскоязычному сообществу. В ней объединились рецензенты и переводчики, которые проверяют корректность терминологии и переводов в книгах. Их истории — внутри материала.

За три года существования клуба «книжные дебагеры» успели обработать более 20 книг от ведущих издательств. Чтобы присоединиться к клубу и менять будущее ИТ-литературы вместе с КРОК нужно заполнить анкету на сайте сообщества. А пока делимся историями наших рецензентов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что я понял:

В работе часто встречаюсь с совершенно разными направлениями. Хочется постоянно быть в курсе того, что происходит в мире ИТ: искать лучшие решения, сравнивать, изучать. С поиском помогают медиаресурсы по типу Хабра, но если ты решил перенести что-либо из сёрчинга в активное пользование, для погружения понадобятся книги. Из последнего прочитал пару книг по Kafka и высоконагруженным приложениям, а также талмуд по Jive.

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

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

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

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

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

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

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