YAGNI - الممارسة الرشيقة التي لا يجب ذكر اسمها؟[مغلق]

Question

مع استيعابي المتزايد للتفكير الرشيق في طريقة عملي، يبدو أن كلمة yagni ("لن تحتاج إليها") أصبحت أكثر أهمية.يبدو لي أنها واحدة من أكثر القواعد فعالية لتصفية الأولويات المضللة وتحديد أولوياتها لا للعمل في المقبل.

ومع ذلك، يبدو أن مفهوم yagni بالكاد يتم التطرق إليه هنا في SO.لقد أجريت البحث الإلزامي، ولم يظهر إلا في عنوان سؤال واحد - ثم في دور ثانوي.

لماذا هذا؟هل أبالغ في تقدير أهميتها؟

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

فيما يلي بعض الأسئلة المستمرة التي قد يطرحها المرء.

هل تم تحديد اختبارات الوحدة الخاصة بي بناءً على متطلبات المستخدم أو بنية إطار العمل؟

هل أقوم بتثبيت (واختبار وصيانة) اختبارات الوحدة الموجودة فقط لأنها خارج إطار العمل؟

ما مقدار التعليمات البرمجية التي تم إنشاؤها بواسطة إطار العمل الخاص بي والتي لم ألقي نظرة عليها مطلقًا (ولكن لا يزال من الممكن أن تعضني يومًا ما، على الرغم من yagni)؟

ما مقدار الوقت الذي أقضيه في العمل على أدواتي بدلاً من حل مشكلة المستخدم؟

عند البرمجة الزوجية، غالبًا ما تكمن قيمة دور المراقب في "yagni".

هل تستخدم أداة CRUD؟هل يسمح لك (بل يشجعك) باستخدامه كأداة _RU_، أو أداة C__D، أم أنك تقوم بإنشاء أربع أجزاء من التعليمات البرمجية (بالإضافة إلى أربعة اختبارات وحدة) عندما تحتاج إلى واحد أو اثنين فقط؟

Answer 1

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

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

YMMV.

Answer 2

Yagni و KISS (اجعل الأمر بسيطًا يا غبي) هما في الأساس نفس المبدأ.لسوء الحظ، أرى ذكر KISS بقدر ما أرى كلمة "yagni".

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

Answer 3

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

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

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

Answer 4

المشكلة التي أجدها هي أن الناس يميلون إلى تجميع مصانع الكتابة باستخدام حاويات DI (ما لم يكن لديك ذلك بالفعل في قاعدة التعليمات البرمجية الخاصة بك) ضمن YAGNI.وأنا أتفق مع JB King هناك.بالنسبة للعديد من الأشخاص الذين عملت مع YAGNI، يبدو أن هذا هو الترخيص لقطع الزوايا/لكتابة تعليمات برمجية غير دقيقة.

على سبيل المثال، كنت أكتب PinPad API لاستخلاص نماذج PINPad المتعددة/المصنعين.لقد وجدت أنه ما لم يكن لدي الهيكل العام، لا أستطيع كتابة حتى اختبارات الوحدة الخاصة بي.ربما لست ممارسًا متمرسًا في TDD.أنا متأكد من أنه ستكون هناك آراء مختلفة حول ما إذا كان ما فعلته هو YAGNI أم لا.

Answer 5

لقد رأيت الكثير من المنشورات على SO تشير إلى التحسين المبكر وهو شكل من أشكال yagni، أو على الأقل ydniy (لست بحاجة إليه بعد).

Answer 6

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