ما هي أفضل تقنية لبناء البرامج القابلة للتطوير (القابلة للتمديد) ، والصيانة ، والمقترنة بشكل فضفاض؟

Question

لقد كنت ألعب مع مفهوم "الوحدة النمطية" التي تنفذها بعض أطر عمل MVC ويبدو أنها حل جيد ، وأيضًا مع TDD ، لكنني أعتقد أنه يجب أن يكون هناك شيء أكثر ، مثل نمط التصميم الذي فاتني (أعرف فقط ملف قليل) ، سيسمح لي ذلك ببناء تطبيقات يمكن أن تنمو (في الكود) بدون حدود.

أي أفكار؟

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

Answer 1

في "حقائق ومغالبات هندسة البرمجيات" ، يقول روبرت ل. جلاس:

الحقيقة 15. إعادة الاستخدام في SMALL هي مشكلة جيدة حل.

الحقيقة 16. لا تزال إعادة استخدام العارضة مشكلة لم يتم حلها في الغالب.

الحقيقة 17. إعادة الاستخدام في الفصائل تعمل بشكل أفضل في عائلات الأنظمة ذات الصلة.

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

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

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

---

إعادة التعليق من A_VAR:

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

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

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

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