Architecture Decision Recordسجل قرار البنية المعمارية: snake_case أم camelCase لواجهة REST؟
القرار: ستُستخدم اصطلاحية التسمية snake_case لنقاط نهاية واجهة REST
الحالة: مقبول
السياق
توجد صيغتان شائعتان في اصطلاحات التسمية لواجهات REST البرمجية: snake_case وcamelCase. في صيغة snake_case تُفصل كل كلمة في الاسم بشرطات سفلية، أما في camelCase فتُكتب الكلمة الأولى من الاسم بأحرف صغيرة وتُكتب الحرف الأول من الكلمات اللاحقة كبيرًا. وسيحدد هذا القرار أي اصطلاح تسمية ينبغي استخدامه لواجهة REST البرمجية.
محركات القرار
الاتساق مع اصطلاحات التسمية القائمة في المشروع
قابلية القراءة والوضوح لكل من قد يعمل على الواجهة البرمجية
التوافق مع أفضل ممارسات القطاع في اصطلاحات تسمية واجهات REST
سهولة التنفيذ والصيانة
القرار
ستُستخدم اصطلاحية التسمية snake_case لنقاط نهاية واجهة REST. ويستند هذا الاختيار إلى العوامل التالية:
الاتساق: يستخدم المشروع بالفعل اصطلاح التسمية snake_case لجميع نقاط النهاية، وسيكون من المفيد الإبقاء على هذا الاصطلاح لضمان الاتساق في المشروع كله.
قابلية القراءة والوضوح: اصطلاح snake_case أكثر قابلية للقراءة وأسهل فهمًا. فالشرطات السفلية تفصل بوضوح بين الكلمات، مما يسهّل تحليل معنى الاسم وفهمه.
التوافق مع أفضل ممارسات القطاع: يُستخدم اصطلاح snake_case على نطاق واسع في القطاع ويُعد من أفضل الممارسات لواجهات REST، مما يجعله خيارًا جيدًا للمشروع.
سهولة التنفيذ والصيانة: الإبقاء على اصطلاح التسمية القائم أسهل في التنفيذ والصيانة، إذ سيلزم تحديث كل الشيفرة والتوثيق القائمين إذا اختير اصطلاح جديد.
العواقب
لهذا القرار عواقب محتملة.
إذا لم يكن أعضاء الفريق الجدد المنضمون إلى المشروع على دراية باصطلاح التسمية snake_case، فقد يؤدي ذلك إلى ارتباك وأخطاء في التطوير. غير أن هذا الخطر ضئيل، لأن snake_case اصطلاح واسع الاستخدام.
إذا استُخدمت في المشروع أدوات أو أطر أخرى تعتمد بكثافة على اصطلاح camelCase، فقد يتطلب ذلك جهدًا إضافيًا للتحويل بين اصطلاحات التسمية. غير أن ذلك ليس مصدر قلق كبير لأن المشروع وحّد اصطلاح snake_case.
وعمومًا، فإن قرار استخدام اصطلاح التسمية snake_case لنقاط نهاية واجهة REST ينتج نهجًا متسقًا وقابلًا للقراءة ومتوافقًا مع معايير القطاع، مع سهولة تنفيذه وصيانته.