Введение
За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.
Общие идеи
Собеседование на middle-разработчика часто выглядит так же как собеседование junior-а.
Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Поэтому на таких собеседованиях обычно просят «написать декоратор» или «написать сортировку пузырьком на любом языке».
Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект.
Собеседование — это не экзамен, а возможность выявить насколько компания и кандидат подходят друг другу.
Это важное правило часто не понимают сами работодатели. Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. При этом на протяжении всего этого собеседования мы общались десять минут. Такое же поведение часто прослеживается со стороны кандидата. Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете «отличие Python2 от Python3». Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.
Middle-разработчиком нельзя стать без опыта.
Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.
На позицию Middle-разработчика soft skills становятся важным фактором.
Чем выше должность, тем с большим количеством людей приходится взаимодействовать. Поэтому очень часто при приёме на позицию middle-разработчика создаются дополнительные собеседования с HR-специалистом для составления психологического портрета будущего сотрудника. К этому собеседованию надо относиться также серьёзно, как и к техническому. Надо понимать, что Вам дальше работать с этими людьми. И если Вы чувствуете, что Ваши будущие коллеги Вам не очень подходят, то лучше сразу отказаться от дальнейшего сотрудничества.
На позицию middle-разработчика реже дают тестовые задания?.
Это утверждение достаточно субъективное. Лично я действительно столкнулся с таким фактом. Связываю это с тем, что работодателя больше интересует твоё резюме. Если резюме составлено неважно, то скорее всего следует ждать тестового задания.
Вопросы
В данном разделе будет представлен основной список вопросов, который я задаю работодателю на собеседовании. Возможно через какое-то время этот список будет расширяться или сужаться. Нужно отметить, что эти вопросы следует задавать именно на технических собеседованиях и желательно именно тому, с кем Вам потом взаимодействовать.
1. Как дела с тестированием? Какие тесты вы пишете? Какие библиотеки для тестирования вы используете? (фабрики, моки и т.д.)
Тестирование – очень важная часть любой разработки. В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Единственное, кому можно простить отсутствие тестов – это стартапы. В стартапах часто меняется курс движения из-за чего старые проекты обычно бывают никому не нужны. А значит обеспечение качеством таких проектов было впустую потраченным временем. Для всех остальных компаний пощады в этом вопросе быть не должно. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production.
Когда работодатель ответит на вторую часть вопроса, Вы сможете понять насколько хорошо команда обеспечивает качеством свой продукт и также возможные обязанности разработчика о которых не было рассказано в вакансии.
Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Но иногда я слышал вот такой ответ: «Тестами должны заниматься тестировщики, а разработчик должен творить». Это абсолютно неверно.
Разработчик должен писать необходимый минимум тестов, потому что именно он знает, как должен работать функционал, который он сотворил. Никто не говорит о ненужности тестировщиков. Но важно понимать, что разработчики тоже должны нести ответственность за качество своего кода.
2. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?
Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:
- Flake8 – анализ кода на соблюдение PEP8,
- Pylint – статический анализ кода,
- Coverage – анализ кода на тестовое покрытие,
- Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.
Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.
3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?
Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.
4. Есть ли Code Review? Как оно проходит?
Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение bus-фактора.
5. Какую систему контроля версий Вы используете?
На данный момент в России существует немало компаний, которые до сих пор использует hg, svn и прочие древние системы контроля версии. Особенно это относится к компаниям, которые на рынке больше 10 лет. Этот вопрос больше проверяет насколько старая компания восприимчива к новым технологиям. Также стоит отметить, что я недолгий период времени принимал участие в разработке используя hg и особого удовольствия мне это не доставило.
6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?
Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует git/hg, то и задать его нет смысла. Если же компания использует git/hg, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.
7. Используете ли Вы методологию разработки (scrum, kanban и т.д.)?
В разработке важно придерживаться какого-то определённого подхода(методологии). Самый популярный подход в разработке – итеративный. Такой подход позволяет определить Ваш вклад в проект. В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Это позволяет Вам определить Вашу эффективность. Также это помогает понимать Вам сроки выделенные на задачи. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.
8. Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)?
Присутствие систем мониторинга в проекте так же важно, как и присутствие тестов. Именно системы мониторинга позволяют объективно оценить работу целой системы основываясь на действиях, которые совершает конечный пользователь. Если систем мониторинга нет, то стоит задуматься о качестве производимого продукта. Это всё равно что повар, который готовит еду, но никогда не у кого не спрашивает вкусная ли она.
9. Используется ли в проекте система для хранения логов и работы с ними(ELK-технология и прочее)?
Для меня это тоже является важным показателем. Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.
10. Какие БД используются в проекте? Почему именно такие?
Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.
11. Какая версия языка Python используется в проектах? Если используется версия Python2.x, то планируется ли переход на Python3.x? И как будете происходить миграция с одной версии на другую?
Этот вопрос, равно как и предыдущей, направлен на оценку компетентности собеседующего, а также на оценку его рассуждения. Надо понимать, что работодатели бывают очень безграмотны и такие вопросы позволяют это выявить уже на стадии собеседования. Прежде чем задавать такого рода вопросы, я Вам настоятельно рекомендую самим углубиться в них.
12. Компания ищет fullstack-разработчика или backend-разработчика?
Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Многие компании считают это выгодным для себя. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Иными словами, «На двух стульях не усидишь».
В большинстве случаев компанию устраивает, то что ты не знаешь frontend и рассчитывает на то, что ты его подучишь непосредственно в бою. Уточню, что вакансия fullstack-разработчика неприемлема лично для меня. Многие же находят в этом отличную возможность окунуться в богатейший мир frontend-а при это не заплатив ни рубля.
13. Используется ли технология контейнеризации в проектах?
Этот вопрос является дополнением к вопросу №3.
14. Немного поспрашивать собеседующего о том, чем он занимался до этого проекта и давно ли он в проекте.
Этот вопрос очень важен. Чем богаче опыт вашего собеседующего, тем больше это отразится на ваших умениях и навыках через какое-то время. Особенно хорошо задавать такой вопрос в небольшой компании, где медленная текучка кадров.
15. Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит?
Любому сотруднику полезно получать обратную связь от своих коллег. Если в компании существуют для это специальные мероприятия, то это прекрасно. Если — нет, то в этом нет ничего страшного. В любом случае, никто не запрещает запросить обратную связь от коллег в вольной форме.
16. Есть ли у в компании переработки? Если есть, то компенсируются ли они и как часто они происходят?
Мало кому нравится перерабатывать, особенно если ты студент или кормящий отец. Существует огромное количество компаний, которые ставят переработки на первый план. Чтобы понять, что в компании нет переработок или есть но редко, необходимо задавать подобного рода вопросы. Если в компании изредка случаются переработки, то в этом нет ничего критичного. Если переработки участились, то стоит задуматься о целисообразности дальнейшего пребывания в компании.
17. Насколько в компании сильна бюрократия? (Оцените от 1 до 10)
Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. заказами. Степень бюрократии в компании зависит только от фантазии руководства. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста.
18. Как обстоят дела с выбиванием ресурсов?
Под ресурсами понимаются новые компьютеры для сотрудников, сервера, домены, лицензии и т.д. Этот вопрос можно также отнести к предыдущему вопросу о бюрократии.
19. Как собеседующий относится к новым внедрениям в проекте?
Данный вопрос позволяет оценить демократичность внутри команды. А также данный вопрос позволит понять, насколько голос обычного разработчика имеет вес для команды и наставника.
20. Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы?
Конференция – это отличная возможность для разработчика и для компании заявить о себе и своих достижениях. Если компания публикуется и является участником конференций, то в какой-то момент Вы тоже сможете пользоваться такой возможностью. Если Вам это не интересно, то и спрашивать об этом нет смысла.
21. Есть ли митапы внутри компании?
Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.
22. Есть ли в компании стажёры и развита ли система наставничества?
Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.
Заключение
Всё вышесказанное является моими мыслями, основанными на личном опыте и не является 100-процентно верной информацией. Главная мораль статьи заключается в том, что проверять надо не только кандидата, но и работодателя. Также не стоит нервничать перед собеседованиями или на собеседованиях. Надо понимать что собеседующие такие же люди как и Вы, которые тоже ошибаются или чего-то не знают или не понимают.
Комментарии (116)
MechanicZelenyy
14.12.2018 21:08+7Это с каких пор hg — древняя система контроля версий?
Она между прочим моложе git (на целых 12 дней).artemisia_borealis
14.12.2018 22:39А fossil даже не упоминается в статье, а ведь он самый молодой из этой тройки. Аж не целый год моложе. Т.е. на самом деле автор скрывает от нас всё самое современное.
selivanov_pavel
15.12.2018 00:42+1. hg использует ту же модель распределённой VCS, что и git. Я его однажды использовал(давно), на мой вкус удобнее git при тех же возможностях.
kalininmr
16.12.2018 18:07между моделями hg и git есть, по крайней мере, одно крупное отличие.
висящие ветки git невозможны в hg.
несколько разная топология.
в hg всегда остается источник.
avkoval
16.12.2018 09:43Да, статья мне в целом на 90% понравилась но этот момент покоробил. Я, как программист работавший с до cvs-эры, перешёл на CVS, потом на Subversion, потом на Mercurial и git могу сказать что с этой перспективы мне жаль что git стал намного популярнее, потому как в с hg работать легче и система сама более понятная и удобная. Важно для меня — в hg сложнее «выстрелить себе в ногу» — тут историю не затрёшь, в то время как в git это поставлено на поток, у пользователя полный контроль (во flow с rebase для ветки, так вообще постоянно это делают, но рискуют тем, что при неадекватных действиях пользователя, затереть часть истории, а часто вы встречали программистов которые на 100% хорошо понимают что они делают с git? я — не часто).
Работая на проектах и с hg и с git, могу сказать что по функционалу они пересекаются на 90%, при этом функционал mercurial в целом шире, но из за того что система непопулярна, сложно найти адекватную поддержку в тулзах (github, gitlab и тп только для git, потому приходиться юзать другие, менее удобные пакеты и сайты) и это большой минус. Ну и второй минус прилагается — программистам сложно переключаться, все привыкли к git, и внедрить hg в другой компании — шансы близки к нулю, при всех очевидных для меня преимуществах.
В общем автор тут не прав, но видимо что то пошло у него не так. А статья хорошая, спасибо!
VaalKIA
14.12.2018 21:34Вопросы не мальчика, а…
Заголовок спойлера
SergeyEgorov
14.12.2018 22:13+3И как? В скольких из сорока компаний все разработчики пишут тесты?
sfilatov96 Автор
14.12.2018 22:32+1Почти везде. Видимо мне везло. Но многие говорят что есть, а на деле 20 тестов которые гоняются раз в день.
SergeyEgorov
14.12.2018 22:50+1Это круто! Я собеседовался раз пятьдесят и мне всегда говорили что писать тесты разработчикам некогда.
skapral
14.12.2018 23:14Наверное можно было бы спросить вместо «пишете ли вы тесты» что нибудь вроде «какое у вас покрытие тестами». Тогда уже простым «есть» не отмажешься.
sfilatov96 Автор
14.12.2018 23:17покрытие — это хороший показатель, но не достаточный. покрытие мб 100 процентное, только вот тестов всего 5, из за того что в тестах криво расставлены проверки ибольшая часть файлов заигнорина на coverage. Сам тако видел.
skapral
16.12.2018 03:50Вообще идея какбэ была не в том что покрытие — показатель, а в том что если команда знает и может назвать свое покрытие тестами, значит относится к тестированию серьезней чем вышеупомянутое «20 тестов прогоняемые раз в день». Но таких ушлых ребят как вы щас описали наверно никакими вопросами не смутишь)
Shpiler
14.12.2018 22:47Все же перечень вопросов заточен на некоторый не очень широкий спектр компаний, которые занимаются, скорее всего, привычным вам вещами. Например список тех, кому можно простить отсутствие тестов всего один пункт про стартапы. А как же хардварщики? Или вы знаете как покрыть тестами код для микроконтроллера, который к тому же может иметь внушительные вставки на ассемблере? А ещё есть компании которые вообще никогда ничего не программировали, но тут им резко понадобился человек в новый отлел, который с помощью этих ваших компукхтеров наконец поможет бизнесу встать на рельсы современности. Понятно, что никакого CI, код ревью и прочего аджайла там нет и быть не может, но разве это не круто с нуля сделать классный проект, особенно если за это готовы хорошо платить? Ближайший пример из жизни — компания всю жизнь занималась радиотехникой, проектировали антенны и усилители, а тут пришёл заказчик и говорит — хочу чтоб ваше железо слало мне данные вот в таком то виде, и вот тут ещё сбоку аналитику надо приделать. И делают, нанимают программистов, те работают, софт их работает. А новомодных методик разработки как не было так и нет
sfilatov96 Автор
14.12.2018 22:53Коллега, добрый день!
22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик». Таково название статьи. Насколько я знаю python не относится к хардварным вещам. Мб за исключением raspberry или orangepi.Shpiler
14.12.2018 22:59Я тоже так думал. Пока не увидел код управления многотонными механизмами написанный Целиком на питоне. И кстати хорошо работает…
sfilatov96 Автор
14.12.2018 23:20Наверное этот код дальше скармливается в транслятор и превращается в Си. Ибо я с трудом понимаю как интерпретируемый язык может исполняться на микроконтроллере.
Shpiler
14.12.2018 23:37В микроконтроллерах там обычный С и asm, но и логики в них около нуля, просто преобразуют байты в вольты и обратно. А вот вся логика на питоне в линуксе под х86. Ту её часть что отвечает за хотелки заказчика, конечно, покрыли тестами, а вот уровнем пониже стоит регулятор скорости (и не только) на том же питоне и как его автоматически тестировать придумать так и не удалось. Тупо потому что у сервера с тестами нет той самой штуки скорость которой надо регулировать. Она есть где то в другой стране, туда разработчики ездят живьём и живьём же вручную все тестируют, благо площадь полигона и перехват управления в ручной режим позволяют ничего при этом не сломать.
bugdesigner
15.12.2018 02:42Очень даже легко может исполняться. Есть такой прект https://micropython.org — сам использовал на esp8266
Shpiler
14.12.2018 22:54UPD. А, да, статья то про python, так что ассемблер не в кассу. Но тем не менее. Не раз видел (и писал) питоний код, который общается с суровым железом и тестами не покрывается почти никак в виду прямой и неэмулируемой зависимости входных данных от выходных
SergeyEgorov
14.12.2018 23:01Мне кажется автоматизированно тестировать в наше время можно что угодно. Было бы желание и средства. Ну а сделать с нуля классный проект, особенно если он масштабный, на мой взгляд невозможно, если нет никаких автоматизированных средств контроля качества.
Shpiler
14.12.2018 23:24Тут вопрос что считать масштабным. После какой то степени разрастания кодовой базы, версий и самой команды разработчиков — да, становится (почти) невозможно. Особенно если предполагается такая неприятная сущность как сторонний пользователь, которому нужны фронтэнд, куча уровней защиты от дурака и вот это вот все. Но многим задачам и не нужны такие масштабы, есть вполне серьёзные вещи, которые решаются силами команды из 3-4 человек. Из того что сам видел — видеоаналитика для ЦОДД, там реально всю систему пилят три программиста, один из которых ПиЭм и документации делает больше чем кода. Ну и куда им этот CI?
sfilatov96 Автор
14.12.2018 23:28В случае с ЦОДД стоит задуматься над проблемой BUS-фактора и проблемой внедрения нового сотрудника.
Shpiler
15.12.2018 00:10Как ни странно — проблема автобуса остро стоит для компании в примере на пол ветки выше и то в силу некоторых исторических причин, которые возникли, когда вместо разработчика нанимали технологию (где то даже здесь была статья на эту тему), а привычка писать документацию ещё не родилась. У ребят с видеоаналитикой в этом плане все в порядке — насколько мне известно там или типовые решения, которые любой грамотный новый разработчик сможет без труда понять и воспроизвести или же все довольно неплохо описано в документации, которую просто требуют сверху
le1ic
14.12.2018 22:48+2В целом вопросы разумные, в том смысле, что понятно желание знать на них ответ, но…
1) ответы на многие вопросы практически ничего не значат. «Используется ли технология контейнеризации в проектах?» да, и что? нет, и что? «Какую систему контроля версий Вы используете?» да какая блин разница. Различия некритичные. Да, гитхаб удобнее всего сейчас, но если нужно будет cvs использовать в конкретном проекте, будем его использовать.
2) Некоторые вопросы вызовут раздражение. «Ну твое какое дело, как выбиваются ресуры» — подумаю я себе мысленно. Сразу множество допущений в вопросе, что ресурсов нет, что их нужно выбивать, что собеседующий в этом участвует, что в компании это обсуждается среди тех, в чьи обязанности это не входит. Тут человек показывает, что он не понимает границ своей роли в компании. И вообще разделения ответственности. А значит будет лезть везде.
Какие БД используются в проекте? Почему именно такие? Знаете, «так исторически сложилось» — это самый разумный ответ на этот вопрос. Потому что в 90% проектов разницы нет никакой. А в оставшихся 10% разница есть, но нет верного ответа, потому что всегда есть какой-то tradeoff. И выбирать приходится не БД, а способы (архитектуру) работы с ней.
Используется ли в проекте ELK-технология? опять вы показываете, что ваши вопросы строятся на многих предположениях, которые у вас в голове, и которые являются следствием ограниченного опыта. Тут правильный вопрос был бы, есть ли у разработчиков вообще доступ к логам на продакшене.SirEdvin
15.12.2018 00:24Тут правильный вопрос был бы, есть ли у разработчиков вообще доступ к логам на продакшене.
А ошибки на этом продакшене кто исправляет тогда?
le1ic
15.12.2018 01:18разработчики
SirEdvin
15.12.2018 10:20А как можно исправлять ошибки, если у вас нет информации к логам на проде? На слух от кастомера?
le1ic
15.12.2018 10:37+1Мы на собеседовании проверяем телепатические способности, и умение обращаться с бубном. Разве не все так делают?
На самом деле просто представьте как работают компании, имеющие строгие требования к безопасности. В них у рядовых разработчиков никогда не будет доступа к продакшн серверам, данным пользователей, продакшн логам. Один из вариантов — есть люди с доступом, которые умеют работать с логами. Достаточно пары человек.SirEdvin
15.12.2018 10:48Ну, нормальные компании обычно сразу на выходе просто скрывают чуствительную информацию из логов, оставляя обезличенную.
Компании, в которых лютую "безопасники", в основном занимаются странными вещами, на мой взгляд.
le1ic
15.12.2018 11:05+1Да, но это сложно, практически невозможно, гарантировать. какой-нибудь отладочный трэйс, или эксепшн кинутый в стороннем коде включает переданную информацию.
SirEdvin
15.12.2018 11:58Если мы говорим про python, то обычно для этого настраиваются handler'ы. В том же sentry это довольно неплохо работает.
Areso
15.12.2018 13:49+12) А я вот на должности разработчика принимал в этом участие. Ничего приятного в этом нет. Вместо увеличение ОЗУ в текущем ноутбуке я внезапно, без предупреждения, получил другой ноутбук (причем даже другой фирмы), но это мелочь. А вот чтобы получить виртуалку, мне нужно было ночью монтировать неучтенный сервер в машзале (шутка — это было днем. Сервер, впрочем, был неучтенный). Причем, чтобы получить на него IP адрес и VLAN, другой коллега тоже совершил должностной проступок. В общем, самое настоящее преступление, по предварительному сговору, группой лиц.
Закупка ПО, написанием обоснования которого занимался в т.ч. и я, ведется уже около полугода. Из-за закупки другого инфраструктурного ПО, пришлось резко сдергивать проекты с одних серверов и перемещать на другие сервера. Внезапно оказалось, что к новым серверам нет сетевых доступов и это вылилось в офигенный квест с безопасниками, сетевиками и еще 5 или 6 отделами, каждому из которых нужно было доказать, что в этом есть необходимость. И да, если где-то ошибешься — начинай весь этот work-flow заново. Один из моих коллег (тоже разработчик), раз в 2 недели по расписанию, пишет слезное письмо в одну иностранную компанию с просьбой предоставить свежие триал-ключи. Потому что закупка идет, идет уже около года, и обязательно когда-нибудь закончится хэппи-эндом, но пока — дайте ключи, пожалуйста.
Так что нет, это нифига не праздный вопрос, особенно, если это крупная компания, в которой может быть километры всяких бюрократических процедур.
Так что возможно это не человек будет лезть везде, а ему, без его на то желания, будут делегировать те или иные задачи, связанные с ресурсами.
Даже если вдруг повезет, и весь ресурсный вопрос будет висеть на руководителе, то вопрос «как быстро» тоже имеет значение. У нас, к примеру, между согласием купить и покупкой может проходить несколько лет, за которые, сами понимаете, часть людей успеет сменить работу.
sfilatov96 Автор
14.12.2018 23:00-1по моему Вы прочитали вопросы, но не прочитали к ним пояснения.
Насчёт ELK — вопрос возможно неправильно сформирован. Логи хранить — дело нехитрое. Но разобраться в их огромной каше и как-то их систематизировать — это другой вопрос. Поэтому и спрашиваю про технологию ELKselivanov_pavel
15.12.2018 00:47Есть Splunk, Graylog, можно сложить логи в ClickHouse, ещё куча вариантов. Почему именно ELK?
SirEdvin
15.12.2018 00:56Splunk как то не очень прижился для логов. Graylog — внутри него ElasticSearch, так что уходит в ELK.
ClickHouse это классно, да. Еще вот grafana labs выкатити loki. Но в целом еще некоторое время назад ELK был фактически стандарт и ничего другого просто не было.
sfilatov96 Автор
15.12.2018 10:47Коллега, добрый день!
ELK — это обобщённая аббревиатура. И кстати на собеседовании все прекрасно понимают о чём идет речь даже если у них не используется ни она из трёх букв
SergeyEgorov
14.12.2018 23:19Есть еще вопрос, который я задаю потенциальным нанимателям после стажировки в одной достаточно крупной софтверной компании.
Используются ли при учете рабочего времени системы журнализации и записи действий разработчика за компьютером? Удивительно было после первого рабочего дня обнаружить в автоматизированном табеле уведомление — "Учтено 6,5 часов. Необходимо доработать 1,5 часа".
DistortNeo
15.12.2018 21:07Бред какой-то. Подобные системы приводят только к снижению продуктивности, и, как следствие, к снижению зарплаты.
habr.com/post/102620SergeyEgorov
16.12.2018 07:10В наше время много чего уже известно о природе и психологии человеческой, однако знания эти не мешают нанимателям практиковать устаревшие, но любимые ими методы управления.
saipr
14.12.2018 23:50Как обстоят дела с выбиванием ресурсов?
После прочтения ваших вопросов (они все правильные) встал вопрос, это вы проходили собеседование и устраивались на работу, или это вы проводите собеседования и ищите работников.
Что лучше hg, svh и т.п. — это дело традиций в том числе.DRVTiny
15.12.2018 00:46По-моему при разработке софта, как и в общении с другими людьми, самый важный и просто критически недооценённый людьми с узко-технарским кругозором момент — это способность мысленно поставить себя на место того, кто будет пользоваться продуктом интеллектуальной деятельности разработчика (а при общении — способность мысленно поставить себя на место того, кто выслушивает твою очередную едкую праведно-гневную филипику).
Это не только важный момент, но ещё и объективно — самый сложный, потому что очень трудно отринуть весь свой опыт и все свои единственно верные представления об окружающем мире — и попытаться представить, как мыслит и чего, собственно, хочет тот человек, который будет пользоваться плодами твоей работы. А ему, как это ни странно, может быть важно совсем не то, что важно тебе: не экономия миллисекунд, а грамотно написанная документация, которая позволяет не влезать в исходные коды, чтобы понять «как же оно на самом деле работает», не тестирование, покрывающее искусственно смоделированные ситуации, а возможность оперативно решить проблему в случае возникновения ситуации, которая может вообще никак и никогда не моделироваться в искусственной среде.
Нужно понимать, что наличие реальных денег в компании зависит от заказчиков. И от наличия реальных денег в компании атмосфера в коллективе в российских реалиях зависит порой куда больше, нежели от того, предпочитают там hg или git. И хотя понятно, что с заказчиком взаимодействуют не сами разработчики напрямую — всё-таки не стоит забывать, для кого и для каких реальных условий эксплуатации пишется ваше ПО.saipr
15.12.2018 11:23хочет тот человек, который будет пользоваться плодами твоей работы.
Дай бог, чтобы это было именно так. Но порой между конечным потребителем и разаботчиком стоит промежуточное звено (интегратор, посредник и т.д. и т.п.). И не факт, что он понимает потребителя, а вот с разработчиком может и найти консенсус.
DRVTiny
15.12.2018 00:03Я как человек с преимущественно админским опытом, успевший поработать с тысячами «единиц» разного софта, задал бы ещё несколько вопросов:
1) А что конкретно ваш софт пишет в логи? Есть ли в компании какие-то стандарты, не позволяющие разработчикам не логировать ничего или логировать на «отстань от меня, пожалуйста» или логировать только на этапе отладки, а затем просто на уровне макросов удалять все вызовы логера, «чтоб оно у клиента/заказчика быстрее работало и чтоб клиент не видел лишнего!» Насчёт макросов — вопрос не о конкретном ЯП, а просто принципиальном подходе. Есть такие вещи как OpenLDAP, Samba и Zabbix, умеющие логировать всё чуть ли не построчно, а есть — что-то вроде rsyslogd или zebra, которые могут быть весьма загадочны и непредсказуемы
2) Есть ли определённый стандарт подробности обработки исключений? Насколько распространена ситуация, когда исключение «обрабатывается» (снова по принципу «на… отцепись пожалуйста») на 5 уровней выше того места, где оно возникает? Отличаются ли информация, предоставляемая в случае возникновения исключения, для этапа «отладки» и этапа эксплуатации заказчиком в продуктиве. Есть ли понимание того, что заказчику может быть как минимум неприятно и больно видеть стек-трейс с глубиной вложенности в 20 уровней и что неплохо бы предоставлять в таких случаях информацию, полезную заказчику «что в общих чертах произошло и как это можно исправить», а не предполагать, что заказчик во всех абсолютно ситуациях должен бежать к вам, о великий разработчик, даже если недотестированное и вывалившее какую-то невразумительную околесицу приложение нужно здесь и сейчас. Я неоднократно сталкивался с приложениями, которые вываливали гигантский стек-трейс в ответ на что-то вроде «не могу забиндится на порт» или «такого файла не существует». Если честно, в таких случаях у меня абсолютно всегда возникало желание кастрировать тех, кто так пишет софт. Я сам не всегда пишу тесты и не всегда даже пользуюсь системами контроля версий, но зная о том, насколько критичными бывают вменяемые сообщения об ошибках — хотя бы никогда не делаю их криптографическими и понятными только мне как разработчику.
3) Ну и да, я бы обязательно узнал, почему в компании выбрали именно Python при таком обилии качественных и несложных компилируемых языков со статической типизацией. Потому что база данных — это, безусловно, хорошо (особенно когда это не MySQL vs PostgreSQL, а что-то вроде PostgreSQL vs. ClickHouse vs. Tarantool), но если код пишется на интерпретируемом языке с прекрасным во всех отношениях GIL — наверное, для этого есть очень веские основания? Хорошо бы всё-таки при этом главным основанием была не дешевизна и переизбыток на рынке python-девелоперов, что позволяет убегать на совещания, когда очередной умник начинает задавать слишком много вопросов…
P.S. И да, сложность стандартных алгоритмов (на 99% уже имеющих готовую общедоступную реализацию, в т.ч. в виде C++ блобов для Python) — это, конечно, важно, но для оптимизации производительности неплохо бы знать и некоторые internals целевой системы. Поэтому конечно следует поинтересоваться у потенциального работодателя, что он знает, например, о современной структуре виртуальной памяти в Linux. Ну и классический конечно вопрос: если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление? Кстати, поспрашивать работодателя о флагах clone, о преимуществах и недостатках разделяемой памяти (shared memory), о стоимости переходов между разными кольцами защиты ОС — тоже совершенно не повредит…SirEdvin
15.12.2018 00:331) А можно пример? Я не представляю себе как можно стандартизировать логгирование и точно разделить, что логгировать надо, а что нет, не сделав при этом кучу излишних действий и не превратив дебаг логи в полноценную отладочную машину.
2) Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом, он легко читается и подсказивает где что нужно подправить. Segmentation fault в этом плане значительно хуже.
3) Да бы не начинать холивар по поводу языков могу заменить, что все зависит от точки зрения. Я вот не знаю ни одного достаточно популярного компилируемоего языка, который бы меня так же устраивал как python. Жду когда в rust завезут async/await и можно будет снова проходить растбук.
если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление?
Мне вот интересно — это был такой выпад в сторону технологии? Просто вопрос звучит так же, как "как глубокоуважаемый работодатель исправит бесконечный цикл запущенный в собранном c++ бинарнике". Я думаю, вы уже знаете ответ.
DRVTiny
15.12.2018 00:58Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.
Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта. Когда я разрабатываю что-то — мне интересны стек-трейсы. Когда я как пользователь вижу стек-трейс на экране вместо вменяемой диагностики проблемы («Отсутствует файл такой-то, процедура установки выполнена некорректно», «Файл такой-то недоступен для записи, проверьте прав доступа», «Не могут создать новый сокет — проверьте лимиты на количество открытых файлов») — у меня это вызывает как минимум раздражение: я не понимаю, почему я должен видеть информацию, которая понятна только разработчику, если приложение мне дали как продуктивное, а не как некий «subject for deeper debugging». Во многих ситуациях я могу сам исправить проблему или даже искусственно создать приложению те условия, в которых оно всё-таки будет работать, даже если в нём и содержится какой-то баг. Мне-то нужно, чтобы оно работало, а не собирало стек-трейсами «полезную информацию для отладки продуктива».SirEdvin
15.12.2018 10:15Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.
А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта.
Не только, я тут мастер на все руки :) Просто у меня стек трейсы сидят где-то по середине, самое раздрадающее это "что-то пошло не так" или ошибки, которые вроде как обработаны, но которые не имеют никакого отношения к реальной проблеме, например, когда приложение пишет, что не может подключится к порту, а на самом деле ему не хватает прав создать папку, но у него на все ошибки один обработчик.
Neutral
16.12.2018 14:53А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.
Полагаю, примерно как с убийством тредов извне. Но это работает только если поток не завис насмерть, а просто долго выполняет какую-то синхронную операцию.
DRVTiny
15.12.2018 01:04Я не представляю себе как можно стандартизировать логгирование
Речь не о техническом документе, хотя для того же кода на C бывает полезно делать trace-отладку типа «вошли в функцию такую-то, важный аргумент такой-то равен вот этому значению» и вокруг обработки внешнего ввода хорошо бы расставлять побольше диагностики, потому что это и есть реальный источник львиной доли ошибок в якобы хорошо протестированных приложениях. Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».SirEdvin
15.12.2018 12:12Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
Может я не прав, но мне кажется, что задать вопросы с более-менее очевидными ответами довольно странно.
Как и с вопрос о базе данных, если вы потребуете какого-то осмысленного ответа, более-менее опытный разработчик обязательно скажет что-то в духе того, что вы написали. Хотя вряд ли у них прямо будет прописанный Code of Conduct с конкретным списоком пунктов кодекса.
le1ic
15.12.2018 01:17Есть ли в компании какие-то стандарты... (логгирования, обработки исключений)
Насколько в компании сильна бюрократия?
Я считаю, это прекрасно. Разработчики как всегда такие разработчики.
SDKiller
15.12.2018 01:23> также серьёзно, как и…
> целисообразности
Однозначно говорит в пользу проведения собеседований в письменной форме.
Соответственно, вопросы претендентов к собеседующим тоже имеет смысл принимать в письменной форме.
saga111a
15.12.2018 10:26+2которые до сих пор использует hg, svn и прочие древние системы контроля версии
А вы можете привести нормальное объяснение на счет mercurial? Или это у вас — не знаю, не использовал, значит плохо?sfilatov96 Автор
15.12.2018 10:38-3ужасный облачный сервис который хранит код. не проведешь нормально код ревью. то есть надо использовать что-то сторонеее
нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.
+ поддержка hg, насколько мне известно заканчивается в след году.ranzhe
15.12.2018 10:50+1Недостатки vcs и недостатки облачного сервиса с каких-то пор стали понятиями тождественными?
sfilatov96 Автор
15.12.2018 11:02вы можете много назвать облаков кроме этого www.mercurial-scm.org/wiki/MercurialHosting
ranzhe
15.12.2018 11:14+2Назвать много не могу, но могу сделать довольно смелое предположение, что существует жизнь и за пределами облачных сервисов.
saga111a
15.12.2018 10:57нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.
Что?
Вы систему версионирования путаете с настройкой конкретного сервера, а не знание системы с отсутствием функционала.
Простите, но с столь некомпетентными заявлениями очень тяжело слушать и серьезно воспринимать рассказ о том как надо вести себя мидлу.sfilatov96 Автор
15.12.2018 11:04я тоже могу ошибаться к и миддл.
лучше кинуть ссылки и разжевать.
я на двух местах работы сталкивался с проблемой того что нельзя разграничить доступ на конкретную ветку.
вместо stash-а есть shelve.saga111a
15.12.2018 11:13>ужасный облачный сервис который хранит код. не проведешь нормально код ревью. то есть надо использовать что-то сторонеее
посмотрите на bitbucked
shelve да, но с настройками.
защита веток —
1) Опять расширения www.mercurial-scm.org/wiki/AclExtension
2) Регулировать процесс иным способом(делать пуш в иную репу с одного хранилища)
saga111a
15.12.2018 11:25+1Если я верно помню то hg и mercurial создавались в одно время по одной и тоже причине — разрабам(ядра линуха) закрыли доступ к системе контроля версий. И выходцы от туда создали свое.
Подходы несколько разные, есть свои плюсы и минусы, и там- и там. Я не буду вам пересказывать статьи выложенные на хабре на тему их сравнения и разводить срач на тему чьямамасистема контроля версий лучше, но назвать mercirual древним указывая на гит несколько странно и некомпетентно.
Все что делаю не для себя или просто с кем-то — git ибо почти все его используют. Все что делаю для себя — меркуриал, ибо удобней.danfe
15.12.2018 14:42+2Все что делаю для себя — меркуриал, ибо удобней.
Так точно. Я старыйсолдат, и не знаю слов любвипользователь CVS и Subversion; Mercurial имхо намного проще и понятнее, чем Git с его наркоманской командной строкой. :-)
playnet
16.12.2018 18:21А ещё с какого перепуга svn вдруг стал древним? У него совсем другой подход, он централизованный, это плюс и минус. Не мейнстрим — это да.
Плюсы, которые мы активно использовали
— Чекаут части пути
— авторизация из коробки (у гита тоже есть gitolite тот же, но это сторонний продукт)
— если много добавляется и удаляется, чекаут существенно меньше чем у того же гита, нет нужды тянуть все изменения
— это больше решение для разработки с закрытым кодом; разработчиков легче разграничивать в правах (можно выдать доступ только на отдельные ветки), при удалении логина у разработчика остаётся только 1 версия а не полное дерево с первого коммита, и при утечке исходников гораздо проще понять кто виновник
— уже на стадии коммита идёт проверка на «свежесть» версии и если она не последняя то сначала нужен мерж
— А ещё он проще того же гита.
Минус пока только 1 могу вспомнить — невозможность работы без доступа к серверу — ни ветку сменить, ни коммиты заслать.
Это всё то что сходу вспомнил.saga111a
16.12.2018 18:40У меня с svn были проблемы с мерджами. Было это лет 6 назад, точно не помню в чем заключалось, но по моему где-то в действиях смена ветки, мердж и загрузка на сервер заключался ад, точно не могу припомнить…
playnet
16.12.2018 18:44С мержем есть некая беда, это да. Впрочем, в гите оно тоже не на волшебном порошке и у меня уже было несколько раз, что оказалось проще сделать чистый клон и потом заново коммитить все свои изменения. Но тоже причин не помню.
nick_gabpe
15.12.2018 13:43+1Я бы ещё задал пару вопросов:
1 пишете ли вы в соответствии с pep8?
2 сколько нужно времени на согласование новой библиотеки в проект.
xpg934
15.12.2018 16:36+240 собеседований за 2 года… нашли ли вы идеал?
Чем больше смотрю на подобные посты, тем больше задаюсь вопросом — люди, вам работать/создавать/добиваться, или антураж/печеньки и как минимум одну новую футболку в неделю, и обязательный вид на горы из окна?
Если я на все эти вопросы отвечу как ожидает задающий, то итоговая стоимость часа разработки для конечного клиента такого работодателя будет запредельная.
Будьте проще. И задайте себе вопрос — а как же раньше все это работало? А то дожили, коммит в гитлаб не пушится и все, можно собираться и домой идти, не могу так работать.
Простите. Наболело.sfilatov96 Автор
15.12.2018 16:52Коллега, добрый день!
Нашёл идеал и в нём работаю, чего всем желаю)
Ни про какие горы, антуражи и печеньки я не писал в этой статье.
Согласен, час работы стоит дорого при таких условиях но никто не запрещает Вам работать в компании с иностранным финансированиемxpg934
15.12.2018 17:21В данном случае я представляю как раз — сторону работодателя.
Ответ ожидаемый, слышал его не раз. В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку. Отрасль перегрета как раз зарубежными деньгами, а разработчики превратились в «дешевую» рабочую силу для зарубежных «дорогих» денег. Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».
Да, есть исключения — компании, которые пилят именно свои продукты и продают из world-wide, но их не так много (и требования к работникам очень серьезные), а у молодого джуна без опыта, который почитает годик хабр на лекциях в универе, создается ощущение — что работать можно и нужно только в больших корпорациях, где все налажено, и там будет прям весело и круто, как показывают в обзорах офисов гугла и прочих яндексов. Дальше они начинают все это искать, а сталкиваются с аутсорсерами, которые просто продают их как… рабов, простите, зарубеж. Дорого продают.powerman
16.12.2018 08:01+2В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку.
Простите, просто хочу уточнить, правильно ли я Вас понял. Вы пытаетесь сказать, что поскольку у "внутреннего Российского заказчика" нет денег, то разработчики должны идти к нему работать на меньшую зарплату и в худших условиях, потому что… что? Из патриотизма? Чтобы избежать участи "раба", причём "рабство" заключается исключительно в том, что он работает на зарубежных заказчиков? Если я Вас понял правильно, то Вам явно не помешает заглянуть в словарик, почитать определение рабства, потом почитать какие законы Россия принимает в последнее время, и немного подумать… в смысле, подумать своей головой, самостоятельно, без подсказок из телевизора.
Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».
И какова же, на Ваш взгляд, причина того, что в зарубежных компаниях количество неинтересных и ерундовых проектов заметно больше, чем в местных компаниях? Кстати, простите что спрашиваю, но как именно Вы подсчитали количество (не) интересных проектов и там и там чтобы сравнить?
И, да, действительно, толковым ребятам совсем невозможно уйти с неинтересных проектов, ведь рынок так перегрет, хорошие программисты совершенно не могут найти хорошую работу и вынуждены держаться за текущее место, даже если занимаются там полной ерундой.
P.S. Кстати, у меня есть для Вас лайфхак: логику хоть и перестали преподавать в школах, но пока ещё не запретили, так что надо ловить момент, и учить её самостоятельно, пока ещё есть такая возможность.
dvayanu
15.12.2018 18:12+2«3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?»
Если в компании есть DevOps-инженер то они не понимают что такое DevOps, как судя по всему и автор этого текста.SirEdvin
15.12.2018 22:08+2Я люблю этот магический культ «никто не понимает что такое девопс».
В текущих реалиях рынка DevOps-инженер это тот чувак, который занимается CI/CD и новомодными практиками в духи контейнеризации, мониторинга приложений и прочего. Я совсем не понимаю, что вас не устраивает.23derevo
15.12.2018 23:35-1Это не культ. Просто отдельный хаброписатель не знает матчасть, вот и всё. А незнание матчасти вызывают сомнения в его экспертизе.
SirEdvin
16.12.2018 00:13+1Это не культ. Просто отдельный хаброписатель не знает матчасть, вот и всё. А незнание матчасти вызывают сомнения в его экспертизе.
Вы же понимаете, для того, что бы упрекнуть в незнании матчасти, нужно, что бы она была. А четкое определения "DevOps" найти довольно сложно, как и в целом определение чему угодно в программировании. Вспомните тоже ООП. У нас тут нет какого-то существенного научного сообщества, которое смогло бы выработать терминологию, как в той же математике.
Поэтому мне кажется довольно странно придиратся к словам, учитывая, что это довольно часто используемое выражение в описании вакансии.
customtema
16.12.2018 10:38Как-то совсем по-джуниорски. Как-то ну совсем теоретически.
На эти вопросы дадут ответы не более, чем в одной из двадцати компаний. А вот другая сторона медали… зарплата в тех компаниях, в которых вам ответят на эти вопросы, вам не понравится =)
SirEdvin
Я так понимаю, вы всегда можете ответить на данный вопрос, когда начинаете проект? И не каким-нибудь "ну, эту базу данных я знаю, а с другой у нас никто работать не умеет".
Лично мне кажется, что это довольно жесткое требование. Например, убер не очень справился с этим например, а вроде неплохая технологичная компания.
sfilatov96 Автор
Хотя бы уметь обосновать, что эту БД знают многие разработчики поэтому мы её и взяли в качестве инструмента.
le1ic
«эту БД знают многие разработчики» я предпочитаю, чтобы код был на 99% независим от конкретной БД, и переход с pg на mysql выполнялся строчкой в конфиге. И только в 1% по-настоящему критичного кода можно как-то заложиться на особенности конкретной БД. А теперь давайте подумаем, что эти 99+1% кода работы с БД составляют процентов 5 кода всего проекта. И нафига ради 0.05% кода нужно чтобы многие разработчики ее знали? Пусть лучше знают базовые алгоритмы и их сложность.
sfilatov96 Автор
бэкенд — это всё таки связующее звено между данными и клиентской стороной. поэтому основные БД и их отличия разработчик должен знать.
Даже упоминая алгоритмы и их сложности было бы неплохо чтобы разработчик знал чем тот же самый Redis отличается от PostgreSQL.
kloppspb
Лет 20 назад я позволял себе думать, что такое возможно :)
le1ic
Это просто вопрос дисциплины архитектуры. Иметь как можно меньше завязок на внешние технологии.
Мы например уже много лет сидим в облаке. И за это время успешно переезжали между Heroku, Google cloud и AWS за конечное время и с не очень большими трудовыми затратами.
И если вдруг нужно будет переехать с постгрес на mysql, то мы за месяц-полтора одним человеком управимся, потому что единственная уникальная функция постгрес — `SELECT FOR UPDATE SKIP LOCKED`, ее использование — осознанное. Больше мы ничего постгрес-специфичного не используем.
cyberly
Как-то не очень вяжется:
SirEdvin
А вы учитываете, что нужно не только мигрировать код, но еще инфрастуктуру, перенастроить мониторинг и вспомогательные аналитические тулзы, которые как раз таки почти всегда прибиты к базе данных? Типо заменить pghero и pgpool на что-то другое (А еще это другое найти и протестировать).
le1ic
да, собственно это и есть основная работа. Миграция кода не больше недели.
Source
Нет, это либо тривиальные проекты, либо банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.
le1ic
> банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.
Я то как раз считаю, что это мудрость. И стандарт SQLxx не зря существует.
Source
Стандарт стандартом, но во-первых полнота его поддержки отличается в разных СУБД, а во-вторых разные СУБД добавляют разные возможности для оптимизации различных запросов.
А в вашем случае, вам остаётся небольшое подмножество стандарта, которое поддерживается более-менее одинаково основными игроками рынка СУБД, в итоге вы делаете запросы неоптимально и с кучей ненужных костылей. Для простых проектов, конечно, без разницы, а для нетривиальных — это потеря производительности и удобства разработки на ровном месте.
Например, как можно использовать PostgreSQL, но при этом не использовать jsonb, PostGIS, CTE, полнотекстовый поиск, оконные функции, индексы по функциям и т.д.? Я уж молчу про партиционирование и прочие тонкости работы с большими БД.
le1ic
jsonb — это во-первых как раз потеря производительности на ровном месте, потому что при размер json больше пары килобайт мне быстрее будет сжимать и обрабатывать json на стороне приложения. Во-вторых это значит код приложения наполнен кастомным SQL, в обход ORM.
gis — да, нужная штука, если он нужен в проекте, но по-моему сейчас все БД поддерживают gis
полнотекстовый поиск — отстой в постгресе, с кучей ограничений
оконные функции — хм, никогда не использовал. Зачем для аналитики? Для аналитики постгрес отстой
CTE — да классная штука, используем, входит в тот 1% от всего кода работы с БД.
Индексы по функциям — ну может в каком-то очень нетривиальном проекте. Но индексы с условием — да, полезная вещь, но это лишь вопрос оптимизации.
Партиционирование — лучше его делать на уровне приложения. Как и все, что касается высокой нагрузки и скорости. Если что-то можно сделать на уровне приложения, лучше сделать это там, так будет более масштабируемо.
вы делаете запросы неоптимально и с кучей ненужных костылей -как я уже писал, 90% проектов это обычные реляционные схемы, для который SQL и был придуман. Приведите мне пример одной специфичной функции PG, который нужен хотябы в 20% обычных web приложений.
Source
Причём тут сжимать? Это полноценный document-storage без необходимости затаскивать в проект к-н Mongo без крайней необходимости. Плюс с возможностью использовать эти поля в условиях на выборки.
Зато не все ORM поддерживают )))
Вы показываете низкую квалификацию такими утверждениями. Любое решение имеет свои trade-offs, и полно случаев когда поисковых возможностей PG более чем достаточно, а затаскивать Solr, Sphinx или Elastic в проект — нецелесообразно.
Ну, это говорит о том, что Вы и стандарт плохо знаете, потому что они даже там есть, но детали реализации в разных СУБД отличаются. Для чего используются? Много для чего: https://postgrespro.ru/docs/postgresql/10/tutorial-window
90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.
Что такое "обычное web приложение"? Не хотите поработать над необычным? )))
SirEdvin
И поехали. Сначала касательно mongo, elasticsearch и так далее.
У них есть нормальное шардирование и нормальный кластер, у postgres — нет. В случаи возможности взять es я бы лучше es взял.
И аппеляция к тому что "ой, ну это же другая технология" не очень уместны. Что json, что полнотекстовый поиск в postgres тоже идут как другая технология, не очень связанная с привычной реляционкой.
Ну, кто-то же их должен делать? И автор коммента как раз написал, что в этих проектах крутые штуки от специфической бд не очень то нужны.
le1ic
С ужасом представляю приложение используещее gis, оконные функции, полнотекстовый поиск и все это не в реляционной модели, а в документах. И чего, апдейтов 10 в секунду держит? )))
OnYourLips
А я только с такими проектами в последние годы и работаю.
SQL вижу только в автоматически сгенерированных миграциях и логах.
Areso
Слышал мнение, что ORM убивает производительность и преимущества любой СУБД.
kalombo
Убивают программисты, ORM же ничего убить не может, это все лишь инструмент, который переводит питон код в SQL.
Source
Ok, убивают программисты, которые не знают SQL и строят запросы через ORM, как через чёрный ящик.
le1ic
В какой-то степени. Есть две опасности ORM. Первая, самая очевидная, бездумные джоинв. Но тут надо просто включить голову и все-таки хоть немного понимать, как работают реляционные СУБД. Ну и желательно поменьше джоинов. Тут просто аккуратность кода и схемы БД нужна.
Вторая проблема менее очевидна, поэтому более опасна. Многие ORM по умолчанию грузят объект целиком. И если у вас есть (очень условный пример) User, и у него в одном из полей хранится допустим картинка, то каждый раз при обращении к модели, ORM будет вытягивать объект целиком. С этим бороться немного сложнее. Потому что неизвестно, где вылезет.
DistortNeo
Видимо, разные ORM бывают. С теми, что я сталкивался — ничего лишнего не грузят.
le1ic
Я последние пару лет с рельсами имею дело. Как там в питоне и hibernate уже не очень помню.
le1ic
А как они грузят, кстати? Нужно явно список полей передавать? Или они lazy? Но тогда это не транзакционно, да и накладные расходы могут еще больше быть.
kalininmr
смотря какая. django вполне может в паре случаев нехило тормознуть(но они известны).
а sqlalchemy достаточно гибка и ей можно подсказать.
всякая экзотика вроде pony тормозит.
в orm часто другие узкие места получаются, например построение кучи объектов.
danfe
Gugic
Я бы сказал что это плохой (неинтересный) пример в плане того, что миграция с условной Mongo на условную же Postgres в реалиях условной java — пример сильно интереснее. (а в обратную сторону — еще интереснее)
Merkat0r
зачем? ради хипсто-каргокульта?
le1ic
))))
Naves
Uber с вами не согласен.
habr.com/company/devconf/blog/353682
habr.com/company/southbridge/blog/322624