هل يؤدي التغيير المتكرر للمتطلبات إلى كود السباغيتي؟

Question

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

Answer 1

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

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

وهناك بعض النصائح لتجنب ذلك:

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

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

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

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

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

Answer 2

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

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

Answer 3

واختبار التغطية الجيدة هي أفضل دفاع ضد التغييرات المتكررة.

Answer 4

1. توقع التغييرات، إذا/عندما تستطيع، وقم بتعميم المتطلبات إن أمكن
2. والأهم من ذلك، توقع الوقت بين التغييرات
3. قم بتقطيع العمل/الميزات/التكرارات حتى يمكن إكمالها في الوقت بين التغييرات
4. هاهو!أنت الآن تمارس نشاطًا سريعًا ويبدو التغيير المستمر أمرًا طبيعيًا 8-P
5. تناول الأسبرين، وتذمر من رئيسك، ثم عد إلى رقم 1؛-)

Answer 5

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

• تحتوي كل وحدة (سواء كانت وظيفة أو فئة أو مكتبة أو تطبيقًا كاملاً) على ملف غرض محدد جيدا.
• كل وحدة مثالية ليس أكبر مما يجب أن يكون لخدمة غرضها المحدد.
• الوحدات هي المتباعدة, مما يعني أنه يمكن استبدالها بوحدات أخرى دون التسبب في تعطل البرنامج.
• يمكن أن تكون الوحدات تم اختباره بشكل فردي للتأكد من أنها تؤدي غرضها دون خطأ.
• الوحدات هي منظمة بطريقة تساعد على جعل مجال المشكلة بديهيًا للمبرمجين الآخرين.

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

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

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

Answer 6

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

http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf سيكون مفيدا.

Answer 7

وزحف نطاق / متطلبات سيئة تحليل (المتغيرة):

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

وأفضل حل هو وضع المعالم وأن تعرف متى تظهر هذا الرابط لمن يحافظ تغيير المتطلبات.

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

Answer 8

كثير من الأحيان، المتطلبات المتغيرة للمشكلة التي وضعت أساليب رشيق للتعامل مع - تم إنشاؤها على الأقل جزئيا في الاعتراف بوجود المشكلة أن متطلبات <م> قيام تغير، في كثير من الأحيان لأسباب وجيهة جدا

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

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

Answer 9

إذا كنت ستغادر مع نصيحة واحدة: معيد البناء، معيد البناء، معيد البناء!غالباً!

كل شيء آخر هو تفاصيل حول جعل إعادة البناء أسهل.

Answer 10

إن تلبية احتياجات التغييرات المتكررة هو الغرض مما يلي:

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

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