ما المقصود بإعادة هيكلة التعليمات البرمجية؟

روّج Martin Fowler لهذه العملية من خلال كتابه "Refactoring"، الذي نُشر لأول مرة في عام 1999. يمكن أن تساعد إعادة هيكلة التعليمات البرمجية على القضاء على "روائح التعليمات البرمجية"، والتي يعرفها Fowler بأنها "مؤشر سطحي يُشير عادةً إلى مشكلة أعمق في النظام". ويضيف أن روائح التعليمات البرمجية "سريعة الاكتشاف أو يمكن ملاحظتها" ويستشهد بالدوال الطويلة والفئات التي تحتوي على بيانات فقط ولا يوجد بها أي أداء يُشير إلى حالات روائح التعليمات البرمجية.

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

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

    ● التجريد

    ● التكوين

    ● نقل المزايا

    ● إعادة الهيكلة الحمراء والخضراء

    ● التبسيط

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

في إعادة هيكلة التعليمات البرمجية، عادةً ما يُطبق التجريد على قواعد التعليمات البرمجية الضخمة. وهو يتكون من آليتين هما ما يلي:

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

 ● تدفع دالة الدفع إلى الأسفل التعليمات البرمجية من فئة مجردة أو فئة رئيسية إلى فئة فرعية لمنطق غير قابل لإعادة الاستخدام أو ينطبق فقط على فئة فرعية معينة.

يُجزئ هذا النهج المعياري أو يقسم أجزاء ضخمة من التعليمات البرمجية إلى أجزاء أصغر لجعلها أبسط وأكثر قابلية للإدارة. دالة الاستخراج والدالة المضمنة هما نهجان للتكوين:

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

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

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

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

تتبع هذه العملية المكونة من 3 مراحل الخطوات التالية:

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

● في المرحلة الخضراء، يكتب المبرمجون التعليمات البرمجية لأداء أو وظيفة معينة. يمكن أن يكون هذا هو الحد الأدنى المطلوب من التعليمات البرمجية لاجتياز الاختبارات، لأن الهدف هنا هو السرعة وليس الجودة.

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

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

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

فيما يلي بعض المزايا التي يمكن أن تكتسبها فرق تطوير البرامج من إعادة هيكلة التعليمات البرمجية:

    ● تقليل التعقيد

    ● تحسين قابلية الصيانة

    ● تحسين قابلية قراءة التعليمات البرمجية

    ● المزيد من السرعة

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

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

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

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

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

    ● تخصيص المطورين

    ● ظهور الأخطاء

    ● التعليمات البرمجية القديمة

    ● توسع النطاق

    ● قيود الوقت

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

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

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

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

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

قبل الشروع في رحلة إعادة هيكلة التعليمات البرمجية، اتبع النصائح التالية للمساعدة على مواجهة تحديات العملية:

    ● الوقت مهم جدًا

    ● التخطيط هو المفتاح

    ● التحليل والتوحيد

    ● الاختبار والتوثيق

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

تُعد إعادة الهيكلة أيضًا أمرًا ضروريًا قبل إضافة مزايا جديدة أو إجراء تحديثات جوهرية أو الانتقال إلى مجموعات تقنية أحدث أو ترقية واجهات برمجة التطبيقات (APIs) أو المكتبات. فهي تحدد إطار عمل أكثر قابلية للتوسع والتكيف للبناء عليه في المستقبل.

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

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

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

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

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

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

يمكن أن تساعد العديد من الأدوات على تسريع عملية إعادة هيكلة التعليمات البرمجية وأتمتتها. فيما يلي بعض الأدوات الشائعة:

    ● بيئات التطوير المتكاملة (IDEs)

    ● أدوات تحليل التعليمات البرمجية الثابتة

    ● موارد أخرى

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

تتضمن بيئات التطوير المتكاملة التي يمكن استخدامها لإعادة هيكلة التعليمات البرمجية IntelliJ IDEA للغات البرمجة المعتمدة على الآلة الافتراضية لجافا (JVM)، وPyCharm للغة Python وامتداد ReSharper Visual Studio للغات C# وC++ و.NET.

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

تتضمن أمثلة أدوات تحليل التعليمات البرمجية الثابتة Codacy و PMD مفتوح المصدر اللذين يدعمان لغات برمجة متعددة و JArchitect للغة جافا وNDepend للغة .NET وLinter وأداة التحقق البرمجي RuboCop للغة Ruby.

Refactoring.com هو موقع أنشأه Martin Fowler يحتوي على كتالوج إلكتروني لطرق إعادة الهيكلة المقتبسة من كتابه. Refactoring.Guru هو موقع ويب آخر يناقش تقنيات إعادة الهيكلة وأنماط التصميم.

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

يستخدم IBM watsonx Code Assistant، على سبيل المثال، نماذج IBM Graniteلتحديد الأخطاء ومواضع التحسين. ومن ثَم يقترح إصلاحات مستهدفة تتماشى مع اتفاقيات البرمجة المعمول بها في الفريق، ما يساعد على تبسيط عملية إعادة هيكلة التعليمات البرمجية وتسريعها. ومن أدوات إعادة الهيكلة المدعومة بالذكاء الاصطناعي Amazon CodeGuru Reviewer وGitHub Copilot وChatGPT من OpenAI.

بالنسبة إلى أولئك الذين يتعاملون مع التعليمات البرمجية القديمة، يدمج IBM watsonx Code Assistant for Z الذكاء الاصطناعي التوليدي والأتمتة لمساعدة المطورين على تحديث تطبيقاتهم. يتيح watsonx Code Assistant for Z Refactoring Assistant للمبرمجين إعادة هيكلة تطبيقاتهم وتحويلها إلى خدمات أكثر نمطية وقابلية لإعادة الاستخدام. ويستخدم خوارزميات تحليل التعليمات البرمجية لتحديث تطبيقات COBOL.

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