تطبيق صلاحيات تعدد المؤسسات في واجهة البرمجة

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

الانتماء ليس عموداً يُضاف لاحقاً

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

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

ثلاثة أسئلة على كل طلب أن يجيب عنها

قبل أن يصل الطلب إلى أي بيانات، يجب أن تكون ثلاث إجابات موجودة سلفاً.

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

أين يكون التحقق

عند حدود واجهة البرمجة، قبل طبقة البيانات، ولا في الواجهة وحدها أبداً.

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

ووضع التحقق عند الحدود يجعل الاختبار رخيصاً أيضاً. فقاعدة تعيش داخل مكوّن تحتاج متصفحاً وصفحة مرسومة. والقاعدة نفسها خلف نقطة واجهة برمجة تحتاج طلباً واحداً.

اختبروا القواعد لا الشاشات

الاختبارات المهمة قصيرة ومملة: لكل دور ولكل نقطة واجهة برمجة، تحقّقوا مما يحدث حين يكون السجل تابعاً لمؤسسة أخرى. الجواب المتوقع هو نفسه دائماً تقريباً، وهذا ما يجعل السلسلة سهلة الاكتمال.

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

الترحيل الذي لا يخطط له أحد

في مرحلة ما سيطلب عميل أن يُقسَم إلى اثنين، أو سيندمج عميلان، أو سيحتاج مستخدم إلى الوصول إلى مؤسسة ثانية. فإن كان الانتماء عموداً، صارت الحالات الثلاث عمليات إصلاح بيانات بجدول حسابات وأنفاس محبوسة.

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