سؤال

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

كثيرا ما أسمع عن منظمات منفصلة فريق الصيانة أو صيانة مبرمج.ما أتساءل عنه هو ما المنطق وراء هذا ؟

وبصرف النظر عن التخندق القديمة رمز أقل البشر, هل هناك أي ؟

الدروس المستفادة من الحفاظ على الخاص بك "خردة" هي أعلى بكثير من قيمة ؟ أليس إصلاح العيوب أكثر فعالية عندما يتم ذلك من قبل أولئك الذين تسبب لهم لتبدأ ؟

أنا في عداد المفقودين أي أسباب لماذا قد يكون من المفيد أن يكون منفصل الصيانة الفريق ؟

هل كانت مفيدة؟

المحلول

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

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

الحياة الحقيقية سحق سبيل المثال:

لقد تم تعيين 1500 ساعة مشروع تنمية مسؤولة أيضا عن صيانة النظم و دعم آخر 3 تطبيقات.خلال هذا المشروع الجديد ، أنت توقف 7 مرات في الأسبوع في المتوسط لدعم هذه التطبيقات 3.في كل مرة تبدأ العمل على 3 تطبيقات, يمكنك قضاء 20 دقيقة على عقلك ملفوفة حول هذه المسألة.بعد تحديد المشكلة ، ثم قضاء 20 دقيقة على عقلك ملفوفة حول العودة رمز آخر تطرق في التطبيق الجديد الخاص بك.هذا هو التكلفة الإجمالية 40 دقيقة في انقطاع أو 280 دقيقة في الأسبوع.هذا يعني أنك فقدت 2.67 ساعات من الإنتاجية في الأسبوع فقط على التحول إلى دعم هذه التطبيقات.

نصائح أخرى

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

وخذ MicroStation و بنتلي على سبيل المثال. في تطبيق تصميم 3D (الهندسة المعمارية، تصميم المحطة، القضبان الطرق والجسور وغيرها). الآن دعونا نقول لدينا V8، V9، V10 في السوق. لديهم ميزات مختلفة، وتغير شكل ملف كبير عبر الإصدارات. ولكن هناك مشاريع ضخمة جدا (أو العملاء هي في غاية الأهمية) أن لديك لدعم عملاء V8 والعملاء V9 بينما أيضا على تطوير الاشياء V10. ولذلك فمن الضروري للشركة أن يكون لها فريق الصيانة (أو الوقت) المخصص لالإصدارات السابقة. أيضا، وعادة ما تسمى هذه الفرق فرق التخصيص إذا كان المنتج الخاص بك يدعم التخصيص والسيناريو المذكورة أعلاه.

المشكلة هي أكثر عملية أظن:

  • القانون القديم قد كتبت من قبل الناس لم يعد في الشركة أو الفريق ؛
  • القانون القديم كانت مكتوبة من قبل الخارجية مطوري ؛

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

إذا كان يمكنك تجنب هذه الحالة ، هذا جيد ، ولكن يجب التأكد من أنه دائما مؤقتة.

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

وباختصار، فإن الكثير من الوقت يتم ذلك لأسباب سياسية / غير عملي.

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

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

انا التخمين:

  • يجعل التطور الجديد أكثر قابلية للتنبؤ ، الأسهل إلى الجدول:لأن المطورين لم يتم دعا إلى إصلاح بعض غير معروف مقدما عدد من قضايا الصيانة

  • فرصة لتدريب المطورين جديدة (مثلا ، لي)

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

...الترجمة إلى البروتوكول الاختياري الخاص بك ويبدو أن , "رجل, هذا الرمز ينتن!أتمنى أن المطور الأصلي, و فرك له الأنف هو: أن هل تعلم له!"

لذلك عندما الرمز مكتوب بشكل جيد بالفعل ، أن الحجة (تعليم المطورين الأصلي) لا ينطبق.

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

[أود تحليل وتشخيص المشكلة ، قانون إصلاح ؛ و QA شخص إضافة جديدة اختبار المقابلة القضية إلى الاختبار الآلي جناح.]

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top