إعادة هيكلة الكود

**إعادة هيكلة التعليمات البرمجية** هي عملية إعادة هيكلة رمز الكمبيوتر الحالي - تغيير شكله - دون تغيير سلوكه الخارجي. يهدف Refactoring إلى تحسين السمات *[[متطلب لاوظيفي|الغير الوظيفية]]* للبرنامج. وتشمل المزايا تحسين قراءة التعليمات البرمجية وتقليل التعقيد. يمكن أن يؤدي ذلك إلى تحسين إمكانية صيانة التعليمات البرمجية المصدر وإنشاء بنية داخلية أكثر تعبيراً أو النموذج الكائني لتحسين قابليتيه للتوسعة.

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

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

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

## الفوائد
هناك فئتان عامتان من الفوائد لنشاط إعادة الهيكلة.

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

## الإختبارات
يجب إعداد اختبارات الوحدات (unite tests) التلقائية قبل إعادة الهيكلة لضمان استمرار الإجراءات الروتينية كما هو متوقع. يمكن أن تجلب اختبارات الوحدة الثبات حتى للأكواد الكبيرة المعادة الهيكلة عند إجرائها باستخدام التزام ذري (atomic commit) واحد. تتمثل إحدى الاستراتيجيات الشائعة للسماح بهيكلة آمنة وذرية تمتد لعدة مشاريع عبر تخزين جميع المشاريع في مستودع واحد، يُعرف باسم monorepo.

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

## التقنيات
فيما يلي بعض الأمثلة على إعادة الهيكلة الجزئية؛ قد تنطبق هذه الأمثلة فقط على لغات معينة أو أنواع اللغات. يمكن العثور على قائمة أطول في كتاب إعادة الهيكلة (Refactoring) لمارتن فاولر. توفر العديد من بيئات التطوير دعمًا تلقائيًا لهذه الهيكلات الجزئية. على سبيل المثال، يمكن للمبرمج النقر على اسم المتغير ثم تحديد إعادة إنشاء حقل "Encapsulate field" من قائمة السياق. سيطلب IDE بعد ذلك الحصول على تفاصيل إضافية، عادةً مع افتراضات معقولة ومعاينة للتغييرات البرمجية. بعد تأكيد من قبل مبرمج إنها ستنفذ التغييرات المطلوبة في جميع أنحاء الكود.

* التقنيات التي تسمح لمزيد من التجريد
** تغليف الحقل - رمز القوة للوصول إلى الحقل باستخدام طرق getter و setter
** تعميم الكتابة - قم بإنشاء أنواع أكثر عمومية للسماح بمشاركة الكود أكثر
** استبدل كود فحص الكتابة بالحالة / الإستراتيجية 
** استبدال العبارات الشرطية بتعدد الأشكال 
* تقنيات لكسر الشفرة إلى أجزاء أكثر منطقية
** تقسم المكونات الشفرة إلى وحدات دلالية قابلة لإعادة الاستخدام تقدم واجهات واضحة ومحددة جيدًا وسهلة الاستخدام.
** اقتطاف قسم نقل جزء من التعليمات البرمجية من قسم موجودة إلى قسم جديد.
** اقتطاف إجراء، لتحويل جزء من إجراء أكبر إلى إجراء جديدة. من خلال تفكيك الكود في قطع أصغر، يصبح من السهل فهمه. هذا ينطبق أيضا على الدوال.
* تقنيات لتحسين الأسماء وموقع الكود
** نقل إجراء أو نقل حقل - الانتقال إلى قسم أو إلى ملف مصدر أكثر ملاءمة
** إعادة تسمية الإجراءات أو إعادة تسمية الحقل - تغيير الاسم إلى اسم جديد يكشف الغرض منه بشكل أفضل
** اسحب - في البرمجة الموجهة للكائنات (OOP)، والانتقال إلى الأقسام الفائقة
** اضغط لأسفل - في OOP، الانتقال إلى فئة فرعية 
* كشف الاستنساخ التلقائي 

## إعادة هيكلة الأجهزة
بينما يشير المصطلح *refactoring* أصلاً حصريًا إلى إعادة هيكلة لرمز البرنامج، إلا أنه تمت إعادة تشفير الكود المكتوب بلغات وصف الأجهزة (HDLs) في السنوات الأخيرة. يستخدم مصطلح *إعادة هيكلة الأجهزة* كمصطلح *مختزل* لإعادة تشكيل التعليمات البرمجية في لغات وصف الأجهزة. نظرًا لأن HDLs لا تعتبر لغات برمجة من قبل معظم مهندسي الأجهزة،  إعادة هيكلة الأجهزة يعتبر مجالًا منفصلًا عن إعادة هيكلة الشفرة التقليدية.

تم اقتراح إعادة الهيكلة التلقائية لأوصاف الأجهزة التناظرية (في VHDL-AMS) بواسطة Zeng و Huss. في نهجهما المتبع، تحافظ إعادة الهيكلة على السلوكات المحاكية لتصميم الأجهزة. القياس غير الوظيفي الذي يحسن هو أنه يمكن معالجة الكود المعاد تشكيله بواسطة أدوات تركيب قياسية، بينما لا يمكن للكود الأصلي. كما تم التحقيق في إعادة هيكلة HDLs الرقمية، وإن كان إعادة الهيكلة اليدوي، من قبل زميل سينوبسيس مايك كيتنغ. هدفه هو جعل الأنظمة المعقدة أسهل في الفهم، مما يزيد من إنتاجية المصممين.

## التاريخ
على الرغم من أن قانون إعادة هيكلة الأكواد قد تمة بشكل غير رسمي منذ عقود، إلا أن الدكتور وليام جريسوولد عام 1991. طرح أطروحة  هي واحدة من أولى الأعمال الأكاديمية الرئيسية في إعادة هيكلة البرامج الوظيفية والإجرائية، تليها أطروحة وليام أوبديك لعام 1992  عن إعادة هيكلة البرامج الموجهة للكائنات،  على الرغم من أن جميع النظريات والآليات لها فترة طويلة كانت متاحة لأنظمة تحويل البرنامج. توفر كل هذه الموارد فهرسًا للطرق الشائعة لإعادة الهيكلة. يحتوي إجراء إعادة الهيكلة على وصف لكيفية تطبيق هذا الإجراء والمؤشرات الخاصة بموعد تطبيق هذا الإجراء (أو عدم ذلك).

يعد كتاب مارتن فاولر *(Refactoring)* *: تحسين تصميم الكود الموجود*  مرجعا أساسيا.

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

* DMS Software Reengineering Toolkit (تطبق إعادة هيكلة واسعة النطاق لـ C و C ++ و C # و COBOL و Java و PHP ولغات أخرى)
* الكسوف القائم:
** Eclipse (لنظام Java، وبدرجة أقل، C ++ و PHP و Ruby و JavaScript)
** PyDev (لبايثون)
** Photran (ملحق فورتران لـ IDE Eclipse)
* [./https://en.wikipedia.org/wiki/Embarcadero_Delphi Embarcadero Delphi]
* مبنية على intelliJ:
** AppCode (للهدف C و C و C ++)
** IntelliJ IDEA (لجافا)
** PyCharm (لبيثون)
** WebStorm (لجافا سكريبت)
** استوديو أندرويد (لجافا)
* JDeveloper (لجافا)
* NetBeans (لجافا)
* Smalltalk : تتضمن معظم اللهجات أدوات إعادة هيكلة قوية. يستخدم الكثيرون متصفح إعادة الهيكلة الأصلي الذي تم إنتاجه في أوائل التسعينيات من قبل رالف جونسون.
* مبنية على Visual Studio:
** [./https://en.wikipedia.org/wiki/Visual_Studio Visual Studio] (ل. NET و C ++)
** CodeRush (الملحق لبرنامج Visual Studio)
** [./https://en.wikipedia.org/wiki/Visual_Assist Visual Assist](الملحق لـ Visual Studio مع دعم إعادة الهيكلة لـ C # و C ++)
* Wing IDE (لبيثون)
* Xcode (لـ C وObject-C وSwift) 

## انظر أيضًا

* مراجعة التعليمات البرمجية
* نمط التصميم (علوم الكمبيوتر)
* فصل المخاوف
* البرمجة المعيارية

## المراجع

## روابط خارجية

* ما هو إعادة الهيكلة؟ (مقالة c2.com)
* الصفحة الرئيسية لمارتن فاولر حول إعادة هيكلة الأكواد
* 

*
تصنيف:برمجة قصوى
تصنيف:مستحدثات تقنية