كيفية التعامل مع إهمال الوظائف في المكتبة؟

Question

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

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

هل هناك أي "أفضل الممارسات" بشأن إزالة التعليمات البرمجية العامة الزائدة عن الحاجة؟

/جانوسسيم

Answer 1

قم بتعيين تاريخ ونشره في العلامة @deprecated.يعتمد مقدار الوقت الممنوح للإزالة على عدد المستخدمين الذين يمتلكهم الكود الخاص بك، ومدى اتصالك بهم وسبب التغيير.

إذا كان لديك الآلاف من المستخدمين وبالكاد تتحدث معهم، فمن المحتمل أن يكون الإطار الزمني في نطاق العقود :-)

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

/**
 * @deprecated
 * This method will be removed after Halloween!
 * @see #newLocationForFunctionality
 */

Answer 2

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

يجيب ريموند تشن على هذا السؤال بشكل أفضل من خلال مدونته حول Win32 API،

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

Answer 3

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

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

Answer 4

يستخدم @إهمال بطاقة شعار.إقرأ ال إهمال واجهات برمجة التطبيقات وثيقة لمزيد من المعلومات.

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

Answer 5

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

Answer 6

من المؤكد أن الأمر يعتمد على النطاق الذي يتم فيه استخدام واجهة برمجة التطبيقات (API) الخاصة بك وما وعدت به لعملائك مقدمًا.

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

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

من ناحية أخرى، في التطوير، أفعل ذلك على الفور، من أجل حل الأمور بسرعة.

Answer 7

قد تكون مهتمًا بأمثلة حول كيفية عمل الإهمال في بعض المشاريع الأخرى.على سبيل المثال، هنا يلي ما السياسة في مشروع Django لإهمال الوظيفة يكون:

قد يؤدي إصدار ثانوي إلى إهمال ميزات معينة من الإصدارات السابقة.إذا تم إهمال إحدى الميزات الموجودة في الإصدار A.B، فستستمر في العمل في الإصدار A.B+1.في الإصدار A.B+2، سيؤدي استخدام الميزة إلى ظهور تحذير PendingDeprecationWarning ولكنه سيستمر في العمل.سيقوم الإصدار A.B+3 بإزالة الميزة بالكامل.

Answer 8

من المؤسف أنك لا تستخدم .Net :(

بنيت في عفا عليها الزمن تقوم السمة بإنشاء تحذيرات للمترجم.