لماذا من المفيد إعادة اختراع العجلة؟

في أحد الأيام أجريت مقابلة مع مطور جافا سكريبت الذي كان يتقدم لوظيفة عليا. طلب أحد الزملاء، الذي كان حاضرًا أيضًا في المقابلة، من المرشح كتابة دالة من شأنها تقديم طلب HTTP، وإذا لم ينجح، قم بإعادة المحاولة عدة مرات.

لقد كتب الكود مباشرة على السبورة، لذا سيكون من الكافي رسم شيء تقريبي. ولو أنه أظهر ببساطة أنه يفهم جيدًا ماهية الأمر، لكنا راضين تمامًا. لكن للأسف لم يتمكن من إيجاد حل ناجح. ثم قررنا، بسبب الإثارة، أن نجعل المهمة أسهل قليلًا وطلبنا منه تحويل وظيفة ذات عمليات رد اتصال إلى وظيفة مبنية على الوعود.

لكن للأسف. نعم، كان من الواضح أنه واجه مثل هذا الرمز من قبل. كان يعرف بشكل عام كيف يعمل كل شيء هناك. كل ما نحتاجه هو رسم تخطيطي للحل الذي يوضح فهم المفهوم. ومع ذلك، فإن الكود الذي كتبه المرشح على السبورة كان محض هراء. كانت لديه فكرة غامضة جدًا عن الوعود الموجودة في جافا سكريبت ولم يتمكن حقًا من شرح سبب الحاجة إليها. بالنسبة للمبتدئ، كان من الممكن التسامح مع هذا الأمر، لكنه لم يعد مناسبًا لمنصب أحد كبار السن. كيف سيتمكن هذا المطور من إصلاح الأخطاء في سلسلة معقدة من الوعود ويشرح للآخرين ما فعله بالضبط؟

يعتبر المطورون أن التعليمات البرمجية الجاهزة بديهية

أثناء عملية التطوير، نواجه دائمًا مواد قابلة للتكرار. نقوم بنقل أجزاء من التعليمات البرمجية حتى لا نضطر إلى إعادة كتابتها في كل مرة. وبناء على ذلك، من خلال تركيز كل اهتمامنا على الأجزاء الرئيسية، فإننا ننظر إلى الكود النهائي الذي نعمل به كشيء بديهي - نحن ببساطة نفترض أن كل شيء سيعمل كما ينبغي.

وعادة ما ينجح الأمر، ولكن عندما تصبح الأمور صعبة، فإن فهم الميكانيكا يكون أكثر فائدة.

وهكذا، اعتبر مرشحنا لمنصب كبير المطورين أن الأشياء الواعدة بديهية. ربما كانت لديه فكرة عن كيفية التعامل معها عند حدوثها في مكان ما في كود شخص آخر، لكنه لم يفهم المبدأ العام ولم يتمكن من تكراره بنفسه أثناء المقابلة. ربما كان يتذكر القطعة عن ظهر قلب - فالأمر ليس بهذه الصعوبة:

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

لقد فعلت ذلك أيضًا - وربما فعلنا ذلك جميعًا في وقت ما. لقد قاموا ببساطة بحفظ جزء من التعليمات البرمجية حتى يتمكنوا من استخدامه لاحقًا في عملهم، بينما لم يكن لديهم سوى فكرة عامة عن كيفية عمل كل شيء هناك. ولكن إذا فهم المطور هذا المفهوم حقًا، فلن يضطر إلى تذكر أي شيء - بل سيعرف ببساطة كيفية القيام بذلك، وسيقوم بسهولة بإعادة إنتاج كل ما يحتاجه في التعليمات البرمجية.

العودة إلى الجذور

في عام 2012، عندما لم تكن هيمنة أطر الواجهة الأمامية قد تم تأسيسها بعد، حكمت jQuery العالم، وقرأت الكتاب أسرار جافا سكريبت نينجا، من تأليف جون ريسيج، مبتكر jQuery.

يعلم الكتاب القارئ كيفية إنشاء jQuery الخاص به من الصفر ويوفر رؤية فريدة لعملية التفكير التي أدت إلى إنشاء المكتبة. في السنوات الأخيرة، فقدت jQuery شعبيتها السابقة، لكنني ما زلت أوصي بشدة بالكتاب. أكثر ما أذهلني فيها هو الشعور المستمر بأنني أستطيع أن أفكر في كل هذا بنفسي. بدت الخطوات التي وصفها المؤلف منطقية جدًا، وواضحة جدًا لدرجة أنني بدأت أفكر بجدية في أنه يمكنني بسهولة إنشاء jQuery إذا قمت بذلك للتو.

بالطبع، في الواقع، لم أكن لأتمكن من فعل أي شيء كهذا - كنت سأقرر أنه كان صعبًا بشكل لا يطاق. قد تبدو حلولي الخاصة بسيطة جدًا وساذجة بحيث لا يمكن تطبيقها، وسأستسلم. أود أن أصنف jQuery كأشياء بديهية، في التشغيل الصحيح الذي تحتاج فقط إلى الإيمان به بشكل أعمى. بعد ذلك، لن أضيع الوقت في الخوض في آليات هذه المكتبة، ولكني سأستخدمها ببساطة كنوع من الصندوق الأسود.

لكن قراءة هذا الكتاب جعلتني شخصًا مختلفًا. بدأت في قراءة الكود المصدري واكتشفت أن تنفيذ العديد من الحلول كان في الواقع شفافًا للغاية، بل وواضحًا. لا، بالطبع، التفكير في شيء كهذا بمفردك هو قصة مختلفة. لكن دراسة رموز الآخرين وإعادة إنتاج الحلول الحالية هي التي تساعدنا على التوصل إلى شيء خاص بنا.

الإلهام الذي تكتسبه والأنماط التي تبدأ في ملاحظتها سوف يغيرك كمطور. ستجد أن تلك المكتبة الرائعة التي تستخدمها باستمرار والتي اعتدت على التفكير فيها كقطعة أثرية سحرية لا تعمل على السحر على الإطلاق، ولكنها ببساطة تحل المشكلة بإيجاز وسعة الحيلة.

في بعض الأحيان، سيتعين عليك دراسة الكود وتحليله خطوة بخطوة، ولكن هذه هي الطريقة التي يمكنك بها، من خلال التحرك بخطوات صغيرة ومتسقة، تكرار مسار المؤلف إلى الحل. سيسمح لك هذا بالتعمق أكثر في عملية البرمجة ويمنحك المزيد من الثقة في التوصل إلى حلول خاصة بك.

عندما بدأت العمل بالوعود لأول مرة، بدا لي الأمر وكأنه سحر خالص. ثم اكتشفت أنها كانت مبنية على نفس عمليات الاسترجاعات، وانقلب عالم البرمجة الخاص بي رأسًا على عقب. لذا فإن النمط الذي يهدف إلى إنقاذنا من عمليات الاسترجاعات، يتم تنفيذه بنفسه باستخدام عمليات الاسترجاعات؟!

لقد ساعدني هذا في النظر إلى الأمر بعيون مختلفة وأدرك أن هذه ليست قطعة من التعليمات البرمجية الغامضة أمامي، والتي لن أفهم تعقيدها الباهظ في حياتي أبدًا. هذه مجرد أنماط يمكن فهمها دون مشاكل مع الفضول الواجب والانغماس العميق. هذه هي الطريقة التي يتعلم بها الناس البرمجة وينموون كمطورين.

إعادة اختراع هذه العجلة

لذا، انطلق وأعد اختراع العجلات: اكتب كود ربط البيانات الخاص بك، أو أنشئ وعدًا محليًا، أو حتى أنشئ حل إدارة الحالة الخاص بك.
لا يهم أنه لن يستخدم أحد كل هذا على الإطلاق - لكنك الآن تعرف كيفية القيام بذلك. وإذا أتيحت لك الفرصة لاستخدام هذه التطورات لاحقًا في مشاريعك الخاصة، فهذا أمر رائع بشكل عام. ستكون قادرًا على تطويرها وتعلم شيء آخر.

الهدف هنا ليس إرسال الكود الخاص بك إلى الإنتاج، بل تعلم شيء جديد. تعد كتابة التنفيذ الخاص بك لحل موجود طريقة رائعة للتعلم من أفضل المبرمجين وبالتالي صقل مهاراتك.

المصدر: www.habr.com