تقنية

كيف تكون مبرمجًا محترفًا؟ من متطلبات التغيير إلى مراجعته

مسار تغيير برمجي على فرع ينتهي بمراجعة ثم دمج
رسم تعليمي لمسار تغيير واحد؛ ليس سجل مشروع فعلي. عرض الرسم بالحجم الكامل.

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

اكتب شرط النجاح قبل الحل

افترض أن متجرًا تدريبيًا يريد خصم 10% من مجموع السلع عندما يبلغ 100 وحدة نقدية، وأن رسوم الشحن خارج هذا الشرط. اكتب هذه الجملة في وصف المهمة؛ عبارة «أضف خصمًا» وحدها تترك سؤالين مفتوحين: متى يبدأ، وعلى أي مبلغ يحسب؟

راجع التصميم والسلوك المقصود والحالات الطرفية. تدعو إرشادات Google إلى حل الحاجة الحالية وتجنب تعقيد لا تتطلبه، وإلى أسماء واضحة وتوثيق يتغير عندما يتغير استعمال البرنامج. [1]

اجعل التغيير قابلًا للتتبع

في مسار GitHub Flow، يُنشأ فرع للعمل، وتسجل تغييرات بوصف واضح قبل طلب المراجعة. يحتوي طلب المراجعة على المشكلة وما تغير، ويمكن متابعة التعليقات والفحوص قبل الدمج. [2]

في مثال المتجر، لا تخلط تعديل الخصم مع إعادة تسمية جميع الملفات وتغيير تصميم الصفحة. سمّ العمل بما يصفه، ثم اكتب السبب: «تطبيق حد الخصم على السلع دون الشحن». يستطيع المراجع عندها مقارنة الوصف بالسلوك الذي يراه.

اختبر الحد وما حوله

حالة الاختبار تفحص استجابة معينة لمدخلات محددة؛ هذا هو المعنى الذي تعرضه وثائق Python. وتوصي إرشادات Google بأن تكون الاختبارات مفيدة، وقادرة على كشف السلوك المعطوب، مع اختيار نوعها المناسب للتغيير. [3] [1]

للمتجر المؤلف، اختبر مجموع سلع 99 و 100 و 150. بلا شحن تكون المبالغ المستحقة 99 و 90 و 135 على الترتيب. ثم أضف شحنًا مقداره 8 إلى الحالة الوسطى: النتيجة 98، لأن الخصم طُبق على 100 فقط.

إن ظهرت 97.2 في الحالة الأخيرة، فافحص هل خصمت 10% من السلع والشحن معًا: 108 × 0.9 = 97.2. هذه نتيجة عملية مختلفة عن الشرط المكتوب. نجاح حساب واحد لا يكفي عندما تكون نقطة الخطأ في تعريف المدخل.

ثلاث حالات أصلية لحساب المبلغ المستحق حول حد خصم 100
حالات المتجر المؤلف: الحالتان 100 و 100 مع شحن تكشفان الحد ومجال الخصم. عرض الصورة بالحجم الكامل.

اطلب مراجعة تستطيع الاستفادة منها

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

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

تعلم من سجل التغييرات

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

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

المصادر ومتابعة القراءة

  1. Google Engineering Practices: ما الذي يفحصه مراجع الكود؟ (يفتح في نافذة جديدة)google.github.io
  2. GitHub Docs: مسار الفروع والتغييرات وطلبات المراجعة (يفتح في نافذة جديدة)docs.github.com
  3. Python: معنى حالة الاختبار في unittest (يفتح في نافذة جديدة)docs.python.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.