Собеседование на Middle PHP разработчика

ruticker 02.03.2025 12:34:33

Текст распознан YouScriptor с канала AreaWeb

распознано с видео на ютубе сервисом YouScriptor.com, читайте дальше по ссылке Собеседование на Middle PHP разработчика

Всем привет, друзья! Меня зовут Михаил, это проект, и вот наконец-то новое видео, и оно про собеседование, то что вы очень сильно любите. Судя по просмотрам, предложили мне пройти собеседование на вакансию PHP девелопер. Не сказано, кто именно, но я думаю, это уровень примерно метла. Ищут, короче, зарплата от 150, то есть там я так примерно прощупал, до 180-190 готовы платить. Компания небольшая, это стартап, ему всего лишь год. До этого у них была аутсорсная контора, которая, собственно, предоставляла им разработчиков. Сейчас они набирают штат себе собственных разработчиков. Я сразу хочу вас попросить прощения за то, что в этом видео будут постоянно в середине видео где-то Telegram-уведомления, вот эти звуки. Если что, это из видео, поэтому простите, пожалуйста, я забыл замьютить. В этом видео будет только техническая часть, и она необычная, потому что меня собеседовал техдир, он не PHP-шник, и задавал мне всякие такие общие вопросы. Всегда стыковались PHP плюс были интересные вопросы по паттернам проектирования, теорию которых я не то чтобы хорошо знаю. В целом паттерны не так часто и знаю, такое множество, которое применял бы на своей практике. Короче, интересное собеседование, оно меня натолкнуло на то, что надо очень много почитать, поизучать, и надеюсь, вам тоже как бы подтолкнет вас на то, чтобы вы тоже как бы потянули какие-то моменты. Если вас интересует, как мы начинали наш звонок, то есть как я рассказывал о себе и какие вопросы я задавал своему интервьюеру, то бегом к нам в Telegram-канал, там все эти отрывки будут. В этом видео их не будет, это да, такой байт на Telegram на подписочку. Плюс там же будет сама вакансия в PDF. Собственно, на этом все. Все соцсети также есть в описании, подписывайтесь на ВКонтакте, Telegram, как я сказал, наш чат в Telegram, там общаемся, помогаем при необходимости. Ну и приятного просмотра! Так, ну собственно, давай начнем с базы. В принципе, а, ну принципа, да, принципа 3 — это инкапсуляция, это полиморфизм и наследование. Инкапсуляция — это когда мы можем защитить данные, которые находятся у нас в объекте, взаимодействовать с ними только внутри этого объекта и не позволять извне как-то менять там состояние и так далее. То есть инкапсулируем то, с чем работаем. Там, как пример, приватные свойства. Достаточно. Дальше, наследование — это возможность расширять возможности класса, к примеру, путем наследования от другого класса его функционала. Полиморфизм — это, как бы так это выразится, ну скажем так, возможность, скорее проще привести пример. У нас есть один родительский класс, который имеет какой-то метод, и мы можем в дочернем классе от этого класса занаследоваться и переопределить этот метод. При этом у нас есть два, как бы, возможных класса, от которых мы наследовались, у них есть два одинаковых, ну то есть одинаковые два метода, но выполняя их, выполняется разный код, потому что мы переопределили родительский, фактически переопределение, как бы, методов дочернего класса, вот так сказать. Хорошо. На самом деле, инкапсуляция, я все чаще слышу именно такое определение. Тем не менее, базовая инкапсуляция, конечно, предполагает скорее включение в один объект полей и методов, конечно же, не исключая, как бы, вот этой вот принципы приватности полей и методов. Нет, имеется ввиду, что мы до момента возникновения, как бы, объект программирования, как бы, поля и методы — это были разные совершенно сущности, и объединяя в одну, как бы, в одну сущность эти две разных, две разных, как бы, сущности, тавтологию, мы как раз получаем, как бы, то самое капсулирование, то есть прям по названию инкапсулирование. Инкапсуляция, типа, это включение в один объект, это полей и функций. Это чисто теория, это так на будущее. В целом ты прав, конечно же. Скажи, пожалуйста, в своей работе ты используешь наследование и полиморфизм? Да, причем постоянно. Я пишу всякие абстрактные классы с набором, с базовым набором какого-то функционала, при этом обязывая, там, например, реализовывать часть функционала по абстрактным методам. Банальный пример: вот из недавнего, ночами работал, у меня была задача подключения двух разных платежек. Функционал у них абсолютно в целом похож, просто условно поинты разные. Там, где-то за платежные ссылки создавался класс, там, payment system, условно абстрактные, с набором основного функционала, где есть всё для обработки продукта и, там, не знаю, обработка колбэков. Но вот методы getURL, paymentURL и всё остальное, это, соответственно, реализовывался отдельно уже, когда я наследовался. Также часто использую обычные классы, там, когда, не знаю, часто оказываюсь в таких ситуациях, когда мне нужно сделать сахар для, например, работы с базой данных, то есть свою минимальную ORM, при этом подключить стороннюю, либо я не могу, создаю какую-то общую модель, от которой потом, как в том же Laravel, наследуют свои классы. Там уже, соответственно, весь функционал для работы с базой есть. Там, условно, в методе getTableName ты указываешь название таблицы, и весь функционал для работы с этой таблицей уже в родительском классе. Звучит супер! Так, хорошо, ты затронул, значит, вот еще какую тему. Скажи, пожалуйста, про четвертый принцип, не слышал случайно? Четвертый принцип? Нет, наверное, честно, на самом деле, слышал, конечно. Судя по тому, что ты говоришь, я понимаю, что просто невозможно не... Это самое. Да, конечно, это редко называют. Обычно говорят, да, действительно, про третий принцип. Но это, в принципе, тоже окей. Скажи, пожалуйста, а у тебя вот тоже, исходя из того, что мы с тобой проговорили, а у тебя какой язык программирования? Ты, так понял, там попробовал как минимум несколько штук, какой-то вот любимый? Именно прям, ну, любимый у меня PHP 8+. Именно всё, что ниже, немножечко не очень, потому что в 8+ появляются всякие, но улучшается типизация, всякая вот эта вот история, которая мне нравится. Вообще, в целом, мне нравится TypeScript, но TypeScript — это не язык, мне нравится. Она за типизации. Нравится C#, но самый любимый, то что лежит к сердцу ближе, это, конечно, PHP. Вот еще какой-то странный язык, не помню. Ну да. Хорошо. А скажи, пожалуйста, а почему еще PHP у тебя? Почему ты его выделяешь, почему он тебе любимый? Ну, мне нравится та инфраструктура, во-первых, комьюнити. Нравится, нравится то, как сейчас развиваются фреймворки, какой крутой сахар мы имеем там для разработки, уже очень быстрой разработки бизнесовых задач. Мне всё это нравится, все эти опенсорсные штуки. Я сам периодически занимаюсь написанием пакетов под Laravel или просто пакетов. В общем, мне всё это комьюнити, вся эта история нравится. Язык сам неплохой, опять же, начинается с восьмой версии. Понятно. Окей, тоже заговорил про типизацию. Давай поговорим, что... Ну, как бы так сформулировать. Какая бывает? Можно так сформулировать: бывает строгая типизация и неявная типизация, что-то такого, нестрогая типизация в PHP. Я просто не помню, как правильно называется. Строгая типизация — прям строгая. У тебя нет там, условно, возможности, как например в C#, указать в качестве аргумента тип строка и передать мне число. В PHP, в целом, если мы не используем какую-нибудь там, не помню, как эта функция называется, чтобы указать более жесткую проверку типов, то по дефолтным настройкам, передавая там в аргумент, который строка, число, оно будет конвертировано в строку. Как сам считаешь, какая лучше? Ну, строгая, на мой взгляд, лучше, конечно. Хотя у неё есть свои минусы, скажем так, проблемы и сложности при разработке. Но, например, ну, как сказать, опять же, ты не такой гибкий. Короче, у тебя код будет стрелять, если вдруг с сервера внешне... Вот у нас был однажды случай, можно быстренько расскажу. Мы писали на C# клиент для одного внешнего сервиса, и клиент этот внешний сервис, у него был API, который был написан на PHP. И у него, из-за того, что это было написано на PHP, а как это сказать, короче, возвращалась, я не помню, как точно возвращалась, в одном поле в одном случае объект ключ-значение, а в другом случае пустой массив, потому что JSON-код, он работает немножечко нестабильно. В таких ситуациях, и ты, соответственно, у себя на стороне C#, где уже определил, что да, это дикшинари, там, Киеве, и соответственно ждёшь одного, а тебе приходит там массив. И опа, всё ломается. Да, как бы в этом проблема строгой типизации. Вот это как пример. Хорошо, хорошо. А еще вот ты шаг зацепил, ты на самом деле сказал, я и прошу прощения, меня тут по работе дёргают чуть-чуть, буквально пропустил. А что тебе, всё понравился или не понравился C#? Мне нравится язык, он мощный, похож на JavaScript и, соответственно, и на PHP. Знаешь, связь TypeScript, типа TypeScript с PHP перемешанный. Вот нормальный, но, к сожалению, я просто, у меня не было времени нормально заняться им. Там тратил время на английский, на PHP, на C#, она не учила нормально так, но успел поработать, знаешь, там, открыть пару файликов, разобраться в коде. Так сложно. Так, значит, смотри, такой вопрос. Сейчас, как они называются, своими забываю. Ладно, Бог с ним. Скажи, пожалуйста, списочный типы в PHP есть? Смотря в каком? Списочный тип — это, ну, вообще есть, наверное, если я правильно понимаю. Ну давай, давай, как ты понимаешь, что такое списочный тип? Списочный тип — это просто набор, список элементов, каких, не знаю, массив, лист. Я, честно говоря, не особо, поэтому мне всё время интересно, и этот вопрос всё время вызывает затруднение. Какой списочный тип? Ассоциативные массивы — это словари в C#, условно. Поэтому да. Вот, хорошо. Не суть важно, по большому счету. Давай предположим, что массив ты, значит, передаешь массив, например, функции аргументом, потом внутри функции изменяешь значение внутри массива, который снаружи, этой функции значение поменяется? А если мы передадим функцию массив и поменяем внутри функции значения массива? Вот так? Да, не поменяете, если мы не сделаем его ссылочного типа, кого переменные аргумент, который мы передаем функции. Хорошо. А скажи, пожалуйста, по умолчанию в PHP как передаются аргументы: по ссылке или по значению? По значению. По значению, то есть создастся копия массива. Да, и поэтому, собственно, снаружи не поменяется. Окей, принято. Так, что ещё такого по теории? Как по-русски называется этот... Ложе? Сейчас, подожди, забыл прям. Да, это речь про анонимные функции. Давайте, собственно, есть, есть стрелочные функции, есть анонимные. Что это такое и зачем используется? Ну, в PHP появились лямбда-функции, начиная с версии 7.4. Это можно, наверное, провести аналогию с JavaScript-овскими, типа стрелочной функции. Короче, ну, в общем, анонимная функция — это функция, которая не имеет никакого названия. Её можно передать как аргумент в какой-то другой, например, метод или занести в какую-нибудь переменную и уже вызвать отдельно. При этом, ещё в PHP есть особенностью анонимных функций, что они имеют возможность, у них есть, короче, оператор, с помощью которого можно в тамбэк-функцию передать дополнительные данные. Очень полезно, когда какой-то замыкание там. Спасибо, подсказал мне, я вылетаю из головы каждый раз. И до замыкания. Расскажи, пожалуйста, про замыкание. Что это такое? Ну, замыкание — это, собственно, вот то, о чем я сказал. В PHP эта функция анонимная, которая имеет оператор, с возможностью принимать дополнительные параметры. И, соответственно, она анонимная, она может быть спрятана в виде переменной или передана в виде аргумента какой-то функции и вызвана уже внутри этой функции, а не посредственно сам механизм замыкания. Как? Что такое? Что происходит, когда замыкание же не только к PHP относится, на самом деле. Замыкание в целом — просто некий механизм. Механизм замыкания, ну, предположим, что-нибудь, если не знаешь, в моем понимании. Но это же... Может быть, я помню, ты собеседование мне разъясняли эту историю, но я уже очень... Я понял, да, это сейчас один из самых частых вопросов фронт-фронтам. Да, потому что это, типа, там в JavaScript, там немножечко другое представление. Я, честно говоря, не помню, но да, там чуть-чуть другое представление. Но по факту замыкание, ещё раз говорю, это механизм, который, он в целом реализуется во многих языках программирования, может по-разному немножечко называться, но в целом механизм-то один и тот же. Фактически это сохранение контекста, э, ну, то есть внешнего контекста и функции, то есть там какие-нибудь аргументы, которые ты передаёшь. Ты же анонимную функцию передаёшь, а у него контекст теряется фактически внешний, когда, как когда ты там где-то там в другом месте вызываешь. Паттерны проектирования. Давай поговорим про них. Какие знаешь, какие типы бывают, какие использовал сам? Аля вот сейчас. Да, сегодня все против меня, видимо. Да, а ещё раз, паттернов проектирования довольно много, они делятся на различные группы. Я, честно говоря, не помню. Я помню структурная группа, порождающие. Есть паттерны, ещё какая-то. Вот я в основном работал с порождающими паттернами, например, с абстрактной фабрикой. Это паттерн, который позволяет как бы создавать семейство связанных между собой объектов и как бы при этом не привязываясь к конкретным классам этих объектов, создаваемых. В общем, сейчас пример, наверное, не приведу, потому что, честно говоря, давно уже. Хорошо. Зачем она нужна? Не знаю, выделить, создать общие интерфейсы, что ли, для определенных сущностей и как бы, не знаю, создать типа семейства для там, для каких-то существ, например, продуктов или не знаю, там как-то так. Это сложно просто сформулировать. А зачем создавать вот это семейство? Почему? Зачем вообще принципиально какую задачу мы решаем, используя? Для того чтобы, видимо, изолировать логику создания объектов от непосредственной, там, так сказать, от бизнес-логики. Видимо, да. Да, надо, на самом деле, хороший вопрос. Спасибо, я после митинга сегодняшнего, сегодня вечерком почитаю, потому что запамятовал сильно. Да, ничего страшного. Давай, ещё какие паттерны знаешь, в принципе, расскажи вообще просто. Какие? Какие? Ну, просто бывают, читал про какие-то, вспомнишь? Наш самый частый, который я использовал, это фабричный метод, который по сути необходим для того, чтобы там на основе какого-то общего интерфейса создавать как бы объекты там каких-то сущностей. Вот это самый такой часто мной используемый паттерн. Ещё я знаю синглтон, тоже порождающий паттерн. Его, по сути, насколько я помню, суть в том, что есть по сути один экземпляр класса, и этот экземпляр класса как бы глобальный для всего приложения, и ты, соответственно, можешь им пользоваться. Давай пока по синглтону поговорим, потом, если что, не вспомнишь. Смотри, ну, в целом, всё правильно сказал. Вопрос такой: часто синглтон называют антипаттерном. Да, его довольно часто называют антипаттерном, потому что он глобальный, поэтому из этого порождаются проблемы при тестировании, примокании там объектов и так далее. Поэтому не всегда синглтон как бы такой, какой нужен. Хорошо, есть ещё семейство там контроллер V7. Ну, вообще, я, конечно, сталкивался, потому что всё-таки работал с фреймворками, точно сталкивался с MVC — моделью контроллер. Соответственно, там контроллер принимает события от условного клиента, как-то обрабатывая через модель, и эта модель уже возвращается в виде какого-то представления. Ну, как пример. Вот все эти паттерны, они тоже были придуманы не просто так. Можешь приблизительно хотя бы предположить, зачем нам вообще использование, например, того же... Ну, вообще, в целом, это же некоторого рода стандарт, которого мы придерживаемся при разработке приложений. Сам по себе паттерн довольно логичный, понятный. Поэтому, если мы по нему действуем, приложение получается логическим, потому что разбивается на логически понятные части. Потому что если бы мы, допустим, не знаю, там действовали по концепции каких-то просто компонентов и не было бы никакой цепочки по адекватной, это могло бы приводить к хаосу. Поэтому сам подгугли чуть-чуть. Ну да, всё правильно, в целом. То есть, короче, мы можем сказать, что это архитектурный паттерн. Про то, зачем он конкретно нужен, кроме просто некой организации, как бы, структуру приложения, предположить не можешь? Почему именно так мы организуем структуру приложения? Опять же, решает это использование. А почему именно так? К сожалению, тут, наверное, надо как-то в историю поддаться этого паттерна, чтобы понять. Я не знаю. Ну, просто по мне так это звучит логично. Хорошо, смотри, на самом деле архитектурные паттерны, вот эти вот конкретно, вот эти три, они нужны для того, чтобы отделить, собственно, бизнес-логику от её представления, фактически. А можешь предположить, зачем нам отделять бизнес-логику от представления пользователя? Ну, потому что в целом плохо, если логика исполняется где-то на стороне представления. Логика — это такая бизнес-логика, довольно абстрактная от остального приложения. Вещь, которая должна отрабатывать где-то там и возвращать только результат. Весь её код, условный, должен появляться в контексте. Почему? Вот почему? Потому что это бизнес-логика. Ну, это, ну, такой код, который представление само по себе — это просто рендеринг результата. А результат этот формирует, соответственно, бизнес-логика, которая абстрагируется от этого. И почему нам важно? Я тебя подвожу к мысли. Почему нам важно, как бы, именно, чтобы представление этой бизнес-логики не было? Во-первых, представление может быть много. Да, во-вторых, представление мы можем, ну, типа, менять как-то динамически, и для того, чтобы как бы каждый раз при изменении представления нам не приходилось как бы бизнес-логику переписывать, вот мы пытаемся её разделить из всех. Фактически, хорошо, мы такой вопрос. Значит, вот этот висит. Как ты считаешь, насколько он применим? Чисто мы, когда говорим о представлении, обычно речь идет именно о пользовательском интерфейсе. Насколько применим такой паттерн, такой подход чисто бэкенду? Он абсолютно и полностью применим, конечно же, потому что представление — это не только HTML, срендеренный у тебя на страничке. Представление может быть, может быть вообще пустое тело ответа со статусом 200. Это уже понятно, что что произошло, или это может быть очень сон, который вернули XML. Вот так. Ну давай дальше. Пойдемте. Скажи, пожалуйста, приходилось ли тебе работать... Стоп, я работал. Хорошо, но ты разрабатывал самостоятельно. Конечно. Тогда расскажи, пожалуйста, что это такое и принципы основные. Вспоминай, пожалуйста, это не обязательно там всё-всё помнить. Ну, начнем с того, что REST — это всего лишь архитектурный стиль, и, скажем так, он работает по HTTP REST API. Это обязательное условие. Обязательное условие, что теперь это те протоколы, по которым работает REST API. У него есть несколько принципов, боюсь не назвать какие-то или назвать лишние. На самом деле, ну, что я знаю, я знаю, что как бы REST API — это какой-то определенный стиль, должен соблюдаться. Там это касается тех же углов интерфейсов. Там REST API разрешает кэширование. REST API не является каким-то там... стоит там свистеть на стороне клиента и в общем всё в этом духе. Так вот, чтобы ещё какие-то... Ладно, бог с ними с принципами. Нормально всё, ничего, их это так, чтобы всё помнить. Это мы не на экзамене, я в принципе понял, что ты понимаешь, о чём речь. Скажи, пожалуйста, в принципе, что такое REST API? Вот, ну, как бы вообще, что это такое? Вообще, да, это как бы всё правильно ты говоришь, но вот что это? Ну, по сути своей, это архитектурный стиль, по сути, для общения с сервером. Э-э, сам по себе он выглядит как request-response, то есть мы отправляем какой-то запрос на этот сервер, и сервер нам возвращает какой-то ответ в каком-то, в понятном для э-э, понятном формате. Там JSON или XML, это может быть чаще он используется. Вот, и по сути это просто набор поинтов, которые разбиты по категориям, разбиты по request-метам, и мы, как клиент, с ними взаимодействуем для того, чтобы иметь динамику и, в принципе, какую-то логику в контексте своего приложения. Скажи, пожалуйста, какие методы работы? Сказал, какие бывают? Самые основные — это GET, POST, DELETE, PATCH. Есть ещё OPTIONS, они это не совсем для каких-то запросов. Это, по-моему, OPTIONS, он нужен тоже для пингования сервера, то ли что-то типа того, пингования запроса. Могу ошибаться, но основные вот я назвал — это POST, PATCH. А смотри, давай так, я про общем. Кстати, мне самому надо посмотреть, честно говоря, с 1000 лет не слышал про него, прям реально давно. Ты в первый кто упомянул вообще это. Хорошо, в консольке, в нетворке, и я понял. Скажи, пожалуйста, вот чем PATCH отличается от PUT? На самом деле, у них разница, как бы, фактически физическая разница у них нету. То есть у них разница, наверное, в концептуальной какой-то. В общем, в концепции применения этих request-методов. Я могу сейчас перепутать что-то из этого, то что-то то, но вроде бы PATCH используется для частичного изменения, например, какой-то модели в базе, сущности в базе, а PUT, наверное, если я их не путаю местами, но вроде правильно, он создаёт либо создаёт эту модель заново, либо заменяет эту модель, эту сущность в базе полностью. Но я, условно, говорю в базе, как это правильно, ресурсы, наверное, назвать. То есть PATCH используется для частичного изменения, там какой-то сущности, PUT для либо создания, либо полного изменения всех данных, что есть. Хорошо, а ты сам прям вот создавал целиком с нуля при этом какие-нибудь там флаги? Очень такое использовал? Но, к сожалению, под Laravel сложно использовать. Лагер я использую, постман, сразу заношу всю коллекцию запросами туда и там же рендерю, либо там же документацию, либо там экспортирую XML, который кидаю в свагеры, свагер уже рендерит на своей стороне. О'кей, так тут вроде всё понятно. Давай по базам данных чуть-чуть. Какими базами данных приходилось работать? С MySQL, PostgreSQL. Больше, конечно, MySQL, MariaDB, PostgreSQL. Так, только с реляционными я работал, с Mongo, но совсем чуть-чуть, потому что у нас пользуется Mongo. Поэтому сильно за неё ответить не могу. Если считаются всякие Redis, почему бы и нет, тоже база. Да, к сожалению, я там с Redis сам работал посредством всякого кодового сахара и как бы сами не умею писать там запросы, транзакциями делами. Да, транзакции — это возможность отправить несколько запросов одновременно, например, два запроса на апдейт, и при этом иметь возможность сделать бэк в случае, если что-то пойдёт. И так чаще всего используется, если нужно сделать прямо в работе непосредственно в своей, как бы, использовал. Да, не так часто, но использовал. Да, окей, давай что-нибудь попроще, допустим, сейчас сформулирую такое: что такое ключи просто? Ну, ключи — это элементы с, чаще всего, с индексом, которые чаще всего хранят какой-то идентификатор записи. Вторичный ключ чем первичный встречный отличается? Первичный ключ — это непосредственно идентификатор самой записи, вторичный ключ — это условная связь между другой табличкой, идентификатор первичного ключа другой таблицы для организации связи. Что такое индекс? Ну, я не могу сказать точно, прямо определение. Не надо мне определение, не надо понимание. То есть ты можешь как угодно договориться, хоть совсем криво, мне, чтобы ты понимал, что это такое. Это некоторая сущность, которая позволяет ускорить fetching данных из модели. То есть, например, прайм-рекорды, чаще всего, в зависимости от настроек базы, форинке, они уже имеют по дефолту индекс, и это позволяет довольно быстро делать SELECT данных по, например, индексу с использованием того же. Также индексы можно добавлять к различным полям для, опять же, того, чтобы ускорить выборку данных при использовании WHERE, ORDER BY. По-моему, нежелательно использовать LIKE. Да, индексы можно делать, можно создавать индекс под одно поле, можно создавать индекс под группу полей. И да, индексы, они, соответственно, также, помимо того, что они улучшают SELECT, они в то же время ухудшают UPDATE, потому что каждый раз при UPDATE записи нужно перезаписывать индекс, и это бьёт по оптимизации. Ну вот, хорошо. Так, а скажи, пожалуйста, вот в зависимости от настроек, говоришь, допустим, дефолтный, как бы индекс может строиться автоматически. Насколько это в целом обязательно и как, когда можно не строить, например? например. Ну, наверное, для... Я даже не знаю, там зависит ли это как-то от количества данных. Если мы мало делаем, в принципе, запросов под этот форин-кейт, то не особо нам нужен индекс. Если мы не делаем там условных джойнов каких-то, то не особо нужен индекс под это поле, если не так часто и массово это дело. Хорошо, принято. Так, хочу чуть-чуть вернуться к вопросу нормализации, потому что это вопрос на самом деле довольно серьезный и местами даже ключевой. Я тебе сейчас расскажу, что такое чуть подробнее. Что такое нормализация? Соответственно, это процесс удаления избыточных данных, говорит нам Интернет. То есть метод проектирования базы данных, который позволяет привести базу данных к минимальной избыточности, понимаешь? Ну, для того чтобы, наверное, не было лишних данных и производительность была лучше. В целом, смотри, пример для нормализации. У нас есть, грубо говоря, какая-то табличка с большим набором полей. Собственно, в одном из полей мы же можем хранить, например, данные одного из полей, если они у нас счетные, да? То есть если они у нас условно заранее как бы известные, то есть как отдельный справочник, а можем хранить их прямо в этой табличке фактически сами значения, правильно? Ну вот, нормализация — это фактически выделение вот этого столбца в отдельный справочник с использованием уже внутри конкретно исходной таблицы нормализации. Вот теперь скажи, пожалуйста, знаешь ли ты, в каких случаях нормализация не нужна и может быть даже нужно, скорее, где нормализация нужна? Она точно нужна, если у нас есть посты, у которых есть категории, и название категории лучше хранить в отдельной модели. Где нормализация — обратный процесс, как ты понимаешь, да? То есть типа наоборот. У нас есть справочник, мы его хотим пихнуть в эту же табличку зачем-то. Зачем, можешь предположить? Да, я пытаюсь придумать кейс ситуации, в которой можно применить, где нормализация... Могу тебе подсказать, могу тебе подсказать, что у... как бы, как это называется, у минимизации избыточности есть обратная сторона. Ну, как бы основная проблема все-таки в том, что при минимизации избыточности мы создаем новые таблички, новые модели, и как это скажется на самой базе по производительности — может ударить, правильно? Совершенно правильно, это может ударить по производительности. Соответственно, предположить из этого, что в каких случаях понадобится? В таких случаях, когда мы, там, условно, от одной модели идем ко многим другим целям за данными, чтобы... Да, и что мы добиваемся ди нормализации? Мы избавляемся от лишних моделей, все переносим на плечи одной. Зачем? Для того чтобы не делать больше запросов и работать там меньше запросов, вообще меньше джойнов. В общем, для увеличения производительности, да, просто для скорости селекта, условно. Да, в тех случаях, когда нам важна больше скорость селекта, чем избыточности, в тех случаях мы как раз можем себе позволить подумать о нормализации, фактически. Хорошо, принято. Так, на самом деле у нас время постепенно выходит. Сейчас все тогда с базами данных закончим, еще поспрашиваю чуть-чуть. С гитом же работаете? Да, какой командой можно отменить? Гид реверт, по-моему, или рецепт, вроде. А скажи, пожалуйста, а откатить изменения именно в файле можно? Можно, но я пользуюсь айди ешкой и постоянно делаю рулбэк через неё. Я понятия не имею, какая команда за это отвечает. Хорошо, нормально. Большинство уже так работает, естественно, понятно. Хорошо. Так, скажи, пожалуйста, у нас есть мерж и ребейз. Чем отличаются? Это, наверное, самый частый вопрос. Ну да, наверное, согласен. Суть в следующем: когда мы делаем мерж, мы просто из одной ветки вливаем новый код в другую ветку. Когда мы делаем ребейз, мы ветку, которую ребейзим, вот другой ветки перебазируем, типа обновляем на основе той ветки, от которой мэрж появился, и дальше добавляем наши коммиты, которые мы добавили. То есть мы как будто бы сделали, обновили кодовую базу, сделали более свежее относительно, например, моей ветки, условно. Вот, а мерж — это когда мы просто слили всё там, не парясь о том, что там, не знаю, просто влили. Вы, допустим, ваша команда, каким нас ребейз сквошками. Хорошо. Так, скажи, пожалуйста, я тут сейчас по гиту, там тоже сильно не буду вдаваться в подробности. Так, в общем, спрошу, допустим, хотел спросить, а, кстати, не знаю, наверное, тегируют как-то по версиям продукт наш основной в наших сервисах, за которые мы отвечаем? Я да, делаю, чисто для галочки там на гитхабе своих опенсорсных всяких неопытных сортных проектах. Да, тоже тегирую. А зачем? Чтобы что? Для создания релизов, в основном. А что такое тег в принципе? Это, скажем, скорее не как отдельная сущность, а типа ссылка на определенное состояние твоего репозитория или типа того. Ну, в целом, всё правильно. Чем отличается по итогу? А, ну да, точно, так он же не меняется. То есть мы создали тег и всё, она как бы потом, мы можем менять, писать мне коты. Ну, это так, я на самом деле тоже ничего, тоже ничего не влияет, да. Окей, в принципе, мне кажется, что я всё по большому счету. Спасибо. А вот еще будут такие общие вопросы чуть-чуть. Скажи, пожалуйста, у вас этой доки-доки вы используете? Да, наверняка же сейчас, по-моему, сейчас разработкой бездокиров вообще уже все очень... в плане настройки инфры под докер, но использую с кубером, работал с мини-кубом чуть-чуть, уже даже не помню, к сожалению, нет, у нас девопс за всё это отвечает, поэтому у нас тоже, конечно же. Но всё равно, в целом, чтобы понимание было, как хотел это удариться, потому что у нас была задача такая, но потом подменили меня, и я, к сожалению, этим так и не позанимался. Хорошо, себя сиди. Вот в этой области у тебя какой-то опыт наверняка тоже имеется? Да, я настраивал спецпроект, есть наверняка. Ну, тоже тут никаких углубленных знаний, конечно, мне не надо, так интересно. Да, у меня есть набор экшенов, по экшенам, которые делают там, как это правильно назвать, код стайл, короче, проходятся по поводу, делают нормальный код, прогоняют тесты всякие, вот такие вот проверочки у меня и стен какой-нибудь, что-нибудь такое. Да, да, и там, соответственно, я отказался от экшенов, которые пушат мне что-то на сервер. Я сейчас пользуюсь nvoir, по-моему, это штука, где ты просто цепляешь свой репозиторий, и он всю эту связь сиди, весь как бы по кнопке для тебя организует, а ты всего лишь настраиваешь руки. Ну да, в гитхабе настраивал пайплайны, в гитлабе тоже настраивал. Не так много делал, максимально простые, потому что я не работаю там над сложными сервисами, там надо смарт-катом основным, тоже не я работаю, у нас там пайплайн из. Хорошо, сейчас ещё по верхам тоже пробежимся. Скажи, пожалуйста, документированием проекта как у вас дела обстоят? Как ты сам, как ты сам в этом участвуешь? Участвую, всё своё в основном, это всякие технические типа инпойнты и куски кода, что за что отвечает, там кто за что овнет. Но документирование у нас есть девелопер, смарт-катком, там вот у нас всё это документирование всего связано с нашим проектом, но я, к сожалению, за это не отвечаю. Документирование технических вещей, типа там, как развернуть, как настроить, всё это делаем, потому что сами через неделю уже забываем. Хорошо, ну то есть как бы файл обычный в репозитории, практика есть такая, даже обязательная скорее. Хорошо, что тестированием? Тесты там? Да, я очень люблю тесты, я в основном работаю по ТДД. ОК, значит, скажи, пожалуйста, вот еще ты в качестве дебага чем пользуешься? Я раньше пользовался, когда на Маке работал, сейчас я работаю на винде с WSL, и мне всё настроить дебаг, поэтому всё профайлю руками. Ну, в смысле, дамплю. Ну, просто лень строить этот багер. Хорошо, окей, но в целом как бы пользовался. А что касается SQL, DataGrip использую, DataGrip. Понятно, Explain всякие, Explain. Ну, редко, чаще всего просто мне надо проверить, вернет ли мне то, что нужно, запросы пишу обычно. Селект тоже использую. Хорошо, понятно. Ну, пожалуй, у меня, наверное, вопросы закончились в этом смысле. В целом, у меня очень положительные впечатления, как бы большей части вопросов. Молодец, моё, я давно год не проходил собеседование, чувствуя затупил. Я просто даже не готовился. Обычно я тоже не готовился, вот, ничего страшного. В целом, как бы, да, в целом пока что выглядит так, что вероятно пойдёшь. Вопросы могут повторяться и, скорее всего, будут повторяться, вот, нашего разработчика. Надо посмотреть, как бы, как ему нужно, как бы самостоятельно.

Назад

Залогинтесь, что бы оставить свой комментарий