Мифы разработки и Reference Promotion
Есть тема управления памятью и в ней много заблуждений. Часто это связанно с формулировками и дефинициями. А также, что многое нельзя проверить практикой.
Например, один из вопросов для споров: "когда value type хранится в куче?". Этот вопрос далеко не всегда практический, но часто его задают, чтобы оценить эрудицию и начитанность кандидата статьями и опытом. Это неплохая оценка, ведь показывает насколько глубоко любит копать кандидат чисто на интересе. Его задали сегодня в нашем чате.
Тут обычно вспоминают Boxing.
Когда происходит Boxing? (Вспоминая великий фильм Seven хочется пошутить What's in the box????). Компилятор прибегает к этому в нескольких случаях:
- когда value type нужно хранить в Any или протоколе
- когда переменную захватывает замыкание и она должна пережить стековый фрейм
- внутри инициализаторов структур, чтобы мутировать self, пока он ещё не до конца сконструирован
Одно из заблуждений, которое встречал на собесах, это ожидаемый ответ "когда структура хранит в себе классы". Но это не совсем правда.
В "куче" структура только "бывает" при инициализации. После выхода из инициализатора box уничтожается, и структура может снова жить как value.
В итоге, как правильно отвечать на вопрос "живет ли структура в куче"?
Есть тема управления памятью и в ней много заблуждений. Часто это связанно с формулировками и дефинициями. А также, что многое нельзя проверить практикой.
Например, один из вопросов для споров: "когда value type хранится в куче?". Этот вопрос далеко не всегда практический, но часто его задают, чтобы оценить эрудицию и начитанность кандидата статьями и опытом. Это неплохая оценка, ведь показывает насколько глубоко любит копать кандидат чисто на интересе. Его задали сегодня в нашем чате.
Тут обычно вспоминают Boxing.
Boxing — это когда значение value type (структуры или enum) кладут в специальный объект в куче. Внутри box хранится само значение, а переменные получают ссылку на него.
Когда происходит Boxing? (Вспоминая великий фильм Seven хочется пошутить What's in the box????). Компилятор прибегает к этому в нескольких случаях:
- когда value type нужно хранить в Any или протоколе
- когда переменную захватывает замыкание и она должна пережить стековый фрейм
- внутри инициализаторов структур, чтобы мутировать self, пока он ещё не до конца сконструирован
Одно из заблуждений, которое встречал на собесах, это ожидаемый ответ "когда структура хранит в себе классы". Но это не совсем правда.
В "куче" структура только "бывает" при инициализации. После выхода из инициализатора box уничтожается, и структура может снова жить как value.
В итоге, как правильно отвечать на вопрос "живет ли структура в куче"?
Обычно структура — это value type, и она хранится в стеке или inline в другом объекте. Но во время инициализации или в особых случаях (замыкания, протоколы, Any) компилятор делает boxing — временно помещает структуру в кучу.
В закрытой базе собрал детальный разбор самых полезных советов. Есть и очевидные, но также и не совсем.
Я напомнию, что действует последние дни акции. Потом не говорите, что не предупреждал.
Впереди месяц вайбкодинга и промт-инженеринга. Удивительно даже для меня, но там много интересного можно обсудить и пощупать, что меняет привычки. Там будет много живых общений и разборов. А также кое-какие интересные сюрпризы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Overeducated & underexperienced
Недавно в комментариях на одном канале тимлидов наткнулся на классный фидбэк про систему образования.
Там сравнивали подходы вузов, отмечая СНГшную систему как ту, что даёт много теории и базы, но мало практики. Приведу цитату::
Вы можете со мной не согласиться, но как сын учителей и педагогов, я часто слышал от своих родственников похожие споры.
Сейчас я собеседования не провожу, но раньше активно участвовал в них. Мне нравилось придумывать секции для iOS-разработчиков и добавлять туда элемент справедливости. Я воспринимал это как баланс в игре: если его не поддерживать, система уходит в хаос.
О дизайне собеседований и о том, почему всё не так просто, как советуют ютуб-блогеры, можно будет поговорить отдельно. Давайте про реальные вещи, а не пересказы пересказов тех, кто давно не работает и работает только с искаженной призмой.
В одной из прошлых компаний действовало правило "Если кандидат говорит слишком много теории, но не справляется с простыми практическими задачами — это красный флаг".
Что это значит? Не нужно путать эрудицию и практику. Бывают кандидаты, кто идеально рассказал управление памятью: компилятор, сайд таблицы, стэк и куча, isa поинтеры и всё всё всё. Но только ему даешь изи задачу на утечку памяти, то он сыпится. Что делать с такими кандидатами?
Что делать с такими кандидатами? В команде тогда спорили долго, но сошлись на том, что нанимают не участников "Что? Где? Когда?", а людей, которые будут решать реальные задачи. В итоге правило было простым: нерешенная практическая задача обнуляет даже самые блестящие теоретические ответы.
Знать как делать идеально != делать идеально. Именно поэтому в этом канале и закрытой базе я делаю акценты на задачники, а не теорию. Её отлично может упаковать уже нейронки, а руку набить до идеальности могут только многократные неидеальные повторения. Нужно найти границу между overeducated и underexperienced.
Недавно в комментариях на одном канале тимлидов наткнулся на классный фидбэк про систему образования.
Там сравнивали подходы вузов, отмечая СНГшную систему как ту, что даёт много теории и базы, но мало практики. Приведу цитату::
>Так обучают в традиционной российской школе и вузах:
В своё время от канадца услышал тот же фидбэк о выпускнике МГУ: overeducated & underexperienced.
Вы можете со мной не согласиться, но как сын учителей и педагогов, я часто слышал от своих родственников похожие споры.
Сейчас я собеседования не провожу, но раньше активно участвовал в них. Мне нравилось придумывать секции для iOS-разработчиков и добавлять туда элемент справедливости. Я воспринимал это как баланс в игре: если его не поддерживать, система уходит в хаос.
О дизайне собеседований и о том, почему всё не так просто, как советуют ютуб-блогеры, можно будет поговорить отдельно. Давайте про реальные вещи, а не пересказы пересказов тех, кто давно не работает и работает только с искаженной призмой.
В одной из прошлых компаний действовало правило "Если кандидат говорит слишком много теории, но не справляется с простыми практическими задачами — это красный флаг".
Что это значит? Не нужно путать эрудицию и практику. Бывают кандидаты, кто идеально рассказал управление памятью: компилятор, сайд таблицы, стэк и куча, isa поинтеры и всё всё всё. Но только ему даешь изи задачу на утечку памяти, то он сыпится. Что делать с такими кандидатами?
Что делать с такими кандидатами? В команде тогда спорили долго, но сошлись на том, что нанимают не участников "Что? Где? Когда?", а людей, которые будут решать реальные задачи. В итоге правило было простым: нерешенная практическая задача обнуляет даже самые блестящие теоретические ответы.
Знать как делать идеально != делать идеально. Именно поэтому в этом канале и закрытой базе я делаю акценты на задачники, а не теорию. Её отлично может упаковать уже нейронки, а руку набить до идеальности могут только многократные неидеальные повторения. Нужно найти границу между overeducated и underexperienced.