Возможно вы опечатались, имели в виду snake case, "змеиный", т.к. подчеркивания выглядят как змейка. Sneak имеет совсем другое значение, и не слышал чтобы его для case упоминали
Кликнул на статью почитать, а это значит что заголовок получился кликбейтным успешно.
Для контекста - я не являюсь экспертом по С++, хотя легко его читаю, но неплохо разбираюсь в конкурентности и многопоточности. И вот, уже читаю вводные к проблеме, мне показалось что автор ошибается. Когда я прочитал предлагаемое решение, +- стало понятно в чем дело, и я еще больше понял почему я не хочу иметь ничего общего с миром пишущих на С++. И дело не в С++ самом.
Моя школа скептически относится к использованию всяких "санитайзеров" и "инспекций" кода, приоритизируя грамотный дизайн кода вместо этого. Здесь же автор сначала описывает классические симптомы "г****кода", который то работает то нет, и падает неожиданно, а потом, на полном серьезе предлагает "улучшить санитайзинг и инспекции". Окей, а какие еще варианты решения предлагает автор в самом начале? Еще эти: вообще отказаться от многопоточности, фактически, и - использовать готовые библиотеки, и (!)(!) - использовать другой язык. Оуоуоу.
Но какая же самая главная ошибка в рассуждениях? Самая главная имхо ошибка, это сама предпосылка что "мютекс живет отдельно от данных, своей жизнью". Это как так-то? Это ж значит вы его сами и разместили отдельно от данных? Своими руками-то, лично? Там есть еще аргумент, что "вдруг потом кто-то классы поменяет, и мютекс заживет своей жизнью". А вы не рассматривали вариант - просто не пускать менять классы тех, кто не понимает как мютексом пользоваться?
А как им кстати пользоваться? А мютекс ВСЕГДА должен быть вместе с защищаемыми данными. И размещение мютекса отдельно, это классический ляп любого студента или джуна. В данном случае, автор видимо открыл для себя эту проблему, и придумал решение в виде описать интерфейс/абстрактный класс, требующий чтобы делать как правильно. ЭТО ХОРОШО, автор нашел правильное решение, вот только делать это можно и без изобретения класса SharedState, а просто знать как правильно, и так делать.
Я понимаю автора - сам немало велосипедов настроил когда-то, под соусом "великих методик". Это нормальный процесс обучения, и набора опытом. Поэтому, я статью плюсую.
Но в то же время, меня смущает три момента:
1) Автор всерьез предлагает как решение проблемы "усиление санитайзинга и инспекции" и прочего статического анализа кода. Че серьезно, это решение? Это значит, что окружение, коллеги автора, тоже так считают. И это печалька.
2) Просто шокирует простыня комментов под статьей. Это значит, что есть огромная аудитория в С++-мире, которая не знает как делать правильно синхронизации? Предложения спинлоков как варианта решения тоже "доставило". Или в чем дело?
3) Я пришел по статье из канала про КасперскиОС - из чего можно предположить что эту ОС пишут джуны и студенты? Вот это уже пугает.
Отличная статья, только я так и не понял, при чем тут было глубокое дерево, если проблема в итоге была в не очистке кэша?) Вообще, я когда статью начинал читать, сразу подумал, "а нет ли у них там кэша, который не очищается нормально?") Оказалось так и было) А почему я так подумал, потому что кроме утечек-утечек, кэш - еще один патологический пожиратель памяти. Но работу вы провели великолепную, читал с удовольствием.
Предположим, у Вас болит зуб. Это проблема, в смысле задача. Ее надо решить.
Правильное решение - найти стоматолога. Профессионального, который с оборудованием, принимает в кабинете, а еще некоторые люди отзывы смотрят прежде чем к нему идти.
Ваш вариант - есть проблема здесь и сейчас - незачем искать стоматолога, подойдет любой прохожий с пассатижами?
Ээээ... Там много что пишут. Когда вы идете устраиваться на работу, вы матчите то что там написано, с тем что вы сами про себя считаете. И то что порой в требованиях пишут рандомный набор - это же все знают, что об этом говорить-то? Это просто так есть.
Вы должны сами для себя прежде всего понимать кто вы есть в этом мире, что вы умеете, какую ценность несете.
Таким образом слова "то на что претендуете" - это не про список требований в вакансии. Это - про то что вы сами про себя считаете и вслух говорите.
Например - вы приходите на вакансию Питон-программиста. Или 1С. Или любого другого. Или стоматолога. Или менеджера. Сам факт что вы пришли - манифестация вами утверждения что вы в этом профессионал, вы декларируете "вот я, я пришел, я знаю Питон".
И если вы и правда его знаете - вам не страшны никакие опросы и вопросы. Если вы его правда знаете. А если не знаете - вряд ли заучивание поможет.
Хм. :) То что я хотел сказать - сказал. Детализируйте плз какого продолжения вы ждете, и я могу даже спираль из лома скрутить, ток подать, и в среде аргона лампочку сделать!
Еще раз, чтобы не было разночтений: - список вопросов который всем так не понравился - моя личная шпаргалка. - Вам, при использовании моей шпаргалки, возможно не надо пользоваться ей буквально. - список не является "официальным чеклистом для приема на работу" куда либо - это моя личная шпаргалка. - Эта шпаргалка - прежде всего не для тех кто ищет работу, но прежде всего для тех кто проводит собеседования. Материал для вдохновления, чтобы написать свою. Возможно даже, для другого языка (!). Смотрите шире и более обще. - Несмотря на критику, под каждым словом подписываюсь, так что не надо тут "накидывать косвенно" на МТС. Не согласы - пишите мне лично "ты написал дичь", и (!) содержательно аргументируйте почему. - И САМОЕ ГЛАВНОЕ: лучший способ пройти любое интервью - по чесноку знать то, на что претендуете. Тогда не придется ничего заучивать.
Статья как раз о том, что возможно НЕ НАДО спрашивать про определение транзакции, или про труктуру пакета. Вы, для себя, для своего проекта, должны определить что точно и без вариантов должен кандидат знать. На все остальное можно закрыть глаза.
Важно ли для вашего проекта знание структуры пакета? Да или нет? Если нет - это не попадает в список. Если да - тогда да. И так по каждой позиции.
Данный список - моя личная шпаргалка, чтобы самому уже не путаться (т.к. когда проведешь два собеса в день, (а и так было), то уже не помнишь что спрашивал что нет), и это не официальный список МТС. Более того, наверняка многие коллеги со мной бы поспорили, по этому списку.
Вообще-то, это мой личный список вопросов. Моя личная шпаргалка. Ну а поскольку я работаю в МТС, то если вы придете к нам на работу устраиваться, и вам "повезет" что собеседовать буду я, то я задам эти вопросы... или не эти, или другие. Но это точно не копирование кого-то. Если у кого-то так же (а мне уже говорили об этом, как комплимент), ну значит крутяк, я мыслю похожим образом, и для вас дорогие читатели выше вероятность что это валидный подход.
Я имел ввиду то, что не надо вестись на красивые рассказы. В том кокретном случае не было "если кандидат покажет", а было "кандидат рассказывает". Так-то если покажет - то я согласен, и сам являюсь сторонником того что лучший определитель кто он - это что он сделал. Покажи что ты сделал - я скажу кто ты.
А у вас есть показать, что вы сделали? У меня - есть. Но есть не у всех.
Этот разговор, о том как понять вообще профпригоден кандидат или нет. Например, я убежден, что человек пришедший из PHP, и не понимающий что есть стек и поток (а эти вопросы именно после общения с адептами PHP, не хочу никого задеть, честно), на бэке не может работать, на высоконагруженных проектах. Статья о том, как отсеять.
Если у вас есть знакомый, который может показать свои проекты, с тестами и CI/CD, то может и тратить время вот на это все и не надо. Но таких знакомых на пересчет пальцев, обычно.
Автор здесь: да, поймали меня. Так вышло потому, что сначала был список вопросов, который пополнялся. Он и сейчас есть, на гитхабе, на английском правда. Статья была дописана сверху него, как бы. Таким образом, здесь нет противоречия. Да, такой вопрос есть. И да, я считаю что это плохой вопрос. Как говорил Ларри Уолл - "1 - я всегда прав, 2 - я могу изменить свое мнение".
Там же написано, что цель статьи - не дать вам чеклист готовый! Она как раз об этом. Я поражен сколько много комментов, и, пользуясь случаем хочу ответить тем, кто удивляется тем что вопросы какие-то может не нужны, или неуместны..... Друзья! Эта статья - мой личный опыт (история рассказанная за пивом), вкупе с некоторой моей личной шпаргалкой. И как и всякую не свою шпаргалку, использовать все это буквально точно не надо.
Скорее, это про определенную мысль, которая пронизывает статью от начала до конца, о отношении к самому действу под названием собес. Что это? Для чего он? А список вопросов, вы если что, и сами напишите. Этот список - просто пример, рассматривайте его так, и не более чем так.
И еще. Да, у нас в МТС высокий уровень. И да, мы считаем что разработчик бэка должен отличать L2 и L3. И точно должен знать про память.
Кто-то писал, что "а что я могу почерпнуть отсюда". Окей, если вы прочитали, это заставило вас задуматься - вы уже что-то почерпнули.
Отличная статья! Следующий шаг, после сентимент анализа комментариев - сентимент-анализ статей, перед публикацией :)
Отличная статья, спасибо. Картинка с базовыми ценностями сверху очень хороша.
Возможно вы опечатались, имели в виду snake case, "змеиный", т.к. подчеркивания выглядят как змейка. Sneak имеет совсем другое значение, и не слышал чтобы его для case упоминали
Кликнул на статью почитать, а это значит что заголовок получился кликбейтным успешно.
Для контекста - я не являюсь экспертом по С++, хотя легко его читаю, но неплохо разбираюсь в конкурентности и многопоточности. И вот, уже читаю вводные к проблеме, мне показалось что автор ошибается. Когда я прочитал предлагаемое решение, +- стало понятно в чем дело, и я еще больше понял почему я не хочу иметь ничего общего с миром пишущих на С++. И дело не в С++ самом.
Моя школа скептически относится к использованию всяких "санитайзеров" и "инспекций" кода, приоритизируя грамотный дизайн кода вместо этого. Здесь же автор сначала описывает классические симптомы "г****кода", который то работает то нет, и падает неожиданно, а потом, на полном серьезе предлагает "улучшить санитайзинг и инспекции". Окей, а какие еще варианты решения предлагает автор в самом начале? Еще эти: вообще отказаться от многопоточности, фактически, и - использовать готовые библиотеки, и (!)(!) - использовать другой язык. Оуоуоу.
Но какая же самая главная ошибка в рассуждениях? Самая главная имхо ошибка, это сама предпосылка что "мютекс живет отдельно от данных, своей жизнью". Это как так-то? Это ж значит вы его сами и разместили отдельно от данных? Своими руками-то, лично? Там есть еще аргумент, что "вдруг потом кто-то классы поменяет, и мютекс заживет своей жизнью". А вы не рассматривали вариант - просто не пускать менять классы тех, кто не понимает как мютексом пользоваться?
А как им кстати пользоваться? А мютекс ВСЕГДА должен быть вместе с защищаемыми данными. И размещение мютекса отдельно, это классический ляп любого студента или джуна. В данном случае, автор видимо открыл для себя эту проблему, и придумал решение в виде описать интерфейс/абстрактный класс, требующий чтобы делать как правильно. ЭТО ХОРОШО, автор нашел правильное решение, вот только делать это можно и без изобретения класса SharedState, а просто знать как правильно, и так делать.
Я понимаю автора - сам немало велосипедов настроил когда-то, под соусом "великих методик". Это нормальный процесс обучения, и набора опытом. Поэтому, я статью плюсую.
Но в то же время, меня смущает три момента:
1) Автор всерьез предлагает как решение проблемы "усиление санитайзинга и инспекции" и прочего статического анализа кода. Че серьезно, это решение? Это значит, что окружение, коллеги автора, тоже так считают. И это печалька.
2) Просто шокирует простыня комментов под статьей. Это значит, что есть огромная аудитория в С++-мире, которая не знает как делать правильно синхронизации? Предложения спинлоков как варианта решения тоже "доставило". Или в чем дело?
3) Я пришел по статье из канала про КасперскиОС - из чего можно предположить что эту ОС пишут джуны и студенты? Вот это уже пугает.
Отличная статья, только я так и не понял, при чем тут было глубокое дерево, если проблема в итоге была в не очистке кэша?) Вообще, я когда статью начинал читать, сразу подумал, "а нет ли у них там кэша, который не очищается нормально?") Оказалось так и было) А почему я так подумал, потому что кроме утечек-утечек, кэш - еще один патологический пожиратель памяти. Но работу вы провели великолепную, читал с удовольствием.
Но тогда в первые можно было поставить 2 по 4, тогда все компы получились бы одинаковые?
Предположим, у Вас болит зуб. Это проблема, в смысле задача. Ее надо решить.
Правильное решение - найти стоматолога. Профессионального, который с оборудованием, принимает в кабинете, а еще некоторые люди отзывы смотрят прежде чем к нему идти.
Ваш вариант - есть проблема здесь и сейчас - незачем искать стоматолога, подойдет любой прохожий с пассатижами?
Ээээ... Там много что пишут. Когда вы идете устраиваться на работу, вы матчите то что там написано, с тем что вы сами про себя считаете. И то что порой в требованиях пишут рандомный набор - это же все знают, что об этом говорить-то? Это просто так есть.
Вы должны сами для себя прежде всего понимать кто вы есть в этом мире, что вы умеете, какую ценность несете.
Таким образом слова "то на что претендуете" - это не про список требований в вакансии. Это - про то что вы сами про себя считаете и вслух говорите.
Например - вы приходите на вакансию Питон-программиста. Или 1С. Или любого другого. Или стоматолога. Или менеджера. Сам факт что вы пришли - манифестация вами утверждения что вы в этом профессионал, вы декларируете "вот я, я пришел, я знаю Питон".
И если вы и правда его знаете - вам не страшны никакие опросы и вопросы. Если вы его правда знаете. А если не знаете - вряд ли заучивание поможет.
Хм. :) То что я хотел сказать - сказал. Детализируйте плз какого продолжения вы ждете, и я могу даже спираль из лома скрутить, ток подать, и в среде аргона лампочку сделать!
Да, там можно еще многое добавить, спасибо!
Еще раз, чтобы не было разночтений:
- список вопросов который всем так не понравился - моя личная шпаргалка.
- Вам, при использовании моей шпаргалки, возможно не надо пользоваться ей буквально.
- список не является "официальным чеклистом для приема на работу" куда либо - это моя личная шпаргалка.
- Эта шпаргалка - прежде всего не для тех кто ищет работу, но прежде всего для тех кто проводит собеседования. Материал для вдохновления, чтобы написать свою. Возможно даже, для другого языка (!). Смотрите шире и более обще.
- Несмотря на критику, под каждым словом подписываюсь, так что не надо тут "накидывать косвенно" на МТС. Не согласы - пишите мне лично "ты написал дичь", и (!) содержательно аргументируйте почему.
- И САМОЕ ГЛАВНОЕ: лучший способ пройти любое интервью - по чесноку знать то, на что претендуете. Тогда не придется ничего заучивать.
Статья как раз о том, что возможно НЕ НАДО спрашивать про определение транзакции, или про труктуру пакета. Вы, для себя, для своего проекта, должны определить что точно и без вариантов должен кандидат знать. На все остальное можно закрыть глаза.
Важно ли для вашего проекта знание структуры пакета? Да или нет? Если нет - это не попадает в список. Если да - тогда да. И так по каждой позиции.
Данный список - моя личная шпаргалка, чтобы самому уже не путаться (т.к. когда проведешь два собеса в день, (а и так было), то уже не помнишь что спрашивал что нет), и это не официальный список МТС. Более того, наверняка многие коллеги со мной бы поспорили, по этому списку.
Эх, вот уж этот список
Вообще-то, это мой личный список вопросов. Моя личная шпаргалка. Ну а поскольку я работаю в МТС, то если вы придете к нам на работу устраиваться, и вам "повезет" что собеседовать буду я, то я задам эти вопросы... или не эти, или другие. Но это точно не копирование кого-то. Если у кого-то так же (а мне уже говорили об этом, как комплимент), ну значит крутяк, я мыслю похожим образом, и для вас дорогие читатели выше вероятность что это валидный подход.
90 минут достаточно. Если на вопросы есть корректные ответы. Если нет - 30 минут вежливости. Ну час.
Читайте внимательнее :) все вопросы не надо задавать. Это не чеклист. Это шпаргалка.
Посмотрите мой ответ на это выше. Да, есть такое. Сорян гайз. Выше коммент почему так, и как так :)
Я имел ввиду то, что не надо вестись на красивые рассказы. В том кокретном случае не было "если кандидат покажет", а было "кандидат рассказывает". Так-то если покажет - то я согласен, и сам являюсь сторонником того что лучший определитель кто он - это что он сделал. Покажи что ты сделал - я скажу кто ты.
А у вас есть показать, что вы сделали? У меня - есть. Но есть не у всех.
Этот разговор, о том как понять вообще профпригоден кандидат или нет. Например, я убежден, что человек пришедший из PHP, и не понимающий что есть стек и поток (а эти вопросы именно после общения с адептами PHP, не хочу никого задеть, честно), на бэке не может работать, на высоконагруженных проектах. Статья о том, как отсеять.
Если у вас есть знакомый, который может показать свои проекты, с тестами и CI/CD, то может и тратить время вот на это все и не надо. Но таких знакомых на пересчет пальцев, обычно.
Автор здесь: да, поймали меня. Так вышло потому, что сначала был список вопросов, который пополнялся. Он и сейчас есть, на гитхабе, на английском правда. Статья была дописана сверху него, как бы. Таким образом, здесь нет противоречия. Да, такой вопрос есть. И да, я считаю что это плохой вопрос. Как говорил Ларри Уолл - "1 - я всегда прав, 2 - я могу изменить свое мнение".
Там же написано, что цель статьи - не дать вам чеклист готовый! Она как раз об этом. Я поражен сколько много комментов, и, пользуясь случаем хочу ответить тем, кто удивляется тем что вопросы какие-то может не нужны, или неуместны..... Друзья! Эта статья - мой личный опыт (история рассказанная за пивом), вкупе с некоторой моей личной шпаргалкой. И как и всякую не свою шпаргалку, использовать все это буквально точно не надо.
Скорее, это про определенную мысль, которая пронизывает статью от начала до конца, о отношении к самому действу под названием собес. Что это? Для чего он? А список вопросов, вы если что, и сами напишите. Этот список - просто пример, рассматривайте его так, и не более чем так.
И еще. Да, у нас в МТС высокий уровень. И да, мы считаем что разработчик бэка должен отличать L2 и L3. И точно должен знать про память.
Кто-то писал, что "а что я могу почерпнуть отсюда". Окей, если вы прочитали, это заставило вас задуматься - вы уже что-то почерпнули.
Желаю всем хорошего и продуктивного 2022 года!