Добрый день! Меня зовут Алексей, я Java / Kotlin разработчик. Со времен института я работаю в IT и считаю своим долгом в профессии постоянно образовываться. Разработка, на мой взгляд, похожа на медицину или науку в части отношения к информации: либо ты следишь за тенденциями, читаешь, пробуешь, интересуешься, либо через n лет остаёшься на обочине профессии. В медицине, насколько я слышал, есть очень авторитетный журнал The Lancet. А как разработчику оставаться на информационной волне?

Лично я обязательно читаю еженедельную рассылку Хабра, чтобы быть в курсе. Но для того, чтобы погрузиться хорошо в какую‑то область, статьи недостаточно — надо читать книги. При этом книги по какой‑то конкретной технологии я читаю редко, потому что технологии быстро устаревают. Чаще я читаю что‑то по подходам, например, архитектурным (и у меня есть план развиваться в эту сторону). Пример того, что я почитываю: паттерны проектирования API / высоконагруженные приложения / DDD и Event Sourcing.

О кривых переводах

Часто бывает так, что читаешь книгу на русском и не совсем понимаешь, о чём идет речь. Приведу несколько примеров:

• «Управление транзакцией с помощью повествований» — это перевод термина сага, который у разработчиков чаще всего не переводится.

• «Типичный рабочий процесс векторной БД включает три этапа» — имеется ввиду workflow или pipeline.

• «Конечные точки» — эндпоинты.

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

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

А ещё IT книги, надо сказать, стоят далеко не дёшево. Достаточно долго я с этим мирился, потом плевался, потом снова мирился и так по кругу, пока не наткнулся на книгу «Микросервисы. Паттерны разработки и рефакторинга» Криса Ричардсона. Это было последней каплей. Попробуйте сами:

Я читаю её уже год, потому что мой мозг отказывается нормально её воспринимать. Например, я ни разу не слышал определения «граничные функции», а «edge functions» не переводят. Или «сбор показателей» — это «сбор метрик». А «ограничение частоты запросов»? Это же «rate limiting»? А «ведение журнала запросов» — это «логирование». И так везде.

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

Идея появилась в августе 2025 года. Но перед тем, как её развивать, я решил поискать, вдруг кто-то уже реализовал такую идею (хотя вряд ли — я же такой уникальный :)?

Всё уже придумано до нас

Оказалось, что ребята из КРОК уже организовали всё то, о чём я рассказывал. Их идеология:

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

Как всё работает в нескольких пунктах:

Итак, я добавился к ребятам в чат, куда присылают новости сообщества и анонсы книг на рефакторинг, и стал ждать книгу на ревью, которую было бы интересно править с пользой для себя. Принцип прост — кто первый встал, тот и берёт книгу «на разбор».

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

Как разработчик я сильно вовлечен в нейросети (тут и личный проект бота который помог мне обьехать больше 70 стран, и пресловутый вайбкодинг). И вот удача — на рецензирование пришла книга «Промт инжиниринг для LLM Искусство построения приложений на основе больших языковых моделей» от создателей GitHub CoPilot. Как раз мой вариант влиться глубже, чем статьи на Хабре / ручное составление промтов для локальных нейросетей, но и не такая хардкорная как архитектура нейросетей / finetuning / устройство RAG. И я взял её на ревью..

Как выглядел процесс?

Ребята из сообщества прислали в личку предварительную версию перевода в doc и английскую версию в pdf, чтобы можно было сверяться с оригиналом. Правки делал в OneDrive, так как лицензионного Word у меня нет, а формат просили не менять — редактору издательства так удобнее.

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

Вернувшись к компьютеру сверялся с оригиналом. Когда с переводом были проблемы у меня было несколько вариантов действий:

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

• Если речь шла про странный термин, то в первую очередь обращался к GPТ и уточнял варианты перевода на русский в этом контексте.

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

На всё про всё ушло 1,5 месяца в режиме «читаю на выходных и в отпуске в свободное от путешествий время». Дальше отдал doc ребятам из сообщества, которые взаимодействуют с издателем, и мне сообщили срок выхода книги (1,5 - 2 месяца). После выхода книги мне отправили бесплатно несколько экземпляров (для себя и друзей — похвастаться).

Этот квест был не так уж прост, скажу я вам, потому что вдумчивое чтение — это очень большая нагрузка на мозг. А я очень внимательное читал из-за ощущения ответственности.

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

Что же изменилось в книге после меня?

Несколько примеров. «Синтез кода» превратился в «генерацию кода».

А «тонкий слой возможностей» переписан в «приложение минимально вмешивается во взаимодействие LLM и пользователя».

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

Что можно было бы улучшить

№1. Было бы удобнее, если бы существовал инструмент, в котором прозрачно видно, какие изменения принял издатель, а какие нет (например, GitHub, Jira и т. д.). Я оставил порядка 600 комментариев по всему тексту, но глава № 9 так и осталась «Рабочие потоки» (как и все упоминания в ней). Я узнал об этом только после выхода книги.

Ещё это касается даты выхода книги. Например, у меня уже есть вторая книга, но она до сих пор не вышла, хотя прошло полгода с рецензии.

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

№3. Кажется, слово «ревью» или «рефакторинг» для этого процесса подходит лучше, нежели «дебаггинг». С откровенными ошибками именно перевода я столкнулся пару раз, всё остальное — неудачные названия или формулировки.

В основном, опыт от рецензирования совпадает с тем, что пишут ребята из сообщества:

Но лично у меня есть ещё пара мыслей.

Личные выводы

Вывод № 1. Чтение в роли ревьювера повышает внимательность благодаря ответственности. Это как с принципом «Хочешь научиться — научи другого».

Вывод №2. Когда читаешь книгу, которая еще не переведена на русский язык, то вероятно, ты одним из первых получаешь эти знания.

В целом, мне понравилось и буду дальше заниматься книжным ревью. И вам рекомендую!

P.S. Остерегайтесь брать книгу на рефакторинг в которой вы не согласны с автором. У меня так произошло и я страдал 3 месяца.