Как я на go в продакшн писала
История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.
В выходные я потыкала курс по базовому синтаксису go на хекслете и почитала книгу, которую мне посоветовала подруга. Работа над проектом началась непросто: я никак не могла скачать корпоративные модули, несмотря на (вроде бы) правильную настройку конфигов и переменных окружения. Пришлось мучать лида (кажется, он был не очень доволен). Мы провозились пару часов, и в конце концов оно как-то заработало (я точно не поняла, что именно помогло с этой проблемой).
После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.
День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.
Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать.
По итогу выяснилось, что я использовала неправильные строковые константы для сообщений об ошибках и накосячила в одном месте из-за плохого знания домена (надо было фильтровать сущности по определенному полю, кто ж знал). Но в целом нормально.
Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).
История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.
В выходные я потыкала курс по базовому синтаксису go на хекслете и почитала книгу, которую мне посоветовала подруга. Работа над проектом началась непросто: я никак не могла скачать корпоративные модули, несмотря на (вроде бы) правильную настройку конфигов и переменных окружения. Пришлось мучать лида (кажется, он был не очень доволен). Мы провозились пару часов, и в конце концов оно как-то заработало (я точно не поняла, что именно помогло с этой проблемой).
После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.
День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.
Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать.
По итогу выяснилось, что я использовала неправильные строковые константы для сообщений об ошибках и накосячила в одном месте из-за плохого знания домена (надо было фильтровать сущности по определенному полю, кто ж знал). Но в целом нормально.
Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).