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

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

بشكل عام، تطبق إعادة الهيكلة سلسلة من عمليات إعادة الهيكلة الدقيقة الأساسية الموحدة، والتي يكون كل منها (عادة) تغييراً طفيفًا في الكود المصدري لبرنامج الكمبيوتر الذي إما يحتفظ بسلوك البرنامج، أو على الأقل لا يعدل توافقه للمتطلبات الوظيفية.  توفر العديد من بيئات التطوير دعمًا تلقائيًا لأداء الجوانب الميكانيكية لإعادة الهيكلة الأساسية. إذا تمت إعادة صياغة التعليمات البرمجية بشكل جيد، فقد تساعد مطوري البرامج على اكتشاف وإصلاح الخلل أو الثغرات الخفية أو النائمة في النظام من خلال تبسيط المنطق الأساسي والقضاء على مستويات التعقيد غير الضرورية. إذا تم القيام به بشكل سيئ، فقد يفشل متطلب عدم تغيير الوظيفة الخارجية أو إدخال أخطاء جديدة أو كليهما. 
«من خلال التحسين المستمر لتصميم الكود، نجعل التعامل معه أسهل وأكثر سهولة. هذا في تناقض حاد مع ما يحدث عادة: القليل من إعادة الهيكلة والكثير من الانتباه يساهم في التسريع من وتيرة إضافة ميزات جديدة, إذا اعتدت على عادة إعادة الهيكلة بإستمرار ,فستجد أنه من السهل تطوير التعليمات البرمجية والحفاظ عليها.» – Joshua Kerievsky, Refactoring to Patterns

التحفيز

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

الإختبارات

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

إعادة هيكلة الأجهزة

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

التاريخ

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