أريد أن أشارك أفكاري في واحدة من صفات البرنامج: الصيانة.
المشاريع لا تدفع دائما الانتباه إلى الصيانة. نتيجة لذلك ، مع تغيير الفريق ، تبدأ الصعوبات. خاصة إذا تغير الفريق بشكل غير متوقع وبتكوين كبير.
في المشاريع ، لعبت دور ضمان الجودة. من بين الصفات الأخرى ، كان من الضروري رعاية المرافقة. من جانب المبرمجين ، أولاً وقبل كل شيء ، يعني ضمناً أن الكود يجب أن يكون مصحوبًا بتعليقات وبنية جيدة. وفي الوقت نفسه ، المرافقة شيء أكثر. تتيح لك إمكانية الصيانة الجيدة الاستفادة من الشركة المصنعة لمنتج البرنامج. ليس من دون سبب أنه في الشركات الكبيرة يمكنك العثور على البرامج القديمة التي لا تزال بعيدة عن الواجهة الودية ، ولكن لديها إمكانية صيانة جيدة. بسبب هذا ، فهي ليست في عجلة من أمرها لتحل محل تطوير الشركات المنافسة.
يمكنك إعطاء تشابه مع وضع الكهرباء في مبنى:
- سوف يزودك كهربائي جيد بداراتها قبل وضع الأسلاك. لن يكون من الضروري حتى بعد سنوات عديدة اللجوء إليه لفهم ما الذي يؤدي إلى أين وكيف يعمل. لن تكون هناك مشاكل أثناء العملية.
- إذا لم يقم كهربائي بعمل مخطط الأسلاك ، في المرة القادمة سوف يتصلون به فقط ، لأن باستثناءه ، لا أحد يعرف كيف يتم ترتيب كل شيء - ثم يجب عليك التفكير فيما إذا كان الأمر يستحق التعامل معه.
كاختبار ، يمكنني أن أقدم لكم الانتباه إلى الجوانب التالية لزيادة الصيانة.
الوثائق الوظيفية.
هناك حاجة إلى الوثائق ليس فقط "للمستخدمين في مكان ما هناك" ، ولكن أيضًا حتى الساعة 12 ظهرًا ، يمكن لأي شخص غير مألوف بالمنتج استخدامه دون طلب المساعدة من الآخرين. على سبيل المثال:
- يمكن للمبرمج الذي تم تعيينه بالأمس تصحيح ميزة ،
- الدعم الفني يمكن الإجابة على سؤال المستخدم
- يمكن للاختبار معرفة ما إذا كان هناك شيء ما في ميزة غير مألوفة قد تم كسره.
توثيق البنية التحتية
غالبًا ما يتم استخدام العديد من الأدوات لإنشاء المنتج. من بينها:
- نظام التجميع. ربما يتكون من العديد من الأجهزة ، ولكل منها العديد من الإعدادات ؛
- خدمات البنية التحتية الأخرى ، مثل خوادم الملفات ، ونظام تخزين الأكواد (خاصة إذا كانت هناك تبعية للمكتبات على أنظمة أخرى) ، وما إلى ذلك ؛
- تقف الاختبار. يجب أن تكون إعداداتها ووصفها في خطط الاختبار.
كل هذا مرتبط بالمشروع. وسيكون من الجيد الحصول على وصف تفصيلي للهيكل ، بحيث يمكنك استعادته بسهولة في حالة فشل محرك الأقراص الصلبة المزوّد بآلات الهيكل. أو حتى تتمكن من إجراء تغييرات في البنية التحتية دون جهد دون قضاء وقت في دراسة كل شيء صغير.
توثيق المشاكل والمخاطر
في عملية إنشاء المنتج وتشغيله ، ستظهر المشاكل بالتأكيد. يمكن تصنيفها ووصفها كقاعدة حل.
بعض العيوب قد يكون لها حل. إذا كان العيب خطيرًا ، فيجب أن يكون من الممكن إيجاد طريقة للتغلب عليه في قاعدة بيانات المشاكل. على سبيل المثال ، إذا كان يمكن تعيين أي إعدادات فقط في متصفح معين.
إذا كشف التطوير عن معلومات قد تنشأ عن مشاكل في المستقبل ، فينبغي أن توصف هذه المعلومات على أنها مخاطر. على سبيل المثال ، إذا تم استخدام وحدة نمطية في نظام يضم 100 مستخدم ، فمن المحتمل أن ينقطع عن 500 مستخدم.
تعليقات وأوصاف الكود
قد يكون هناك مستند مع وصف فني لجميع الوحدات ، بما في ذلك جميع المخططات المعمارية.
معلومات عن الأدوات المستخدمة
على سبيل المثال ، ما هي الأدوات وكيفية استخدامها لتصحيح الأخطاء والاختبار.
في بعض الأحيان قد يحتاج المبرمج إلى أدوات اختبار لتصحيح وظائفه. أو قد يحتاج المختبر إلى معلومات حول أدوات المطور لجمع المعلومات عند العثور على عيب.
بما في ذلك الأمر يستحق الانتباه إلى انتشار الأدوات. حتى لو كانت بعض الأدوات مناسبة تمامًا للمهمة الحالية ، لكنها قديمة وغير مدعومة ، فقد تكون صعبة.
إنجاز المهمة
كما يقول مبدأ باريتو: يستغرق 80 ٪ من الوقت لإكمال 20 ٪ من العمل.
وإذا لم يكتمل شيء ما ، فلا بد إذن من وجود سبب. على الأرجح ، كانت مكلفة.