در اکثر شرکت‌ها، مدیریت باید به توسعه دهندگان اعتماد کند که در جهت ارزیابی مهارت‌های داوطلب، یک سری مصاحبات فنی را با موفقیت انجام دهند. اگر به عنوان یک نامزد کار خود را به خوبی انجام دهید، در نهایت باید یک مصاحبه داشته باشید.
این مقاله حول محور زبان JavaScript می‌باشد، که می‌توانید دوره مربوط به آن را در این لینک بر روی راکت بیابید.
در اینجا برخی سوال‌ها را مشاهده می‌نمایید که می‌توانند به شما در بررسی مواردی که مهم هستند کمک کنند.
با بخش دوم این مقاله همراه ما باشید:
۶. وراثت وابسته به نمونه اولیه، چه زمانی یک انتخاب مناسب است؟
بیش از یک نوع وراثت وابسته به نمونه اولیه وجود دارد:
- نمایندگی (مانند زنجیره نمونه‌های اولیه)
- پیوسته (مانند mixinها، Object..assign())
- تابعی (این مورد را با برنامه‌نویسی تابعی اشتباه نگیرید؛ در اینجا عبارت است از تابعی که برای ساخت یک بسته برای state / کپسوله‌سازی خصوصی استفاده می‌شود.)
هر نوع وراثت وابسته به نمونه اولیه، مجموعه موارد استفاده مختص خود را دارد، اما تمام آن‌ها به طور مساوی در قابلیت خود برای فعال‌سازی ترکیب‌بندی، کاربردی هستند.
چیزی که مصاحبه گران دوست دارند بشنوند:
- در موقعیت‌هایی که ماژول‌ها یا برنامه‌نویسی تابعی یک راه حل واضح را فراهم نمی‌کنند.
- وقتی که باید آبجکت‌ها را از چندین منبع تشکیل دهید.
- هر زمان که به وراثت نیاز دارید.
هشدارهایی که باید حواستان به آن‌ها باشد:
- هیچ دانشی درباره زمان استفاده از نمونه‌های اولیه ندارم.
- عدم داشتن هیچ‌گونه آگاهی درباره mixinها یا Object.assign().
۷. معنای «ترجیح دادن ترکیب‌بندی آبجکت نسبت به وراثت وابسته به کلاس» چیست؟
معنای آن این است که استفاده مجدد از کد به جای وراثت‌گیری از کلاس‌ها و ساخت طبقه‌بندی آبجکت، باید با مونتاژ کردن واحدهای عملکرد کوچک‌تر، در قالب یک آبجکت جدید انجام شود.
چیزی که مصاحبه گران دوست دارند بشنوند:
- از سلسله مراتب کلاس جلوگیری شود.
- از موقعیت کلاس شکننده جلوگیری شود.
- از طبقه‌بندی سفت و سخت جلوگیری شود.
- کد را انعطاف‌پذیرتر کنید.
هشدارهایی که باید حواستان به آن‌ها باشد:
- شکست در اشاره کردن به مشکلات بالا.
- شکست در بیان تفاوت بین ترکیب‌بندی و وراثت کلاس، یا برتری‌های ترکیب‌بندی.
۸. اتصال داده دو طرفه و جریان داده یک طرفه چه هستند، و چه تفاوتی با هم دارند؟
اتصال داده دو طرفه یعنی این که فیلدهای رابط کاربری، به طور دینامیک به داده مدل متصل شوند. به صورتی که وقتی یک فیلد رابط کاربری تغییر می‌کند، داده مدل به همراه آن تغییر کند و برعکس.
جریان داده یک طرفه یعنی مدل مورد نظر، تنها منبع حقیقت است. تغییرات اعمال شده به رابط کاربری، پیام‌هایی را فعال می‌کنند که قصد کاربر را به مدل مورد نظر ارسال می‌کنند (یا در React، در واقع store می‌کنند). فقط مدل است که به تغییر داده state برنامه دسترسی دارد. تاثیر آن این است که داده‌ها همیشه در یک جهت جریان دارند، که در نتیجه درک آن را ساده‌تر می‌کند.
جریان‌های داده یک طرفه قطعی هستند، در حالیکه اتصال داده دو طرفه میتواند باعث بروز اثرات جانبی شود که درک و پیروری از آن‌ها سخت‌تر است.
چیزی که مصاحبه گران دوست دارند بشنوند:
- React یک مثال استاندارد جدید از جریان داده یک طرفه است، پس اشاره به React یک نشانه خوب است. Cycle.js یک پیاده‌سازی معروف دیگر از جریان داده یک طرفه است.
- Angular یک فریم‌وورک معروف است که از اتصال داده دو طرفه استفاد می‌کند.
نکته: دوره‌های مربوط به این دو فریم‌وورک را می‌توانید در این لینک‌ها بر روی راکت بیابید:
هشدارهایی که باید حواستان به آن‌ها باشد:
- هیچ درکی از معنای این دو ندارم. نمی‌توانم تفاوت آن‌ها را بیان کنم.
۹. نکات مثبت و منفی معماری‌های یکپارچه و میکروسرویس چه هستند؟
یک معماری یکپارچه، یعنی این که برنامه شما به عنوان یک واحد کد چسبناک نوشته شده است، که کامپوننت‌هایش به گونهای طراحی شده‌اند تا با هم کار کنند، و فضای حافظه و منابع مشترکی را به اشتراک می‌‌گذارند.
یک معماری میکروسرویس، یعنی این که برنامه شما از تعداد زیادی برنامه‌های کوچک‌تر و مستقل ساخته شده است که قابلیت اجرای فضای حافظه خود را دارند، و به صورت مستقل از یکدیگر مقیاسگذاری می‌کنند، که احتمال دارد این فرایند در میان چند دستگاه جداگانه باشد.
نکات مثبت معماری یکپارچه: برتری اصلی معماری یکپارچه این است که اکثر برنامه‌ها معمولا تعداد زیادی نگرانی مانند وارد شدن (logging)، محدودیت نرخ، امکانات امنیتی و اختلال سرویس دارند.
وقتی که همه چیز در برنامه مشابه اجرا می‌شود، ارتباط دادن کامپوننت‌ها با این نگرانی‌ها ساده است.
همچنین از آنجایی که دسترسی به حافظه به اشتراک گذاشته شده از ارتباط پردازش داخلی سریع‌تر است، در این روش میتواند یک برتری در کارایی هم وجود داشته باشد.
نکات منفی معماری یکپارچه: همینطور که برنامه تکامل پیدا می‌کند، سرویس‌های برنامه یکپارچه با هم جفت می‌شوند، و باعث می‌شوند که جداسازی این سرویس‌ها برای اهدافی مانند مقایس‌گذاری مستقل یا نگهداری کد، سخت‌تر شود.
همچنین درک معماری‌های یکپارچه بسیار سخت‌تر است؛ زیرا ممکن است dependencyها، اثرات جانبی و پردازش‌هایی وجود داشته باشند که وقتی به یک سرویس یا کنترلر خاص نگاه می‌کنید، واضح نباشند.
نکات مثبت معماری میکروسرویس: معماری‌های میکروسرویس معمولا بهتر سازمان‌دهی می‌شوند؛ زیرا هر میکروسرویس یک کار بسیار مشخص دارد، و نگران کار کامپوننت‌های دیگر نیست. بازسازی مجدد و پیکربندی مجدد سرویس‌های غیر جفت شده هم برای رسیدگی به برنامه‌های دیگر، ساده‌تر است. (برای مثال رسیدگی هم به کلاینت‌های وب و هم به API)
همچنین این معماری‌ها می‌توانند بسته به نحوه سازمان‌دهی شدنشان، برتری‌های کارایی هم داشته باشند؛ زیرا جداسازی سرویس‌های مهم و مقیاسگذاری آن‌ها به صورت مستقل از بقیه برنامه، ممکن است.
نکات منفی معماری میکروسرویس: همینطور که شما یک معماری میکروسرویس جدید می‌سازید، احتمال کشف نگرانی‌هایی که در هنگام طراحی پیش‌بینی نکرده بودید، وجود دارد. یک برنامه یکپارچه میتواند کمک کننده‌های به اشتراک گذاشته شده یا میان‌افزارها را به گونهای تاسیس کند که نگرانیهای این چنینی را بدون تلاش زیاد مدیریت کنند.
در یک معماری میکروسرویس، شما یا باید سربار ماژول‌های مختلف را برای هر نگرانی متقاطع خرج کنید، یا این که این نگرانی‌ها را در یک لایه سرویس دیگر که تمام ترافیک داده‌ها از درون آن مسیردهی می‌شوند، کپسوله‌سازی کنید.
در نهایت، حتی معماری‌های یکپارچه هم ترجیح می‌دهند که ترافیک داده‌ها را از طریق یک لایه سرویس خارجی برای نگرانیهای متقاطع مسیردهی کنند، اما با یک معماری یکپارچه، می‌توان هزینه این کار را تا زمانی که پروژه ما بالغ‌تر شود، به تاخیر انداخت.
میکروسرویس‌ها مکررا بر روی ماشین مجازی یا محفظه‌های مختص خود مستقر می‌شوند، و باعث بروز ازدیاد کار ماشین مجازی می‌شوند. این عملیات‌ها مکررا با استفاده از ابزار مدیریت محفظه، خودکارسازی می‌شوند.
چیزی که مصاحبه گران دوست دارند بشنوند:
- رفتار مثبت در قبال میکروسرویس‌ها، بدون در نظر گرفتن هزینه اولیه بالاتر در مقابل برنامه‌های یکپارچه. آگاهی از این که میکروسرویس‌ها در مدت زمان طولانی بهتر اجرا شده، و مقیاسگذاری می‌کنند.
- عملی بودن درباره میکروسرویس‌ها در مقابل برنامه‌های یکپارچه. برنامه را به گونهای ساختاربندی کنید که سرویس‌ها در سطح کد از یکدیگر مستقل باشند، اما اتصال آن‌ها به یکدیگر به عنوان یک برنامه یکپارچه در ابتدا ساده باشد. هزینه‌های سربار میکروسرویس‌ها میتواند تا زمانی که پرداخت آن عملی‌تر شود، به تاخیر انداخته شود.
هشدارهایی که باید حواستان به آن‌ها باشد:
- عدم آگاهی از تفاوت میان معماری‌های یکپارچه و میکروسرویس.
- عدم آگاهی درباره سربار اضافی میکروسرویس‌ها.
- عدم آگاهی از سربار کارایی اضافی که از IPC و ارتباط شبکه برای میکروسرویس‌ها می‌آید.
- منفی‌بافی بیش از حد درباره اشکالات میکروسرویس‌ها. عدم توانایی در بیان راه‌هایی که می‌توان برنامه‌ای یکپارچه را جداسازی کرد، به گونهای که در زمان مورد نیاز برای تقسیم آن‌ها به میکروسرویس‌ها، این کار ساده باشد.
- دست کم گرفتن برتری‌های میکروسرویس‌‌هایی که به صورت مستقل قابل مقیاسگذاری هستند.
۱۰. برنامه‌نویسی ناهمگام چیست، و چرا در JavaScript مهم است؟
برنامه‌نویسی همگام یعنی این که با ممنوعیت فراخوانی‌های شرطی و تابعی، کد شما به ترتیب از بالا به پایین اجرا می‌شود، و عملیات‌های طولانی مدت مانند درخواست‌های شبکه و ورودی / خروجی دیسک را محدود می‌کند.
برنامه‌نویسی ناهمگام یعنی این که موتور در یک حلقه رویداد اجرا می‌شود. وقتی که به یک عملیات مسدود کننده نیاز است، درخواست مورد نظر شروع می‌شود و کد شما بدون مسدود کردن نتیجه، به اجرا شدن ادامه می‌دهد. وقتی که پاسخ نهایی آماده است، یک وقفه بروز داده می‌شود که باعث اجرای یک handler رویداد می‌شود، جایی که جریان کنترل ادامه پیدا می‌کند. به این صورت، یک thread برنامه تنها میتواند تعداد زیادی عملیات همزمان را قطع کند.
رابط‌های کاربری طبیعتا ناهمگام هستند، و اکثر وقت خود را صرف انتظار برای ایجاد وقفه توسط ورودی کاربر و فعال کردن handlerهای رویداد می‌کنند.
Node به صورت پیشفرض ناهمگام است، که این یعنی سرور مورد نظر تقریبا به صورت مشابه کار می‌کند، در یک حلقه منتظر یک درخواست شبکه می‌ماند، و در حالیکه درخواست اول در حال رسیدگی شدن است، درخواست‌های بیشتری را می‌پذیرد.
این مسئله در JavaScript مهم است؛ زیرا یک تطابق بسیار طبیعی برای کد رابط کاربری می‌باشد، و برای کارایی سرور بسیار سودمند است.
چیزی که مصاحبه گران دوست دارند بشنوند:
- درک این که مسدود کردن چیست، و پیامدهای کارایی.
- درک این که مدیریت رویداد چیست، و چرا برای کد رابط کاربری مهم است.
هشدارهایی که باید حواستان به آن‌ها باشد:
- با عبارات ناهمگام و همگام آشنا نیستم.
- نمی‌توانم پیامدهای کارایی یا رابطه میان کد ناهمگام و کد رابط کاربری را بیان کنم.
مقالات مرتبط:
- تکامل جاوااسکریپت ناهمگام: از callbackها، تا promiseها و Async / Await
- JavaScript ناهمگام با استفاده از Async / Await
نتیجه گیری
به موضوعات سطح بالا بچسبید. اگر کاندیداها می‌توانند به سه سوال پاسخ دهند، معمولا معنای آن این است که آن‌ها تجربه برنامه‌نویسی کافی برای درک تغییرات و سینتکس زبان را در چند هفته دارند؛ حتی اگر تجربه زیادی در JavaScript نداشته باشند.
نامزدها را بر پایه مواردی که یادگیری‌شان ساده است رد صلاحیت نکنید.
چیزی که واقعا باید بدانید این است که: «آیا این نامزد نحوه جمع‌بندی یک برنامه را می‌داند؟»
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید