تحليل الأخطاء الشائعة التي يرتكبها المبرمجون المبتدئون، ص. 1

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

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

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

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

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

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

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

4. التمسك بالحل الخاطئ

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

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

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

6. وضع توقعات عالية بشكل غير واقعي على قائد الفريق

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

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

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

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

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

8. الميل إلى اتخاذ قرارات غامضة

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

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

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

10. الفشل في كتابة الاختبارات

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

11. التعليقات المفرطة

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

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

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

12. التسمية السيئة

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