مبدأ المسؤولية الواحدة في ServiceNow
نُشر في ٧ فبراير ٢٠٢١ · 1 دقائق قراءة
أقرأ حالياً كتاباً رائعاً بعنوان Clean Architecture: A Craftsman's Guide to Software Structure and Design لروبرت سي. مارتن، وأجد نفسي أتساءل باستمرار: هل ثمة شيء يمكنني تطبيقه من هذا الكتاب على عملي في ServiceNow؟ أعتقد أن الجواب نعم.
ما هو مبدأ المسؤولية الواحدة؟
مبدأ المسؤولية الواحدة (SRP) جزء من مبادئ SOLID، التي تصف كيفية ترتيب الدوال وهياكل البيانات في كلاسات، وكيف ينبغي أن تترابط تلك الكلاسات.
الحجة لصالح هذا المبدأ بسيطة: يجعل نظامك أسهل في التطبيق ويمنع الآثار الجانبية غير المتوقعة للتغييرات المستقبلية.
ينبغي أن يكون للكلاس أو الوحدة سبب واحد فقط للتغيير.
ما معنى "المسؤولية" في سياق ServiceNow؟
في سياق ServiceNow، "كلاساتك" هي مكونات إعداداتك:
- Script includes
- إجراءات Flow Designer
- UI Policies
- Client Scripts
- Widgets
مثال: سكريبت عميل يتحقق من صحة أرقام الهواتف يُقال إن له مسؤولية واحدة. أما سكريبت عميل يتحقق ويعيد تنسيق الأرقام بإضافة رموز الدول، فله مسؤوليتان.
وفقاً لمبدأ SRP، ينبغي تقسيمهما إلى سكريبتين مستقلتين — واحد للتحقق وآخر للتنسيق.
لماذا يهم هذا؟
حين يكون سكريبت أو تدفق واحد مسؤولاً عن أشياء كثيرة جداً، فإن أي تغيير فيه ينطوي على مخاطرة. قد تصلح سلوكاً وتكسر آخر دون قصد. الفصل بين المسؤوليات يعني أن كل تغيير محدد وقابل للاختبار وآمن.
يبدو المبدأ بسيطاً، لكن تطبيقه باستمرار هو ما يُميّز نسخة ServiceNow مبعثرة عن أخرى سهلة العمل عليها فعلاً على المدى البعيد.
للمزيد حول Clean Architecture، راجع كتاب روبرت سي. مارتن.