Як пройти СПІВБЕСІДУ НА JUNIOR C#/.NET розробника — Transcript

Відео допомагає підготуватись до співбесіди на позицію Junior C#/.NET розробника, розглядаючи типові питання та відповіді.

Key Takeaways

Розуміння основ платформи .NET є важливим для Junior C# розробника.
Практичні навички роботи з ASP.NET Core, Entity Framework та базами даних — ключові для співбесіди.
Груповий формат співбесіди допомагає краще підготуватись і побачити різні типи відповідей.
Важливо не лише знати теорію, а й вміти пояснити простими словами складні концепції.
Підготовка до співбесіди має включати повторний перегляд матеріалу та роботу над прогалинами у знаннях.

Summary

Відео демонструє реальний процес технічної співбесіди для Junior C#/.NET розробників з фокусом на бекенд.
Розглядаються популярні питання з C#, ASP.NET Core, Entity Framework Core, баз даних та базові знання про .NET екосистему.
Автор пояснює, як правильно відповідати на співбесіді, дає приклади правильних та іноді неправильних відповідей.
Формат відео — групова співбесіда з кількома кандидатами, що дозволяє побачити різні підходи та поведінку.
Відео орієнтоване на кандидатів без великого комерційного досвіду, які хочуть отримати перший офер.
Пояснюється, що таке платформа .NET простими словами та які технології вона включає.
Обговорюється шлях виконання C# коду через CLR до машинного коду.
Автор дає поради щодо очікувань роботодавця від Junior розробника, зокрема щодо практичних навичок.
Відео містить посилання на додаткові ресурси та спільноти для подальшого вивчення.
Автор закликає глядачів залишати коментарі для покращення формату та контенту.

Full Transcript — Download SRT & Markdown

Speaker A

Привіт. Це відео — це не просто технічна співбесіда. Можеш вважати його конспектом з найпопулярніших питань для Junior C# розробників, яке дозволить тобі, по-перше, готуватись до співбесід, по-друге, побачити, як виглядає реальний процес співбесіди, побачити, як поводять себе різні кандидати і, можливо,

Speaker A

зрозуміти, які прогалини і гепи у знаннях ти маєш до того, щоб краще підготуватись і знайти для себе свій перший офер, можливо, покращити існуючий і залетіти на якогось стромна. Приємного тобі перегляду. Відео вийшло доволі довгим, тому, напевно, дивись його в

Speaker A

декілька пресетів, як то кажуть, і обов’язково пиши коментарі, чи подобається такий формат. Мені це дуже важливо, бо створювати подібний контент доволі важко. І якщо є якісь зауваження, коментарі, також буду радий послухати.

Speaker A

Гарного перегляду всім. Ще раз привіт. Привіт тим, хто дивиться цю співбесіду в записі. Ми сьогодні проголомов м-м технічну співбесіду, тому що вона групова, в нас тут багато. І наша сьогоднішня задача не просто, скажемо так, провести співбесіду реальній

Speaker A

людині і оцінити її рівень знань, а пройтися по суті по структурі найпопулярніших питань на співбесіди на Junior C# розробника. Ми будемо фокусуватись саме на бекенд розробниках.

Speaker A

Ми тут фронтенд особливо не будемо зачіпати, а ми будемо більше говорити по бекенду, по C#, ASP.NET Core, зачепимо базу даних, можливо трішечки cloud, ну так, дуже поверхнево.

Speaker A

І також ця співбесіда передбачає, що я буду давати правильні відповіді на питання або можливо неправильні, можливо ви мене поправите там потім в коментарях, що я тут щось неправильно сказав, але я буду давати такі відповіді, які були б прийнятні на

Speaker A

співбесідах, але як, скажемо так, інтерв’юер я буду намагатись вас підводити, звісно, до відповідей. Сьогодні буде фокус в основному на такий, як квізи, по суті, питання-відповідь. Питання-відповідь. І вона буде йти по такій структурі, що я буду кожному з кандидатів задавати

Speaker A

питання, а-а, буду м е там давати час на відповідь, але для того, щоб не затримувати, щоб у нас був певний темп, я буду, якщо людину бачу, я бачу, що людина не може відповісти, я буду давати правильну відповідь, ми будемо йти далі.

Speaker A

А питань буде багато і я би хотів, щоб ті, хто цей запис дивляться, могли його передивитись декілька разів і могли використовувати його для, а, скажемо так, підготовки до співбесід. Я думаю, це буде дуже корисно. Це буде в публічному доступі і по структурі питань

Speaker A

ми будемо йти по таким доволі класичним питанням, як на мою думку, і які описані в моєму роадмапі для C# розробників. А його і в принципі безліч корисної інформації можна знайти в спільноті, звідки сьогодні доєднались мої підписники та учні до цього дзвінка.

Speaker A

А всі посилання будуть в описі під відео. Я ще потім, можливо, про це скажу. А сьогодні до нас приєднались мої підписники з моєї Telegram-спільноти.

Speaker A

Як ми вже познайомились, вже хлопці і дівчата ще не працюють, окрім, як я зрозумів, Стаса, але він от тільки нещодавно влаштувався і теж позиціонує себе як джуніор. Відповідно, всі питання будуть плюс-мінус на рівень джуна, скажемо так. Десь можливо я буду

Speaker A

перегинати паличку трішечки, як на мені здається, але воно плюс-мінус відповідає от ринковим нормам на час запису цього відео. Це там 2025 рік.

Speaker A

Так, я ще раз гляну. Записи в мене всі ідуть. Все чітенько. Залишаюсь в Зумі. А ми вже... Я не буду зараз витрачати ваш час на те, щоб ми з вами всі познайомились. Давайте уявимо, що ви вже пройшли рекрутерську співбесіду і у нас

Speaker A

вакансія на от таку дуже, дуже смачну вакансію для джуніора. Тобто досвіду особливо не вимагається комерційного. По стеку ми хочемо, щоб ви знали, там C#, вміли робити бекенд застосунки на ASP.NET Core, Entity Framework Core, вміли працювати з реляційними базами даних. У

Speaker A

нас тут позраз, але якщо ви працювали з SQL сервером, теж підходить. А щоб ви вміли писати адекватний код, як для джуна, розуміли, що взагалі відбувається і мали, скажемо так, практичні навички вирішення якихось задачок, да? Тобто от в мене були б такі очікування, коли я б

Speaker A

наймав людину на умовні там 500-700 $, да? Але, скажемо так, я би тут очікував від людини, щоб вона могла робити базові класичні задачі для бекендчика. Тобто, якщо я кажу: "Нам треба докинути колоночку в базу даних, зробити міграцію і розширити існуючі

Speaker A

API", людина це робила без зайвих питань, тому що вона вже це колись робила під час навчання і розуміє, як це відбувається. Або як мінімум може самостійно розібратись, а не приходити до мене і питати, що таке міграція. Да?

Speaker A

Тобто це як приклад просто для розуміння якихось моїх очікувань. Вони не є якимись неадекватними. Це все можна спокійно вивчити самостійно і ми відповідно про це, ну, буду от цілитись десь на такий рівень. Як я сказав по структурі, ми будемо питати людей, е-е,

Speaker A

наших сьогодні учасників по колу, а для того, щоб, як і учасники спробували себе в різних питаннях, плюс глядачі побачили, як різні люди себе, скажемо так, поводять. А під час таких співбесід я таку штуку практикую разом зі своїми студентами. Воно не дуже

Speaker A

сильно відповідає реальним технічним співбесідам, де одну людину ганяють, але такий формат дозволяє, скажемо так, непогано підготувати в цілому групу до співбесід. Тому от я вирішив показати вам саме такий формат. А тому будемо починати. І от Денис, ти перший

Speaker A

доєднався, ти в мене перший. Е, тому можемо починати е з тебе. Почнемо з таких от розігрівчиків. А це не дуже, напевно, часто питають на співбесідах, але я для загального розуміння хотів от там поцікавитись. От ти кажеш, ти позиціонуєш, що ти типу джуніор C#

Speaker A

розробник. Пишеш на мові програмування C#, використовуєш платформу .NET. І от чи розумієш ти, що таке платформа .NET взагалі? Да, що таке от платформа .NET і так далі? Бо в вакансіях ось люди пишуться, ти наче себе позиціонуєш як розробник.

Speaker A

Міг ти пояснити, що це таке, як ти це розумієш? Своїми словами, без якихось замудрених, можеш там називати слова фреймворки, кросплатформи, ще якихось таких речей, просто своїми словами.

Speaker A

А так, без питань. А взагалі оця .NET, він включає таку велику екосистему, можна сказати, а-а яка включає в себе вже м фреймворк для різних за призначенням. Тобто ця екосистема включає, наприклад, ASP.NET Core, який використовується для розробки веб-застосунків та бекенд сервісів. Це

Speaker A

включає і WPF, тобто який для розробки десктопних застосунків. Це включає там, ну, той же WinUI. Xamarin, який вже засталені. Це включає і MAUI, який використовується для кросплатформної розробки. Тобто це можна сказати така велика екосистема, яка містить декілька фреймворків вже різних за призначенням.

Speaker A

А, а якщо от пояснювати простими словами, уяви, що до тебе підійшов твій братик, молодший чи сестричка і каже: "От ти там .NET розробник". Що це значить?

Speaker A

Якщо простими словами пояснювати, м, то це той розробник — це людина, яка в принципі може із загальними знаннями, які маючи загальні знання навіть, а, в принципі, розробити каркас майже будь-якої системи. Майже. Тобто, ну, давай так. Я би на співбесіді

Speaker A

сформулював відповідь, що .NET — це набір інструментів, які ти, в принципі, перелічував: фреймворків та технологій, які, а, дозволяють створювати застосунки різного призначення, використовуючи різні мови програмування, однією з яких являється C#. Це, в принципі, типова нормальна відповідь, незамудрена і

Speaker A

зрозуміла навіть не дуже технічним людям. Окей, тоді по цьому все. Йдемо далі. А, Вадим, ти в мене наступний ідеш. А-а, от дивись. От давай вже трішечки про внутрішню частину .NET поговоримо, да? А і поки ми не заходимо в нюанси C#, але от таке питання,

Speaker A

яке часто опускають на співбесідах, але мені здається, воно доволі важливе по поводу того, яким чином C# от виконується там умовно операційною системою, якщо так можна сказати, чи який шлях C# проходить від C# коду до так званого машинного, бінарного і так

Speaker A

далі. Угу. Так, хороше питання. Е, наскільки я розумію та пам’ятаю, то спочатку наш код C# не одразу перетворюється у бінарний код, який розуміє комп’ютер та процесор, а, е, він

Speaker A

точніше CLR. CLR, так. І це, власне, в цей CLR переводиться не тільки мова C#ARP, а наприклад також інші мови, які підтримують доnet. Одна з них точно це Visual Basic. І ось вже цей CLR переводить наш код з мови C#ARP на

Speaker A

ось цей проміжний і вже він компілюється у машинний код, який розуміє праці під операційну систему. Так.

Speaker A

А а оцей байткод, пам'ятаєш, як він називається? Ну ти сказав, ну він не зовсім й код, але от от від слова вінце називається якось так він називається якось інтерюк рівень знання англійською як рівень знання англійської intermediate language. Interm А просто а intermediate

Speaker A

language. Так просто абревіатура абревіатура. Пам'ятаю, що intermediate було. Угу. Так. І по суті ти правильно сказав, що, е, з компілятором мови, будь то C#P, там, Visual, Basic, F#P, Visual, C++ і і що, щось ще там, якісь мови, я, чесно

Speaker A

кажучи, не всі пам'ятаю. Воно компілюється в intermediate language, який вже виконується всередині CLR common language runtime, да, типа, ее, runtime загального призначення, там, як хочете, можете перекладати. І от в цьому якраз і фішка донету, що він може різні

Speaker A

мови компілювати в один intermediate language, який вже just in time компілятором GIT виконується на рівні типа більш низького рівнему на рівні типа там заліза операційної системи, на якому виконується а-а код. Е, дякую, Маша. А-а, можливо, ти пам'ятаєш ось

Speaker A

такі, ее, абревіатуру, як CLS і CTS в контексті CLR. Угу. CTS - це type system. Він забезпечує сумісність типів між мовами.

Speaker A

Ну, наприклад, C#arp і INF в Sharp мають бути сумісними завдяки CSУ. CLS - це common language specification. Вона визначає набір правил, які мають підтримуватись донетмови, щоб вони взаємодіяли, ну, були взаємосумісними.

Speaker A

Ну, він забороняє використовувати спеціальні фічі однієї мови, які не підтримують інші. Ну да, в цілому теж не дуже розпоширене питання, але ми сьогодні будемо плотненько приходитись. Добре. Ілья, питання тобі. А за весь час історії дотнету у нас було декілька їх версій. В

Speaker A

нас був DNET framework, DNET core. Зараз у нас просто DNET був ще, точніше є DNET standard. І от можеш простими словами різницеюframework.netstandard.net core.net.

Speaker A

Ну, без пояснень, типа, що ось там такі-то фічі, такі-то методи є, там їх нема. Просто от хай-левельно.

Speaker A

Окей. Ну, ще можу сказати, що доnet framework така вже трошки засторіла і саме найголовніше не є кросплатформою.

Speaker A

DNET і там п'ятий, шостий, це вже таке трошки більш сучасне. Багато фічей м підтримують.

Speaker A

І ось DNETCore найсучасніше кросплатформи що майже везде за DNET corner насучасніший. Може, может пятийшостий вже, вже дев'ятий там, по-моєму, який чи восьмий зараз актуальний.

Speaker A

Ну, дев'ятий, да? Да. Ну, да. Тобто, е-е, історично, от як ти сказав, netфреймворк не був кросплатформеним, а на якій операційкій він був на операційній системі?

Speaker A

Windows только, вроде бы. Да. Да, він потім у нас з'явився Dutnet Core, який став вже кросплатформным. Там переколбасили трішечки е-е CLR, воно там називалось Core CLR, а вони, по-моєму, використали ось цю, як цю моно якось там називався фреймворк, хтось там його

Speaker A

писав. Я, чесно кажучи, вам історію не підскажу тут, але в цілому, да, DNET корсплатформі, що дозволив виконувати застосунки на дотнеті, там, умовно на Лінуксі, на Mac S і так далі. Ну і зараз, скажемо так, я не знаю, як це

Speaker A

ребрендинг, вони заробили замість DNETкору просто DNET. А от часто таке питання, я тобі раз я тобі його задав, тебе вже дому, що Dotnet стандарт багато хто сипеться на цьому і починає, скажемо так, трішечки путати framework, dnetcore, dnetстан. Для чого?

Speaker A

Можливо, ти не стикався, ти можеш цього не знати, особливо там, тому що воно не супер актуально зараз, але можливо знаєш.

Speaker A

Ну да, я не стикався, але можливо так догадаюсь, там якісь специфічні правила може написані.

Speaker A

Ну не зовсім. Давай я напевно відповім, щоб не витрачати час. Коли була міграція між DNET фреймворком і DNETкором, то DNET Core, ну, доволі сильно відрізнявся від DNet фреймворка, там набором аі, набором методів, функцій і так далі. І часто потрібно було підтримувати рішення

Speaker A

і на DNet фреймворку, і на DNETкорі. Ну, умовно був старий моноліт на DNet фреймворку, писали нові мікросервіси на DNetкорі і потрібно було і використовувати якісь спільні бібліотеки, які можна було використати і там, і там. Тому з'явився, скажемо так,

Speaker A

такий стандарт DNET стандарт, який просто дозволяє створювати бібліотеки, які можна підключати як до DNET фреймовока, так і до DNET е кора. І цей DNET стандарт просто по суті підтримує набори API, які є і там, і там. Але DNETARD ти не можеш зробити виконуємий

Speaker A

проект. Типу ти не можеш, типа не можеш запустити до DNE. Це просто бібліотечка. Але, ну, типа, скажемо так, сучасні, скажемо так, розробники не сильно з цим стикаються, тому що, ну, або просто не звертають на це увагу, да, тому що вже

Speaker A

є, типа, там Dotnet Core 3.1 вважається вже типа Legacy, він не підтримується, тому у вас типа таких проблем, скажемо так, немає, але я от застав версії і тому там Dotnetстан, ну, треба от часто таке питання проскакувало Mercedes окей, по дотнету так пройшлись. А

Speaker A

спонсором цього відео є моя настануса пошаar. Цей продукт існує вже близько двох років на ринку. Я веду вже п'ятий потік. У нас є купа кейсів студентів, яких ми працевлаштували по суті з нуля, без досвіду. Скоро вже будемо набирати

Speaker A

на шостий. Якщо тобі цікаво вивчити C#P, ти хочеш стати бекнд розробником і хочеш знайти роботу в IT, то для тебе цей продукт може бути корисним, тому що він заточений саме під пошук роботи, проходження технічних співбесід. Ми будемо разом багато практикуватись. Я

Speaker A

буду робити тобі кодрев'ю, підсказувати, як краще зробити якесь рішення, як робити код на рівні комерційному, як правильно проходити співбесіди. Розповім не тільки про технічні речі, а й про пошук роботи, про заповнення CV і LinkedIn. Ти можеш залишити заявочку під

Speaker A

цим відео. Я залишу посилання на анкету. Вона коротенька, вона не зобов'язує тебе до покупки. І з тобою зв'яжеться мій менеджер, розповість тобі усі деталі і ти зможеш прийняти рішення, чи тобі це підходить. І прямо зараз ми набираємо на

Speaker A

ранній старт шостого потоку, що дозволить тобі розбити оплати на частини і отримати матеріали ще до старту наставництва, відповідно мати більше часу на підготовку. І продовжуємо співбесіду далі.

Speaker A

І давайте, е, підемо уже в шарпи, але почнемо з теж таких заїжджених питань. Ооп. Влад, можеш назвати, будь ласка, стовпи ООП або там фунда фундаментальні речі в ООП. А просто перечислити їх без пояснень.

Speaker A

Ну, основа - це поліморфізм, наследование абстракція і ще і открити закритость. А, ну там слово таке є, а пов'язано починається з інвапсуляція, да? Окей. Да. А от чи чув ти якісь, скажемо так, розмови, чи є абстракція саме з товфом ООП, чи ти просто типа

Speaker A

сприйма от десь прочитав, що це є основою ООП і так і вирішив? Не, тут суть в том, что каждый, ну, кожен классуе, описывает якусь сущность, взятую с реальной жизни, будь то нажить процесс, машину, ну, любой объект, процесс, события в таком контексте. По суті, да,

Speaker A

абстракція - це якась проекція реально існуючого об'єкту на код і проекція тільки тих властивостей, які необхідні саме в коду. Ну, в цілому, типа, теж халіварна тема, але от цікава твоя думка. А далі, Стас, питання тобі. От поліморфізм багато хто, е, типа, знаєш,

Speaker A

скажемо так, валиться на цьому питанні. Тому спитаю про це, тому що, ну, наслідування наче як просте питання.

Speaker A

Тому спитаю про поліморфізм. Взагалі полірмофізма є навіть не один вид, я сказав би його можна і в дженериках побачити, і в кастах навіть, і багато де, якщо говорити, е загально, як це було попешному, то ее об'єкти м як то сказати, наприклад, можна

Speaker A

привести, якщо два об'єкти, ой, два класи наслідують якийсь один інтерфейс, то вони можуть мати можуть від нього наслідуватися одинаково, але мати різну реалізацію, тобіш, е, і якщо ми от будемо створювати якісь об'єкти, які наслідується від цього інтерфейсу, то ми можемо

Speaker A

визначити, які я які саме яку саме поведінку буде мати цей об'єкт, е, залежно від того, яку реалізацію має клас, який від нього наслідується.

Speaker A

Е-е, ще на рахунок, які є ще види поліморфізму? Наскільки я знаю, adхо - це від женериків поліморфізм. Ще є е-е не пам'ятаю точно, це коли ми кастимо об'єкти і напевно більше не скажу. Треба трохи було б згадати, бо таке дуже абстрактне

Speaker A

питання цей політи перегрузка методів. Ну, в принципі, як і дженерики, да, тобто теж можна вважати видом поліморфізму.

Speaker A

Угу. Ну, а як би ти сформулював? Дивись, ти привів приклади. А якщо одним словом сформулювати, от дивись, наприклад, на співбесіді від тебе хочуть от там якийсь душний чувак і каже: "А ну-ка давай мені е-е одним типа не одним словом, а одні

Speaker A

одним терміном". Як би ти це пояснив? Один об'єкт може мати різну поведінку, ну, приймати різні різні властивості там по суті вратання. Да, да, да.

Speaker A

Окей. Ну, грубо кажучи, так. Окей. Да, хорошо. А, Денис, питання тобі. Не будемо по всім стовпам проходити. Поліморфізм, напевно, найскладніший для всіх. Давайте краще вже по Сішарпу трішечки поговоримо. А наслідування в Сішарпі, чи підтримує C#ARP множини наслідування?

Speaker A

А, і якщо да, то приведи приклад. Якщо ні, то чому? Або якщо є нюанси, то поясни нюанси.

Speaker A

А на відміну від C++ CШ SARP не підтримує множинне наслідування, проте він підтримує множинну реалізацію інтерфейсів.

Speaker A

Угу. А і ось це навіть можна віднести до абстрактних, так званих, класів. Тобто навіть якщо ми наслідуємось від абстрактного класу, то ми можемо наслідуватись від одного абстрактного класу.

Speaker A

Окей. Хорошо. От поки не кажи про абстрактні класи. Раз ти вже згадав їх, то питання одіму йде. Е-е, от уна ми поговорили, давай так, різниця між абстрактним класом і інтерфейсом.

Speaker A

І можливо ти приведеш якісь кейси, які в тебе були, або може десь чу якісь типа юзкейси, коли коли і що використовувати.

Speaker A

Так ну ее справді цей інтерфейс та абстрактні класи чимось подібні, проте все ж в них є різниця.

Speaker A

От, наприклад, вже, як Денис сказав, це те, що все-таки абстрактний клас, він є далі класом, тому можна насити тільки один від нього.

Speaker A

Е, ну, тобто як на відміну від інтерфейсів, їх можна наслідувати чи там реалізовувати. Ее, багато. Далі, там, здається, є різниця в тому, що в інтерфейсі завжди має бути методи public, а в абстрактному класі їх можна ее можна робити іншого типу. Також ну

Speaker A

інстанцію, instance інтерфейсу не можна створити, на відміну від абстрактного класу. А можна інстан абстрактного класу створити?

Speaker A

Ще щось? Ну, ти можеш написати, дивись, даю підсказку. Конструктор у нього може бути у абстракта, да? Конструктор. Конструктор може бути в інтерфейса. Ні. А от, значить, ну виходить значить, інстанти не можна. Ее, але конструктор може бути. Як так?

Speaker A

Напевно, він вказує, яким чином можна створювати об'єкти похідні від цього класу. Ну, інститу, ну, по суті, так, типу, ти можеш мати protected constructтор і в абстрактному класі, ну, дуже части кейс умовно, уяви, що ти там робиш, я не знаю, класи е для

Speaker A

машин, умовно описуєш. І, наприклад, ее у тебе якось ти описуєш там кузови для машин. І може бути таке, що моделі, наприклад, різні машин, але, наприклад, там умовно там в одному кузові може бути там різні роки, але в одному кузові. Ну,

Speaker A

умовно я плохо орієнтуюсь в машинах, типу. Але, скажемо так, уяви чи там, наприклад, е-е, давай так, ти в базовому класі описуєш, наприклад, і базову поведінку автомобіля, типу двері відчиняються, закривається, двигун, типу, е, стартує, зупиняється і типу треба базовий клас. який там умовно

Speaker A

в свій конструктор, це абстрактний клас, може отримати там двіжок, е-е якийсь там, я не знаю, електроніка, да, коробка передач, електроніка і так далі. І там є якась в ньому базова описана поведінка.

Speaker A

Або якщо це там говорити про якісь тамкейси, які були, наприклад, в мене, то я робив типа клас, який відповідає за запити до якогось сервісу. Умовно там Нова пошта IP client Client.

Speaker A

І можна зробити базовий AP client Client, в якому ти реалізуєш те, як відбуваються абстрактно запити. Ну, типу прокидується і через HTTP клієнт чи там через Flurл ти робиш запит і отримуєш якусь там типа відповідь через женерики, а вже в Нова пошта Client ти реалізовуєш

Speaker A

логіку для апі саме нової пошти. Ну, умовно. А, да. А в інтерфейсі, да, як ти вже зазначиш, це просто, ну, по суті, описання, ее, тобто абстрактний класце.

Speaker A

обк. Да, абстрактний клас може містити в себе базову поведінку, але ти не можеш типа створити його instance і ти в ньому можеш описати абстрактні методи, які мають бути реалізовані в наслідниках. А інтерфейс описує по суті як контракт сигнатуру своїх наслідників. Типу в тебе

Speaker A

має бути ось такий-то метод, який має такі-то параметри, таке-то повертає і все. Але в цьому в якійсь версії C#Р додали реалізацію методів для інтерфейсів. Я не знаю, якщо чесно, навіщо. От я чесно не розібрався. От скажемо такий от є

Speaker A

сеньйор і нікуразу не використовував, але якийсь душний чувак на співбесіді може про це спитати і типа таке типа таке є.

Speaker A

А окей, хорошо. Ми прям плотно, душно про це поговорили трішечки. Е-е ідемо далі. А питання [музика] майже, раз ми вже говоримо про ці всі наслідування інтерфейси обов'язково варто згадати віртуальні функції. Що це таке? Ее як воно працює і можеш там

Speaker A

приклад якийсь привести. Віртуальні функції. Це ми можемо написати метод з ключовим словом Virtual і перевизначити його за допомогою ключового слова overй.

Speaker A

Тобто можемо переписати його поведінку, уточнення. Де переписати? Е, в класів. Угу. Так. Можу приклад привести?

Speaker A

Ну, давай так. Навіщо це треба і чи можна це зробити без типа типа чо чи ч типа от як буде себе поводити два класи зі словом Virtuтуа overй і як без цього без нього? Ось так от ось таке питання.

Speaker A

Ну це потрібно для того, для поліморфізму. Угу. Щоби об'єкт по-різному реагував на однакові виклики.

Speaker A

Вони ще також потрібні для того, щоб, наприклад, ми створили абстраsний клас pay Payment і там зробили метод Pay і від нього унаслідували, від цього метода у нас навпаки. Ми ще створили два класи, допустим, Card Payment чи Cash Payment. І ми у

Speaker A

наслідували цього класу Payment. І получається ми метод Paper визначили. І коли ми створюємо ще один клас, який відповідає за поведінку розрахування і ми в ньому можемо створити клас process Payment, який в будет ім буде викликати саме Pay метод і

Speaker A

викликає буде викликатися його правильна реалізація. Типу, а що означає правильно? Уточни це. Ну, ту, яку користувач там чи наша бізнес-логіка зробила, чи оплатили картку, що оплатили Ну, дивись, ти там трішки так пішла, а, типа, в приклад трішечки, короче,

Speaker A

усложніла відповідь собі. Дивись, типа, завдяки ось цим, типа віртуальним функціям оверайдам, якщо зовсім просто, ми можемо описати в батьківському класу якусь поведінку і, як ти вже сказала, заоверайдити, переписати цю поведінку, зберігаючи контракт метода в класінику.

Speaker A

Це дозволяє нам, коли ми, наприклад, використовуємо батьківський клас і C#ARP дозволяє, наприклад, написати parent е parent parent дорівнює new child, тобто підставити в зміну типу parent instance типу child.

Speaker A

І відповідно завдяки ось цьому віртуальному методу, якщо в чайлді він зовораджений, то при виклики на цьому паренці ось цього метода якогось там сам метод, наприклад, викличеться сама реалізація всередині чарта. А якщо цього не зробити, то по суті викличеться

Speaker A

реалізація в паренті. Це можна цього можна також досягнути типа поведінки условно, як там у віртулі через ключове слово new, але це трішечки, скажемо так, типа код smell, як на мене, використовувати ключове слово new. А воно типа як в класінику ти перекриваєш

Speaker A

е parent метод. Угу. Да. Але, ну, скажемо так, віртуальні функції, по-перше, працюють краще, тому що, а-а, ну, типа, оце ключове слово new, воно просто перекриє, е-е, в насліднику батьківський оцей метод, але, по-моєму не буде в тебе поведінки, як у

Speaker A

віртуальних функціях, наскільки я пам'ятаю. А-а, тому, скажемо так, про цю проблему якраз віртуальні методи і вирішують.

Speaker A

Ну, там не буду вже питати про ці всякі там віртуальні там тейбли і всяку таку штуку. Ні, ми не будемо так душніть, як там в плюсах, по-моєму, таке є.

Speaker A

Хорошо, про Оп поговорили трішечки. Йдемо далі. Ілья, принципи Solid. Е-е, чи знаєш ти, що це таке? І можливо розшифруєш принцип л, букву?

Speaker A

Угу. Ну, сорі, це в нас варвіатура. Кожна буква за свій якийсь принцип відповідає. І L, наскільки пам'ятаю, це List of Substitution Principle. І він відповідає за роботу з інтерфейсами.

Speaker A

Інтерфейсами. Впевнений. Ну, може десь там дотично може бути, але не зовсім. Ні, тоді не пам'ятаю.

Speaker A

А, да, якби було б класно відповісти. Соліди - це набір, скажемо так, правил, підходів, як ви проектуєте е-е код з типа з використанням ООП підходів. Тобто це як без практиси до ООП застосунків. І list substitution принцип означає, що якщо ми в нашому

Speaker A

коді замість класу типа батьківського класу підставимо child, у нас не має ламатись код типа follow програми. Що це означає? Наприклад, у вас в parрен класі не викидуються ексепшени, типу, і про це про це інші розробники знають і спокійно

Speaker A

використовують, не загортаються там в треке і так далі. Але якщо ти, наприклад, в класінику викинеш exception неочікуваний і там буде і він буде викитуватись типа, скажемо так, на при якійсь умові, умовно там валідації якогось там параметра і типу, наприклад,

Speaker A

в парен класі був допустимо, що параметр може бути нол, а вже класі насліднику це недопустимо. І це якраз ламає cost substitution принцип. Ну, це як такий приклад.

Speaker A

Е-е, окей. А наступне питання, Владу, принцип Д теж доволі, скажемо так, популярний використовую і, скажемо так, йому, напевно, ти дуже часто слідуєш або про нього думаєш.

Speaker A

Ну да, это ж в нас инверсія зависимостей. Тут ключевая основа в том, ну, суть цього принципу в тому, чтоб у нас мы зависели от абстракций, а не от деталей реализации конкретно. Якщо говорити в контексті C#ARP, то по суті ми маємо

Speaker A

залежати там умовно від інтерфейсів або там якихось абстрактних класів, а не конкретних імплементацій. Да. Ещё потом легко подменить реализацию как ну как dependency injections. Окей.

Speaker A

Стас, ідемо далі по Оп. Так, базово пройшлись. Давайте вже в C#шаp підемо. Value reference типи, що ти можеш про них розказати і що знаєш, да? От отак от таке питання.

Speaker A

Постараюсь попростіше, бо там можна багато говорити про це. Загалом, всі типи, всі типи даних, всі шарпі діляться на два типи. Це value typй і референсйp.

Speaker A

І це valp - це самі примітивні типи даних і вони зберігаються в такій області пам'яті, як стек. Це int, це числа типу in, дабла і там чар і подібні і структури.

Speaker A

А референс typй - це складніший тип даних. Ее він працює як ти, коли створюєш об'єкт, на нього створюється посилання, яке зберігається в стеку, а саме значення цього об'єкта, воно зберігається в кучу. Це більш великий обсяг даних в пам'яті і в ньому об'єкти

Speaker A

розташовані більш хаотично і він пристосований для великих об'єктів. Приклади референс тайпів - це любий клас. І можна було б сказати strнг, але там трошки складніше з ним.

Speaker A

Давай про стрінг іншими залишимо питання. Добре. Ну, це в принципі все, що я можу сказати.

Speaker A

Окей. Ну, в цілому так. Я ще би уточнив простек кучу. Хорошо. А в плані передачі е-е типів як параметри методів, яка там є різниця між ними?

Speaker A

М це питання про ре. Ну типа value. Ні, не про реф, не про ключове слово реф, а саме от різницю. От ти передаєш, наприклад, от int як параметр і якийсь там твій класик, твою модельку як параметр.

Speaker A

Якщо ти передаєш примітивний тепдани в в параметри методу, то там значення скопіюється. А якщо ти передаєш складний тип даних, то там буде мінятися об'єкт.

Speaker A

Там ссилка скопіюється і буде мінятися сам об'єкт. Ну давай не складний, тому що ти можеш і структуру складну описати по суті. Давай так. Референс я.

Speaker A

Ну да, референс типу в плані цього, да? Хорошо. А, Денис, питання тобі. Отут згадали стрінг, що він якийсь там особенний. В чому в чому його особенность?

Speaker A

Цеable. І коли ми робимо якусь операцію, наприклад, та ж конкатинація, неважливо, чи то метод, чи то просто оператор плюс, то у нас кожен раз створюється новий об'єкт. І в плані оптимізації і продуктивності, це не дуже гарно.

Speaker A

Окей. Типу тому, що створюється по суті кожен раз нова строка, да, що засаряє пам'ять. А що ми можемо використати?

Speaker A

Типа, а коли нам, ну, там іноді ж треба динамічні строки будувати, що ми можемо використати?

Speaker A

А для цього було створений спеціально так званий, тобто він дозволяє динамічно динамічно змінювати строку, або додавати, або видаляти. Проте важливо зауважити, що stringбідер має набагато менше методів для маніпуляції зі строками. Тому тут вже в залежності від ситуації треба дивитись. Якщо нам,

Speaker A

наприклад, потрібно купу операцій зі строками робити і ці операції якісь складні, то може якось можна сінг використати. А якщо там, наприклад, цих операцій ну дуже-дуже багато і це буде неефективно, то вже використовувати біildдер, тобто залежно від ситуації.

Speaker A

Питання з зірочкою: чи можна використовувати стріми для побудови строки? От в мене от воно чисто в голові зараз всплило. Цікаво твої думки.

Speaker A

А стаєми потоки? Ну як стоїмо? Давай так, щоб у людей не було конфюзаждами. От типа саме стрім, да, просто будемо називати його по суті поток даних, да? От типу ось так.

Speaker A

А я думаю, що можна, тому що це, ну, в принципі, робота с байтами, тобто, а, і у нас же символи, тобто ядки, це вони складаються якраз з байтів, тому я думаю, так, можна. Ну, молож такі самі думки, по-моєму. String

Speaker A

Builder, я це тут можу, якщо хто дивиться в записі помилятись. Я це, мені здається, він теж, по-моєму, якийсь типа аналог стріма чи щось таке використовує, але я можу помилятись зараз, тому не претендую на, скажемо так, правду. Ну, це як просто, знаєш, і це питання можна

Speaker A

задавати, щоб побачити і мислення людини, да, типа, чи розуміє вона, що таке стрім. І от бачиш, типу, от ти гарно відповів, що, типа, проявив якусь креативність, не просто завчив відповіді. Хорошо.

Speaker A

Про строки згадали. value reference типи е-е окей. А питання Вадиму таке е-е питання теж доволі популярне, на якому сипляться багато кандидатів, бо можна помучить людину. Чи може value type потрапити на кучу?

Speaker A

Ну, фактично, якщо ми говоримо про боксинг, то так зможе. Ну, але чи це буде, чи це, чи він буде ще тоді вельтипом? Ну, дивись, типа, це в принципі я до цього і вів.

Speaker A

А тоді от скажи, що таке бокс, unboxing? Ее, так, бокс ібоксingг - це власне і є процесом умовного переходу з одного типу в інший. Тобто анбосиг - це коли ми розпаковуємо об'єкт з референсйпа, з хіпа в стек і боксинг - це коли навпаки

Speaker A

ми е-е value type в reference ее зв обгортуємо. Е да. Але питання е завдяки чому ми можемо це робити? Ти кажеш приведемо із референс типа value і навпаки. Це якби можливо завдяки чому ці шарпи?

Speaker A

Це можливо [музика] треба подумати хвилинку. М. О, давай так. Підсказка це, напевно, скажу завдяки. Завдяки чому так?

Speaker A

Це можливо завдяки наслідуванню. Е, і якому саме? Ага. Я я здається зро Ну, напевно, тому що у дотнеті всі об'єкти, всі класи наслідуються від object, да?

Speaker A

Тому саме через за допомогою цього наслідування, якби оскільки всі і звичайні типи, і референс, ну, типу звичайні, тобто valable type, які там звичайні наші інти, чари і так далі, все рівно теж наслідують обжект. І за допомогою власне цього, що вони є е

Speaker A

похідними класами від object, відбувається бокс та анбоксing. Ти можеш привести in до обжекта і в тебе відбудеться боxingг unboxing. Але цей процес, ну, точніше бокс, він є він є дуже неефективним і потребує багато ресурсів.

Speaker A

Да, він потребує ресурсів. Цим потрібно бути обережним. І про це, як з цим справлятись, розкаже Маша. Маша може готуватися, а ми з тобою ще домучуємо ось це питання. Дивись.

Speaker A

А чи відбудеться бокснг, коли от в мене є клас, от я створюю клас там user model і я пишу там public int?

Speaker A

Де цей ID інтова буде лежати чи відбудеться боксинг? Він же на кучу потрапляє. Е, напевно, чи ні? Чи не на кучу.

Speaker A

Чекай ще раз. не до кінця зрозумів, що якби в нас є instance instance класа інстан, да, і там одне поле айдішка інтова.

Speaker A

Int - це во нас value тип, правда? А user - це клас. Юзер у нас має бути на кучі, да, як ми вже це проговорили.

Speaker A

А де оця айдішка буде лежати? Ну, айдішка теж буде на кучі. А чи буде боксг?

Speaker A

Е, у випадку, якщо ми хочемо з, бо не дуже розумію, типу, якщо ми хочемо цейс класа зробити з його з нього ніяких приведень. Просто я створив new от там new user і в конструктор прокинув одиничку, одиничку.

Speaker A

Е, да. Де чи буде боксинг відбуватись, чи ні? Ну, здається, ні. Він одразу буде створюватися наші не бу не буде не буде, да? Ти правильно, бо не нема приведення, типа він буде просто лежати там цьому, скажемо, ну, по суті, типа

Speaker A

ти, коли ось цю одиничку створюєш, вона створюється на стеку того методу і це значення копіюється в поле юзера, якщо зовсім душно про це говорити. А, хорошо, хорошо, Маша, я тобі спойлернув питання.

Speaker A

В тебе вже має бути готова відповідь, типа, завдяки чому ми можемо побороти бокснгбоксинг? Е, завдяки дженериками ми можемо робити шаблонні класи, які уникають боксінга і аубоксинга за рахунок того, що на рівні intermedіалеч кожен раз, коли, наприклад, ми робимо

Speaker A

new intive, якщо на рівні intermedia language, intermediate language ще не згенерований клас саме підліс inв, то він його згенерує. А якщо вже згенерований, то він просто перевик вже стає існуючий.

Speaker A

Хорошо. А-а, ну в цілому, да, я вже навіть не знаю, що тобі подушніть, типа тебе е-е дивись ліств, ти от згадала.

Speaker A

Угу. Теж питання. Ну хоча ні, ти вже і не буде питання. Ти вже і так знаєш відповідь, тому що ти, звичайно, на це відповіла. Питання було в тому, чи забокс ці інти. Ну, типа відповідь ні, тому що ти, в принципі, да, відповіла на

Speaker A

це питання. Окей, хорошо. Е, дженерики згадали. І тут раз ми згадалисти, Ілья, питання тобі. Колекції структури даних. Секція. Є у нас такий таких два інтерфейси. I enumerable.

Speaker A

Треба було мені 7 років працювати, щоб навчитись це вимовляти. і анумератор. А-а, що це таке? Навіщо вони треба? А що ти про них знаєш?

Speaker A

Про I numerable можу сказати, що по суті кожна колекція його реалізує. Ага. І вона дозволяє, ну, цей процесс дозволяє нам, ну, прибирати наші об'єкти, які, да? А завдяки чому?

Speaker A

For each. Ну да, ну for each, типа, як приклад. Але от ти кажеш inumerable - це коле інтерфейс, від якого наслідуються всі колекції. Колекції можна перебирати. І я ще згадав ще один інтерфейс до цього.

Speaker A

А, ну да. А який я забув? Анумератор. А, анумератор. Да. генератор. Можливо, ти пам'ятаєш, яким чином вони взаємопов'язані ці два інтерфейси?

Speaker A

Ну, під єдине, що можете сказати, що можливо нумератор якось доповняє inumerable. А, ну дивись, типа вable є метод getumerator, який повертає нумератор. І якраз ось цей ноумератор викликається forм. Тобто в тебе ти for each не можеш викликати на е-е об'єктах, які не

Speaker A

наслідують i enumerable. І а власне цей меerator - це як не знаюк курсор по суті, який рухається по колекції. Там є метод move next, який переходить і терується по об'єктам колекції. Є метод current, по-моєму, називається, щоб отримати текущий

Speaker A

об'єкт, на якому ми стоїмо. І є, по-моєму, reset чир, це повернутись на початок колекції. Це вже всередині анумератора.

Speaker A

А, да, якось так. І по суті ти можеш реалізувати свою свій і свіймератор. Ти можеш зробити, наприклад, imumerable, де на кожній ітерації цикла for тобі генерується рандомне число.

Speaker A

Типа іі ти можеш таке написати через Iноble iноer ти forчом типа можеш перебрати наприклад рандомні числа які там кожнійтераці будуть генеруватись.

Speaker A

О і можливо ти згадаєш ключове слово пов'язане з цим якраз з колекціями. Ну от саме в контексті оцих двох інтерфейсів.

Speaker A

Ну трошки не розумію чим. Y, бачив таке ключове слово. А, y, y return, да, да. Y return. Ну, ти от можеш написати yeld return і по суті таким чином, якщо ти в тебе просто return, в тебе там буде

Speaker A

intти, а y return ти по суті можеш як колекцію повертати і перечисляємо зі свого методу.

Speaker A

Ее. Угу. І, тобто, в нашому випадку там рандомного числа, наприклад, ти можеш зробити y return, run next і типа range чиселами указати, і в тебе буде на кожному етерації повертатись число нове рандомне.

Speaker A

Окей, хорошо. Ее, Влад, питання тобі, які колекції структури даних ти використовував? Можливо, приклади приведеш, а я тобі там далі помучую вже по ним.

Speaker A

В основном, наверное, 90% часу - это обычный массив лист. Ну, по типу вектора X плюсов, динамично расширяющийся.

Speaker A

Окей. І самый минимум diк, ну, знаю за Linked list, за set, ну, їх в основному ще не использовав на базовому районі, я знаю.

Speaker A

А от давай так поясни. От ти кажеш динамічний масив, динамічно розширя розширюваний масив. А як воно як цей ліст лежить в пам'яті?

Speaker A

Ну, вообще лист, э-э, должен лежать одним сегментом, одним ку одним куском в памяти. Угу. Ну, ковбаса такая, да?

Speaker A

И получается, что когда мы, допустим, добавляем элемент, очередной массив, то этот массив будет перезаписываться с нуля, то есть будет браться новый кусок памяти и записываться сюда все новые данные, ну, старые и плюс новые в один новый кусок.

Speaker A

Угу. Тобто тобі потрібно бути обережним з розширюванням, тому що в тебе в якийсь момент може бути як два масиви в пам'яті існувати. Один менший, один більший.

Speaker A

Нічого. Ні. Ну, дивись, наприклад, ти розширюєш свій ліст, правильно? Ее, ти виділив ковбасу 100 елементів на нього, на цей ліст.

Speaker A

І там Денис щось там спойлерить. Денис, по Денис пока. Ну, у нас же ж управляемый язык, поэтому Ну, дивись, ну, дивись, типа ти виділив у участок на 100 елементів в лісті і ти їх заповнюєш просто постійно докидуєш елемент в кінець, правильно? Ось так

Speaker A

ліст працює. І в якийсь момент ти можеш дійти до того, що в тебе весь ліст заповниться.

Speaker A

Не, понятное дело, что если там будем миллиарды элементы выделять, то у нас ж память не бесконечная. Но там ещё изначально есть такой момент, что, ну, вот, да, как прояву ёмкость, то, что изначально выделяется больше памяти под массив для того, чтоб не было вот этой

Speaker A

лишней перезаписи. Ну, допустим, там создали элемент на, ну, точнее массив на пять елементів, а выделилось восемь. Ну, и чисто за счёт компілятора то, что воно працює, чтоб избежать лишних переделений памяти.

Speaker A

Да, але все одно типу ліст працює таким чином, що коли в тебе, наприклад, ти виділив там навіть 100 елементів, ти всі їх заповнив, то в момент, коли вони всі за заповнились, ліст автоматично себе розширює.

Speaker A

Створюється копія вдвічі більша, там на старих системах, там з меншою розрядністю там в півтори рази, по-моєму. І умовно в тебе створює в тебе якийсь момент в пам'яті буде існувати два масиви. Один на 100 елементів заповнений, інший на 200 елементів

Speaker A

пустий. І в тебе елементи оці 100 елементів, вони скопіюються в більший, а старий потім видалиться garbage collector.

Speaker A

Ну да, да. Але ну це може вплинути на перфоманс, якщо ти, наприклад, ізначально не ти, наприклад, знав, що в тебе буде 100 000 елементів, наприклад.

Speaker A

Ну 100 000 елементів багато. Давай так 10 000. Не, ну если мы точно знаем, что у нас вот размер коллекции не будет меняться, тогда сразу проще обозначить количество элементов, ну, які будут деляться по Ну, тут я погоджуюсь, да, якщо ти знаєш

Speaker A

чіткий чітку чітке число елементів, да, краще виділити типа для цього. Окей. А ну давайте ще вас більше людей попитають. Дякую, Стас, питання тобі. От ми згадали ліст. Понятно, колбаса, яка динамічно розширяється. А словар diary, яка чим він відрізняється?

Speaker A

Це тип колекції, ключ значення, тобіш там працює воно як є певний масив ключів і під кожний ключ прив'язує своє значення. На цьому, в принципі, можна сказати, що оперативна пам'ять - це є такі великі дикшенері, якщо грубо кажучи. А от

Speaker A

м що ще сказати? воно використовується е можна використовувати його для кеша такого, якщо брати in memory. Ну why not, да?

Speaker A

Або там по типу задачок, знаєте, там задачка на римські числа або щось таке. Ну я практично призначення йому не находив, не дуже часто використовував, того не скажу багато.

Speaker A

Ну а я тебе помучу все одно трішечки. От ти кажеш ключ значення, да? А питання, е, чи є там якась штука, типа унікальність ключа, чи щось таке?

Speaker A

М, так, це хеш. І він завжди унікальний. Ну, цього прям гарантувати не можна, наскільки я знаю.

Speaker A

Все одно може бути такий кейс, що він колись повториться. Але це називається колізія, да?

Speaker A

Так, так, колізія. І в кожного, е, ну, вкла object самого базового є такий метод, як getхш-код чи просто хеш-код.

Speaker A

його мо можна отримати. Якщо ти проектуєш якийсь свій власний об'єкт, тобі бажано його там якось переоприділяти.

Speaker A

Це є таке чув такі рекомендації. Ну да, є таке. І що ще? Ну призначення хша це не повторювались елементи, якщо вони, по-моєму, якесь одинакове ім'я або щось подібне.

Speaker A

А якщо вони повторились? Якщо сталась колізія, як відреагує, знаєш? Якщо сталася колізія за Якщо сталася колізія то створиться ще один масив під капотом, по ідеї.

Speaker A

Ну, я можу можу розповісти, якщо якщо хочеш. Ну, я раніше, коли Jav, там взагалі був такий прикол в неї, що під капотом будувалося бінарне дерево, яке заново ці елементи переопреділяло. І через те, що колізія типу оцей бакет один був

Speaker A

заповнений там і в нього налізли, то тамбудувалось це дерево і це гарантувало, що все одно буде швидкий доступ до елементів через те, що це буде по деревній структурі. Е хоча на першу голову приходить, що там буде якийсь linked listст, який буде просто по цим

Speaker A

елементам. якраз отрі саме вшапі працює таким чином, що рахується шкод в тебе типа по суті як іде у тебе хеш- таблиця іде де у тебе два масива в одному тут типа лежать типа по суті ключі і індекс там

Speaker A

рахується за рахунок хеш-кода і остачі відділення на по-моєму кількість ключів наскільки я пам'ятаю і цей ключ посилається на linked list де лежать типа поно нодом лежать key, value і hasш, по-моєму, там ще лежить, наскільки я пам'ятаю. І таким чином,

Speaker A

навіть якщо в тебе у ключив однакове, е-е, як це називається, одна у уключив однакові хші, тобто сталась колізія, за рахунок того, що ти в другому масиві оцієї хеш таблиці зберігаєш link list, де в кожній ноді лежить key value, типа

Speaker A

оригінальне значення, ти можеш все одно достати по оцьому ключу те value, яке ти по ньому поклав.

Speaker A

Ну, звучить логічно, да? Да, типу. Ну і понятне дело, через таку реалізацію у нього може бути складні типа складність складність пошуку типа погіршуватись, якщо в тебе є колізія.

Speaker A

Але це прям дуже поганий кейс має бути, що якщо таке скла. Ну да, да. Ну це типа це на великих об'ємах даних може. Ну, я, чесно кажучи, не стикався з такою проблемою там з на своєму досліді.

Speaker A

Е, раз ми згадали Шкод, згадав. Круто. Е-е, до речі, раз ти вже згадав Ш-код, який ще метод там доволі часто потрібно переопределять?

Speaker A

Equals, да? Equals. Ну давайте по reference equals різницю між потрі подвійне дорівнює і так далі. Я вас мучить не буду сьогодні, бо це якось супердушна тема. А давайте підемо. От те, що мені цікавіше, мені скаже здається важливіше, щоб Джун знав, це складності алгоритмів.

Speaker A

Денис, питання тобі. Я не буду тебе питати там про складність бінарних пошуків і всяку таку штуку. Це все можна вивчити.

Speaker A

Давай так. у тебе я пишу forч, в якому я звертаюсь до якоїсь колекції з використанням linkq методів і дивись, у тебе є там forage або просто якийсь цикл, неважливо, і всередині я роблю сам collection точка first of default по

Speaker A

якійсь умові. Уявив, да, собі, як воно виглядає. Тобто у нас як ми в циклі ми звертаємо циклі циклі то колекції і там визиваємо метод first of default.

Speaker A

Яка буде складність цього алгоритму в найгіршому кейсі? А в найгіршому? Ну, зазвичай кажуть про worst case, а в найгіршому квадратичне. Чому? Тому що перше у нас є сам цикл. Це вже перша складність це, да?

Speaker A

А, а first or default - это що такое? Це у нас first ми знаходимо за за якоюсь умови.

Speaker A

Для цього нам потрібно пройтись по всій колекції. І, наприклад, якщо ми пройшлись по всій колекції, ми нічого не знайшли з цією мовою, то нам повертається значення defult. Тобто в найгіршому випадку такого елементу в колекції не буде, да?

Speaker A

А, а і тому у нас буде, як простими словами кажучи, цикл в циклі. Да. А якщо в мене first or default без умови, тоді яка буде складність?

Speaker A

Типу ти можеш написати first to default з умовою, а можеш без. Аа, ну я думаю, в такому отут можу помилятись, наче просто повертає перший елемент колекції і в такому випадку це буде складність о просто.

Speaker A

Ну да, ітогово, да, тому що перший елемент - це о від одиниці буде повернути. Ти правильно мислиш. Це просто я так, скажемо так, тебе чекну.

Speaker A

А, о, питання інше питання таке типа теж стосується структур. Ой, не структур, складності алгоритмів.

Speaker A

Мені потрібно перевірити чи є число n степенню числа. Яка складність такого алгоритму буде? Який би ти алгоритм? Давай. Ти хотел systemдизайн. От тобі за дизайн алгоритм. Як ти будеш це рахувати?

Speaker A

А, тобто мені треба перевірити, чи є число n в степенню числа m. Да. Угу. М. Мені потрібно описати алгоритм сам, як він буде почав дивидність.

Speaker A

Дивись, ти можеш, ну, дивись, щоб сказати складність, треба мати якийсь алгоритм, тому що в цілому ее можна підійти по по-різному, але є straightйтфорд рішення, яке типа більшість робить просто в лоб. І там можна посказати [музика] ану я зараз спробую те написати. То,

Speaker A

тобто у нас, наприклад, є число, воно, наприклад, в степені n. Я в коментарях буду писати. І нам потрібно знайти е чи є n степ чи є n степенню числа m. Тобто n не є степенню.

Speaker A

Ее n - це типа, ну, наприклад, я прокидую. N - це четворка, е, - це двойка. М - це - це двойка.

Speaker A

Тобто четворка є степенню двойки. Типа це 2 квадрат. Але якщо прокину там типа, ну, степінню, я маю на увазі цілою степеню. П'ятьрка не являється степенню число 2.

Speaker A

А, да, я зрозумів. Ну, я напевно моя моя думка тільки що я спробую конь знайти.

Speaker A

Що-що ще раз не почув? Корінь. А я спробую корінь знайти. Так. Ну, а якщо давай straightтфод рішення, у тебе нема якоїсь мас біблі математичної бібліотеки в дотнесі, ти там пишеш: "Ну таке стрійтфорвард рішення, якби там в тупу робити. Просто ділити, поки типа

Speaker A

ділиться, поки чи число буде ціле, типа поки ти будеш по суті як рекурсивно ділити ее n на і поки повертається ціла остача, значить воно ділиться.

Speaker A

Можна так просто це мені мені здається це настільки неефективне рішення, що до цього складно додуматись.

Speaker A

Та ні, це саме тупе рішення, як на мене. Ну типу я до чого довів, щоб не витрачати час. Буде логарифміч логарифмічна складність, де логарифм будет по основаннию от N.

Speaker A

Ну да, тому що в принципі наче отой поінь з числа ж можна представити у вигляді логарифму. Тому це в принципі логічно, да?

Speaker A

Ну да. Ну типу просто підсказках, хто дивиться це відео. Якщо у вас є ділення в алгоритмі якесь, значить там буде логарифмічна складність. Якщо ідуть, якщо цикл, це вже n. Якщо цикл в циклі - это n квадрат. Якщо цикли послідовно, це

Speaker A

n. Все. Типа це ж така чорнетка в голові запам'ятали і будь-який алгоритм можете порахувати.

Speaker A

А что? Ну всё, хватит у вас душить. Что-то уже вы начали цей патьпотеть потихонечку начали.

Speaker A

Ну давайте по колекціям в цілому все. Так нормальненько пройшлись. Давайте далі. Ну і ще один інтерфейсable.

Speaker A

Це питання Вадіму. Що таке disposable? коли чи використовував ти його, що про нього знаєш?

Speaker A

Окей, IDPOS - це інтерфейс, який, ну, дає змогу очищати ее зовнішні, скажемо так, ресурси, такі, які автоматично не може очистити garbage колектор. Ну, найпопулярніші приклади - це, звісно, з'єднання з базою даних, ее якісь стріми чи рідстріми, наприклад, при

Speaker A

роботі з файлами. е, та, наприклад, HTTP клієнти. І отже, ми маємо реалізувати для них, е-е, якщо ми використовуємо десь в наших класах такий маємо, ее реалізувати інтерфейсable, тобто дати реалізацію методу Disposed.

Speaker A

Е, і при використанні найчастіше конструкції using е в кінці автоматично ці ресурси будуть очищатись.

Speaker A

Угу. Аз згадав. А у яким чином працює? Зінг - це приклад синтаксичного цукору, якщо так кажуть українською мовою. Він насправді розгортається в конструкцію try catch fin. І тобто в будь-якому випадку в кінці буде застосовувати, ну, trйфлі в нас finлі, да,

Speaker A

trйфлі, так. І в кінці буде завжди тригеритися метод dispose інтерфейс іди був. Хорошо. Хорошо.

Speaker A

Маша, питання тобі. От раз ми згадали IDOS, з чим потрібно best practice, як описаний в документації Майкрософта, часто ти IDposable ще з однією штукою реалізовуєш в класі, з якою?

Speaker A

Пов'язано з GB колектором. finлай. Ще раз погано чую. Finaliz. О, от finaliz. А що ти реалізовуєш?

Speaker A

Ну, щоби уникнути зараз, ну, затрати карбічколектора ресурсів, можна прописати деструктор та метод dispost dispos зробити приватну зміну типу і dispose, яка по дефолту буде false. і в методі прописати, що із dispose true і викликати finлай carbage collector типу воно скаже

Speaker A

що якщо що все ж таки викликався dispose ми очистили свої ресурси і сказали cl CLR що не треба викликатизатор бо об'єкт вже очистений очищений просто видали з пам'яті відповідно CЛR не буде витрачати на це ресурс Все.

Speaker A

Ну давай сформулюю. В принциму типа хід думок правильний. Давайте не плутати деструктор і фіналізатор, тому що деструктор - це трішечки, ну, типа інша штука. Але, да, типа, в принципі, часто проводять аналогію з нею. Финалізатор - це спеціальний метод, який по дефолту не

Speaker A

реалізований у класі і в яко і якщо ви його реалізовуєте, то при видаленні цього об'єкту garbage колектор буде ставити цей об'єкт в спеціальну чергу, з якої ці фіналізатори будуть викликатись для додаткової очистки якихось ресурсів. І в дотнеті, як best

Speaker A

practice, якщо реалізовувати ID побоналізатор - це додатковий предохранитель. Якщо розробник провтикав викликати dispose або using сигналізаторі, ви можете типа очистити ці ресурси для того, щоб у вас не було утечок пам'яті. І але відповідно, якщо ви все-таки dispose викликали, як Маша

Speaker A

писав, то ви можете через бу просто бул поле приватне сказати в dispу я вже був disпознутий. І якщо я був disпозинутий, ви можете через спеціальний метод у класа GC GC.spress finalize прокинути туди reference до об'єкта. А зазвичай ви

Speaker A

прокидуєте референт до самого слова, до самого себе через ключове слово thisс. Ви кажете GC, чувак, я реалізований з фіналізатором, але мене не чіпає, я вже сповзнутий. Да, тобто в цілому правильна відповідь.

Speaker A

А Ілья, раз ми вже пішли про GC, що ти знаєш про GB Collector? Що це таке?

Speaker A

Можливо нюанси його роботи? Ну, это часть силеара. отвечает за manage ресурсы, он их автоматически чистит. Знаю, что у Гарч колектора есть, ну, он так разделяет на объекты так по трём уровням. Там нулевой, первый, второй, да, да, поколение. Ну так он в целом

Speaker A

работает. Э-э он вызывается автоматически. Он ходит, ну, проверяет, нету ли ссылок больше на какой-то объект.

Speaker A

Если нет, он их чистит. Если есть, то он их перекидывает на первое поколение. Э- потому что, ну, как минимум, это уже могут быть объекты, которые могут использоваться там в следующий раз. И, в принципе, сам метод вот это чистки памяти, он такой ресурс.

Speaker A

Ага. Всё, в принципе. А от дивись, ти там кажеш, що типу він перевіряє референси на об'єкт. Це в цілому вірно, щоб типу, ну, я би для, якщо ви хочете прям глибоку відповідь типа дати на співбесі, це не обов'язково

Speaker A

для джунів, що нема до цього об'єкту ви не можете достукатись до якихось рутових корінних об'єктів, типа в самому дотне, тому що у вас може бути кейс, наприклад, що клас А і Б у них кроossence один на одного, але при цьому вони обидва ніде

Speaker A

можуть не використовуватись. до них нема посилань з ротових об'єктів самого дотнету, там з мейну, наприклад, до них ніяк не достукатись. Відповідно, вони мають бути видалені garbage колектором для того, щоб уникнути утечки пам'яті.

Speaker A

Це раз. По-друге, ну, про покоління ти сказав, а я би ще деталізував. Можливо, ти знаєш деталі алгоритму, як вона очи очищається. Це не супер обов'язково для джунів, але я би помучив людину, якщо вже пішла за це мова.

Speaker A

М. Ну, а в плані деталі алгоритм. Ну, дивись, воно не просто воно не просто бере і їх зразу їх видаляє. Там є декілька кроків.

Speaker A

Можливо тобі, е, подсказка, що типа слово метла і подмітать. Можливо, тобі е щось підскаже.

Speaker A

Там є таке слово сві. А ні, тоді таке не знаю. Да. Дивіться, короче, як воно працює.

Speaker A

Коли ува garbage колектор він там в залежності, це прямо я вже здушно кажу, це не потрібно нажнів знати. Типа не кожен сеньору скаже, що типа є різні конфігурації garbage колектора: workstation, сервер і через це він може себе по-різному поводити, по-різному

Speaker A

запускатися, типа там concurrent, ніcent і так далі. там лочити, не лочити застосунок, але типа в цілому для джуна достатньо розуміти, що це є там спеціальний бекграунд, скажемо так, процес, який очищає пам'ять. І відповідно, коли він очищає ці об'єкти, які вже ніде не

Speaker A

використовуються, це референс типи, то він спочатку їх помічає для видалення, потім він їх видаляє, а потім він робить так називаєму дефрагментацію пам'яті. Це така дефрагментація пам'яті. У вас є от колбаса забита, от перше покоління, нульове, нульове покоління забите

Speaker A

інстансами об'єктів. Воно його, коли видаляє, воно ж не буде ось тут кусок кусок, як ви відрізаєте від ковбаси, воно буде отак от отак от по їх видаляє.

Speaker A

І відповідно у вас буде переч така пам'ять з короткими про типа з проміжками пам'яті, які не заповнені. І відповідно там вам здається, ну, блін, в мене гігабайт пам'яті вільний. А по факту вільного участку в гігабай у вас тут нема, тому що ось тут 100 Мб, отут

Speaker A

50 Мб, отут 200 Мб і так далі. Відповідно об'єкт там, наприклад, на 500 Мб ви вже створити не можете.

Speaker A

Відбувається так називаєма діагфрагментація і всі об'єкти заганяються типа в край а-а по-моєму там в кінець е цього типа е поколінь, скажемо так, і діфрагментація. І відповідно, якщо об'єкт переживає ее видалення, е то він переходить в наступне покоління, е, яких

Speaker A

всього три. А Влад питання, можливо, ти знаєш, чому їх три, а не два чи чотири чи п'ять і так далі?

Speaker A

Ну, кму пришли разработники в Майкрософте, потому что такое это оптимальный вариант. Ну, тому що якщо робити слишком много поколений, то надо будет по каждому проходиться, а якщо мало, там одно либо два, то, соответственно, тоже придётся вот часто по нем проходиться. Ну, как,

Speaker A

ну, компромиссное решение тут. Ну да. емпірично є байка, що вони просто так прийшли, типа емпірично, типа два мало, три нормально і так і залишили. А можливо ти ще знаєш про інші участки?

Speaker A

М ці попавариш об'єкт ХИП, там где большие объекты, точно не помню, там что-то свыше 8 Кб, ну плюс-мінус 84 000 байт чи щось таке розмір, да?

Speaker A

Да, щось таке. И они, соответственно, лежат, по-моему, чуть отдельно и идут там вообще маркируются під цифрой три. Ну и, соответственно, редко по ней проходится мусорщик.

Speaker A

А як ти думаєш, для чого це зроблено? Що саме? А воно типа виділене окремий large objectт. Чому не можна було якось чому вони не живуть просто так само, як і інші об'єкти? Потому что при дефрагментации довольно будет накладно

Speaker A

переносить оці великие объекти. Проще, чтоб вони сразу лежали, ну, в одном месте. Вот условно там с краю этой ковбаси пам'яті.

Speaker A

Ну, в цілому, да, типа це просто з точки зору використання ресурсів. Ще там з якогось п'ятого дотнету появився pint object, типа, як об'єкти закріплені за одним участком пам'яті. Я ніколи цим не користувався, але якщо ви хочете казирнуть знаннями на співбесіді,

Speaker A

то можете це згадати. Денис, ти руку підняв, ти хотів щось е доповнити? А, да, там було питання, чому ALA3 е Generations. І у мене з'явилась думка, що може це якось пов'язана така singletлon, transent, тобто це взагалі не раз.

Speaker A

Ні, ну от ні про це ще далі поговоримо. Ну, в принципі, на джуна не супер потрібно там знати всі нюанси GC, тому що там, ну, можна плотно засісти просто, в принципі.

Speaker A

Ну, ми нормально так поспілкувались, тобто ви прям непогано відповідаєте. Окей, хорошо, GC поговорили. Тепер тема, на якій, ну, ви вже маєте валитись. Ви занадто гарно відповідаєте.

Speaker A

Треба вас трішки піддушить. Багато поточка, асинхронщина, примітивої синхронізації. Давайте ось. Да, Стас, ну до тебе, я думаю, ти маєш відповісти. Ти поки непогано відповідав.

Speaker A

Давай так. Різниця ее точніше так. Чи можете пояснити, що таке асинхронність? Не в контексті США, а в цілому.

Speaker A

Ну, от умовно я можу у тому я працюю в офісі і захотів кушать. Да.

Speaker A

От в мене є варіант. Е, піти купити піцу і потім знов сісти працювати. Це синхронно виходить. Я буду йти по піцу, купити піцу, прийти поїсти і потім працювати. А синхроно я можу замовити піцу, подожди, поки вона прийде, але

Speaker A

паралельно я буду працювати. Я просто вийду по неї, заберу і буду кушать. Оце, грубо кажучи, асинхронність. Тобто ми можемо ну можна делегувати якусь задачу на інший потік і при цьому якісь більш інші пріоритетніші процеси виконувати. Ну, це, напевно, не

Speaker A

вважає, ну, це не поділяється на пріоритетність, але просто, що можна отак розпалелити задачу тимчасово і е ти приводиш проговарний приклад, але от давай в контексті технічному поговоримо, типу в чому різниця запустити поток, який щось рахує всередині нашого застосунку і

Speaker A

асинхронністю. От в своєму розумінні для в якому там були створені саме ті синхронні операції, так називаємі неблокуючі операції.

Speaker A

Е-е запустити окремий потік - це просто ти виділяєш окремий процес, ну, окремий окремі ресурси під процес, які яки буде просто виконувати.

Speaker A

Не процес. Процесце все-таки більш типа високорівне розуміння. Давай так. Поток будемо говорити, оперувати такими термінами.

Speaker A

Ну да. поток. Ти просто виділяєш поток, щоб він виділив, ну, щоб він порахував деякий результат і він буде працювати паралельно головному, тобто і це не асинхронно. А от якщо говорити про асинхронність, в тебе є головний потікмей, який умовно там рендерить юйку

Speaker A

користувача в якомусь вpфі і ти можеш використати ascate, щоб умовно він звернувся до бази, щось виконав. Тобіш, е, він почне виконувати цей метод, зупиниться на еве рейті і скаже там якомусь потоку: "Іди чекай цей результат виконання операції, а я поки

Speaker A

буду дальше показувати якісь класні картинки користувачу". Ну, ти приводиш правильні приклади, а от на співбесіді, якщо ще б не проводити всі ці приклади, типа розумієш і це я бачу, можна сказати, що ми використовуємо асинхронність в контексті виконання різного роду IO операцій, які виходять

Speaker A

поза межі застосунку і роблять, як ти сказав, запити до бази, запити по мережі і так далі. І ми не хочемо, скажемо так, блокувати потік, який викликає ці операції, бо ми не знаємо, скільки часу там запит по мережі буде йти.

Speaker A

Відповідно, ми використовуємо асинхронний підхід для цього. Тобто, наприклад, якщо ти навіть з використанням assate викликчеш ее декілька так типа паралельно і там task venol зробиш, це не являється типа асинхронністю, якщо вони просто щось всередині себе рахують.

Speaker A

Ну, це паралелізм більше буде. От. Да. А от якраз паралелізм, раз ти вже це згадав, то це паралельне виконання CPU баoundтed операцій найчастіше. Типу те, що виконується всередині нашого застосунку, якісь підрахунки.

Speaker A

А давай підемо далі. Раз вже заговорили паралелізм багатопоточка синхронність що таке concurrence або ко con конкарент виконання?

Speaker A

Це досі питання. Це Денису питання. Сорі. Конкарент виконання. А, ну це по суті паралельне виконання.

Speaker A

А тоді паралелізм. Таке? А паралелізм - це, можна сказати, підхід, властивість - це коли ми одночасно можемо запустити м дві на виконання дві задачі саме одночасно або на одному єди, а тоді це буде псевдопаралельно, а або, наприклад, на декількох ядрах.

Speaker A

От. А з того, що можу сказати ще, то є аля два способи. Це через рес і через таз. Це ти не в цю сторону виходиш. Так, на на сабесі це гарно робити, типа ходіть в іншу сторону, навалювати, навішувати лапшу навучу інтерв'юеру. Але

Speaker A

зараз я я цьому, скажемо так, я цьому навчаю, тому давайте так е-е про до конкарентові повернемось. До конкарент повернемось.

Speaker A

Ти вже там згадав за ядра і от я тебе хочу підвести до відповіді. Типу от уяви, що в тебе є одноядерний процесор, який може виконувати тільки один поток.

Speaker A

От навіть от в мене в мене зараз от MacBook, я не знаю скільки тут ядер, по-моєму, там 12 CPU чи щось таке, я не пам'ятаю конфігурацію. Ну, умовно, давай там 16 ядер. Я тобі зараз відкрию свій диспетчер задач і в мене тільки в Зумі

Speaker A

буде 160 потоків там щось таке чи там 120, типу явно больше, чим ядер. При тому, що в мене ще паралельно там відкрит ОБС, в мене відкриті ще інші приколи. Як він їх обробляє? Типу одночасно. Ну, ти підняв руку і тобі відповідь, Денис, типу. Тому

Speaker A

ее тобі точніше тобі питання, як він їх обробляє, як там воно Ну я тобі от руками навіть показую, що там відбувається.

Speaker A

А-а, дивіться, є проблема в тому, що якби ми створювали, ну, по-перше, що таке застосунок? Це взагалі окремий як процес, да? І якби нам потрібно було ослоювати ще процеси, процеси, це дуже затратно.

Speaker A

Ти ти не ти не туди йдеш. Ти взагалі от типу у нас у тебе 1000 потоків і 10 ядер.

Speaker A

Яким чином ці 10 ядер при умові, що одне ядро виконує один потік, да? Типа там же ж є віртуальні фізичні ядра. Яким чином він їх виконує? Типа одночасно?

Speaker A

А, ну я думаю, що, а, от, наприклад, на ви сказали, що на ЗОМ дуже багато потоків, навіть більше, ніж ядер.

Speaker A

А це за рахунок того, що а потоки, які входять в процес, в цей один потоки створювати набагато легше і взаємозв'язок між ними відбувається набагато легше. Давай я дам відповідь і підемо далі. Типу, а, дивіться, по то типа CPU у вас є залізяка CPU, да?

Speaker A

Е-е, як працює взагалі ком комп'ютер, якщо мовою там фізики ток є або його нема? Там ці всі транзистори, ноліки, единички, ток є, ток нема. Все, типа, це все, що може, ну, по суті, як він працює комп'ютер. Відповідно, CPU посилає, як

Speaker A

мізки посилає команда, типа, а, різним частинам вашого комп'ютера. Типа виведі от в мене на камеру, типа воно посилає сигнал камері, щоб вона типа включилась.

Speaker A

Камера збирає типа там лінза, там всякі діафрагми і так далі. Оце типа мене знімають зараз, повертають там процесору якісь дані. Але поки воно чекає відповідь там від камери, від монітора, це ядро, воно може дуже швидко переключитись, перестрибнути на інший

Speaker A

поток і виконати якісь операції там, тому що не всі операції виконуються CPюшкою, да? CPU посилає сигнал, наприклад, там запис на диск. Запис на диск займає час, 100%. Типу той самий, а-а, особливо, якщо у вас HDD, де там головка бігає

Speaker A

фізично, да, по ньому, по диску. Відповідно, у вас 1000 потоків. Один поток херачить типа запис на диск, запускає запис на диск і CPU, наприклад, в цей момент може перестрибнути на інший поток дуже швидко. Це називається контекст switch. Дуже швидко і

Speaker A

опцьовувати інший поток. І відповідно це і називається конкаренс. Я не знав, что именно Я не знав, що саме про це треба сказати. Я Ну так, в цьому прикол. В цьому прикол співбесід. Я тебе до цього підводив, ти мені там філософію за процеси почав

Speaker A

розповідати і віртуальну пам'ять. Я тому тебе і перебив. Ладно, ідемо далі, бо час вже і так нас вийде більше двох годин, походу. Ми у вас ще задачка, а ми ще з вами до баз даних дійшли і ще нічого

Speaker A

на цей. Ее давай, Вадим, питання тобі. Різниця між таском і тредом? М так. Ну, Task використовується для синхронності. Тобто це такий спеціальний Generic, який включає в собі, ну, які ми використовуємо при асинхронних е-е операціях, асинхронних методах. Тобто ось він так обгортує, скажемо так, той

Speaker A

тип, який ми хочемо повернути. Ее а треди ми використовуємо при паралельному виконанні різних процесів.

Speaker A

Ну, я б не зовсім так. Дивись, стред - це об'єкт, який по суті є абстракцію над протоком, об'єктом процесора, який ми створюємо типа об'єктом операційної системи, sorry, який ми створюємо через C#AR. Task - це абстракція над якоюсь задачею, який типа містить в собі статус

Speaker A

виконання цієї задачі, результат. ми можемо там викликати певні методи і типа там continua наприклад, якщо задача виконалась, як її там продовжувати виконання, а get result чи там run syнроніс і так далі, типа. І task, важливо розуміти, що task не являється

Speaker A

потоком. Task - це просто абстракція всі шарпі. І а тред - це вже типа, якщо ми створюємо трет, то у нас створюється поток на рівні операційної системи.

Speaker A

Відповідно відповідь може ще ой питання ще може бути на співбесідах типа коли використовувати taskреadт. Самі Microsoft рекомендують в більшості випадків використовувати таски.

Speaker A

Чому? Ми поговоримо про са далі. Ми не будемо поки що спойлерити. А ее треди нам потрібні тільки коли нам прям потрібно реально окремий об'єкт на рівні операційної системи. Або ми можемо максима ми хочемо максимальний рівень керування над цим потоком. Бо він

Speaker A

більш важкий в плані використання ресурсів, коли ми його створюємо. Да, якось так. Е, маше тебе достався самий сок.

Speaker A

А сінкавей, як він працює? Ну, ти мене не маєш підвести, я думаю. Тут weight працює так.

Speaker A

Ми, ее, короче, потік заходить в асинхронний метод, побмічений ключовим словом і підходить до ключового слова.

Speaker A

Він запускає цей асинхронний метод, м, повертається в труд. Ця асинхронна операція виконується потоком стредпула і жоден потік не чекає виконання цього коду. Ну, це в нас для неблокуючих викликів використовується.

Speaker A

І коли evвейт виконується, повертається результат виконання, то або той потік, що це є асинхронний метод виклади викликав, або інший стритпула буде виконувати код після евейту. Е, також це реалізується, здається, через стейт машину, яку генерують компілятор.

Speaker A

Метод розбивається на частини і після кожного евейта зберігається його стан. Виходить, ну, потік не блокується, виклик повертає Таск, а коли результат готовий, то стоїть машина продовжує виконання з того місця, на е раніше було доречно говорити про synchronization context, а-а, типу там,

Speaker A

наприклад якихось Windows формах, там типа часто, наприклад, така штука використовувалась, як configure a в старому ASP.net, але зараз це вже не актуально, скажемо так.

Speaker A

можуть спитати на співбесідах, але навряд чи джена. Якогось сеньйора можуть про це подушити. Ти в цілому сказала правильно, але якщо ви хочете там прям жорстко задушніть, то в цілому типа відповідь типа для джуна гарна. Ти і стейт машину згадала, і adдpol згадала.

Speaker A

Да, тут ще важливо зазначити, що pool - це о спеціальний набір потоків, які виділяються разом зі створенням вашого дотнестосунку. І відповідно тому вигідніше використовувати таски, тому що воно вже використовує ресурси, які були зараніє виділені, типа з цього тредпула,

Speaker A

да. Але тут ще важливо зазначити, що ее оці тип асинхронні методи, да, вони просто в якийсь час, тобто насправді твій перший поток, який заходить в асинхронний метод, він там ще і далі піде і не і не одразу повернеться в

Speaker A

тредpol, а поки він не дійде до низькорівневих викликів, до там спеціальних функцій операційної системи, які вже там контролюють типу там запит до мережі і потім типу він доходить і тільки в той же момент, коли ця низькорів штука запускається, він

Speaker A

повертається в тредadpool. Потім, я не пам'ятаю, як ці бібліотеки називається, вони рівні типа вінусі, в Лінуксі. Це типа там низькорів операції операційної системи в низькорів Апі. Потім це нізкорівневе аі, коли, наприклад, запит до мережі виконався, прийшов результат, воно повертає керування до твого

Speaker A

застосунку, до стей машини, яка вже далі виконує код після цього evй. Але, ну, типа, в цілому, ти правильно сказала, достатньо вже розуміти Джуну, що код до евейта виконується одним потоком, код після евейта може виконуватись іншим. Це перше. Плюс, що Aвей, він хоч і очікує

Speaker A

результати виконання, але не є блокуючим, тому що викликаючий поток повертається вредпу. Пройт машину це згадати, це взагалі типа highлеvel такий типа для, ну, на всі джуни мають, як на мене, це там прям супершарити.

Speaker A

State машина на рівні intermediate language. Ти помогу сказала це теж це проговорю. Е, генерується.

Speaker A

Але ще питаннячко таке. Якщо я, наприклад, позначив метод ключовим словом ASН, а AAT всередині не викликав, ну, чи може така кейс бути?

Speaker A

Так, можна. Asзначає, що метод може бути е асинхронним, необов'язково. А, а чи чому це погано? Чому тобі компілятор поругається на це?

Speaker A

Це запутує ще й інших розробників, бо вони очікують, що там буде Avatй. Ну, бо там згенерується state машина, яка типу буде useless. Типа не хотів хотів про це, да, сказати.

Speaker A

Ну все, тоді я вже перервав його. А давайте далі. Ілья, питання тобі. Душне питання. Насправді зазвичай синхронні методи в тебе повертають task. Ти пишеш asyn task або as task там inви, наприклад. А чи можна написати assin void?

Speaker A

Ну я так ніколи не писав. Але чи можна? Але чи можна? Ну типа як ти думаєш? Чи можливо читав, чув?

Speaker A

Ну, я вважаю, що не можна. Можна, а void можна використовувати. Його не бажано використовувати, тому що у нас там не відловлюються ексепшени в такому випадку. Це може крашнути вашу апку, типа нюанси. Ось типа всі state машини і так далі. Воно

Speaker A

не так працює, як хотілося би. І, е, assin void можна використовувати, ее, для evвентх hand хендлерів. Це єдиний зкейс, типа, коли його, типа, кажуть використовувати. В цілому, я не пам'ятаю, що в мене на практиці це було, але це така душне питання сабесів.

Speaker A

Ті, по-моему, у Ріктора це в книжці він, по-моєму, цю тему піднімав, наскільки я пам'ятаю. Але, да. Окей. Ну, раз ти не пам'ятаєш, давай далі. Наступне питання теж в контексті тасок. М чи можна якимось чином запустити аля паралельно декілька тасок, а потім дочекатись

Speaker A

результати їхнього виконання? Чи робив ти такі якісь задачки? Ну да, можна використовувати банальний task vult.

Speaker A

Угу. Wait. А ще які нам знаєш, наприклад, там яка різниця між when any і all?

Speaker A

Ну, воно це ми получається повинні дочекатися, поки всі таски, там, наприклад, ми три створили, е-е, треба дочекатися, що всі три завершились.

Speaker A

Ага. А вни мабуть [музика] он будет по мере завершения тасок в н, коли хоч якась виконається, типу він типу поверне результат, типу ось ось ця різниця, типу, ну, по суті в назві вся зашита різниця. Окей. Ну, типа, when all важливо знати, як на

Speaker A

мене, Джену, тому що доволі часто можна використовувати на практиці. Стикається Влад, Угу. Далі питання тобі. Е-е, чи знаєш ти, ее, якісь проблеми, пов'язані з багатопоточністю, можу тобі конкретизувати умовно, коли ми одночасно декількома потоками робимо якісь операції? Чи знаєш ти проблеми,

Speaker A

пов'язані з цим? Ну, это ж у нас по сути гонка за даными. И можно получить додук, когда первый объект звертается до другого, а другого треба звернутись до першого.

Speaker A

І получается стоп. Ну, ти так і Race condition згадав, і deadlock. Race condition, зрозуміло, коли багато потоків стучить стукується в одну секцію. А от деadlock не зовсім, мені здається, коректний приклад, тому що, ну, в цілому ти правильно описав, що

Speaker A

deadlock - це ситуація, коли, по суті, через використання якихось примітивів синхронізації ми можемо створити таку ситуацію, коли один поток по суті блочить і два потоки блоть один одного і в нас створюється ситуація, коли вони не можуть з цього з цього вийти і в нас

Speaker A

відбувається стан системи, яка називається deadlog. Це ти згадав. Е-е, і можливо ти знаєш просто назви інструментів, які дозволяють е-е справлятись з такими ситуаціями. Саме от, наприклад, з дрейс кондишеном.

Speaker A

Ну, есть несколько примитивов синхронизации. Ок сеформу Slim монитор. Окей, хорошо. Inter. Ну, це ти, ну, прямо здав interlлок ще прикольно. Хорошо. А-а, Стас, е, давай таке базова для джуна, типа, більше там мучить не треба. Різниця між семафором і локом.

Speaker A

Можеш хоча би в принципі роботи описати. Цього достатньо. Ну, для джуна, як на мою думку. Можеш подушніть, якщо хочеш подушніть.

Speaker A

Да, тут даже нема щодо душнить. Семофор він пускає в критичну секцію. Може пустити в критичну секцію задану кількість потоків. Тобто не лише один, як це робить КК.

Speaker A

Ее, та і що типу не знаю, що ще сказати. Це, в принципі, єдина, ну, сама базова відмінність між ним, яку як єдино тебе розуміти.

Speaker A

Ну, окей, в цілому, да, хіба що можна згадати що типа е ну так в цілому по відмінності. Так, окей.

Speaker A

Ще можуть на спитати на співбесідах, у що розгортається лок у трайфлі, там монітор Enter, монітор exit. Угу.

Speaker A

Можуть запитати, це я вам всім кажу зараз, щоб це не проходити. Ще можуть спитати різницю між Сімафором, Сімафором слімом. І в принципі в більшості випадків бажано використовувати Sма Slim, тому що це типа об'єкт doтnet. Він больше лег более легковесний. І він ще

Speaker A

має типа асинхронний метод weight as, тобто він підтримує типа as weight. Це можуть спитати. І ще можуть спитати, чому влог вже в нових версіях донету типа інший лок з'явився, а раніше вам потрібно було прокидувати log object в log. Е, чому він не може бути

Speaker A

value типом? Ну і тут відповідь в тому, як value типи працюють, тому що буде копіювати значення і типу воно не зможе залочитись на копії. Вам потрібен типа референс тип для цього, який ви ніхто не будете типа чіпати його, да? Він типа

Speaker A

чисто для локів використовується. І ще така типа на співбесідах типу наведіть приклад дедлоку. Саме базовий приклад - це в одному методі log 1, log 2 об'єкти, в іншому навпаки log 2, log 1. Тобто ось вам базовий приклад дедлоку. Якщо вже забули перенервніше,

Speaker A

ось просто от ось так руками собі запам'ятаєте такий був, щоб типа привести приклад дедлоку. Я вас вже зараз не мучую цим, тому що я вже сам замучився питання задавати, тому будемо йти далі, щоб більше темп покрити. В принципі, от ми тільки пройшли базу

Speaker A

Днету зараз таку типа, і то не все ми покрили. Але далі піде простіше, тому що постаті на ASP доnetкору там питати нема чого, що на сеньора, що на джуна.

Speaker A

Денис, ти вже згадував лайфтай сервісів Trend and Scoped Singleton, да? А поясни між ними різницю. От ми зараз переходимо вже вnet.

Speaker A

Угу. А можна сказати так, це життє вони описують життєвий цикл об'єктів при Dependency Injection, образно кажучи.

Speaker A

Аз каже що у нас об'єкт створюється кожного разу, коли ми до нього звертаємось. От буквально кожного разу створюється його копія.

Speaker A

Коли ми його прокодовуємо, його інжектимо в конструктор кудись, да? А наприклад стоп це ну за замовчуванням об'єкт створюється в межах, а, наприклад, якогось запиту, да, якогось сеансу і а він живе в межах цього сеансу, але не обов'язково склоп можна задати і свій,

Speaker A

да, тобто і єлтон, це, тобто об'єкт створюється з самого Отут може зараз помилятись. А об'єкт створюється з самого початку застосунку і використовується протягом усього його життя. А хоча ні, напевно, він створюється лише тоді, коли до нього звертаються і вже живе на протягом

Speaker A

всього життя застосунку. О, так, напевно. Ну да, да. Отак правильно. Ну, в цілому ти правильно сказав, да, типа ось типа їхня головна різниця.

Speaker A

Вадим, що таке midleвеare? О, це напевно питання, яке от я напевно не дам зараз відповідь. Я ось якраз midleвеare трохи погано погано в цьому орієнтуюсь.

Speaker A

А тут ее відповідь, що може Маша, Маша, може ти пам'ятаєш відповідь? Та це такий ніби пайплайн, через який проходять реквести.

Speaker A

По суті, це Chain of Responsibility pattern. Десь всього ти таке казав. Він тримає в собі HTP контекст.

Speaker A

Вони працюють як конвеєр, що дозволяє розділити опробку запиту на незалежні частини. І також треба в правильному порядку задаватиле. Да, по суті, midleвер - це шматочки коду, якіпляють запит HTTP в певному порядку і дозволяють виконувати над ним певні операції ще до виконання

Speaker A

конкретно самогопоінта аі. А можливо, Вадим, ти пам'ятаєш фільтри і екшени, що це таке? Ее, ще раз. Фільтр і фільтр і екшн, да?

Speaker A

Ну, тут не буду, не буду видумувати, не зможу дати відповідь. Ну, типа action - це по суті наш end point, який повертає якийсь, наприклад, action result. А по суті це може бути котролер або minimal app і вже логіка в

Speaker A

ньому. А фільтр - це код, який ее виконується або перед екшеном, або після, і дозволяє додати там певну логіку.

Speaker A

Наприклад, там, не знаю, логувати кожен реквест або там кожен респонс. Ну, ви цим не, скажемо так, не робіть такого. Я один раз зробив на проекті, коли був з Дженом і нам прилетів чек на 1000 євро за за ніч, тому що логував кожен запит.

Speaker A

Але, ну, типа, в цілому можна таке зробити. Е-е, там і там був методи он чи, наприклад, відновлювати exception, наприклад, після після якогось методу специфічним чином. Але для цього, якщо що, в світлих версіях доnetту є i exception handler, який ви можете

Speaker A

реалізувати, щоб зробити глобальний exception handler. Окей. М Ілья, питання е тобі, е, теж по SP.net corруu щось таке. Меня ні, давай по апі, по HTTP.

Speaker A

[музика] Які HTTP методи ти знаєш і для чого вони потрібні? Для чого вони використовується в контексті restful API? Уточнення.

Speaker A

Угу. Ну, есть запроси get, delete, put, patch. Такі є. Патч. І забув самий головний, самий улюблений у всіх пост.

Speaker A

А пост, да, і операції по суті. Ну да. От можеш типу теж заєжене питання постпу пач. Яка між ними різниця?

Speaker A

Скажемо так, технічно по факту наче нема, а семантично. Ну простото мы делаем create какого-то объекта. Угу.

Speaker A

Мы его полностью обновляем. А патч так моментами то що прям деталь детально хотів какую-то детальку. Пос створює пут повністю пачково.

Speaker A

Денис, ти хочеш додати чи спитати? А іти іти. Тому що є такий технічний нюанс. А наче а пост ми можемо, якщо його виконанемо другий раз, то дія виконається і, тобто щось зробить. Якщо ми пут зробимо другий раз, то наче це ніякого впливу не буде

Speaker A

мати. Це називається ідемпотентність. І ти можеш зробити і ти можеш зробити і інпотентний пост, наприклад. Це актуально в банківських системах і так далі. І це можна по-різному реалізовувати, але про це не знаю, чи є сенс зараз поговорити. Ну,

Speaker A

точніше можна поговорити, але давайте заїжджені питання поки пройдемо. А, окей. А, Влад, як ти розумієш, що таке?

Speaker A

Да, от ми згадали REST в API. Що таке REST? О, это как архитектурный стиль, методология по работе между по взаимосвязи между сервером, клиентом, ну, используя HTTP запросы.

Speaker A

Якось так. Окей. А які ти там, можливо, підходи, характеристики пам'ятаєш? Там можуть під Да, ти вже там згадав client server. Ще можу дати підсказку там stateless.

Speaker A

Ну, это то, що нам не надо сохранять состояние объектов. Там каждый HTP запрос то есть он передал информацию, допустим, на клиента и забыл о нём. Ну, как-то так.

Speaker A

Да. Да. А ще там якісь принципи пам'ятаєш окрім цього? А ні, особо. Ну, там є casability, ability, ось такі речі. Це я насправді теж все в голові не тримаю, але раптом вас можуть душити. А самі душні питання, це

Speaker A

maturity model, типа, як ви проектуєте рести. Але, чесно, я за за всі там роки кар'єри один раз тільки спілкувався про це з чуваком, який душнився про це все на всіх на сабесах, а я сам, ну, скажемо так, не сильно це типа якось вінка якось

Speaker A

розібрався, почитав, що таке є. Це типа як наскільки у вас зріле проектування вашої там апішки саме ре в ресті, да? Бо ми там оперуємо нашими сучностями як ресурсами, да, і ми по суті оперуємо над ними з використанням круто операції, яку

Speaker A

ми реалізовуємо методами, да, там було типа app, е, наприклад, post app/users значить, що має створитись user з семантикиста, да, і там от вуніку вам розповідали, но я універ я я скіпнув це от по суті. Ну окей. Це головне, що ти розумієш, що це не

Speaker A

протокол, а підхід до проектування, типа по суті підхід, філософія і так далі. Ну протокол, да, там состор правил, да. Ну і HTP протокол, TCP протокол. До речі, Стас, душне питання. І різниця між HTTP протоколом і TCP протоколом.

Speaker A

[музика] HTTP. Зачекайте зачекайте. TCP - це випадково не на рівень нижче протоколу, ніж HTP.

Speaker A

Ну, невипадково. А, а свідомо. Ну, свідомо. Ну, це типу оця модель OSI, де це все розписано, що спочатку йдеться через HTTP, а потім це під якщо підкопати нижче, це буде TCP.

Speaker A

Ну да, по суті, TTP - це глибший HTTP - це application layer протокол, якщо ми говоримо про Ось модель, а TCP - це transporter layer. І HTTP тримає під собою там в залежності від версії або кожен раз відкриває TCP, е, скажемо так,

Speaker A

з'єднання закриває, або тримає його відкритим. А ви TP3 воно використовує UDP наскільки? Але це Ну це А це не вебсокети випадково UDP?

Speaker A

Ні, UDP - це не вебсокети. UDP - це протокол, який не гарантує доставки. Е-е, ну так воно ж в сокетах використовується. Він за цей швидкий доволі хіба ні.

Speaker A

А, ну тут я можу, до речі, вебсокети. Ну, можливо, да, можливо. Е, я тут, на жаль, кстати, не підскажу. Можливо, забув.

Speaker A

А типу, але це в HTP3, це там, по-моєму, Google їх реалізував. Він там по-своєму, як вони називаються. І вони гарантію реалізували на аліcкейшлейрі саме типа в цьому UDP, тобто хоч там UDP, але доставка типа аля контролюється, але це вам не на джуна

Speaker A

точно необхідно. Це скоріше так, якщо таке десь типа з кимось поспілкуватись, це вас скоріше спитають просто про ваш рівень е-е освіти, скажемо так. Ну, по апішкам, бачите, дуже швидко пройшли це самі базові питання. Не бачу сенсу там сильно

Speaker A

задрачувати людину, типа про краще дати практику або лайкоінг, щоб людина накидала ее щось. Ми про це далі ще поговоримо. Бази даних. Ну, нарешті, але до того, як дійти до баз даних, Entity Framework, Денис, Entity Framework. Що таке, що таке

Speaker A

взагалі Entity Framework? Давай ось таке питання. А, ну м це object, е-е, о, господи, це ORM, тобто object relation mapping, а-а, який дозволяє обовзя прости простою мовою працювати а з базою даних та та з таблицями як суб'єктами. Тобто

Speaker A

наприклад є таблиця, наприклад, є таблиця людей і NTфorк дозволяє кожен кожен ядок таблиці просто представити як клас, як сутність.

Speaker A

Ну так можна можна без прикладів. Ти правильно сказав, да? Щоб ми далі йшли. Окей. Entity фреймворкумка. Хорошо.

Speaker A

Вадим, питання тобі. Дивись, типа, ти коли з Entity фреймворком працюєш, ти по суті можеш використовувати методи linkq і вони схожі на синтаксис стіква та SQL типа language. І отут питання, мож воно трішки з зірочкою, напевно, але чи знаєш ти, яким чином от

Speaker A

ти, коли пишеш там тока ver, select і так далі, яким чином воно переводить оцей код зшарпу в запит до бази даних в sequel?

Speaker A

Тобто, коли ми використовуємо лінки в для операції над нашими над БД. Угу. Ну, тут можна, ну, там, та там, здається, там якийсь от там є такий складніший більш, ну, якийсь є певний от спеціальний процес, який власне і ось умовно

Speaker A

переводить ці наші в запити лінків в SQL. Ее і якщо не помиляюсь, це називається Expression 3. Все, я таке чув, але ось і там є якийсь ще спеціальний інтерфейс для цього, але я не згадаю. Expression 3. В принципі, цього відповіді достатньо.

Speaker A

Воно типу вміє звертатись просто по назві полів, по назві там класу. Воно може будувати кварю. І власне через цей expression drept framework не завжди будує ефективні квері. Типу іноді доводиться писати щось ру ручками, да? Ну, типа ці через ада.

Speaker A

Та через процедуру, через ада, там що хочеш можна використовувати. Е-е, да. Окей. Хорошо. А-а, Маша, питання тобі. Є такий інтерфейс Iqueriable контекст entity фреймворку. А можеш розказати в чому його прикол?

Speaker A

Ну, завдяки ньому можна робити відкладені запити до бази даних. Будувати, наприклад, за якимись умовами вери щось робити. І потім, коли, наприклад зробимо Боже як називається, каунту ліса с, наприклад, зробимо і так далі, то у нас відбудеться запит.

Speaker A

М, да. Коли відбудеться запит, коли нам ці дані вже необхідні в оперативній пам'яті. Угу.

Speaker A

Да. А м окей. Да, в цілому ти правильно сказала, що типу коли там to list або там count і так далі відбувається. Хорошо.

Speaker A

Е-е, Ілья, питання тобі. М-м, що таке там lazy loading в NC фреймворку? Ну, это не похоже на Yн.

Speaker A

Ну, не знаю, що для тебе схоже, типу, але ее типа давай так підска я підскажу, це пов'язано з джойнами, підгрузкою даних і так далі. Можливо, в цей бік тебе щось нагадає?

Speaker A

Не, к сожалению. Дивіться, типу ми Ну давай, Денис, якщо ти знаєш відповідь, кажи вже ти так активнічаєш вже. Денис, ти перший був там.

Speaker A

А наче Ігор одінг, тобто це в тому сенсі, що у нас дані, тобто сутності таблиць відразу підвантажуються і в майбутньому, наприклад, до них легше звертатись, це менш затратно. В Entity Framework це реалізується наче за допомогою Include методу. Вот. Алоading,

Speaker A

ну це за замовчуванням справа цьобою, за допомогою Express NT, Iquariable інтерфейсу і внутрішніх механізмів.

Speaker A

Тобто, ну, по-моєму, ти трішечки трішечки не зовсім. Так, Вадім, який в тебе варіант відповіді? Зараз скомпілюємо з вами відповідь.

Speaker A

Тобто я трохи цей щось завтикав, не почув чесно, що Денис відповів, але взагалом, ну, laading - це коли ми в момент запиту не завантажуємо сутності з таблиці інші. І тому якісь сутності, з якими у нас є relation.

Speaker A

Давай уточнимо. Ось так. Так. Ну, тобто в реаліційній базі даних є зв'язки і ми їх не завантажуємо. Через що, коли ми починаємо над цими даними оперувати, працювати, ми мусимо їх дозавантажити і це значно сповільнює наш наш операції над ними. Наприклад, якщо

Speaker A

ми отримали якийсь список чогось там, я не знаю, машин і хочемо там подивитися їх власників, то нас за ко на наш кожний запит, ні, на кожну нашу операцію над кожним кожною машиною нам потрібно буде довантажувати окремо її власника. І це дуже повільно. Тому в

Speaker A

такому випадку краще робити ірлодінг, який одразу завантажує ці зв'язані сутності, да? І раз ти, да? І питання, дивись, у тебе є машина і в неї є користувач, типа там юзер, хай там буде якийсь, типа, ні користувач, оу, ну давай так, оунер,

Speaker A

власник і власник. І питання, чи потрібно тобі робити include для того, щоб підгрузити ці дані? Якщо тобі просто потрібно прописати ее умову, типа, дивись, ти цього Оунера ніяк не підтягуєш потім в оперативну пам'ять, але тобі потрібно по оунеру

Speaker A

пофільтрувати, наприклад, де owner ID дорівнює, не давай не owner ID, а owner точка fone number contains такий-то номер.

Speaker A

Ну, виходить, там потрібно мати дані цього юзера, тому треба Ні, воно це робить під капотом. Без інклюда можна це зробити. Ну, типу, якщо ти прописуєш include, типа в цілому, е, не сильно щось поміняється, але, типа, наскільки я пам'ятаю, але тут

Speaker A

питання, як воно побудує квирю, можливо, воно більше даних підтягне, чим потрібно. Це я от тобі от я зараз подумав про це, але в цілому тобі інклю не потрібно робити і верце і спрацює і він буде ефективним.

Speaker A

Ну да, типу, ну мене часто типу поправляють, тому що я люблю явно речі прописувати в колі. Мене типа пінають мої колеги, типу аля, нахера треба, якщо вер там спрацює? Я просто не люблю, коли в коді є якась implicit поведінка.

Speaker A

Давай, Денис, ти що ти хочеш додати? А наче як наче черезг, якщо у нас типу відбувається в циклі, то у нас SQL запит буде створюватись при кожній ітерації.

Speaker A

Навіть це якщо простий там select, а при Ну то там буде N + 1, там по-моєму цей N + 1 problem чи якось так воно називається.

Speaker A

А да, хорошо. Чи каже за допомогою Include. А за допомогою Include якраз, ну, ітераці не буду кожного разу ще виконуватись, да? Окей, хорошо. Ідемо далі. А то этот Влад і Стас скучает там. Да, да, Влад, в свому ми тут це вгадали.

Speaker A

Давай так, типа, я не буду ка питати вас про оптимізацію фреймворку, вам це не супер обов'язково знати, але от можливо ти знаєш, що таке noтacking в NT фреймворку.

Speaker A

А це коли ми отключаємо моніторинг с орки скора и она явно не будет отслеживать сущности.

Speaker A

Ну, если надо прочитать, то можно отключить стерики. Ну да, це це, по-перше, оптимізує кварю. Плюс це гарантує, що це буде саме останнє значення з бази, бо у вас можуть виникати приколи, що Entity Framework не те що кешує, а може

Speaker A

тримати в оперативній пам'яті е-е дані, які, наприклад, там ще не були збережені. Короче, неактуальні, скажемо так, дані. Я з такими проблемами, наприклад, в юніттестах стикався чи в інтеграційних тестах. В інтеграційних тестах.

Speaker A

Угу. О, окей. Ну, понти фреймворку в цілому все. Типу теж тут нема чого такого вас мучить. Типа хіба що вам дати Linkq пописати якесь про оптимізації типа SPIT qu і так далі. Не дуже думаю, що треба вас питати, хоча ви можете це знати в

Speaker A

цілому. Можуть на співбесідах про таке підняти мову. Але давайте до БДшок. Стас, що таке реляційні бази даних?

Speaker A

Реляційні бази даних - це такі бази даних, які будуються на основі даних, які пов'язані між собою. Вони структуровані, е, і зберігаються для нас як на вигляд в табличках, але вони просто, ну, зв'язані між собою, на відміну від нових СQL, де вони всі

Speaker A

динамічно, неструктуровано лежать. Просто ти згадав no sequel. А в якому вигляді вони там можуть лежати? В нереляці.

Speaker A

Ну, на окосон. завжди. Ну, я з монго лише працював, то я більше. В цілому це можуть бути документно орієнтовані як монгоo DB, може бути key value, як redis, може бути векторна база даних. Це, наприклад, для всяких аіллемок використовується і так далі.

Speaker A

Може бути графовал буде, да, графова. Це може бути для соцмереж, наприклад. Це теж може бути no sequel.

Speaker A

Ось типа як приклади. Але раз згадав, знаєш, круто. Але типа на джуна на Сішарпі я би говорив тільки про реляційки. Хіба що спитати просто різницю, чи читала людина. Якби скажемо, якщо людина там взагалі не цікавилась, це теж показник, що ну якби

Speaker A

аля типа просто зацікавленості людині в індустрії, типу наскільки вона буде ініціативна, наприклад, на роботі.

Speaker A

Ну, це щоб просто розповісти, щоб показати, що є не тільки отакий якись бази, щоб можна було привести приклад.

Speaker A

Денис, от у нас є рейшншипи типу one to one, one to many між таблицями, man to many, да? А воно реалізується завдяки типа там, давай так, точніше розкажи ти, як воно реалізовується, за рахунок чого?

Speaker A

А воно з, ну, воно реалізується за допомогою первинних та зовнішніх ключів. Тобто, умовно кажучи, там м я там є сутність людина, є сутність метадані.

Speaker A

І, наприклад, я маю індекс і в своїй таблиці в таблиці людина. Е, впевнений, що ти оперуєш індексом, а не foren key чи primary ke?

Speaker A

Ну, primма, ну, primary ke, да, да, да. Я вибачте тут можуть задушити тебе. Праки не завжди можуть бути кластерним індексом.

Speaker A

Про цей про індекси ми ще поговоримо. Не завжди це може бути і строка, ім'я, наприклад. Тобто Так. А, а чому не може строка бути? Е, і строка теж може бути. колонка типу warрchar або warchr може мати індекс на

Speaker A

собі. Давай не не топи себе. Ну, типу точніше, як це я тебе зараз типу потралівию трішки але давай от primary for key ти правильно почав. Типу в нас є е давай так. Primary key, що це таке? І forign key, що це

Speaker A

таке? Прайма, які це, образно кажучи, ідентифікатор сутності. А кожна сутність має, ну, кожна сутність має первинний ключ, тобто унікальне значення, за якою воно ідентифікується.

Speaker A

А зовнішній ключ - це, можна так сказати, посилання на первинний ключ іншої сутності. Тобто за допомогою цього істори зв'язок.

Speaker A

Да. Окей. Е, питання, як реалізовується many to many? To many м [музика] приклад, наприклад, навести конкретний приклад чи, ну, є один з підходів, який можна сходу сказати.

Speaker A

Ну, ну, наприклад, тобі дали задачку. Це наприклад а люди можуть там, наприклад, люди можуть створити сутність parent і сутність childд. І одного чайлда може бути багато парентів.

Speaker A

Ну, умовно їх може бути всього два. Ну, давай уявимо, що ми в супертолерантному суспільстві, де може бути оди батько один, батькодва, батькотри, чи там парент один, парент 2, парентри. Ми ми в майбутньому, ми в 2000 там 75му році.

Speaker A

І от як би ти це реалізував, цю цей зв'язок? Ну, насправді, я завжди створював його, ну, скажімо так, вже нормалізованим за допомогою створення додаткової сутності.

Speaker A

Ой, ну, нормалізованим. Ну, тобто, наприклад, нехай буде сутність там, яка буде зватись par and Child і нехай вона в собі, наприклад, ну то ти ж то от оце твоя це проміжна таблиця називається. От твоя от твоя відповідь.

Speaker A

Тобто в цілому це правильно. Ну і ти згадав ще нормалізації, що є в базі. Що ти про це знаєш? Давай от Вадим, Вадиму питання.

Speaker A

Не треба описувати прям всіх приколів нормальних форм. Можеш просто сказати, що це таке і до якої нормальної форми можна стремиться в базах даних.

Speaker A

Е-е, ну, значить, нормалізація - це от з виключити надлишковість даних, щоб в нас було тільки ті дані, які нам потрібні, щоб не вони не бу не дублювалися.

Speaker A

Угу. Ее, ну і я не знаю, якісь там може усунути можливі проблеми при операціями над даними, тобто там додавання, модифікація, видалення, ну, уникнення дублікаців, да, покращення, да, ну, казав про дублювання, так.

Speaker A

Е, ну, і загалом ціль якби, щоб було легше працювати з батою даних, тобто обслуговувати і по краю.

Speaker A

Окей. Ну, і видавати дані. А до якої нормальної форми треба зазвичай стремяться або радять стреміться?

Speaker A

Ну, до третьої, типа, їх там насправді більше, ніж три, але типа в цілому, якщо ти до третьої доходиш, ти красавчик.

Speaker A

А все, да, я я зрозумів про що. Так, так, все, все, я поняв. Так, до третьої, да?

Speaker A

Окей. А, Маша, питання тобі. Е-е, я роблю запит на табличку і роблю умову по, е-е, наприклад, там по якомусь полю.

Speaker A

Я постійно роблю вер по ньому. Ну, і це не індекс, це не індекс, це не там, ой, не індекс, сорі, не primary key, не foring key.

Speaker A

А яким чином можна? І в мене ця кваря працює не так швидко, як хотілось би. Як я можу покращити перформанс цієї квирі?

Speaker A

Мм. Даже не знаю. Ну, я взагалі одне слово сказав і спчай спойлернув, але ти походу вже втомилась і не почула.

Speaker A

Мабуть, не скажу. Підсказка. Операция на чтение. Це селект. А, селек, да, точно вибірка. Не згадаєш, да?

Speaker A

Ну, а розказати, як він працює? Нет. Як покращити перформанс цього селекта? Е, селекто індекс додати.

Speaker A

А індекс? По може ти от просто, може ти забула, може ти розкажеш просто, що таке індекс тоді, якщо ти просто забула.

Speaker A

А, ну існує кластерні, не кластерні і а все зрозуміло. От в цьому випадку на читання краще використати не кластерний індекс. Кластерний може бути один тапис, у некластерних може бути декілька.

Speaker A

некластерні використовуються для, ну, підвищення перформансу читання з бази, але при цьому вони впливають на запис, бо, е, кожен індекс лежить у файлі окремо і коли додаються дані, то цей файл заново перестворюється. Тому найкраще їх використовувати та для таблиць, які

Speaker A

часто читаються, але не часто пишуться. Угу. Також структура цього файлу - це бедево. Не завжди, але по дефолту, да, по ну ще буває вроде координат, щось ш ще може бути, да?

Speaker A

Окей, да. Ну, в цілому правильно, да, що типа кластерний індекс один на табличку - це фізичне сортування таблички. І на кластерни їх може бути декілька. І це окремі файли, які там під собою колекція, структура даних бедерево.

Speaker A

І складність пошуку не стається логарифму по основі 2 в Да. Да. А банері 3 чи B + 3 а залежить типа від там в різних базах, по-моєму, наскільки пам'ятаю, по-різному може бути, типа я не пам'ятаю, по-моєму, в позросі

Speaker A

все-таки Binary 3 використовується. Я більше з погресом працюю. А, але можу теж, типа, там треба згадати, типа, в цілому, знаєш, то уточнитися.

Speaker A

Можливо, хтось з вас читав нещодавно документацію, бо я туди недавно не заглядав. Окей, хорошо. Ілья, питання тобі. Чи чув ти про таку штуку, як каптеорема?

Speaker A

Тільки не плутай one cup. Я не почув все одно. А кап теорема, що таке?

Speaker A

Ага, кап теорема. Ні, не чув. А можливо, Влад, ти чув? Ну там суть в том, что из вот этих трёх показателей мы можем обеспечить только два. То есть там будет, скажем так, надо будет находить компромисс между целостностью данных и

Speaker A

скоростью выполнения транзакций. Ну, в принципе, скорость работы базы данных. Ну, ця теорема означає, що, наприклад, там база даних може реалізувати тільки одну дві з трьох букв, і вони розшифровуються як і consistency, availability і partition tolerance.

Speaker A

Типа там Partition Tolerance - це можливість скейлити базу горизонтальну. Це для джунів не супер типа, скажемо так, актуально. Ви навряд чи цим будемо займатись на своїх там проектах. AVABIL - це про доступність даних. А в тому плані, що, наприклад, база не уходить на

Speaker A

підтримку або не лочиться, поки дані, наприклад, між собою синхронізуються. А, да. А консистентність даних - це м про те, що е, наприклад, коли дані оновлюються, то вони на всіх нодах, бо там всіх інстансах мають бути типа однаково оновлені. Е, то

Speaker A

бунетичность, да, щоб не було такого, що на сервере, на европейськом сервере я Дмитро, а на і американськом сервері в мене там старий к нікнейм у мене був раніше в дитинстві Діма Асаas.

Speaker A

В мене пошта так називалась. То от, наприклад, щоб таких таких приколів не було. Окей. Ілья, а можливо ти пам'ятаєш, знаєш, що таке транзакція?

Speaker A

Ну да, по суті знаю. Можеш розказати, що це таке? Сейчас сформулирую. Ну, есть даже AC такие правила.

Speaker A

Ну, можна про AC, да, поговорити, якщо ти хочеш. Ну отма, господи, да, от транзакции получается это когда у нас два исходных варианта. У нас или там всё загружается в базу, или ничего.

Speaker A

Если какая-то бук, ну да, тут типа всі операції або стались, або не стались. Нема проміжно проміжного якогось результату, да?

Speaker A

Окей. Угу. Далі давай. Ну, м скоріше я би і від цього слова і описував, що таке транзакція, да? Це по суті якась атомарна ее операція над базою даних, яка якимось чином видозмінює дані і вона або сталась, або ні. Наприклад, я би так

Speaker A

якось би це назвав, якщо своїми словами. Е, ну, а раз ти згадав ACIT, можеш розшифрувати просто всі букви. Аміститі ми сказали ще три шифрувать, наверное, я не смогу.

Speaker A

Consistency, isolation і durability. Consistency, це ми обговорили, що типа якщо зміни відбулись, то вони видні для всіх. Isolation - це про те, що транзакції в залежності від рівня ізоляції транзакції певним чином ізольовані один від одного. Аability, що ваша транзакція не захерачить базу, що

Speaker A

вона вас не приляже. В цілому A на джуна треба знати базу, розуміти, що це таке є, що це певні типа характеристики транзакційних баз даних, так називаємих, типа all up.

Speaker A

Але прям типа здращуваться, як на мене, ну, типа на джуна корисно, але не прямо обов'язково.

Speaker A

І давайте там, в принципі, теж базові питання пройшли, але от Стас один у нас там залишився. Рівні ізоляції транзакції. Чи можеш ти от сказати, що це таке, Стас, е, і можливо пояснити ее різни типа як працює дефолтний рівень

Speaker A

ізоляції транзакцій і який він? Ну, це в плані пролоків, що е ці дані локаються і не можуть бути більше ніким змінюватись, поки транзакція не пройде.

Speaker A

Є row level, ее, є рівні ізоляції транзакції, тобто є різні приколи. Я оптимісткмістиклоки, але я не хочу поки що з вами про це говорити. Ну, типа, якось це вже трішечки, ну, на джуна якось це окіл, як мені здається, особливо без досвіду.

Speaker A

Ну, важкуватові навіть рівня ізоляції транзакції це душно трішки. Ну, давайте розкажу, раз я це підняв питання, якщо ти не готова відповідати.

Speaker A

е-е типа бази, типа ви можете робити операції над базами даних паралельно, типу одночасно підключитись з різних потоків, з різних серверів і міняти там дані. Відповідно транзакції можуть відбуватись певним чином, типа паралельно. Відповідно, ми можемо налаштовувати рівень ізоляції транзакцій, що значить, що транзакції

Speaker A

в залежності від цих налаштувань по-різному бачать результати роботи інших транзакцій. І є там зазвичай чотири рівня.

Speaker A

Наприклад, там в позрисі їх по суті три, але теж типа в документації навіть не розписано чотири. А read committed, read committed, repeatable read і seralizable.

Speaker A

Як вони працюють? Rн commit типа самий не стрікт, самий, скажемо так, свободний рівень ізоляції транзакцій. Це значить, що коли виконуються дві паралельних транзакції, одна транзакція може бу може бачити результати виконанні іншої транзакції, яка ще не за не за кінчилась, яка ще не

Speaker A

закомітилась. Це тіпа максимально класний перформанс, але при цьому може бути проблема, що транзакція один побачила зміни транзакції 2, а потім транзакція два відкатилась, бо завалилась, а транзакція один бачить зміни, які ее типа сталися, але потім були зарулбечені.

Speaker A

Це типа там є проблема, називаються dirty readт phantom readт і так далі. Я там не згадаю всі їх назви, але от типу я вам описую ке станеться. Тому цей рівень ізоляції там не практично не використовується. Або там, якщо вам

Speaker A

потрібно супер-пупер performance перформанс і вам пофіг на а ось ці типа приколи з даними. Дефолтний рівень - це read committed. Це транзакції, які виконуються паралельно, бачать результати виконання інших транзакцій, які були закомічені, тобто були збережені в базу.

Speaker A

Далі repeatable read. Транзакції бачать результати результати закомічених транзакції, які були виконані до початку цієї транзакції. Не під час, а до початку. А seralizable, якщо говорити утрірована, воно аля е заставляє транзакції бути виконаними синхронно, типу одна за одною. Але

Speaker A

насправді це трішечки не так. Наприклад, позраз він дозволяє використовувати він воно виконає їх паралельно, але во але воно використає свою внутрішню систему для того, щоб затрекати, що ці зміни не пересікають один одного. Тобто, якщо вони не пересікаються, то воно типа

Speaker A

збережеться нормально. Але якщо воно бачить, що типа одна транзакція змінила о там ровчик з адішником один, інша транзакція теж, воно викине excepпtion, ну типа помилку, що типу сорі, ти не можеш так зробити, там якось realizable eror чи щось так типа такого. Тобто вони

Speaker A

не будуть виконані синхронно, вони виконаються паралельно, але вони не збережуться. Там цей паттерн е-е MVVC чи щось таке типа називається там. Я точно не, я колись читав про це, але в цілому оцей патерн, воно просто трекає стан тих

Speaker A

ровщиків в базі, які змінились. Якщо вам це було корисно, я не знаю навіщо це на співбесіді розповідати, тим паче на джуніф, але тепер ви це знаєте.

Speaker A

Так, бази даних все. А на співбесіді я би ще спитав людину, чи налаштовувала вона GitHub Actions хоча би базово, чи якийсь CCD, хоча би просто бачила його, ну, типу умовно Ямлік якийсь писала чи GitHub Action залаштовувала. І ще би спитав, чи

Speaker A

користувалась людина ажуром, хоча би зареєструвалась, відкривала консольку, ну, чи будь-який інший cloudд, чи якось деплоїла свій застосунок на оточення?

Speaker A

Я зараз не буду це покривати, що ми зробили задачку, але в цілому я раджу джунам один раз налаштуватися CD чат GPT берете, за два дня налаштуєте, все у вас буде льотати. І в ажур задеплоїти, чи в чи в GCP, чи в будь-який інший клаунт,

Speaker A

свою апку задеплоїти, щоб побачити, як цей процес відбувається. Бажано з використанням докера, контейнеризації і так далі, типа аля, сучасні технології і так далі. Тому що якби цей практичний досвід дозволить вам виділятись на співбесідах і це типа супер класно.

Speaker A

Питати вас не буду. І так мені кажеться ми ду задушнілі. Зараз будемо рішати задачку. Але яким чином ми будемо її рішати? А я вам зараз покажу код. Денис, тобі ти не радуйшся, тому що ти будеш рішати перший, бо ти в

Speaker A

мене перший в черзі. В тебе не буде часу подивитись е-е сильно на задачку. У всіх інших буде. І я вам в чому буде суть задачки? Я буду показувати шматок шматки коду, які нам потрібно буде порефакторити і ви маєте сказати, що в

Speaker A

ньому не так, щоби ви покращили. Це такий простенький вид лайфкоінгу, про який я розповідав на ефірах. І як на мене, це гарний показник, щоб типу, бо ці всі відповіді, що ми пройшли, їх можна завчити. Я не сильно вамлявся в

Speaker A

якусь практику, але зараз буде вже більше практика. Я вам пошарю екран. Е-е код. Вам має бути видно зараз.

Speaker A

Це пофіг. Видно вам код чи ні? Так. Да. Е-е, оп, що тут? Я згенерувався чатом GPT, тому ні, скажемо так, не сидіть строго.

Speaker A

В чому суть? У нас є е-е задачка з не задачка, у нас є застосунок з двомапоінтами, які е-е має управляти список-дулістом, да, самий базовий заєний петпроект. Там у всіх таке є. І тут є двапонти.

Speaker A

І є DB контекст, який зберігає ці тудушки. Є описана моделька цієї тудушки. А подивіться, я от зараз отак от ось так от зроблю. В принципі, тут більшу частину коду видно. Тут просто два поля.

Speaker A

Title is done. Більшу частину коду тут видно. Подивіться пару хвилиночок, що вам тут подобається, не подобається.

Speaker A

І ми зараз спробуємо порефакторити. Типа тут у мене нема виписаного списку, що тут не так, що тут так. Типа я хочу послухати ваші коментарі. Тобто максимальний freм.

Speaker A

прийнятті рішень, але я буду вам показувати конкретні участки кода, що де не так, і буду вам коментувати, буду намагатись распределить між нагрузку между вами равномерно, але, ну, якщо цього не вийде, то, ну, типа, сорі, як мінімум, це все буде, всім буде корисно.

Speaker A

Відповідно, Денис, ти у мене перший. Всі, ви вже всі подивились, да, вже типа зрозуміли контекст.

Speaker A

Окей. Мені починати чи от давай, Денис, я тобі буду показувати участки, щоб ти не все на себе забирав, да, і ти будеш А, а, окей, окей.

Speaker A

Да, давай почнемо, напевно, з гета або якщо хочеш з А, типа, оцей участок дивимось.

Speaker A

Ну, типа, дивіться, синтаксично тут нема помилок, типа, навіть якщо вони десь тут виникнуть, їх нема. Тобто помилки в кодстайлі можуть бути в ООП підходах, використанні фішок дотнету, проектуванні і так далі.

Speaker A

Тобто синтаксично тут не про це не думайте. От давай. Добре. Тоді мені можна починати, да? Можеш починати. Я тебе переб'ю, якщо захочу перейти до наступного типу кандидата.

Speaker A

Добре. По-перше, е-е, ну, ту toду DB контекст, він повинен інжектитись, тому що створювати йому його при кожному запиті ЦК.

Speaker A

А-а, ну, а чого? А він із Dependency інжекна буде тоже створюватись при кожному запиті?

Speaker A

Ну, він буде створюватись, але я насправді в цю тему не дуже вникав, але мені здається, що якщо ми створимо, будемо постійно створювати копію, то ми буде можемо за різними даними в той працювати. Ну, це може створити конфлікти певні логічні. Ну, DBEК не є,

Speaker A

да, але в цілому, типа, ти правильно кажеш, щоб ми мувнулиi, тому що, наприклад, він то взагалі адисposeable, то треба ще using на ньому залізати, а DI це зробить автоматично. Тому це правильно. Окей. І ми його прокинемо там умовно сюди. Окей.

Speaker A

Угу. Хорошо. Е, давай далі. Що ще можеш прокоментувати? А я бачу, що, ну, знову ж таки, у нас тут є звернення напряму до DB контексту, а DB to do to list. А я б це завернув в repasто і паттерна окремо.

Speaker A

А, ну, знову, щоб обмежити м доступ до DV контексту, тобто до бази даних. І, ну, це, в принципі, без практис.

Speaker A

А чому це без практиса? Тому що, якщо ми можемо, якщо ми будемо напряму звертатись, то а це ризики.

Speaker A

Ризики. Ну, ми напряму, можна сказати, ми напряму звертаємось до даних. Просто напряму через код.

Speaker A

Чому напряму? У нас контекст по суті є обртка над даними, типа. І знаю безліч кейсів, наприклад, на моєму проекті, де ми не використовуємо репозиторій і нормально живемо. А, ну, не обов'язково використовувати репозиторії, але, наприклад, той же DB DB контекст, цей

Speaker A

клас, він містить купу методів, має багато можливостей. А якщо ми створимо репозиторії, то це буде, ну, так виражає виражаючись фасад над великою системою.

Speaker A

Е, ти правий в плані інкапсуляції. І гарно на співвесці сказати, що репозиторій дозволяє абстрагуватись від реалізації дата стореджу, тому що в репозиторії у вас може бути не тільки DB контекст всередині і підвищити тестабіліті вашої системи, тому що можна

Speaker A

тіпа зробити інтерфейс для репозиторія, який легко замокати в тестах. Легше, ніж DB. А, ну да, да. Testability, да.

Speaker A

Хорошо. Репозиторії. Хороший зауваження. Що ще? А потім я бачу в нас звернення до Jonalizer.

Speaker A

Realiz виніс в окремий сервіс і тоже в ну Inject через dependency injection. Ну а ти впевнений, що нам взагалі стерилізація потрібна?

Speaker A

А зараз items. Що таке items взагалі? Items якісь, ну, items - це тудушки. Дадада.

Speaker A

А-а, насправді з того, чи вона взагалі необхідна, я тут я в це по ну так глибоко не вникав і я тут не зможу повністю відповісти, але може вона і не потрібна, і може вона автоматично виконається.

Speaker A

Ну, в цілому we don't need типа explicit і we don't need seralization. О, так от напишу. Блін, курсор мені все портить.

Speaker A

Типа ми можемо просто завернути його в result, наприклад, як тут або на рівні типа там midleвеерів, фільтрів і так далі описати, як ці типа який об'єкт, який контракт має повертати Апі. Тому нам явно стерилізація тут не потрібна. Типа, вона тільки

Speaker A

ускладнює написання коду розробникам, типу простіше повернути просто items. Угу. А-а, от підсказку тобі даю. Тут може щось, щось не так.

Speaker A

А DP to do to list. А, а у мене є думка, що, ну, я можу помилятись, що вар тут не варто вказувати ціни проте.

Speaker A

В цілому можливо типа для кращого читання коду можна написати було, що це ліс тудушок, але в цілому це, ну, супер.

Speaker A

Я би не сказав, що це є проблемою. Ну давай, можливо, я спробую передати слово Вадіму далі. Ви там в чатіки не спойлеріть, будь ласка.

Speaker A

А Вадім, як ти думаєш, що тут не так може бути? Ну, я теж не знаю, що тут так. Ну, хіба може що в нас цей е ось там з Iqueriable ми повертаємо.

Speaker A

Ну, дивись, тут ми певні. Пам'ятаєш, ми з тобою говори ми говорили сьогодні про запити до мережі, до бази даних, які виходять поза межі застосунку.

Speaker A

І у нас ось тут щось типа чатік не треба писати зараз нічого. А можеш показати наші? Наші дус, як вони виглядають?

Speaker A

Дус - це DB сеetт. Це типа три поля. Ага. Ні, ну типу я ні, чесно, щось так не можу сказати зараз.

Speaker A

Денис, можливо додумався ти? Да, да, я навіть в чат написав. Це не воно зараз виконується не асинхронно, а ну і типу це тормозить систему.

Speaker A

Ну да, це блокуючий виклик. І виклик до бази даних краще робити асинхронним для того, щоб не блокувати потік цього запиту.

Speaker A

А і ще один типа make a sy call. Ее, до речі, хтось там писав: "Стас, return items може просто не спрацювати". А що ти маєш на увазі? Що типу аля воно не заверне його в action result?

Speaker A

Я маю на увазі, що можна просто item зробити і по ідеї воно має працювати.

Speaker A

Ну да, а ти про це? Да. Ну да, в цілому, да, да, да, ти правий, да. Окей. Make a call. Це ми додали.

Speaker A

Вадім, давай ще тебе помучую і більше не спаляріть в чаті, будь ласка, нічого. А дивись, підсказка. У нас тудушок може бути дохера в базі даних.

Speaker A

Навіть от ми тут зробили to list навіть типа зробили вже не блокуючи виклик. Як ти думаєш, типа в чому може бути проблема, якщо тут душек дохера, наприклад, 100 000?

Speaker A

Ну, буде довго виконувати запит. Можемо зробити пагінацію, якщо я не помиляюсь, так називається. Тобто по чуть-чуть, як це, не знаю, як це правильно так технічно розказати. Ну, якби не всі одразу отримувати, а так пачками. Пачками так по сторінкам, да.

Speaker A

Е-е, окей хорошо. І ми ще сьогодні згадували оптимізація Entity фреймворка. Можливо, ти пам'ятаєш? Так. Так. Можливо ще, оскільки ми тут тільки читаємо, можна виконати noтacking. No trakcking, да.

Speaker A

Окей, хорошо. Ну, бачите, скільки на одної строчки вже провтикав. Ще я би зробив би, якщо там цідужки, я би ще сказав на співбесіді, що можна додати user ID якийсь і проектувати, що повертати не тільки для якогось юзера або сюди якись

Speaker A

передавати qu параметри, по яким ми шукаємо цідужки. Але в цілому Pageation, ну там з головою достатньо для цього кейсу, бо немає якихось там бізнес-реваріментів на це. Також ее Анне також Вадім, можливо, ти знаєш штуку, спеціальну конструкцію, яка дозволяє отменять запити. Можливо, чув

Speaker A

чи використовував? Чесно, ні. Підсказка Concellation Token. Можна прокинути Concellation Token. М. Це дозволить з фронтенду, наприклад, там з клієнту отмініть запит.

Speaker A

А-а якщо він там, скажемо так, м типа захотіли ми його отмінить, тому що ми можемо тягнути зси багато даних навіть при Pagation. Concellation token це дозволить зробити, отменить. Це не прямо обов'язково знати, але я би це на співбесті сказав. Це непогано. Ну, в

Speaker A

цілому вже код виглядає покраще. Давайте, хто там у нас наступний? Ее, Маша. Угу. Ну, то вже мені А ще я вже дивлюсь на другий метод.

Speaker A

А ти вже дивишся другий. Але ще я би Пам'ятаєш, чим я всіх мучив? Не пишіть що-то там в тому-то місці.

Speaker A

Ну, я би шлях би ще звичайно би винесла в константу, бо він тут, ну, шлях константу окей, типа to constant теж типа в принципі непогана практика.

Speaker A

А move to const. Так, ми вже створили репозиторій, зробили репозиторії. Часто в контексті архітектури може бути [музика] що-то там слойов якихось, я не знаю, щось може в такий бік подумати.

Speaker A

Ой, Боже. Ну, я розумію, що ви втомились, але давайте вже доб'ємося. для цього би репозиторію би, понятне діло, інтерфейс би зробила.

Speaker A

Ні. Да, да. Injected interface. А оцю логіку, як ти думаєш? От давай я тобі під підсказку отдаю. Ось ось це все.

Speaker A

Куда? Ну, він вклі архітект, що він на рівень інфраструкча. Е, Денис, можеш не піднімати руку? Я тебе питати не буду, поки всіх не попитаю.

Speaker A

Ось логіка в мене була би в репозиторії. Взагалі було би все не так. Я би дивись ее м ти коли реалізовувала свої проекти, ти використовувала, напевно, Command Query Segregation або Nlayer архітектуру.

Speaker A

І чи писала ти там, як ти, в якому місці ти описувала логіку? Чи писала ти логіку всередині апішок?

Speaker A

Ні. От. І що це значить в контексті цієї задачки? що її всю треба винести в репозиторії і також так application layer services cqs всю логіку ми маємо це в нас presentation layer в застосунку і для того щоби і ми по суті у нас зараз ось цей метод

Speaker A

апішка залежить від імплементації ось цієї а Ми можемо зробити I to do сервіс, в який занести цю всю логіку і зробити окремий application layer. Це будь то там layer архітектура або command query segregation.

Speaker A

Отак от. Окей. Трішки тебе помучав. Давай якийсь ще один комент сюди і я далі з хлопцями піду.

Speaker A

Ну, тут SQL ін'єкція мені взагалі не подобається. Ого, да. А що таке injection? А, е, ну, туди ми можемо, вона дуже погано впливає, бо ми можемо все поламати туди. Будь-яка, людина може якісь неправильні дані зробити, ще щось і все поломати. прокинути запит якийсь і

Speaker A

зламати бдшку, там якийсь delete зробити або там дропнути щось, да? Це є sequel injection.

Speaker A

Окей. А як його побороть можна в контексті? Давай саме цього запиту. Е, за допомогою в репозиторії прописати метод, там де ми що додаємо tйтle.

Speaker A

Окей. Тобто винести тіпа контролювати параметри, які ми туди прокидуємо. Окей. Так. О, хорошо. Move to parameters. Це ми вже далі з хлопцями вирішимо. Move body to parameters. Param.

Speaker A

А далі хто нам? Іля. Як ми оце тіло, бачиш, ми зараз це тіло прокидуємо як строку по суті сюда.

Speaker A

Якось. Як ти думаєш, що окей це? Ну, это точно не окей. А как это пофиксить?

Speaker A

Сейчас подумаю. Підсказка. Вот у нас є тудушка наша. А сделать дтошку. О. Да. Да. Ну, чтобы она не работать, получается с entity, да?

Speaker A

Ну, щоб не було сикл інжекна і ми контролювали тіло запиту, а не будь-яке рандомне можна реч було прокинути.

Speaker A

Тимовнеш то і в тебе ось тут буде ось такий код туду ДТО. Якось так. І тут вже ти його опрацюєш і і зможеш відповідно ось тут use instead да?

Speaker A

Угу. що ще можна в цьому методі покращити? Ми от поки що контекст цього чувака говоримо.

Speaker A

Ну, в принципе, как и в предыдущем, бізнес-логику вынести. Ну да, слой. Окей. Да, и в принципе то же самое сделать, как-то отделить именно слой инфраструктуры, ну, который работает репозитория, да, то же самое, в принципе, сделать.

Speaker A

Окей. А-а, окей хорошо. А, напевно, іще одне, я бачу покращення. Можливо, якщо скажеш, то покращимо, якщо не скажеш, то підемо до наступного кандидата.

Speaker A

Ну, я вижу return, created и там. Ну, обычно created возвращают или прямо уже тело, которое создали, или просто как там 2011 статус кода, типа created и всё.

Speaker A

Ну, я би в цілому просто повернув би айдішку звідси, якщо нам потрібно потім якийсь редирек зробити.

Speaker A

А, ну да, или так вернуть то, что нам нас интересует. Ну, а вони, як я зрозумів, чат GPT хотів мені згенерувати, щоб ось тут був ось така типа айдішка сутності. І ти, типа, тут можеш при створенні запису в базі ти

Speaker A

получиш айдішку і типу повернеться, типа як road або просто айдішку. Можна бу ось так зробити. ID return created item ID. Всесь, давайте далі. У нас є що покращити ще тут. Можливо ось тут або можливо ще ось тут. І це питання до Влада.

Speaker A

Ну, как варіант. Вот эта вот строка в предыдущем методе DB Dattbase, execute SQL. Ага. Там же ж можу применить метод.

Speaker A

Ну вот ми вже написали типа entity framework, типа ми вже ти по суті це покращили, да? Ну те, що ти там згадав, що є типа exit, нубо даже либо даже в обход оремки, ну сразу вызвать.

Speaker A

Ну это не смысл. На же ж класс простой. Ну окей, це ми типа покращили. Давай ще далі. Що ще може бути?

Speaker A

У нас паблик debity context. Ну, тут получается ж нам же ж тоже надо треба сделать инверсию. Ну, чтоб мы зависели от интерфейса.

Speaker A

Де саме? Зараз, секунду. Хотя не, у нас же ж и так конкретная реализация контекста от дебитый текста.

Speaker A

Ні, тут типа наслідування правильно воно ти так і будеш робити. Ну тут так. А чи працює в тебе в тебе цей DB контекст взагалі чи ні?

Speaker A

А он там должен наслідоваться вот бейз не наслідование наследование правильно он так и называется DB контекст я просто помню что в строке когда писал public dbset нашидушки название и я просто не использовал таким методом set to ну це типа як синтаксіс такому по-моему

Speaker A

в останніх версіях тут там можно просто написать public db. Ну там, короче, можна по-різному зробити, але тут не в цьому, короче проблема.

Speaker A

Дивись проверку на ноу, может, якусь ще. Дивись, е-е, Маша, поки поки цей ще у нас ще там хлопці залишились.

Speaker A

А дивись, у нас ніде взагалі не описано, який у нас двіжок бази даних. Дивись, у нас ніде нема, що це sequel server, це postgress і так далі.

Speaker A

А у нас же ж нет этого, как его, строки даже не подключено база. Ну да, як вариант.

Speaker A

То есть надо по-любому ж заинжектить наш контекст. Ну, вообще в отдельно, конечно же. І, ну да, щоб його інжектити, його потрібно ще зареєструвати в Dependcy Injection, да? Тобто ще потрібно його наконфігурити. Що потрібно для конфігурації DB контекста?

Speaker A

Строка нужна подключение ж string, да? Ну, типу, а-а, тут буде якийсь конструктор і тут буде DB context, там що-то там options. Ось так от буде за доволі часто подів щось, да? А в самому ось ось тут от що треба

Speaker A

зробити? Билдер. Билдера не вижу. Да. Построили приложение. Дадада. І ну типа давай типа щоб не писати код. То есть тут буде.

Speaker A

Ну да, ну да. І вот воно тобі мені вже згонерувало. От тобі то там будуть builder, тобі потрібно ще зареєструвати і ось тут буде а-а, по-моєму, builder configuration, да, якщо я не помиляюсь. Get connection string.

Speaker A

Ну, якось так, да. Database. Окей, хорошо. Це ми налаштували. А що ще от важливо, коли у нас підхід, що в нас код first підхід? Що нам ще необхідно зробити DB контекстом?

Speaker A

Ну, вообще изначально мы ж миграции делаем. О, міграції. А як їх накатувати, щоб гарантувати, що типа стан бази даних відповідає стану твоєї системи, стану твого кода? Світ ти робили можливо таке. Ну не, ну вообще, да, пробовал, делал. И получается, мы же первый раз,

Speaker A

когда прокидываем миграцию, то она уже либо создастся, либо нет. Если нет, тогда уже надо смотреть, почему.

Speaker A

Ну, в цілому ти можешь играть, если мы уже, допустим, создали. А ти не робив такого, що типа коли в тебе стартує application, ось тут буде, наприклад там якийсь метод типа, який ти пишеш, типа run migrations, який ти там можеш, наприклад, в extensн

Speaker A

винести. Ні, Run migra не було такого. Ну, типа, ти можеш, коли застосунок стартує, ти можеш описати йому логіку, щоб він типа накатував міграцію при стартапі алікейш. Якщо вона не накатиться, то вона в тебе вкрашниться твоя аплікушка.

Speaker A

Навіщо так робить даже? Ну, дивись, тому що ти зробив в коді міграцію і твій, наприклад, застосунок нака ти його запускаєш і тобі потрібно накатити ці міграції. Ти ж не хочеш завжди їх руками накатувати, наприклад.

Speaker A

Це можна зробити просто при стартапі, або можна зробити на якомусь хлсчеке, або ну наприклад або можна ще в конструкторі DB контекста це зробити, але мені подобається на стартапі або на хлчекі конструкторі, щоб типа тощо писать это в исхідном коде как-то, да,

Speaker A

не очень добре. Ну, в конструкторі, щоб не перевіряти кожен раз, чи не є накатані міграції і так далі. А, наприклад, в мене було щось таке, що в Хілсчеках, що на стартапі застосунку. Ну, це тобі напрям обов'язково прям знати. Це коріше про

Speaker A

твій досвід. Тут питання типу джun прикольно б це було зробити в петпроектах, але не супер, типа обов'язково. Тобто от це як варіант описуєте, як то можна зробити. Тобто там, короче, додати ее run dbigrations somewhere.

Speaker A

Окей. Ну, если всё добре буде, то оно ж нічого не не сделает, правильно ж?

Speaker A

Ну да. Але якщо типа є нова міграція, коку ти не накатив, воно автоматично це накатить і в тебе гарантовано, що типа ті бджка відповідає цьому е коду.

Speaker A

Ну да, сучностям. Зрозуміло. Окей. Е-е і залишається Стас. Що ще б ти покращив? Там здається не треба навіть свої методи писати, щоб мігрувати базу. Якщо я не помиляюсь, DB контекст в об'єкта database є метод migrate, який ти ми

Speaker A

його так, ми йому так і визовемо. Ми типа ось тут це цю логіку опишемо.

Speaker A

Ну ти просто говорив про extнtion методи, що ти маєш сам це викликати просто. Ні, ти можеш exension метод зробити, свій extension метод, типа apply migrations, в якому ти якраз визиваєш оцей типа DB contexe database migrations і так далі.

Speaker A

Ага. Окей. Я в endpintті, який створює цей е сам саму entitттію, я б не заставляв би юзера чекати, поки засейвляться зміни в BDСі, того я викликав би AV DB Save Changers, як мінімум.

Speaker A

Ну, це не блокуючий виклик, да, тоже. Ну окей. Вот навіть не то, що це execute SQL сам по собі поганий, там навіть сам по собі SQL запит дивний. Він просто вставляє tйтle.

Speaker A

Так, ми ж ми це вже от ми ж переробили це вже на Entity Framework, тобто тут був би, ну, просто типа, що буде махать вже, да.

Speaker A

Вот. Е, що на рахунок модельки, я б там поставив би не інтове значення дічника, а лонгове на всякий випадок, тому що цих тудушок може бути багато у всякому випадку. Або як, або ще можна гуїд або гуїд, да, щоб взагалі було супер.

Speaker A

Так, якщо говорити про тудушки, блін, я не знаю, чи прийнято взагалі робити такі, що мають просто статус їздан або дан, то я б статуси робив би якусь інамку завхажувам useam типу для кращого forward compatibility, скажемо так. Ну та, ну, щоб юзер

Speaker A

відчував, що він може там більше ма. Ну да, типа, в тебе точно не тільки дан має бути.

Speaker A

Угу. Так, що ще такого? Е, можеш вище програнути подивись? Я тут тобі ще підказку покажу.

Speaker A

Підказку. Е-е, ту-ту-ту-ту-ту. О, якщо не знаєш, замість пустої пустого рядка можна зробити стінхті, щоб це було гарніше хотя би.

Speaker A

Ну, я бы сделал бы, що можно там або, наприклад, use min max мак какой. Ну, типа, що там max типа обмежу по довжині його.

Speaker A

Ну, це в on model creating по ідеї, що можна закрутить. Ні, що можна через data anotation можна ще зробити ось так от там пому. Я не привик, я через церце обично робив іменно теж подобається антифреймwork, типа просто якщо там в тебе зовсім

Speaker A

прості описання через data annotation получається більш е мінімалістичний. Ну да, да, да. Так, а тут що такого ще можна докупати?

Speaker A

[музика] Ту-ту-ту-ту-ту. Цікаво цікаво. Ми насправді тут вже так класно, доволі класно по рефактори, але тут вже починають починається така вкусовщина місцями.

Speaker A

Ну, я тоже так думаю, щось тут уже або щось мінять. Conation token теж типа прокинути можна.

Speaker A

А можна я думав, що треба це вже дупляція буде з минулогопонта. Я думав, це вже і так всі розуміють, що воно буде повторюватися наступно дуже просто. Е, можливо, я теж таку підсказку, можливо, ти хочеш якусь валідацію цієї модельки додати, якусь

Speaker A

бібліотечку типа fluent validation чи зробити. Це ж винесеться все в сервіс і ще робити якусь валідацію цієї тудушки, типа, що tйтle не пустий. е-е, що там якісь інші поля адекватні і так далі.

Speaker A

Угу. А-а, Угу. Щоб з такого, що нового вкинуть, що ще не було. Ну, ми дещо забули типа описати в цілому теж підсказку, що ми сервіси не зареєстрували ніде. Ми зареєстрували БДШку, а сервіси, які ми писали, ніде не зареєстрували.

Speaker A

Сервісів ще немає. Ну да, сервісів нема. Типа ось тут буде ще реєстрація сервісів, register сервісів.

Speaker A

Отак от. Угу. Ту-ту-ту. Ну, блін, навіть не знаю, що тут ще можна було додать.

Speaker A

Ну, я можна ще в дсеті там якось тапличку розконфірувати цих тодушок, якось там, не знаю, індекс повісити, щось таке. Але це вже, да, як варіант, да. Е, цей все, Денис, одне одне зауваження ми закінчуємо.

Speaker A

Давай. Ти там хотів сказати. Окей. Можете опустити нижче. У нас найголовніше не прописане, без чого ми, в принципі, не зможемо взаємодіяти з базою даних. Ну, принаймні при тих знаннях, що я маю. Аure created, мені здається, треба додати.

Speaker A

А ми ось тут же оцей це, да, оце воно би це і робило, да. Ну, в принципі, ти го добре, що ти це проговорив, але да, типа, от ми в контексті DBIG imigrations, ми це і мали на увазі.

Speaker A

Ну, типа, ладно, айдішку воно і так определить, даже не явно, що це primary key, entity framework. Ну, в цілому, да, типа, хіба що оці класи винести в окремі, типа файли.

Speaker A

Endпоint можна теж винести і реєстрацію endpint окремий extension. А і так далі, типа. Ну, в цілому, в цілому вже доволі непоганий фаactр пройшов. Мені подобається далі. Можливо, я щось не бачу, але, ну, доволі непогано получилось і ви себе теж доволі не

Speaker A

прикольно розкрили тут. О, давайте все, перестану. Стопшерінг в цілому. Давайте закінчувати. По фідбеку я дам вже вам особисто на підзапис цей фідбек, як у вас це пройшло. В цілому, якщо говорити о overall, я здивований вашим рівнем, якщо чесно, усі усіх. Ну,

Speaker A

понятно, Маша в мене вчилась, типа, це понятно, а от типу більшість вас, типа, це ви просто підписники, у вас доволі непоганий типа рівень. В цілому мені рівень від питань сподобався. Тобто, понятне, реальна співбесіда відрізнялась, могли би бути більш дужні

Speaker A

питання, були практики і так далі, але в цілому там теоретичну базу ви нормально пройшли, типа мислили теж доволі, ну, типа не проявляли мислення доволі непогане. Тобто там я б далі вже відбирав би, можливо, якесь по тестовому завданню дивився,

Speaker A

якесь би дав або там на по лайфкодінгу дивився, бо от бачите на лайфкодінгу вже у вас типа складніше пішло. Тобто вже тут показник практики, тому тут варіант, що треба давати тестові завдання вже нам, щоб подивитись, як вони пишуть код

Speaker A

хоча би за допомогою штучних інтелектів. Да, зрозуміло, що вони роблять це не самі здебільшими.

Speaker A

А-а, в цілому так. Всем дякую за перегляд, хто додивився це до кінця. У нас майже 3 години получилось. Ну, не знаю. Такого на YouTube, напевно, україномовний. Я таких відосів не бачу, тому я думаю буде супер корисноце. Все, тоді стоповий запис.

Speaker A

Всім дякую за перегляд. І ще там може бути якісь вставки е-е в відео. Про мікросервіси питають. Я вважаю, що це не супердоречне питання для Джуна. можна подушніть, але можна це на окремих відосиках.

Topics:співбесідаJunior C# розробник.NETASP.NET CoreEntity Frameworkтехнічне інтерв’юпідготовка до співбесідибекенд розробкапрограмування на C#розробка ПЗ

Frequently Asked Questions

Що таке платформа .NET і як її пояснити простими словами?

.NET — це велика екосистема інструментів і фреймворків для розробки різних типів застосунків, де C# є однією з основних мов. Простими словами, це набір технологій, що дозволяють створювати програми для вебу, десктопу, мобільних пристроїв та інших платформ.

Які основні технології потрібно знати Junior C#/.NET розробнику для співбесіди?

Для Junior розробника важливо знати C#, ASP.NET Core для бекенд-розробки, Entity Framework Core для роботи з базами даних, а також базові поняття про реляційні бази даних і міграції.

Як проходить виконання C# коду у .NET?

C# код спочатку компілюється у проміжний код (IL), який виконується середовищем CLR (.NET Common Language Runtime), що відповідає за перетворення у машинний код, зрозумілий процесору.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →