كيف تجعل الكود قابل لإعادة الاستخدام؟

Question

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

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

Answer 1

يرى 10 نصائح حول كتابة التعليمات البرمجية القابلة لإعادة الاستخدام للحصول على بعض المساعدة.

1. احتفظ بالرمز جافًا.جاف يعني "لا تكرر نفسك".
2. اجعل الفصل/الطريقة تفعل شيئًا واحدًا فقط.
3. اكتب اختبارات الوحدة لفصولك واجعل من السهل اختبار الفصول.
4. قم بإزالة منطق العمل أو الكود الرئيسي بعيدًا عن أي رمز إطار عمل
5. حاول التفكير بشكل أكثر تجريدًا واستخدم الواجهات والفئات المجردة.
6. كود للتمديد.اكتب التعليمات البرمجية التي يمكن تمديدها بسهولة في المستقبل.
7. لا تكتب رمزًا غير مطلوب.
8. حاول تقليل الاقتران.
9. كن أكثر نمطية
10. اكتب التعليمات البرمجية مثل التعليمات البرمجية الخاصة بك هي واجهة برمجة التطبيقات الخارجية

Answer 2

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

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

Answer 3

وأكثر من أي شيء آخر، والصيانة يجعل قابلة لإعادة الاستخدام التعليمات البرمجية.

وإعادة استخدام نادرا ما يكون هدف جدير بالاهتمام في حد ذاته. وبدلا من ذلك، بل هو ناتج ثانوي لكتابة التعليمات البرمجية التي هي منظم بشكل جيد، للصيانة بسهولة ومفيدة.

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

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

وأنا أقترح النظر في أفضل الممارسات لاختيار الخاصة بك لغة البرمجة / نموذج (على سبيل المثال أنماط والصلبة لجاوا / C # أنواع)، والعجاف / رشيق الأدب البرمجة، و (طبعا) كتاب "رمز كاملة". وفهم مزايا وعيوب هذه النهج تحسين الممارسة الترميز الخاص بك لا نهاية. وجميع أكواد تصبح ثم reausable - ولكن عن طريق الصدفة، بدلا من تصميم

وكما نرى هنا: الكتابة للصيانة كود

Answer 4

لمعظم تعريفات "إعادة الاستخدام"، إعادة استخدام code عبارة عن أسطورة، على الأقل في تجربتي. يمكن أن أقول لكم لدي بعض الندوب من هذا؟ :-)

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

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

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

Answer 5

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

لذلك، عليك تحديد الوحدات التي يمكن إعادة استخدامها من أجل ذلك

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

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

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

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

اترك كل الحالة أو السياق المطلوب خارج المكتبة.إضافة طرق لتحديد الحالة للمكتبة.

Answer 6

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

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

1. انسخه وأصلحه.يتعين عليك الآن الحصول على حزم مماثلة تقريبًا - وهو خطأ مكلف.

2. اجعل العبوة الأصلية قابلة لإعادة الاستخدام في حالتين.

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

Answer 7

وقد ذكر آخرون هذه التكتيكات، ولكن هنا هم رسميا.هؤلاء الثلاثة سيوصلونك بعيدًا جدًا:

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

Answer 8

وإضافة إلى العناصر المذكورة أعلاه أقول:

• اجعل تلك الوظائف عامة والتي تحتاج إلى إعادة استخدامها
• استخدم ملفات التكوين واجعل الكود يستخدم الخصائص المحددة في files/db
• قم بتحليل التعليمات البرمجية الخاصة بك بوضوح في هذه الوظائف/الفئات التي توفر وظائف مستقلة ويمكن استخدامها في سيناريوهات مختلفة وتحديد تلك السيناريوهات باستخدام ملفات التكوين

Answer 9

وأود أن أضيف مفهوم "تكوين فئة على الميراث الطبقة" (وهي مشتقة من إجابات أخرى هنا). وبهذه الطريقة لا يهمه "ويتألف" الكائن عن البنية الداخلية للجسم أنها تعتمد على - فقط سلوكها، مما يؤدي إلى تحسين التغليف وأسهل الصيانة (الاختبار، وأقل تفاصيل لنهتم). في لغات مثل C # و Java غالبا ما يكون من الأهمية بمكان حيث لا يوجد وراثة متعددة لذلك يساعد تجنب الجحيم الميراث الرسم البياني ش تكون لديكم.

Answer 10

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

وإحدى الطرق لمساعدة نحو كود حدات لاستخدام التغليف، انظر نظرية التغليف هنا: http://www.edmundkirwan.com/

وإد.

Answer 11

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

Answer 12

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