سير العمل الخفي لمطوري البرمجيات المحترفين
يعتقد معظم الناس أن تطوير البرمجيات مجرد كتابة أكواد برمجية. يتخيلون شخصاً يكتب بسرعة على شاشة مظلمة. هذا يمثل 20% فقط من العمل.
أما الـ 80% المتبقية فهي غير مرئية. إنها تحدث قبل أن تكتب سطراً واحداً. هذا العمل هو ما يميز المحترفين عن الأشخاص الذين يقضون يومهم بالكامل في إصلاح أخطائهم الخاصة.
يقضي كبار المطورين ما بين 20% إلى 40% من وقتهم في التخطيط. هذا ليس تسويفاً، بل هو إدارة للمخاطر. فتغيير الكود يصبح مكلفاً بمجرد أن يصبح قيد التشغيل (live).
تبدو مرحلة التخطيط السليمة كالتالي:
• أعد صياغة المشكلة بأسلوبك الخاص. إذا لم تتمكن من شرحها ببساطة، فأنت لم تفهمها بعد. • حدد القيود. فكر في السرعة، والمواعيد النهائية، والأنظمة الحالية. • ارسم مخططاً للحل. استخدم نقاطاً أو رسوماً بيانية بسيطة لرؤية كيفية تدفق البيانات. • حدد الأمور غير المعروفة. اكتشف ما تحتاج إلى البحث عنه قبل البدء.
يقضي المطورون المحترفون أيضاً الكثير من الوقت في قراءة التوثيق (documentation). فهم لا يكتفون بمجرد تصفح الإجابات في المنتديات، بل يقرأون مراجع الـ API الرسمية والكود المصدري (source code). يساعدهم هذا على تجنب الأساليب القديمة والمعطلة، واكتشاف الحالات الاستثنائية (edge cases) التي تسبب أخطاءً (bugs) في بيئة التشغيل (production).
قبل البدء بمهمة كبيرة، جرب هذه العادات:
• استعرض الحلول الموجودة. لا تبنِ ما هو موجود بالفعل. • قيم المقايضات (trade-offs). قرر أي أداة تناسب احتياجاتك المحددة. • قم بعمل نموذج أولي (prototype) للأجزاء المحفوفة بالمخاطر. اكتب نصاً برمجياً اختبارياً صغيراً لترى ما إذا كانت الفكرة تعمل. • اسأل زملائك في الفريق. محادثة لمدة خمس دقائق قد توفر ساعات من العمل.
عندما تبدأ أخيراً في كتابة الكود، تذكر جمهورك. جمهورك هو الشخص التالي الذي سيقرأ عملك. وقد يكون هذا الشخص هو أنت بعد ستة أشهر.
اكتب كوداً نظيفاً (clean code):
• استخدم أسماءً دقيقة. تجنب الأسماء العامة مثل "data"، واستخدم "pendingInvoices" بدلاً منها. • اجعل الدوال (functions) صغيرة. يجب أن تقوم الدالة بشيء واحد وبإتقان. • اكتب تعليقات تشرح "لماذا" وليس "ماذا". فالكود يوضح ما يفعله، بينما يجب أن تشرح التعليقات المنطق وراء ذلك. • اتبع أنماط الفريق. الاتساق أهم من التفضيلات الشخصية.
مراجعة الكود (Code reviews) أمر حيوي أيضاً. فهي ليست مجرد مهمة روتينية لإتمامها، بل هي وسيلة لمشاركة المعرفة واكتشاف المخاطر. تركز المراجعة الجيدة على القصد والمنطق بدلاً من مجرد التركيز على بناء الجملة (syntax).
الهندسة الحقيقية تحدث في التفكير، والقراءة، والبحث. أما الكتابة فهي مجرد الخطوة الأخيرة.
المصدر: https://dev.to/lui_were/the-hidden-workflow-of-professional-software-developers-1d74