تحليل الأخطاء النموذجية للمبرمجين المبتدئين: الجزء الأول

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

1. الخوف من طلب المساعدة من الزملاء الأكثر خبرة

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

2. لا تحاول البحث عن المعلومات بنفسك

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

3. النسخ واللصق الأعمى

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

4. رمي الحل الخاطئ

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

5. الخوف من طرح الأسئلة حول المهمة الحالية

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

6. توقع الكثير من قائد الفريق

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

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

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

7. الخوف من مراجعة الكود

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

8. الميل إلى الحلول الغامضة

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

9. اختراع الدراجات

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

10. لا تكتب الاختبارات

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

11. المبالغة في التعليق

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

Cat cat = new Cat(); // cat Object

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

12. تسمية سيئة

في كثير من الأحيان، يقوم المبتدئون بتزوير أسماء الفئات والمتغيرات والأساليب وما إلى ذلك. على سبيل المثال، عندما يقومون بإنشاء فئة لا يصف اسمها الغرض منها على الإطلاق. أو يتم إنشاء متغير باسم قصير، مثل x ، وعندما يتم إنشاء متغيرين آخرين باسم n و y ، يصبح من الصعب جدًا تذكر ما يفعله x . في مثل هذه الحالات، عليك التفكير بعناية في الكود ودراسة هذه الوظيفة تحت المجهر (ربما باستخدام مصحح الأخطاء) من أجل فهم ما يحدث هناك ببساطة. هذا هو المكان الذي تساعدنا فيه التسمية الصحيحة في الكود الذي ذكرته أعلاه. تعمل الأسماء الصحيحة على تحسين إمكانية قراءة التعليمات البرمجية، وبالتالي توفير الوقت في التعرف عليها، لأنه من الأسهل بكثير استخدام طريقة يصف فيها الاسم وظيفته تقريبًا. في الكود، كل شيء يتكون من أسماء (المتغيرات، الأساليب، الفئات، كائنات الملفات، وما إلى ذلك)، تصبح هذه النقطة مهمة جدًا عند إنشاء كود صحيح ونظيف. ومن الجدير بالذكر أن الاسم يجب أن ينقل المعنى: على سبيل المثال، لماذا يوجد المتغير وماذا يفعل وكيف يتم استخدامه. وسوف أشير مرارًا وتكرارًا إلى أن أفضل تعليق لوصف المتغير هو اسمه الصحيح. للحصول على دراسة أعمق للتعليقات والتسمية الصحيحة، أنصحك بقراءة الكتاب الكلاسيكي الخالد: “Clean Code. الخلق والتحليل وإعادة البناء "، روبرت مارتن . وبهذا يكون قد انتهى الجزء الأول من هذه المقالة (تأملات). يتبع…