مستقبل البرمجة - مخلص محاضرة لروبرت مارتن بعنوان The Future of Programming
مقالة جاءتني في وقتها، وضع ضوابط لتطوير البرامج اصبح شغلي الشاغل هذه الأيام، حيث يعمل معنا مبرمجون شباب لديهم طاقة لكن بدون انضباط، في إحدى اﻷنظمة المهمة التي قمنا بتشغيلها قبل فترة كادت أن تؤدي إلى كارثة، لكن بفضل الله قمنا بتصحيح المسار في حوالي 3 أيام وتجاوزنا المشاكل الهيكلية في البرامج.
بكل سرور، لعل أن يستفيد من هذه التجربة غيرنا كما تعلمنا منها نحن.
النظام كان برنامج مركز اتصال ورعاية عملاء يعتمد على مقسم asterisk عندما تأتي مكالمة من العملاء تظهر معلوماتهم وآخر بلاغات قاموا بتسجيلها، ثم يسمح بتسجيل بلاغ جديد وسبب المكالمة، ويقوم النظام أيضاً بتسجيل المكالمة، كذلك يوجد عدد من التقارير وشاشات لمتابعة المستخدمين.
قمنا بتشغيله في مركز اتصال مزدحم بالاتصالات، أكثر من 500 مكالمة في اليوم. والنظام معقد جداً به أكثر من 5 خدمات ويب متصلة ببرامج مختلفة، وبرنامج ويب وبرنامج يعمل في الخلفية، وبرنامج آخر يعمل كل دقيقة.
كانت الخطة لإدخال عدد أكبر من المستخدمين يساوي أضعاف من يعملون بالنظام اﻵن، وربما تصل المكالمات في اليوم أكثر من 20 ألف مكالمة، لكن الحمد لله لم نستعجل في هذه الخطوة، وطلبنا من الزبون فترة لمراقبة أداء النظام.
بعد أسبوعين تقريباً، زاد حمل المخدم الذي تعمل فيه كل هذه البرامج فحدث له تعليق، ولم نستطع الوصول إليه، فطلبنا إعادة تشغيله، وكان ذلك بعد نهاية الدوام. فتمت اﻹعادة بعد ساعة أو اكثر من هذه المشكلة، ويُعتبر هذا زمن طويل جداً لتعطل الخدمة، إذ كان هُناك عدد كبير من المكالمات والعملاء لم يتم الرد عليهم. واستلمنا شكوى من الزبون، وكادت التجربة أن تفشل.
بعد إعادة تشغيل المخدم وعمل النظام بطريقة عادية، طلبت من المبرمجين توزيع خدمات الويب على مخدمات مختلفة - وهذه كانت الخطة من البداية أن يعمل كل جزء من النظام في مخدم مختلف- وطلبت منهم استخدام مخدم قاعدة بيانات آخر بطريقة master-slave ويقوموا بقراءة التقارير من الجهاز الـ slave بدلاً من إزعاج المخدم اﻷول master وتخصيصه للكتابة فقط، بهذه نخفف الضغط على قاعدة البيانات. وطلبت منهم وضع نظام الويب في مخدم آخر حتى لا تحدث هذه المشكلة مرة أخرى ولعزل المخدمات، فإذا حدث تعليق مثلاً في مخدم الويب يبقى مخدم الاتصالات asterisk يعمل ولا تتأثر المكالمات بذلك.
لكن للأسف لم يكن ذلك سهلاً حيث أن البرامج مرتبطة ببعضها بطريقة غير صحيحة وبعض عناوين المخدمات موجود داخل كود البرامج بدلاً من أن يكون خارجه، ففشل هذا الحل اﻹسعافي. فتنبهت أن التصميم الداخلي لهيكل النظام به خلل كبير.
فجعلت ابحث في النت عن الطريقة الصحيحة للبرمجة، وبعد البحث كتب موضوعاً يُعتبر ملخصاً لما قرأت والحلول التي كُنت استخدمها مع البرامج ذات العدد الكبير من المستخدمين. كتبت هذا الموضوع في مدونتي:
كذلك قُمت بكتابة ورقة باسم Development rules وجعلها شرطاً لطريقة كتابة البرامج. الجزء اﻷول يتناول التحديات، وبعضها مكتوب في تلك التدوينة، ثم الجزء الثاني يتناول أعراض البرامج المكتوبة بطريقة غير صحيحة، وقد كتبت 14 عرضاً، وكان جزء كبير منها موجود في ذلك النظام. ثم في النهاية كتبت الشروط الواجب مراعاتها في تصميم وكتابة البرامج بطريقة صحيحة، وقد كتبت 15 شرطاً وطلبت من المبرمجين الذين يعملون معنا تطبيقها في كل البرامج خصوصاً البرامج قيد التطوير.
والحمد لله بعد ثلاثة أيام قمنا تطبيق جزء كبير من هذه النصائح وتم توزيع النظام على عدد 4 مخدمات وقل الحمل على المخدم الواحد، واصبحنا مستعدين لإدخال عدد من المستخدمين واستقبال عدد أكبر من المكالمات.
هذا ليس البرنامج اﻷول الذي تحدث فيه مثل هذه المشاكل، لكن كان الحل سريعاً وهو التوزيع في أكثر من مخدم، لكن هذا النظام بالذات كانت به مشاكل في الهيكلية، لذلك استفدنا من هذه التجربة كثيراً ووضعنا بسببها قوانين جديدة. و مازلنا نضيف على هذه القوانين حسب الأحداث التي حدثت بعد ذلك وحسب اﻷمور التي وجدنا أنها مهمة.
كان دوري في أي نظام يتم تطويره هو أن أقوم بوضع هيكل له architecutre، لكن بما أننا نستخدم طريقة الـ Agile فتدخل أشياء جديدة لم تكن في الحسبان فيتغير ذلك الهيكل، فوجدت أنه لابد من عمل تقييم لهيكل النظام كل فترة للتأكد من أنه مازال متقيد الهيكل الصحيح للنظام.
طريقة البرمجة الرشيقة Agile هي مدرسة لطريقة تحليل وتطوير البرامج كدورة حياة كاملة. تصلح لنوع معين من التعاقدات مع الزبون. مثلاً زبون يريد عمل نظام في وقت قصير وليست لديه كامل الفكرة عن الاحتياجات الكلية، فقط لديه احتياجات مرحلية، فيتم تقسيم تطوير النظام إلى مراحل. وهي طريقة اسرع وأقل تعقيد ولا يوجد فيها مفاجئات للزبون مقارنة بالـ waterfall التي ينتظر فيها الزبون وقتاً طويلاً، يمكن أن يزيد عن العام ويُمكن أن يجد أن النظام الناتج يختلف عن ما يتوقعه أو ربما تحدث تغييرات في هذه الفترة تجعل ما تم الاتفاق عليه قد تغير.
جهد جميل، وتدوينة جيدة ايضا. لاحظت أنك توصلت للمبدأ SOLID بطريقة أو بأخرى :)
قمت بحفظ هذه الورقة، وإن شاء الله سوف أقرأها لاحقاً. وقد دلني على هذا المبدأ من قبل الأخ @عبد الرحمن أحمد
التعليقات