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