مطور كامل متقدم حائز على جوائز حول كيفية تحديث فرق الهندسة للمنصات القديمة، وتوسيع نطاق أنظمة المؤسسات لأحمال العمل الثقيلة، وتقديم بنى مرنة دون فقدان سرعة التطوير.
مع تسارع المؤسسات في التحول الرقمي، تكتشف العديد من فرق الهندسة أن أكبر عائق لها هو البنية التحتية القديمة التي لا تزال تعتمد عليها. وفقًا لـ Pegasystems، يقول 68% من صناع القرار في تكنولوجيا المعلومات في المؤسسات أن المنصات والتطبيقات القديمة تمنع مؤسساتهم من تبني التقنيات الحديثة بالكامل. لفهم أفضل لكيفية تغلب فرق الهندسة على هذه التحديات عمليًا، تحدثنا مع عبد العزيز عبد الحليموف، مطور كامل متقدم حائز على جوائز ولديه أكثر من عقد من الخبرة في تحويل الأنظمة الهشة تقنيًا إلى منصات قابلة للتوسع ومرنة.
ابتكر عبد العزيز طرقًا لتحديث أنظمة تخطيط موارد المؤسسات (ERP) القديمة والأنظمة المالية في شركة SoftClub عن طريق تحويلها إلى خدمات صغيرة نمطية. في شركة Barso LLC، طور منصة مؤسسية سحابية أصلية تخدم أكثر من 100,000 مستخدم. كما قاد نشر منصة تعليمية وطنية قائمة على Moodle في أوزبكستان، مما مكّن الطلاب والمعلمين من العمل عبر الإنترنت من خلال نظام يتطلب أداءً مستقرًا، وإصدارات موثوقة، وتكرارًا سريعًا ولكن آمنًا. في حديثنا مع عبد الحليموف، ناقشنا ما يتطلبه تحديث المنصات القديمة، وكيف يمكن لفرق الهندسة توسيع نطاق أنظمة المؤسسات دون المساس بموثوقية النظام وقابليته للصيانة، ولماذا غالبًا ما يكون الانضباط المعماري أكثر أهمية من اختيار التكنولوجيا.
عبد العزيز، اليوم، العديد من الشركات تحت ضغط لتحديث الأنظمة الأساسية. من وجهة نظرك، ما هو أكبر خطأ ترتكبه الفرق عندما تبدأ في تحديث منصة قديمة؟
أكبر خطأ هو التعامل مع التحديث كترقية تكنولوجية بدلاً من قرار معماري حاسم للأعمال. تبدأ العديد من الفرق بفكرة أنها تحتاج ببساطة إلى الانتقال من نظام متكامل إلى خدمات صغيرة، أو من البنية التحتية المحلية إلى الحاويات، دون فهم أولاً أين تكمن نقاط الألم التشغيلية الحقيقية.
في الممارسة العملية، عادة ما تفشل الأنظمة القديمة تحت التغيير قبل أن تفشل تحت التوسع. غالبًا لا تكمن المشكلة في أن المنصة لا تستطيع العمل، ولكن في أن كل ميزة جديدة أو إصلاح أو تكامل يصبح أبطأ وأكثر خطورة وأصعب في الاختبار. إذا بدأ فريق التحديث بالتركيز على الأدوات فقط، فقد ينتهي به الأمر إلى إعادة بناء نفس المشاكل في شكل أكثر توزيعًا.
نقطة البداية الأفضل هي تحديد أين يخلق النظام الحالي أكبر قدر من الاحتكاك: اختناقات الإصدار، أو الوحدات المترابطة بإحكام، أو التبعيات غير المستقرة، أو المناطق التي يكون فيها الأداء والقابلية للصيانة بالفعل في تعارض. بمجرد أن تصبح نقاط الضغط هذه واضحة، يصبح التحديث أكثر انضباطًا. يتوقف عن كونه جهد هجرة غامض ويصبح تسلسلًا من قرارات الهندسة المستهدفة.
لقد حصلت على المركز الأول في تحدي البيانات المفتوحة وحصلت على تصنيف أعلى في تحدي Best Soft في وقت مبكر من حياتك المهنية. كيف شكلت هذه التجارب الطريقة التي تتعامل بها مع مشاكل الهندسة واسعة النطاق لاحقًا؟
ساعدتني المنافسة في تلك المرحلة من مسيرتي المهنية على بناء عادة التفكير بما يتجاوز الحل التقني السريع. تعلمت النظر إلى كيفية صمود الحل مع زيادة التعقيد، ومع اعتماد المزيد من الأشخاص عليه، ومع ضرورة استمرار النظام في التطور. بقي هذا المنظور معي في العمل المهني. بدلاً من التركيز على ما هو رائج، أنظر أولاً إلى ما إذا كان النظام منظمًا بوضوح، وما إذا كان يمكن دعمه دون احتكاك مستمر، وما إذا كان سيظل موثوقًا به مع نمو المتطلبات.
في شركة SoftClub، عملت على تحديث المؤسسات وساعدت في ترحيل أنظمة ERP والأنظمة المالية والموارد البشرية القديمة إلى خدمات صغيرة نمطية. أدى عملك إلى تطبيقات مؤسسية أكثر قابلية للتوسع، وتحسين القابلية للصيانة، واعتماد أوسع للسحابة. كيف تحدد ما إذا كان يجب إعادة هيكلة نظام متكامل تدريجيًا؟
علمتني تلك التجربة أن القرار يعتمد على ما إذا كان النظام الحالي لا يزال يمكن فصله إلى وحدات ذات معنى دون كسر منطق الأعمال. التحدي الرئيسي عادة ليس العمر وحده. إنه كثافة التبعيات المتراكمة بمرور الوقت.
إذا كان النظام لا يزال يسمح لك بعزل المجالات الوظيفية، وتثبيت الواجهات بينها، وتحسين جزء واحد دون إزعاج الباقي باستمرار، فإن إعادة الهيكلة التدريجية عادة ما تكون المسار الأقوى. هذا النهج مفيد بشكل خاص عندما تكون المنصة حاسمة للأعمال ولا يمكنها تحمل مخاطر التسليم لاستبدال كل شيء دفعة واحدة. تصبح إعادة الكتابة الكاملة أكثر واقعية عندما لا تدعم البنية حدودًا واضحة بعد الآن، وعندما يستمر تغيير واحد في التأثير على مناطق غير ذات صلة، وعندما تستمر القابلية للصيانة في التراجع حتى بعد التحسينات المستهدفة. في تلك الحالة، يتوقف النظام عن الاستجابة للتحديث كتسلسل من الخطوات المنضبطة.
لذا فإن الاختبار الحقيقي ليس ما إذا كان النظام المتكامل قديمًا. بل ما إذا كان لا يزال يمنح فريق الهندسة سيطرة هيكلية كافية لتحسين قابلية التوسع والقابلية للصيانة في الأجزاء. إذا كانت تلك السيطرة لا تزال موجودة، فإن إعادة الهيكلة تعمل. إذا كانت قد اختفت، تصبح إعادة الكتابة القرار الأكثر أمانًا على المدى الطويل.
كمطور كامل متقدم في شركة Barso LLC، ساعدت في بناء منصة مؤسسية سحابية أصلية، مما حسّن أداء النظام بنسبة 40%. بناءً على تلك التجربة، ما هي قتلة الأداء الصامتين الأكثر شيوعًا التي تراها في بيئة Spring Boot؟
العديد من مشاكل الأداء لا تسببها الخوارزميات بل قرارات البنية.
أحد المشاكل الشائعة هو عمليات الحظر المخفية. قد تبدو الخدمة غير متزامنة ولكنها لا تزال تعتمد على مكالمات قاعدة البيانات المحظورة أو واجهات برمجة التطبيقات الخارجية. تحت حركة المرور الثقيلة، تستهلك هذه المكالمات مجمعات الخيوط، مما يتسبب في تأخيرات متتالية. مشكلة أخرى متكررة هي التواصل المفرط بين الخدمات. تصبح الخدمات الصغيرة أحيانًا ثرثارة للغاية، مع مكالمات متزامنة متعددة داخل طلب مستخدم واحد. حتى التأخير الصغير في كل مكالمة يتراكم بسرعة. أنماط الوصول إلى قاعدة البيانات مهمة أيضًا. الاستعلامات غير الفعالة، أو الفهارس المفقودة، أو الاستخدام المفرط لـ ORM يمكن أن يخلق اختناقات تظهر فقط تحت حمل الإنتاج. أخيرًا، غالبًا ما يتم التقليل من قيمة المراقبة. بدون مقاييس وتتبع مناسبين، تكافح الفرق لتحديد أي مكون يسبب فعليًا تدهور الأداء. هندسة الأداء تبدأ بالرؤية.
قمت بتطوير بنية مدفوعة بالأحداث باستخدام Apache Kafka و RabbitMQ لدعم منصة تخدم أكثر من 100,000 مستخدم نشط، مما حسّن قابلية التوسع وتحمل الأخطاء وموثوقية النظام. في تجربتك، في أي ظروف تعزز البنية المدفوعة بالأحداث حقًا المرونة وقابلية التوسع؟
الأنظمة المدفوعة بالأحداث قوية عندما يجب أن تظل الخدمات مترابطة بشكل فضفاض ولكن تتبادل معلومات حاسمة. على سبيل المثال، إذا كانت أنظمة فرعية متعددة تعتمد على نفس الحدث، مثل معاملة مالية أو نشاط مستخدم، فإن نشر هذا الحدث إلى وسيط رسائل يسمح لكل خدمة بمعالجته بشكل مستقل. هذا يقلل من التبعيات المباشرة بين الأنظمة.
ميزة أخرى هي المرونة. إذا أصبحت خدمة لاحقة غير متاحة مؤقتًا، يمكن وضع الرسائل في قائمة انتظار ومعالجتها لاحقًا دون فقدان البيانات. ومع ذلك، لا ينبغي اعتماد بنية الأحداث بشكل أعمى. بالنسبة لسير العمل الذي يتطلب اتساقًا فوريًا أو منطق طلب-استجابة بسيط، يمكن أن يكون التواصل المتزامن أوضح وأسهل في الصيانة. الهدف ليس زيادة عدد التقنيات في المجموعة إلى الحد الأقصى، بل استخدام الأنماط غير المتزامنة حيث تحسّن بالفعل تحمل الأخطاء وقابلية التوسع.
قدت نشر منصة تعليم إلكتروني قائمة على Moodle في جميع أنحاء أوزبكستان، مما مكّن الجامعات من مواصلة التدريس عن بُعد وحصل على تقدير من وزارة التعليم العالي. عندما تحتاج منصة فجأة إلى خدمة أعداد كبيرة من الطلاب والمعلمين، كيف توازن فرق الهندسة بين السرعة والموثوقية؟
مواقف كهذه تجبر الفرق على إعطاء الأولوية للاستقرار وإمكانية الوصول فوق البنية المثالية.
أحد المبادئ الأساسية هو التركيز على رحلة المستخدم الحاسمة. بالنسبة لمنصة تعليمية، هذا يعني تسجيل الدخول، والوصول إلى الدورة، والتواصل بين الطلاب والمعلمين. يمكن تأجيل الميزات الثانوية إذا لزم الأمر. تصبح البنية التحتية أيضًا أولوية. يتطلب التوسع السريع موازنة تحميل موثوقة، وتحسين قاعدة البيانات، ومراقبة دقيقة لاكتشاف الفشل مبكرًا.
درس آخر هو أن التواصل الواضح داخل فريق الهندسة يصبح بنفس أهمية الكود نفسه. عندما تتسارع دورات النشر، يساعد التنسيق على منع التغييرات المتضاربة التي يمكن أن تزعزع استقرار النظام. في البيئات عالية الضغط، تصبح الهندسة الضمانة الأساسية ضد الفوضى.
طوال حياتك المهنية، عملت على تحديث أنظمة المؤسسات، وبناء منصات سحابية أصلية، ودعم التطبيقات عالية التحميل. بناءً على هذا التقدم، ماذا يعني مصطلح مطور كامل فعليًا الآن؟
ما كان يصف شخصًا يتعامل مع كود جانب العميل وجانب الخادم يغطي الآن أكثر من ذلك بكثير. يتضمن الدور بشكل متزايد رؤية كيفية عمل المنتج من البداية إلى النهاية، من سلوك الواجهة ومنطق التطبيق إلى سير عمل الإصدار، ورؤية النظام، والأداء بعد الإطلاق. المهندس القوي في هذا المجال لا يقتصر على الترميز وحده. كما يحتاجون إلى فهم البيئات السحابية، وخطوط التسليم، وسلوك وقت التشغيل، والجانب التشغيلي للبرمجيات. أصبحت الوظيفة أوسع وأكثر ارتباطًا بكيفية أداء التكنولوجيا في ظروف الأعمال الحقيقية.
بعد العمل على منصات المؤسسات التي حققت مكاسب أداء قابلة للقياس ودعمت العمليات واسعة النطاق، ما هي النصيحة العملية التي ستقدمها للمديرين التقنيين وقادة الهندسة بشأن قرارات التحديث الأولى التي يجب اتخاذها قبل أن يصبح برنامج التحول كبيرًا جدًا أو محفوفًا بالمخاطر؟
أولاً، استثمر في المراقبة قبل التغييرات المعمارية الكبيرة. تساعد المقاييس والسجلات والتتبع الواضحة الفرق على فهم كيفية تصرف النظام الحالي وأين تكون التحسينات أكثر حاجة.
ثانيًا، أعد تصميم سير عمل النشر مبكرًا. تمكّن خطوط CI/CD الموثوقة من التجريب الأسرع وتقلل من الخوف من التغيير.
ثالثًا، حدد حدود الخدمة الصحيحة بناءً على مجالات الأعمال وليس الوحدات التقنية. تجعل الملكية الواضحة الأنظمة أسهل في الصيانة والتوسع.
عندما تكون تلك الأسس في مكانها، يصبح التحديث عملية منظمة بدلاً من قفزة محفوفة بالمخاطر.
