تطوير البرمجيات المخصصة : إصلاح الأنظمة القديمة وقواعد البيانات

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

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

أهم النقاط

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

ما هو الدين التقني بكلمات بسيطة

صاغ المبرمج Ward Cunningham مصطلح «الدين التقني» لوصف اختيار بسيط: حين يسلّم فريق برنامجًا يشتغل اليوم لكنه سيكون أصعب في التعديل غدًا، فهو يقترض وقتًا من المستقبل. مثل الدين المالي، قد يكون هذا اختيارًا معقولًا في البداية. ومثل الدين المالي أيضًا، له فوائد تتراكم: كل تعديل لاحق يأخذ وقتًا أطول، ويتسبب في أعطال أكثر، ويكلف أكثر. ويقدم Martin Fowler شرحًا واضحًا لهذه الفكرة في مقاله Technical Debt.

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

كيف يتراكم في الشركات النامية

في الشركات التي نشتغل معها، القصة تتكرر تقريبًا بنفس الشكل:

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

لا توجد خطوة من هذه الخطوات خاطئة في حد ذاتها. لكنها مجتمعة تنتج نظامًا لا تستطيع الشركة الاستغناء عنه، ولا تستطيع تعديله دون خوف.

العلامات التي تقول إن الإصلاح أصبح ضروريًا

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

ما يلاحظه المستعملون

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

ما يظهر في الجانب التقني

• النظام يشتغل على نسخة من PHP أو Windows Server أو قاعدة بيانات لم تعد تتلقى تحديثات أمنية. بالنسبة للغة PHP مثلًا، ينشر المشروع قائمة النسخ التي ما زالت مدعومة.
• لا توجد أي اختبارات آلية، فكل تعديل يُجرَّب يدويًا، أو لا يُجرَّب أصلًا.
• النسخ الاحتياطية موجودة، لكن لم يحاول أحد استرجاعها للتأكد من أنها تشتغل.
• كلمات المرور مكتوبة داخل الشيفرة، أو مشتركة بين عدة أشخاص.
• لا أحد يعرف بالضبط على أي خادم يشتغل النظام، ولا من يملك الدخول إليه.

ما يظهر في التنظيم

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

إذا وجدتم ثلاث علامات أو أكثر في نظامكم، فالسؤال لم يعد هل يجب التدخل، بل هل سيكون التدخل مخططًا له أم مفروضًا بعد حادث كبير.

كم يكلفكم الانتظار

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

• وقت الموظفين. كل دقيقة انتظار أمام تقرير بطيء، وكل ملف إكسيل موازٍ، وكل رقم يُراجع يدويًا لأن النظام لم يعد موثوقًا، تُدفع من الأجور.
• مداخيل متأخرة. فواتير لا يمكن إصدارها لأن النظام توقف في آخر الشهر، أو تصدر متأخرة، فيتأخر معها التحصيل.
• مشاريع معطلة. بوابة للزبناء، موقع جديد، أو تطبيق للفرق الميدانية: كلها مستحيلة ما دام قلب النظام لا يتحمل.
• خطر الحوادث. خادم غير محدَّث أو مكتبة غير مصححة باب مفتوح. هجوم فدية أو قاعدة بيانات تالفة بدون نسخة احتياطية صالحة قد يوقف العمل لأيام.

مثال توضيحي بالأرقام: عشرة موظفين يخسر كل واحد منهم عشرين دقيقة يوميًا بسبب البطء والحلول الجانبية، يجمعون أكثر من 70 ساعة في الشهر. بتكلفة متوسطة تبلغ 60,00 MAD للساعة، هذا يعني أكثر من 4 000,00 MAD شهريًا، كل شهر، قبل احتساب أي حادث. الأرقام للتوضيح، لكنها تفسر لماذا يسترجع تطوير البرمجيات المخصصة الموجّه للإصلاح تكلفته أسرع مما يتوقعه أصحاب الشركات.

أنواع الأنظمة التي نصلحها

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

• تطبيقات ويب بلغة PHP طُوّرت قبل سنوات، أحيانًا بدون إطار عمل، وتشتغل على نسخة قديمة من اللغة أو من MySQL.
• قواعد بيانات Microsoft Access أصبحت تُستعمل من طرف عدة أشخاص عبر الشبكة، وتتلف أو تبطؤ كلما كبرت.
• برامج تسيير تجاري أو مخزون مثبتة على حاسوب واحد في المكتب، بدون نسخ احتياطية منتظمة.
• ملفات إكسيل بماكروهات VBA تحولت مع الوقت إلى «نظام» حقيقي لا يفهمه إلا من كتبه.
• مواقع ومنصات WordPress مثقلة بالإضافات، بطيئة، ولم تُحدَّث منذ مدة.

في كل هذه الحالات، تطوير البرمجيات المخصصة يبدأ بنفس السؤال: ما الذي يجب إنقاذه، وما الذي يجب تعويضه؟

الإصلاح أم إعادة البناء من الصفر؟

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

نقرر حالة بحالة، بناءً على أربعة أسئلة:

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

منهجيتنا في تطوير البرمجيات المخصصة للإصلاح

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

المرحلة الأولى : تدقيق مكتوب

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

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

المرحلة الثانية : إيقاف النزيف

بعض المخاطر لا تحتمل الانتظار. الإصلاحات الأولى هي دائمًا نفسها:

• نسخ احتياطية تُسترجع فعلًا. نسخ تلقائي لقاعدة البيانات والملفات، ثم استرجاعها على خادم منفصل لإثبات أنها تشتغل.
• تنظيف الصلاحيات. حذف الحسابات القديمة، وتغيير كلمات المرور المشتركة، وإخراج المفاتيح من الشيفرة، وحصر صلاحيات الإدارة فيمن يحتاجها.
• التصحيحات الأمنية العاجلة. الثغرات المعروفة في الخادم ولغة البرمجة والمكتبات تُصحَّح حسب الأولوية، بالاعتماد على مراجع مثل قائمة OWASP Top 10.
• المراقبة. تنبيه يصل حين يتوقف النظام، أو حين تكثر الأخطاء، أو حين يقترب القرص من الامتلاء.

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

المرحلة الثالثة : جعل التعديل آمنًا

مشاريع تطوير البرمجيات المخصصة تتعثر حين يصبح كل تعديل مخيفًا. لذلك نؤمّن التعديل أولًا:

• إدارة النسخ. كل الشيفرة توضع في مستودع يحفظ تاريخ كل تغيير.
• بيئة اختبار. نسخة من النظام الحقيقي ببيانات مجهولة الهوية، تُجرَّب فيها التعديلات قبل أن تصل إلى المستعملين.
• اختبارات على المسارات الحرجة. ليس تغطية كاملة من اليوم الأول، بل فحوص آلية لما يجب ألا يتعطل أبدًا: إصدار فاتورة، تسجيل تسليم، حساب المخزون.
• التوثيق. طريقة التثبيت والنشر والاسترجاع مكتوبة بوضوح، حتى لا يبدأ الشخص التالي من الصفر.

المرحلة الرابعة : إصلاح ما يؤلم أكثر

مع شبكة الأمان هذه، نشتغل على قائمة الأولويات التي حددها التدقيق. في الواقع، أكبر المكاسب تأتي غالبًا من قاعدة البيانات.

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

المرحلة الخامسة : إعادة الهيكلة تدريجيًا

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

ما يميز الأنظمة في المغرب والخليج

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

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

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

ما الذي يتغير في الشركة بعد الإصلاح

• السرعة. الشاشات والتقارير التي تعوّد الموظفون على انتظارها تستجيب بسرعة من جديد.
• الاستقرار. آخر الشهر يمر دون أزمة. التوقفات تصبح نادرة، وتُكتشف قبل أن يبلّغ عنها المستعملون.
• الأمان. النظام يشتغل على برمجيات مدعومة، بصلاحيات مضبوطة ونسخ احتياطية مُثبتة.
• حرية التطوير. الطلبات الجديدة تُقدَّر وتُنجز بدل أن تُرفض.
• الاستقلالية. النظام موثق، ولم يعد يعتمد على ذاكرة شخص واحد.

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

حماية المعطيات الشخصية والقانون 09-08

الأنظمة القديمة تحتوي غالبًا على معطيات شخصية: أسماء الزبناء وأرقام هواتفهم، ملفات الموظفين، وأحيانًا معلومات مرضى أو نزلاء. في المغرب، معالجة هذه المعطيات يؤطرها القانون 09-08 تحت مراقبة اللجنة الوطنية لمراقبة حماية المعطيات ذات الطابع الشخصي. النظام الذي يشتغل على برمجيات غير محدَّثة، بكلمات مرور مشتركة ونسخ احتياطية لم تُختبر، يجعل من الصعب إثبات أن هذه المعطيات محمية.

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

تطوير البرمجيات المخصصة كخدمة مستمرة

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

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

كيف تحضّرون للتدقيق

يمكنكم تسريع المرحلة الأولى من تطوير البرمجيات المخصصة بجمع ما لديكم:

1. أي صلاحيات دخول تملكونها إلى الخادم، وحساب الاستضافة، واسم النطاق، وقاعدة البيانات.
2. معلومات الاتصال بالمطوّر أو المزود السابق، إن وُجد.
3. قائمة بالمشاكل التي يشتكي منها المستعملون أكثر، بكلماتهم.
4. أي توثيق، حتى لو كان ناقصًا أو قديمًا.
5. التقارير والوثائق التي لا تستطيع الشركة الاستغناء عنها.

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

مورّد مسجَّل يمكن الاعتماد عليه

مسكيكّود هو الاسم التجاري لعبد المالك مسكيك، المصرّح به بالمغرب في نظام المقاول الذاتي (ICE 003938004000054، IF 72025361، TP 47535774). نُصدر فواتير رسمية مختومة، والدفع يتم عبر تحويل بنكي محلي لدى التجاري وفا بنك. نظام المقاول الذاتي، الضريبة على القيمة المضافة غير مطبقة. كل الوثائق في ملف المورد.

أسئلة متكررة حول تطوير البرمجيات المخصصة

الخطوة التالية

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

بقلم عبد المالك مسكيك، الرئيس التنفيذي | المؤسس والمدير التنفيذي للعمليات (COO)، مسكيكّود.