روز دیگر داشتم با یک توسعه دهنده جاوا اسکریپت مصاحبه می کردم که برای یک موقعیت ارشد درخواست می داد. یکی از همکاران که در مصاحبه نیز حضور داشت، از کاندید خواست تا تابعی بنویسد که درخواست HTTP کند و در صورت شکست، چندین بار دوباره امتحان کند.
او کد را مستقیماً روی تخته نوشت، بنابراین برای به تصویر کشیدن چیزی تقریبی کافی است. اگر او به سادگی نشان می داد که به خوبی می فهمد اصل ماجرا چیست، ما کاملا راضی خواهیم بود. اما متاسفانه نتوانست راه حل خوبی پیدا کند. سپس ما که آن را به عنوان هیجان نوشتیم، تصمیم گرفتیم کار را کمی ساده‌تر کنیم و از او خواستیم که یک تابع مبتنی بر وعده‌ها از یک تابع با تماس‌های برگشتی ایجاد کند.
اما افسوس. بله، واضح بود که قبلاً کد مشابهی را دیده بود. او به طور کلی می دانست که چگونه همه چیز در آنجا کار می کند. طرحی از راه حل برای ما کافی است، که درک مفهوم را نشان می دهد. با این حال، کدی که نامزد روی تخته سفید نوشت کاملاً مزخرف بود. او تصور بسیار مبهمی از اینکه چه وعده‌هایی در جاوا اسکریپت وجود دارد داشت و واقعاً نمی‌توانست توضیح دهد که چرا به آنها نیاز است. برای یک جوان، این هنوز قابل بخشش است، اما جایگاه یک ارشد دیگر ترسیم نشده بود. این توسعه‌دهنده چگونه می‌تواند باگ‌های زنجیره وعده‌های پیچیده را برطرف کند و به بقیه توضیح دهد که دقیقاً چه کار کرده است؟
توسعه دهندگان کد تمام شده را بدیهی می دانند
در طول فرآیند توسعه، ما دائماً با مواد قابل تکرار مواجه می شویم. ما تکه های کد را جابه جا می کنیم تا مجبور نباشیم هر بار آنها را بازنویسی کنیم. بر این اساس، با تمرکز تمام توجه خود بر روی بخش‌های کلیدی، به کد تمام‌شده‌ای که با آن کار می‌کنیم به عنوان چیزی بدیهی نگاه می‌کنیم - به سادگی فرض می‌کنیم که همه چیز در آن همانطور که باید کار می‌کند.
و معمولاً کار می کند، اما زمانی که همه چیز پیچیده می شود، درک مکانیک آن بیشتر از آن نتیجه می دهد.
برای مثال، نامزد توسعه‌دهنده ارشد ما، وعده‌ها را بدیهی می‌دانست. او احتمالاً تصور می کرد که چگونه با آنها برخورد کند وقتی آنها در جایی از کد شخص دیگری رخ می دهند، اما او اصل کلی را درک نمی کرد و نمی توانست خودش آن را در مصاحبه تکرار کند. شاید او قطعه را حفظ کرده است - آنقدرها هم سخت نیست:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});من هم این کار را انجام داده ام - بله، احتمالاً همه ما در مقطعی این کار را انجام داده ایم. آنها به سادگی یک قطعه کد را حفظ کردند تا بتوانند بعداً از آن در کار خود استفاده کنند، در حالی که فقط به طور کلی تصور می کردند که چگونه همه چیز در آنجا کار می کند. اما اگر توسعه‌دهنده واقعاً مفهوم را درک می‌کرد، مجبور نمی‌شد چیزی را به خاطر بسپارد - او فقط می‌دانست که چگونه این کار انجام می‌شود و به راحتی هر چیزی را که لازم است در کد بازتولید می‌کند.
به سرچشمه ها برس
در سال 2012، قبل از تسلط فریم‌ورک‌های فرانت‌اند، دنیای جی کوئری حکومت می‌کرد و من داشتم کتاب می‌خواندم. توسط جان رسیگ، خالق جی کوئری.
این کتاب به خواننده می آموزد که چگونه جی کوئری خود را از ابتدا بسازد و فرصتی منحصر به فرد برای درگیر شدن در قطار فکری که منجر به ایجاد کتابخانه شد فراهم می کند. جی کوئری در سال های اخیر مورد توجه قرار نگرفته است، اما من همچنان کتاب را به شدت توصیه می کنم. چیزی که بیشتر از همه در مورد او مرا تحت تأثیر قرار داد این احساس اصرار او بود که می توانستم خودم به همه اینها فکر کنم. مراحلی که نویسنده توضیح داد آنقدر منطقی و واضح به نظر می رسید که واقعاً به نظرم می رسید که اگر تازه وارد کار شوم می توانم به راحتی جی کوئری ایجاد کنم.
البته، در واقعیت، من به چنین چیزی تسلط نداشتم - تصمیم می گرفتم که غیرقابل تحمل باشد. راه حل های خودم برای کار کردن خیلی ساده و ساده لوحانه به نظر می رسید و منصرف می شدم. من jQuery را به عنوان یک چیز بدیهی طبقه بندی می کنم، که شما فقط باید کورکورانه به عملکرد صحیح آن اعتقاد داشته باشید. پس از آن، من به سختی وقت خود را صرف کند و کاو در مکانیک این کتابخانه می کنم، اما به سادگی از آن به عنوان نوعی جعبه سیاه استفاده می کنم.
اما خواندن این کتاب از من یک فرد متفاوت ساخت. من شروع به خواندن کد منبع کردم و متوجه شدم که اجرای بسیاری از راه حل ها در واقع بسیار شفاف و حتی واضح است. نه، البته، فکر کردن به چنین چیزی قبلاً از اپرای دیگری است. اما مطالعه کد شخص دیگری و بازتولید راه حل های موجود است که به ما کمک می کند تا چیزی از خودمان پیدا کنیم.
الهاماتی که دریافت می کنید و الگوهایی که متوجه می شوید شما را به عنوان یک توسعه دهنده تغییر می دهد. خواهید دید که کتابخانه فوق العاده ای که همیشه از آن استفاده می کنید و به عنوان یک مصنوع جادویی فکر می کنید به هیچ وجه روی جادو کار نمی کند، بلکه به سادگی مشکل را به طور مختصر و مدبرانه حل می کند.
گاهی اوقات شما باید کد را منفذ کنید و گام به گام آن را جدا کنید، اما اینگونه است که با حرکت در مراحل کوچک متوالی، می توانید مسیر نویسنده را به سمت راه حل تکرار کنید. این به شما این امکان را می دهد که عمیق تر در فرآیند نوشتن کد غوطه ور شوید و به شما اطمینان بیشتری در یافتن راه حل های خود می دهد.
وقتی برای اولین بار کار با وعده ها را شروع کردم، فکر می کردم این یک جادوی خالص است. سپس متوجه شدم که آنها بر اساس همان کال بک ها هستند و دنیای برنامه نویسی من زیر و رو شد. یعنی الگویی که هدفش نجات ما از کال بک هست خودش با استفاده از کال بک پیاده سازی میشه؟!
این به من کمک کرد که با چشم‌های متفاوتی به موضوع نگاه کنم و متوجه شوم که در مقابل من کدهای مبهم و پیچیدگی ماورایی وجود ندارد که هرگز در زندگی‌ام آن را درک نخواهم کرد. اینها فقط الگوهایی هستند که با کنجکاوی و غوطه وری عمیق به راحتی قابل درک هستند. اینگونه است که مردم کدنویسی را یاد می گیرند و به عنوان توسعه دهنده رشد می کنند.
این چرخ را دوباره اختراع کنید
بنابراین با خیال راحت چرخ را دوباره اختراع کنید: کد خود را برای اتصال داده بنویسید، یک وعده داخلی ایجاد کنید یا حتی راه حل مدیریت دولتی خود را بسازید.
مهم نیست که هیچ کس از همه اینها استفاده نکند - اما اکنون می دانید که چگونه. و اگر این فرصت را دارید که متعاقباً از چنین پیشرفت هایی در پروژه های خود استفاده کنید ، این به طور کلی عالی است. می توانید آنها را توسعه دهید و چیز دیگری یاد بگیرید.
نکته اینجا این نیست که کد خود را به تولید بفرستید، بلکه چیزی جدید یاد بگیرید. نوشتن پیاده‌سازی راه‌حل موجود راهی عالی برای یادگیری از بهترین برنامه‌نویسان و تقویت مهارت‌های خود است.
منبع: www.habr.com