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

سأكون سعيداً لو كتبت عن تجربتك هذه (الكارثة التي كادت أن تحدث) أخ معتز لو لم يكن يزعجك هذا الأمر؟ فالفضول وحب المعرفة يقتلني، أريد معرفة التجارب التي مرّ بها من قبلي لكي يكون لي على الأقل خلفية عن الموضوع.

10

بكل سرور، لعل أن يستفيد من هذه التجربة غيرنا كما تعلمنا منها نحن.

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

قمنا بتشغيله في مركز اتصال مزدحم بالاتصالات، أكثر من 500 مكالمة في اليوم. والنظام معقد جداً به أكثر من 5 خدمات ويب متصلة ببرامج مختلفة، وبرنامج ويب وبرنامج يعمل في الخلفية، وبرنامج آخر يعمل كل دقيقة.

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

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

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

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

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

https://abueyas.wordpress.com/2016/02/06/good-programming/

كذلك قُمت بكتابة ورقة باسم Development rules وجعلها شرطاً لطريقة كتابة البرامج. الجزء اﻷول يتناول التحديات، وبعضها مكتوب في تلك التدوينة، ثم الجزء الثاني يتناول أعراض البرامج المكتوبة بطريقة غير صحيحة، وقد كتبت 14 عرضاً، وكان جزء كبير منها موجود في ذلك النظام. ثم في النهاية كتبت الشروط الواجب مراعاتها في تصميم وكتابة البرامج بطريقة صحيحة، وقد كتبت 15 شرطاً وطلبت من المبرمجين الذين يعملون معنا تطبيقها في كل البرامج خصوصاً البرامج قيد التطوير.

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

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

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

جزاك الله خيراً على الشرح والتفاصيل المفيدة. قرأت المقالة سابقاً واستفدت منها بالفعل، شكراً جزيلاً :)

طريقة الـ Agile فتدخل أشياء جديدة لم تكن في الحسبان فيتغير ذلك الهيكل

هل طريقة Agile هي عبارة عن Architecture من مجال هندسة البرمجيات؟ ومتى تنصح بتعلم هذه الطريقة؟ هل فقط في الأنظمة المعقدة؟ أم يمكن أن تفيد في أي نوع من الأنظمة حتّى لو كان موقع إلكتروني؟

شكراً مرة أخرى.

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

جهد جميل، وتدوينة جيدة ايضا. لاحظت أنك توصلت للمبدأ SOLID بطريقة أو بأخرى :)

https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

قمت بحفظ هذه الورقة، وإن شاء الله سوف أقرأها لاحقاً. وقد دلني على هذا المبدأ من قبل الأخ @عبد الرحمن أحمد

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

هذه كلها أمثلة للمستقبل. الحياة ستصبح صعبة بطريقة سهلة :)

شكراً على نشر المقالة أخي :)

الرابط لا يعمل معي للأسف

@khelll إذا الصفحة بيضاء حاول أن تعمل تحديث بدون كاش (Ctrl+Shift+R). نعلم بهذا الخطأ ونعمل على إصلاحه.

إذا لم يساعد أخبرنا ما المشكلة بالتفصيل.

برمجة

المواضيع والنقاشات المتعلقة بالبرمجة بشكل عام او لغات البرمجة التي لايوجد لها مجتمعات فرعية.

16.3 ألف متابع