Давайте вспомним наших учителей по информатике. Какие они были? Повлияли ли они на ваш выбор профессии?

Мы в партнерстве с образовательной платформой Инфоурок проводим короткий опрос о том, какое влияние учителя информатики оказали на вас при выборе профессии после окончания школы. Будет здорово, если вы поучаствуете🔥

Опрос анонимный и займет не больше 3 минут: https://forms.gle/asntncCA5ckumj3L6

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

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

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

Например, у Хекслета есть проект Code Basics, который специально выложен в открытый доступ. Это помогает тратить меньше времени на его сопровождение, так как наши студенты и другие люди участвуют в его доработке. Даже курсы, выложенные на этом сервисе, являются открытыми. Любой человек может пойти и поправить их. Или даже может написать целиком новый курс, что иногда случается.

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

- Командная работа. Нужно договариваться, обсуждать, предлагать решения, участвовать в код ревью;

- Открытые проекты используются большим числом людей. Вам придется учитывать множество вариантов использования и возникающие риски при изменениях. Это очень быстрый путь в сторону сеньорности;

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

- Бывает, что открытые проекты технически более сложные, чем проекты на работе. Там получается бесценный и новый опыт.

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

А представьте, как это звучит: «Я контрибьютор в React». И кстати, один из студентов Хекслета действительно стал контрибьютором React.

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

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

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

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

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

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

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

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

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

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