عندما يغيّر تعديل صغير هيكل البرمجيات بالكامل

من التجارب التي اكتسبتها في تصميم وتطوير البرمجيات، تجربة تتعلق بنظام قسائم الرواتب الإلكتروني الذي صممته للشركات والمؤسسات.

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

في البداية، كان هيكل ملف Excel محددًا وثابتًا، ولذلك تم تصميم النظام بناءً على هذا الهيكل.

بعد عدة أشهر، اتصل بي قسم المحاسبة في إحدى المؤسسات وأخبرني أن قسم تكنولوجيا المعلومات في المؤسسة قد غيّر هيكل ملف Excel. فلم يعد الملف الجديد يعتمد على الهيكل العمودي السابق، بل أصبح مقدمًا على شكل مصفوفة.

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

بعد دراسة الموضوع، قررت بدلًا من مطالبتهم بتحويل البيانات إلى التنسيق السابق، أن أجعل البرنامج نفسه متوافقًا مع الظروف الجديدة.

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

وفي الوقت نفسه، كانت هناك مسألة مهمة أخرى.

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

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

لكن هذه لم تكن نهاية القصة.

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

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

وكان أحد أهدافي أن لا يضطر العميل إلى دفع تكلفة إضافية لتعديل البرنامج كلما طرأ تغيير صغير.

والمثير للاهتمام أن محاسب الشركة أخبرني بعد فترة أن قدرة النظام على تحويل هيكل Excel الجديد والمصفوفي إلى قسائم رواتب لفتت أيضًا انتباه المسؤولين الفنيين في المستويات الأعلى من المؤسسة وأثارت إعجابهم.

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

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

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

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

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

وفي النهاية، تحوّل تغيير إجباري تسبب في البداية بمشكلة للعميل إلى تجربة قيّمة بالنسبة إليّ؛ تجربة استفدت منها في تصميم الإصدارات اللاحقة من المنتج نفسه ومنتجات أخرى أيضًا.