Иван Садовой @greblin
User
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Works in
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Software Architect
Lead
From 380,000 ₽
Golang
High-loaded systems
Designing application architecture
Kubernetes
PHP
MySQL
MongoDB
Нижняя челюсть, левая шестерка
Иглу уже вытащили к тому времени. Или оно отложенное бывает?
Спасибо за познавательную статью
Однажды почти сразу после введения анестезии почувствовал, как будто от челюсти до глаза прошла какая-то волна. Ощущение не было неприятным, но очень необычным, как будто пронёсся поток воды. Можете предположить, что это было? Точно не помню, для чего именно делали анемтезию, скорее всего это было частью установки импланта
Много лет назад ещё будучи студентом пришёл в небольшую фирму. В первый же день, разбираясь в системе, случайно очистил какую-то табличку. Кажется просто условие where ещё не написал, а запрос уже отправил. Первая мысль была тихо взять вещи, убежать и никогда не возвращаться. Справившись с этим порывом, начал разбираться, как можно исправить. Пока разбирался, пришёл крон и пересчитал все очищенные данные :)
Год назад обнаружили что высоконагруженная система поиска авиабилетов из 30 golang-микросервисов стала регулярно упираться в таймлимит на 99ом перцентиле. Решили разбираться, а не тупо поднять таймауты, потому что в таких вещах сегодня 99ый , завтра 95ый, а послезавтра 90ый, а это уже очень плохо. Потратили несколько недель меня и ещё одного разработчика, обнаружили узкий сервис, перетряхнули все горутины, отпрофилировали pprof'ом, устранили перемещение данных при изменении размера слайсов, залезли в сетевое взаимодействие... Стало лучше, но не сильно. И тут я вспоминаю, что при интеграции новой клиентской по отношению к нашей системы, я забыл передать флажочек, настраивающий фильтрацию длинного хвоста из неконверсионного ассортимента.
В общем, количество ошибок обратно пропорционально опыту. Но при этом цена ошибки прямо пропорциональна ему :)
Спасибо за статью, интересно было почитать.
Мы используем еще один способ, направленный как раз на то, чтобы перейти от экзамена к равноправному диалогу. Мы сначала рассказываем про проекты и команды и предоставляем слово кандидату, чтобы он мог задать любые интересующие его вопросы. И только после этого, если кандидат всё еще заинтересован в вакансии, переходим к проверке скиллов
Хотелось бы еще поинтересоваться опытом коллег по части немедленного проведения CR. С одной стороны всё правильно — блокируется работа коллеги, задача зависает перед отправкой на прод и т.д. Но с другой стороны переключение контекста может быть весьма дорогим и неприятным для разработчика, да и какая-нибудь рабочая встреча в самый неподходящий момент случится.
У себя в команде (8 разработчиков) мы ввели несколько правил:
С одной стороны это хорошо: здоровая атмосфера и восприятие критики в команде, обмен опытом, в котором может участвовать каждый, чаще обнаруживаются баги и улучшения, CR проходят за приемлемое время. Но с другой стороны размывается ответственность, люди чаще думают «А ладно, посмотрю попозже, или еще кто-нибудь посмотрит», или ревьювят сквозь пальцы. И вот уже немедленной реакции нет, одну задаче прямо хорошо поревьювили, а другую «пойдёт» и т.д.
Кто как находит баланс в этой проблеме?
По второму вопросу — да, в ряде случаев имеет смысл поискать сегменты по отдельности. Особенно это может быть заметно на комбинациях внутреннего и заграничного рейсов. Но надо помнить, что при такой покупке авиакомпании не несут взаимной ответственности: авиакомпания второго сегмента не пересадит пассажира на другой рейс, если рейс на первом сегменте опоздал и стыковка нарушилась. Также придется получать багаж и заново регистрировать его. В некоторых случаях могут возникнуть еще и визовые трудности