كيف تصبح مطورًا مبتدئًا متميزًا: دليلك الشامل للنجاح في عالم البرمجة

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

• ماذا تتوقع في وظيفتك (الأيام والأسابيع الأولى)
• خطتك قصيرة ومتوسطة المدى
• العقلية المطلوبة للنجاح
• كيف تكون مطورًا جديدًا متميزًا

ماذا تتوقع في وظيفتك الأولى كمطور؟

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

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

شركتك تريدك أن تنجح: استثمار في مستقبلك

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

هناك بعض المهارات التي تمتلكها عند البدء، ولكن هناك بعض المهارات التي يصعب (ولكن ليس مستحيلًا) اكتسابها خارج بيئة العمل الاحترافية. نظرًا لأن هذه هي وظيفتك الأولى، فمن المحتمل أنك لم تتعاون أبدًا مع فريق كبير باستخدام source control أو قمت بصيانة تطبيقات قيد الإنتاج – وهذا أمر طبيعي! هذه المهارات أسهل في اكتسابها في بيئة إنتاج حقيقية.

أيامك وأسابيعك الأولى: التعلم هو الأولوية

بمجرد إعداد جهاز الكمبيوتر الخاص بك وحصولك على الوصول إلى جميع الأدوات التي تحتاجها، من المرجح أن تكون مهامك الأولى تحسينات صغيرة للميزات أو إصلاح أخطاء بسيطة – مجرد أمور لتبدأ بها في المشاريع المختلفة. بصرف النظر عن المعرفة التقنية البحتة، في كل شركة توجد معرفة بالمجال أو “منطق العمل” (business logic) (ما تفعله منتجات الشركة أو خدماتها وكيف تفعل ذلك) والتي ستحتاج إلى اكتسابها. إذا كان للشركة منتجات متعددة، فقد يمنحونك مهامًا صغيرة في كل قاعدة كود للبدء في استكشاف تلك المنتجات.

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

الغوص في قاعدة كود حقيقية: تحديات وفرص

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

يجب التعامل مع جميع الاختصارات المريحة أو الحالات الهامشية (edge cases) التي تم تجاهلها في البرامج التعليمية (مثل معالجة الأخطاء error handling) هنا – هذا تطبيق حقيقي. قد يكون هذا مربكًا في البداية، لكن قراءة كود الآخرين هي مهارة يجب عليك تطويرها، وهي مهارة ستستخدمها طوال حياتك المهنية (وفي نهاية هذا المقال سأقدم لك بعض النصائح للمساعدة في ذلك). في النهاية، لا تخف من طلب المساعدة! فزملاؤك في الفريق موجودون لدعمك، وفي مرحلة ما في الماضي، كان عليهم طرح نفس الأسئلة بالضبط.

توقعات الشركة من المطورين المبتدئين: خطة الـ 30/60/90 يومًا

أولاً وقبل كل شيء: هذه الشركة لا تتوقع منك أن تقفز وتبدأ في إنجاز الميزات فورًا. إنهم يعلمون أنك ستحتاج إلى وقت لتطوير المهارات التي لا تمتلكها بعد، وفهم قواعد الكود، وتعلم كيفية العمل بفعالية مع الفريق. من المحتمل أن يلتقي بك مديرك ويضع خطة لـ 30/60/90 يومًا. إذا لم يفعلوا ذلك – اطلب أنت! أي مشرف سيقدر امتلاكك لوظيفتك وتوقعات وظيفتك.

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

عقلية المطور المبتدئ: مفتاح النجاح والنمو

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

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

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

وهناك شيء آخر مهم يجب تذكره: امنح نفسك حرية ارتكاب الأخطاء. ستتسبب في تعطيل الإنتاج، وستقوم ببعض التحديثات السيئة لقواعد البيانات (لقد فعلت ذلك بالتأكيد) – يمكن استعادتها، إنها ليست نهاية العالم أو وظيفتك، وكل مطور ذو خبرة فعل ذلك. إنه مجرد جزء من العملية.

مهارتك الأعظم كمطور مبتدئ: إتقان فن التعلم

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

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

قوة المكاسب الصغيرة: النمو المستمر بنسبة 1% يوميًا

أحد كتبي المفضلة، “العادات الذرية” (Atomic Habits) لجيمس كلير (James Clear)، يحتوي على رسم بياني رائع بعنوان “قوة المكاسب الصغيرة” (The Power of Tiny Gains). إنه رسم بياني بسيط يوضح الفرق بين تحسن بنسبة 1% وتدهور بنسبة 1% كل يوم. إذا تحسنت بنسبة 1% كل يوم، فبعد عام ستكون أفضل بحوالي 38 مرة مما كنت عليه في بداية العام! هذه هي قوة “المكاسب الصغيرة”، وهي حقيقة تنطبق تمامًا على أن تصبح مطور برمجيات رائعًا.

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

صفحة واحدة يوميًا: بناء المعرفة المتراكمة

سمعت قصة في بودكاست للمطورين مرة عن الرجل الذي يقوم بصيانة pg gem لـ Ruby. هذه الجوهرة هي الواجهة بين كود Ruby الخاص بك وقاعدة بيانات Postgresql. إنه أمر جاد للغاية، ويستخدمه معظم مطوري Ruby كل يوم. كانت قصة كيف أصبح هو المسؤول عن صيانة هذه الجوهرة مثيرة للاهتمام. قال إنه عندما بدأ لأول مرة، كان يفتح وثائق Postgresql ويقرأ صفحة واحدة – صفحة واحدة فقط كل يوم. بمرور الوقت، اكتسب معرفة واسعة بـ Postgresql وتمكن من البدء في المساهمة في pg gem. وبعد فترة وجيزة، أصبح هو المسؤول عن صيانة تلك الجوهرة. إنه المثال المثالي لتراكم المكاسب الصغيرة – مجرد صفحة واحدة يوميًا. يمكن لأي منا فعل ذلك، وأنا أشجعك على تبني نفس الفلسفة وتطبيقها على أي لغة أو نظام تعمل به!

“الممارسة المثالية تصنع الكمال”: كيف تطور عاداتك البرمجية

ربما سمعت هذه العبارة من قبل: “الممارسة تصنع الكمال” (practice makes perfect). معلم البيانو الخاص بي عندما كنت أكبر استخدم عبارة مختلفة: “الممارسة المثالية تصنع الكمال” (perfect practice makes perfect). أعتقد أنه كان على حق. كان بإمكاني ممارسة البيانو بطريقة خاطئة – بتقنية سيئة، غير دقيقة، بدون إيقاع ثابت – وهذه هي النتيجة التي كنت سأحصل عليها: عزف بيانو غير دقيق. ليست مجرد الممارسة، بل كيف تمارس هو ما يهم.

كان بإمكاني ممارسة المقطع الأول من أغنية مرارًا وتكرارًا وإتقانه تمامًا، ولكن إذا لم أتجاوز المقطع الأول أبدًا، فلن أتعلم الأغنية. كان بإمكاني عزف المقطع الأول من الأغنية بمستوى عازف بيانو عالمي، لكنني أردت أن أعزف البيانو، لذلك كان علي أن أتعلم الأغنية بأكملها. هذا موازٍ مثالي للتطوير. الطريقة التي “تمارس” بها التطوير (عاداتك اليومية، أساليبك وروتيناتك للتطوير) تحدد نوع المطور الذي ستصبح عليه.

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

المطورون على شكل حرف “T”: توسيع المعرفة وتعميقها

الشخص “على شكل حرف T” (T-shaped person) في بداية مسيرتك المهنية في التطوير، هناك العديد من المواضيع التي يمكنك الاستفادة من معرفتها، لذلك تريد توزيع جهدك ومعرفتك عبر مجموعة واسعة من المواضيع. إذا كنت تهدف إلى أن تصبح مطور full-stack، فقد تتضمن هذه القائمة أشياء مثل HTML، CSS، JS، لغة خلفية من اختيارك، SQL، Git، وما إلى ذلك. هناك الكثير من المعرفة والفوائد التي يمكن الحصول عليها بسهولة على سطح كل من هذه المواضيع والتي يمكن اكتسابها من خلال نشر شبكة واسعة واستيعاب كل شيء.

بمرور الوقت، ستجد نوع التطوير الذي تستمتع به أكثر. ربما يكون frontend، backend، عمل قواعد البيانات، ops، التصميم – أو مزيجًا من هذه وأكثر. مع تقدم مسيرتك المهنية، ستبدأ في أن تصبح “شخصًا على شكل حرف T”. الشخص على شكل حرف T هو شخص، كما يُصوّر الحرف T، لديه معرفة وخبرة واسعة ولكن سطحية حول الكثير من الأشياء، ومجالين أو أكثر لديهما معرفة وخبرة عميقة.

يستغرق بناء هذه المعرفة العميقة بعض الوقت، وتكون كل خطوة إلى الأسفل تتطلب جهدًا أكبر من سابقتها – هذه هي الحقيقة عندما تقترب من إتقان موضوع ما. في البداية، اجمع كل تلك المكاسب السهلة للمبتدئين عبر مجال واسع من المواضيع. سيساعدك امتلاك هذه القدرة على شكل حرف T على أن تصبح مطورًا أفضل بشكل عام. مطورو الواجهة الأمامية (Frontend developers) الذين يفهمون مخطط قاعدة البيانات (database schema) أو مطورو الواجهة الخلفية (backend developers) الذين يفهمون كيف سيتم استخدام جداول قاعدة البيانات هذه كنماذج في الواجهة الأمامية سيكونون أكثر دراية وزملاء فريق أفضل من أولئك الذين ينعزلون في مجالهم الخاص. في البداية، هذا التوغل الصغير في جميع جوانب التطوير مفيد أيضًا للعثور على ما تنجذب إليه، ولمنحك الصورة الأكبر لجميع الأجزاء المتحركة في عالم البرمجيات. اتبع اهتماماتك وابقَ متعطشًا للتعلم!

نصائح عملية لتصبح مطورًا مبتدئًا متميزًا

بعد أن تناولنا توقعاتك وكيفية التفكير فيها، إليك بعض النصائح العملية لتجعلك مطورًا جديدًا رائعًا – مطورًا يحب زملاؤك العمل معه.

1. التواصل الفعال: فن طلب المساعدة بذكاء

قد لا تمتلك معرفة ومهارات تطوير مذهلة في يومك الأول، ولكن يمكنك امتلاك مهارات تواصل مذهلة. كمطور جديد، ستطلب المساعدة والإرشاد – كثيرًا. وهذا أمر طبيعي! إليك نصيحة حول كيفية طلب المساعدة بفعالية. الوقوع في مشكلة أمر محبط (كان كذلك بالنسبة لي). في هذه اللحظات، من السهل أن تدع هذا الإحباط يغلبك وتطلق الأسئلة على زميلك المجاور (أو ربما عبر البريد الإلكتروني أو تطبيق الدردشة). أشياء مثل:

• im stuck
• it errored
• the page won't load

الآن، تراجع خطوة وانظر إلى هذا من منظور الشخص الذي تطلب منه المساعدة. رسالة مثل “الصفحة لا تُحمّل” لا تساعد هذا الشخص على الإطلاق. لا يوجد سياق. لا توجد معلومات يمكنهم الاعتماد عليها. في الواقع، سيتعين عليهم طلب المزيد من المعلومات منك. هذا غير فعال بشكل لا يصدق ومحبط للغاية للشخص الذي يحاول مساعدتك.

طريقة أفضل لطلب المساعدة هي التفكير فيها كـ Mad Lib™ (إذا كنت تتذكرها):

• أنا أعمل على _، ولكن عندما أحاول _، يحدث _ بدلاً من ذلك.
• لقد جربت _، _، و _.
• ولقد نظرت إلى _ و _.

قد يكون مثال على هذه الرسالة شيئًا كهذا:

• أنا أعمل على user password reset bug، ولكن عندما أحاول to generate a password reset link، يكون the user's token is already empty.
• لقد نظرت إلى where the token is set، ويمكنني رؤية the token in the database، ولكن the token is missing on line X of File Y.

إذا أرسلت لشخص ما الرسالة أعلاه، يمكنه فهم:

• ماذا تعمل عليه
• ما هي المشكلة
• ماذا جربت بالفعل
• أين تكمن المشكلة

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

2. صقل مهارة “جوجل فو”: البحث الفعال عن الحلول

تمامًا مثل تطوير المهارة في فنون القتال الجسدية Kung Fu، بمرور الوقت كمطور ستطور مهارة في فن “جوجل فو” (Google Fu) – أي فن العثور على الإجابات عن طريق البحث عنها في جوجل. هذه مهارة حقيقية يمتلكها كل مطور ذو خبرة ويتم تطويرها بمرور الوقت. في بعض الأحيان، تحتاج فقط إلى البحث في جوجل عن المشكلة بالضبط التي تواجهها (هذا يعمل بشكل رائع مع رسائل الخطأ):

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

في الصورة أعلاه، لم ير جوجل أبدًا الدالة whos_that_pokemon_its_pikachu() في الملف gotta_catchem_all.rb (باستثناء الآن بعد أن بحثت عنها :)). إزالة تلك المعلومات الخاصة بالمشروع وإضافة معلومات عامة يعطي نتائج أفضل.

3. استخدام “مؤقت المحاولة”: متى تطلب المساعدة؟

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

عندما تواجه إحدى هذه المشاكل، خذ بعض الوقت لمحاولة حلها بنفسك. ستخبرك بعض الشركات بذلك كجزء من عملية الإعداد (onboarding) – شيء مثل “حاول لمدة 30 دقيقة قبل طلب المساعدة”. في شركات أخرى، ليس الأمر محددًا بوضوح، ولكن الرسالة لا تزال موجودة: ابذل قصارى جهدك ثم إذا كنت لا تزال عالقًا، اطلب المساعدة. هذا لا يمنحك الفرصة لحلها والتعلم بنفسك فحسب، بل يحترم أيضًا وقت زملائك في الفريق الذين يركزون على عملهم الخاص. مقاطعة شخص ما لشيء كان بإمكانك اكتشافه بسرعة بنفسك هو خسارة صافية للفريق. لذا حاول جيدًا، ثم بالطبع اطلب المساعدة!

إليك سر أن تكون مطورًا جديدًا رائعًا: أعد ضبط المؤقت دائمًا. لنفترض أنك علقت، حاولت لمدة 30 دقيقة، ثم طلبت المساعدة. في المرة التالية التي تعلق فيها، حاول مرة أخرى لمدة 30 دقيقة أخرى قبل طلب المساعدة. قد يبدو هذا واضحًا، ولكن في تلك الأيام التي تشعر فيها أنك لا تواجه سوى مشكلة تلو الأخرى، ستصاب بالإحباط وستبدأ في طلب المساعدة بمجرد ظهور المشكلة التالية – إنه أمر طبيعي. خذ نفسًا عميقًا، اذهب في نزهة قصيرة، وتعامل مع كل مشكلة بمنظور جديد. (هذا، بالطبع، أسهل قولًا من فعله!)

4. الاسترخاء وأخذ فترات راحة: إعادة شحن طاقتك

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

5. اسأل “البطة المطاطية”: تقنية تصحيح الأخطاء الذاتية

هل سبق لك أن كتبت بريدًا إلكترونيًا أو رسالة نصية تصف مشكلة تواجهها لشخص ما، وقبل أن تضغط على إرسال، تدرك الحل؟ في عالم البرمجيات، هناك عبارة لهذا – rubber duck debugging (تصحيح الأخطاء بالبطة المطاطية):

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

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

6. تدوين الملاحظات: لا تدع المعلومات تتسرب

قد تبدو هذه النصيحة واضحة… ولكن دوّن الملاحظات! ستتعرف على العديد من الأشياء المختلفة عندما تنضم إلى شركة لأول مرة: قواعد الكود، المنتجات، الأشخاص، منطق العمل (business logic)، وسيكون من المستحيل تذكر كل شيء. اكتب هذه الأشياء.

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

• TRY FOR 30MIN
• CHECK THE BUILD PASSES BEFORE ASKING FOR PR REVIEW
• MAKE SURE YOU HAVE LATEST CODE

7. مكافحة متلازمة المحتال يوميًا: أنت تنتمي إلى هنا

إذا كنت لا تعرف ما هي متلازمة المحتال (imposter syndrome)، فإنها تبدو هكذا في رأسك: “أنا لا أنتمي إلى هنا. أنا محتال. الجميع يفهم هذا سواي.” هذه عقلية يجب أن تحاربها يوميًا. ستكون هناك أوقات محبطة كمطور، ولكنك واجهت الإحباط بالفعل وتجاوزته. كل مطور شعر بهذا، وهذا أيضًا سيمر. في الواقع، تبدو متلازمة المحتال أشبه بهذا:

الفرق الجوهري بين المطور المبتدئ والمطور الخبير

بالتأكيد، يمتلك المطور الخبير معرفة وخبرة أكبر من المطور الجديد، ولكن هذا ليس ما يميزهما. المطور الخبير لديه نظام لحل المشكلات. عندما بدأت لأول مرة في التطوير، اعتقدت أنني سأتوقف في النهاية عن ارتكاب الأخطاء – وأنني سأتوقف عن مواجهة الأخطاء. حدث العكس. ما زلت أرتكب عددًا لا يصدق من الأخطاء كل يوم. بناء جمل خاطئ (Wrong syntax)، ملف خاطئ، دالة خاطئة. لم أتوقف عن ارتكاب الأخطاء – لقد أصبحت سريعًا بشكل لا يصدق في إصلاحها. هذه مهارة تتطور بمرور الوقت، وتتطلب حل المشكلات بشكل مقصود. إليك بعض النصائح حول كيفية بناء هذا النظام.

5 نصائح فعالة لتصحيح الأخطاء (Debugging)

1. لا تعبث بكودك عشوائيًا!

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

2. اقرأ رسالة الخطأ بعناية!

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

3. لا تضيع الوقت في المستحيل (أو غير المحتمل)!

هذا شيء أراه يفعله المطورون الجدد غالبًا. يواجهون خطأ في كودهم، يجدون شيئًا يعتقدون أنه المشكلة، ولا يمكنهم تصديق كيف أنه ليس صحيحًا. على سبيل المثال: “أرى أن المشكلة في السطر 14، حيث يتم التحقق مما إذا كان المتغير is_admin هو true، وهو ليس true – ولكن المستخدم مسؤول (admin)!!” يتعاملون مع هذه المشكلة بالتفكير، “كيف يمكن أن يكون هذا!!!” بدلاً من، “كيف يمكن أن يكون هذا؟” هناك أوقات ستواجه فيها خطأ في لغة أساسية أو إطار عمل (framework bug)، ولكن في 99.9% من الحالات، لقد فعلت شيئًا خاطئًا أو أن الموقف ليس كما يبدو. بدلاً من قضاء الوقت في التعجب من المستحيل الذي يتكشف أمام عينيك، شكك في افتراضاتك حول الموقف. هناك شيء ليس كما يبدو. الذهول من المستحيل هو مضيعة للوقت فقط – ابدأ نظام حل المشكلات الخاص بك.

4. “عند الشك، اطبع المزيد من المعلومات!”

لا أعرف من قال هذا في الأصل، لكنها إحدى أكثر تقنيات تصحيح الأخطاء فعالية. عندما لا تعرف ما يحدث، ابدأ في طباعة حالة برنامجك في الأماكن التي تعتقد أن المشكلة تحدث فيها. ما هو موجود في المتغير user؟ ما هي الاستجابة من طلب HTTP؟ هل اتخذنا فرع if أم فرع else في هذا الموقف؟ هل قمنا حتى باستدعاء هذه الدالة أو هل نحن حتى في هذه الصفحة؟ لقد رأيت عددًا لا يحصى من المطورين يحاولون تصحيح وإصلاح مشكلة (وقد فعلت ذلك مرات عديدة بنفسي أيضًا) عندما لم يكونوا يعملون حتى في الملف الصحيح! سيظهر لك أمر print أو console.log السريع أنك في الواقع تنظر إلى الكود الفعلي الذي يتم تشغيله.

5. خطوة بخطوة: بناء الكود بشكل تدريجي

خطأ شائع يرتكبه كل مطور جديد: يفعلون الكثير في وقت واحد. يريدون كتابة الكود لمدة 30 دقيقة، ثم النقر على تشغيل، ورؤيته يعمل. ما يجدونه هو أنهم قضوا 30 دقيقة في كتابة الأخطاء، وأصبح إصلاحها الآن كابوسًا. عندما أذهب لإنشاء صفحة جديدة في تطبيق، أول شيء أفعله هو وضع <p>hi</p> على الصفحة. أريد التأكد من أن جميع الأكواد الداخلية الخاصة بي تم إعدادها بشكل صحيح وأنني أرى hi على الصفحة. آخذها خطوة. بخطوة. افعل شيئًا واحدًا في كل مرة. اجعل “hi” يطبع على الصفحة. بعد ذلك، احصل على مدخلات المستخدم. بعد ذلك، تحقق من صحة المدخلات. بعد ذلك، احفظ المدخلات. إذا اتخذت خطوات صغيرة، فستعرف بالضبط مكان إصلاح المشكلة عند حدوثها. حتى بعد ثماني سنوات في مهنة التطوير، ما زلت أتبعها خطوة بخطوة. أعلم أنني سأرتكب الكثير من الأخطاء، وأريد أن أعرف فورًا متى وأين يحدث ذلك.

الخاتمة

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

إذا أعجبك هذا المقال، أكتب أشياء مماثلة على مدونتي هنا. شكرًا للقراءة! إذا قرأت إلى هذا الحد، اشكر المؤلف لإظهار اهتمامك. قل شكرًا. تعلم البرمجة مجانًا. ساعد منهج freeCodeCamp مفتوح المصدر أكثر من 40,000 شخص في الحصول على وظائف كمطورين. ابدأ.

الخلاصة التقنية

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