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

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

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

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

التحفيز

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

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

الفوائد

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

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

الإختبارات

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

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

التقنيات

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

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

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

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

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

التاريخ

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

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

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

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

انظر أيضًا

المراجع
  1. Kerievsky، Joshua (2004). Refactoring to Patterns. Addison Wesley.
  2. Fowler، Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ص. 63ff. ISBN:978-0-201-48567-7.
  3. Suryanarayana، Girish (نوفمبر 2014). Refactoring for Software Design Smells. Morgan Kaufmann. ص. 258. ISBN:978-0128013977.
  4. Martin، Robert (2009). Clean Code. Prentice Hall.
  5. 1963-، Fowler, Martin (1999). Refactoring : improving the design of existing code. Reading, MA: Addison-Wesley. ISBN:978-0201485677. OCLC:41017370. {{استشهاد بكتاب}}: الوسيط |مؤلف1= يحوي أسماء رقمية (مساعدة)صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link)
  6. Smart, John Ferguson (2008). Java Power Tools (بالإنجليزية). "O'Reilly Media, Inc.". p. 301. ISBN:9781491954546. Archived from the original on 2020-02-12. Retrieved 2018-07-26.
  7. Replace type-checking code with State/Strategy نسخة محفوظة 06 سبتمبر 2017 على موقع واي باك مشين.
  8. Replace conditional with polymorphism نسخة محفوظة 04 أكتوبر 2017 على موقع واي باك مشين.
  9. (these are only about OOP however).Refactoring techniques in Fowler's refactoring Website نسخة محفوظة 21 مارس 2019 على موقع واي باك مشين.
  10. Bruntink, Magiel, et al. "An evaluation of clone detection techniques for crosscutting concerns." Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on. IEEE, 2004. نسخة محفوظة 09 نوفمبر 2018 على موقع واي باك مشين.
  11. لغة توصيف العتاد
  12. Kaiping Zeng, Sorin A. Huss, "Architecture refinements by code refactoring of behavioral VHDL-AMS models". ISCAS 2006
  13. M. Keating :"Complexity, Abstraction, and the Challenges of Designing Complex Systems", in DAC'08 tutorial "Bridging a Verification Gap: C++ to RTL for Practical Design" نسخة محفوظة 28 مارس 2016 على موقع واي باك مشين.
  14. M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1999.
  15. Griswold، William G (يوليو 1991). Program Restructuring as an Aid to Software Maintenance (PDF) (Ph.D. thesis). University of Washington. مؤرشف من الأصل (PDF) في 2016-12-04.
  16. Opdyke، William F (يونيو 1992). Refactoring Object-Oriented Frameworks (Ph.D. thesis). University of Illinois at Urbana-Champaign. مؤرشف من الأصل (compressed Postscript) في 2019-12-16.
  17. Martin Fowler, "MF Bliki: EtymologyOfRefactoring" نسخة محفوظة 20 سبتمبر 2018 على موقع واي باك مشين.
  18. Xuan، Jifeng؛ Cornu، Benoit؛ Martinez، Matias؛ Baudry، Benoit؛ Seinturier، Lionel؛ Monperrus، Martin (2016). "B-Refactoring: Automatic test code refactoring to improve dynamic analysis". Information and Software Technology. ج. 76: 65–80. DOI:10.1016/j.infsof.2016.04.016. مؤرشف من الأصل في 2018-11-26.
  19. What's new in Xcode 9 نسخة محفوظة 16 فبراير 2018 على موقع واي باك مشين.

قراءة متعمقة
  • Wake، William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN:978-0-321-10929-3. Wake، William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN:978-0-321-10929-3. Wake، William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN:978-0-321-10929-3.
  • Mens، T.؛ Tourwe، T. (n.d.). "A survey of software refactoring". IEEE Transactions on Software Engineering. ج. 30 ع. 2: 126–139. DOI:10.1109/tse.2004.1265817. ISSN:0098-5589. مؤرشف من الأصل في 2017-08-28.
  • Feathers، Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN:978-0-13-117705-5. Feathers، Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN:978-0-13-117705-5. Feathers، Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN:978-0-13-117705-5.
  • Kerievsky، Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN:978-0-321-21335-8. Kerievsky، Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN:978-0-321-21335-8. Kerievsky، Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN:978-0-321-21335-8.
  • Arsenovski، Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN:978-0-470-17979-6. Arsenovski، Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN:978-0-470-17979-6. Arsenovski، Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN:978-0-470-17979-6.
  • Arsenovski، Danijel (2009). Professional Refactoring in C# and ASP.NET. Wrox. ISBN:978-0-470-43452-9. Arsenovski، Danijel (2009). Professional Refactoring in C# and ASP.NET. Wrox. ISBN:978-0-470-43452-9. Arsenovski، Danijel (2009). Professional Refactoring in C# and ASP.NET. Wrox. ISBN:978-0-470-43452-9.
  • Ritchie، Peter (2010). Refactoring with Visual Studio 2010. Packt. ISBN:978-1-84968-010-3. Ritchie، Peter (2010). Refactoring with Visual Studio 2010. Packt. ISBN:978-1-84968-010-3. Ritchie، Peter (2010). Refactoring with Visual Studio 2010. Packt. ISBN:978-1-84968-010-3.

روابط خارجية
  • أيقونة بوابةبوابة برمجة الحاسوب
  • أيقونة بوابةبوابة برمجيات
  • أيقونة بوابةبوابة تقانة المعلومات
  • أيقونة بوابةبوابة علم الحاسوب
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.