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

Такой вопрос нам задали в одном из комментариев в ВК. Давайте поговорим об этом.

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

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

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

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

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

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

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

Раз уж мы заговорили о тестировании. На Хекслете есть программа для ручных тестировщиков, а скоро запустим и автоматическое тестирование
https://ru.hexlet.io/programs/qa-engineer

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

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

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

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

Кстати, подробно о том, как создается контент, мы рассказываем в нашей школе авторов: https://making.hexlet.io/authors

Обзор на книгу «Грокаем функциональное мышление»

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

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

В понимании функционального программирования (ФП) есть одна грубая ошибка – думать, что оно сводится к функциям и противопоставлено ООП. На самом деле ФП противопоставляется скорее императивному стилю программирования, и для него огромное значение имеет неизменяемость данных, чистые функции, ограничение сайд-эффектов и тому подобное. Я знал все это перед чтением и надеялся, что сей опус введет меня в мир лямбда-исчислений и каррирования, расскажет про монады и всякие такие интересности, но я ошибся.

Начну с плюсов: в книге не так много картинок, как в «Грокаем алгоритмы», что во многом связано со спецификой содержания. Речь зачастую идет о более абстрактных вещах, прежде всего об архитектуре программ, но при этом объем достигает 600 страниц. Другим плюсом является простота и доходчивость, с которой автор рассказывает о том, что такое функциональное мышление – многие темы повторяются по несколько раз, в книге щедро представлены примеры кода и упражнения, а разделы книги пересекаются друг с другом. Приятным является и то, что книга издана в этом, то есть 2023 году. Наконец, акцент на практическом применении функционального мышления в реальной разработке тоже является своеобразным плюсом, поскольку автор подробно на примерах показывает способы изоляции сайд-эффектов, построения кода, и лично я увидел для себя несколько новых вопросов для размышления. Но здесь-то мы и переходим плавно к минусам сего труда.

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

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