يعرف المطورون الكبار متى وكيف يعيدون بناء كود ريلز

إعادة البناء على نطاق واسع: لماذا تفعل شيئًا كهذا؟

إذا لم يتم كسرها ، فلا تقم بإصلاحها.

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

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

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

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

نعم ، هذا رمز قديم كان منطقيًا في ذلك الوقت ولكن المواصفات تغيرت وأصبح إصلاحه مكلفًا للغاية الآن؟

ربما أعطيتهم نظرة جادة للغاية وأخبرتهم أن يتركوها ولا تلمسها.

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

تحسينات في الأداء

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

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

تحسينات معمارية

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

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

تحديثه

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

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

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

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

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

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

تحضير

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

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

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

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

تنفيذ

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

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

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

اتمامه

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

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

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

أخيرًا ، استمتع بثمار عملك مع الأخذ في الاعتبار جميع التغييرات المخطط لها والتي ستكون الآن أكثر نظافة وأسهل في التنفيذ.

متى لا تفعل ذلك؟

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

تغطية اختبارك ضعيفة

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

لا تعتمد إعادة البناء على ميزة جديدة وقاعدة البيانات لم تتغير منذ وقت طويل

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

أنت مضغوط للوقت

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

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

خاتمة

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