إعادة تمثيل الويب: لا تكرس من أجل إعادة البناء

مقالة مقدمة من wulin.com (www.vevb.com): تم تعريف كلمة إعادة تعيينها في الأصل بواسطة مارتن فاولر وكينت بيك. إنه تعديل يجعل الهيكل الداخلي للبرنامج أسهل في فهمه ويجعل البرنامج أسهل في التغيير دون تغيير السلوك المرئي للبرنامج ... إنها طريقة مقيدة لتنظيم التعليمات البرمجية وتقليل فرصة توليد الأخطاء.

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

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

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

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

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

لا تكرس من أجل إعادة البناء

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

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

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

إعادة تمثيل الخدش لفهم (إعادة إنشاء الخدش)

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

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

ما هو إعادة الإعمار على نطاق واسع؟

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

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

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

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

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

هذه هي إعادة الطعنة-تلك ليست كذلك

من الخطأ دمج مفهوم إعادة الإعمار في تطوير المشاريع الشاقة. إنها في الأساس نوع آخر من العمل ، مع تكاليف ومخاطر مختلفة تمامًا. إنه يخلط بين فهم الناس لماهية إعادة الإعمار وما الذي يمكن أن تفعله إعادة الإعمار.

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

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

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