إعادة هيكلة الكود  إعادة هيكلة التعليمات البرمجية هي عملية إعادة هيكلة رمز الكمبيوتر الحالي - تغيير شكله - دون تغيير سلوكه الخارجي. يهدف Refactoring إلى تحسين السمات "الغير الوظيفية" للبرنامج. وتشمل المزايا تحسين قراءة التعليمات البرمجية وتقليل التعقيد. يمكن أن يؤدي ذلك إلى تحسين إمكانية صيانة التعليمات البرمجية المصدر وإنشاء بنية داخلية أكثر تعبيراً أو النموذج الكائني لتحسين قابليتيه للتوسعة.  بشكل عام، تطبق إعادة الهيكلة سلسلة من "عمليات إعادة الهيكلة الدقيقة" الأساسية الموحدة، والتي يكون كل منها (عادة) تغييراً طفيفًا في الكود المصدري لبرنامج الكمبيوتر الذي إما يحتفظ بسلوك البرنامج، أو على الأقل لا يعدل توافقه للمتطلبات الوظيفية. توفر العديد من بيئات التطوير دعمًا تلقائيًا لأداء الجوانب الميكانيكية لإعادة الهيكلة الأساسية. إذا تمت إعادة صياغة التعليمات البرمجية بشكل جيد، فقد تساعد مطوري البرامج على اكتشاف وإصلاح الخلل أو الثغرات الخفية أو النائمة في النظام من خلال تبسيط المنطق الأساسي والقضاء على مستويات التعقيد غير الضرورية. إذا تم القيام به بشكل سيئ، فقد يفشل متطلب عدم تغيير الوظيفة الخارجية أو إدخال أخطاء جديدة أو كليهما.   عادة ما يكون الدافع وراء إعادة الهيكلة ناتج عن طريق ملاحظة بعض الاخطاء في الكود. على سبيل المثال، قد تكون بعض الطرق لحل مشكل ما طويلة جدا، أو قد تكون الطريقة مكررة من طريقة أخرى قريبة. بمجرد التعرف عليها، يمكن معالجة هذه المشكلات عن طريق "إعادة" هيكلة الكود المصدري، أو تحويله إلى شكل جديد يتصرف كما كان من قبل بدون اخطاء وأسطر أقل.  بالنسبة الإجراءات الطويلة، يمكن استخراج إجراء فرعي أصغر أو أكثر؛ أو لتكرار الإجراءات، يمكن إزالة التكرار واستبداله بوظيفة مشتركة واحدة. يمكن أن يؤدي الفشل في تنفيذ إعادة الهيكلة إلى تراكم الديون التقنية (technical debt)؛ من ناحية أخرى، فإن إعادة الهيكلة هي إحدى الوسائل الرئيسية لسداد الديون التقنية.  هناك فئتان عامتان من الفوائد لنشاط إعادة الهيكلة.   يجب إعداد اختبارات الوحدات (unite tests) التلقائية قبل إعادة الهيكلة لضمان استمرار الإجراءات الروتينية كما هو متوقع. يمكن أن تجلب اختبارات الوحدة الثبات حتى للأكواد الكبيرة المعادة الهيكلة عند إجرائها باستخدام التزام ذري (atomic commit) واحد. تتمثل إحدى الاستراتيجيات الشائعة للسماح بهيكلة آمنة وذرية تمتد لعدة مشاريع عبر تخزين جميع المشاريع في مستودع واحد، يُعرف باسم monorepo.  مع اختبار الوحدة في مكانه، فإن إعادة الهيكلة هي دورة تكرارية لإجراء تحويل صغير للبرنامج، واختباره لضمان صحته، وإجراء تحويل صغير آخر. إذا فشل الاختبار في أي وقت، فسيتم التراجع عن التغيير البسيط الأخير وتتكرر العملية بطريقة مختلفة. من خلال العديد من الخطوات الصغيرة، ينتقل البرنامج من حيث كان إلى المكان الذي تريده أن يكون عليه. لكي تكون هذه العملية التكرارية عملية فعالة، يجب أن تجري الاختبارات بسرعة كبيرة، أو سيتعين على المبرمج قضاء جزء كبير من وقته في انتظار انتهاء الاختبارات. يصف مؤيدو البرمجة المتطرفة وغيرها من تطوير البرمجيات الحساسة (Agile) هذا النشاط بأنه جزء لا يتجزأ من دورة تطوير البرمجيات.  فيما يلي بعض الأمثلة على إعادة الهيكلة الجزئية؛ قد تنطبق هذه الأمثلة فقط على لغات معينة أو أنواع اللغات. يمكن العثور على قائمة أطول في كتاب إعادة الهيكلة (Refactoring) لمارتن فاولر. توفر العديد من بيئات التطوير دعمًا تلقائيًا لهذه الهيكلات الجزئية. على سبيل المثال، يمكن للمبرمج النقر على اسم المتغير ثم تحديد إعادة إنشاء حقل "Encapsulate field" من قائمة السياق. سيطلب IDE بعد ذلك الحصول على تفاصيل إضافية، عادةً مع افتراضات معقولة ومعاينة للتغييرات البرمجية. بعد تأكيد من قبل مبرمج إنها ستنفذ التغييرات المطلوبة في جميع أنحاء الكود.   بينما يشير المصطلح "refactoring" أصلاً حصريًا إلى إعادة هيكلة لرمز البرنامج، إلا أنه تمت إعادة تشفير الكود المكتوب بلغات وصف الأجهزة (HDLs) في السنوات الأخيرة. يستخدم مصطلح "إعادة هيكلة الأجهزة" كمصطلح "مختزل" لإعادة تشكيل التعليمات البرمجية في لغات وصف الأجهزة. نظرًا لأن HDLs لا تعتبر لغات برمجة من قبل معظم مهندسي الأجهزة، إعادة هيكلة الأجهزة يعتبر مجالًا منفصلًا عن إعادة هيكلة الشفرة التقليدية.  تم اقتراح إعادة الهيكلة التلقائية لأوصاف الأجهزة التناظرية (في VHDL-AMS) بواسطة Zeng و Huss. في نهجهما المتبع، تحافظ إعادة الهيكلة على السلوكات المحاكية لتصميم الأجهزة. القياس غير الوظيفي الذي يحسن هو أنه يمكن معالجة الكود المعاد تشكيله بواسطة أدوات تركيب قياسية، بينما لا يمكن للكود الأصلي. كما تم التحقيق في إعادة هيكلة HDLs الرقمية، وإن كان إعادة الهيكلة اليدوي، من قبل زميل سينوبسيس مايك كيتنغ. هدفه هو جعل الأنظمة المعقدة أسهل في الفهم، مما يزيد من إنتاجية المصممين.  على الرغم من أن قانون إعادة هيكلة الأكواد قد تمة بشكل غير رسمي منذ عقود، إلا أن الدكتور وليام جريسوولد عام 1991. طرح أطروحة هي واحدة من أولى الأعمال الأكاديمية الرئيسية في إعادة هيكلة البرامج الوظيفية والإجرائية، تليها أطروحة وليام أوبديك لعام 1992 عن إعادة هيكلة البرامج الموجهة للكائنات، على الرغم من أن جميع النظريات والآليات لها فترة طويلة كانت متاحة لأنظمة تحويل البرنامج. توفر كل هذه الموارد فهرسًا للطرق الشائعة لإعادة الهيكلة. يحتوي إجراء إعادة الهيكلة على وصف لكيفية تطبيق هذا الإجراء والمؤشرات الخاصة بموعد تطبيق هذا الإجراء (أو عدم ذلك).  يعد كتاب مارتن فاولر "(Refactoring)" ": تحسين تصميم الكود الموجود" مرجعا أساسيا.  لدى العديد من محرري البرامج وIDEs دعم إعادة الهيكلة الآلية. من الممكن هيكلة رمز التطبيق وكذلك عمل الاختبار. فيما يلي قائمة ببعض المحررات، أو ما يسمى بمتصفحات إعادة الهيكلة.