سياسات التطوير

سياسات التطوير


مقدمة

انطلاقا من توجه وكالة الوزارة لتقنية المعلومات لتحقيق تحول رقمي محوكم وفعال وتبني منهجية التطوير المرنة عالية الجودة، فقد تبنت الوكالة المساعدة للتحول الرقمي وضع سياسة تضمن ضبط جودة عمليات التطوير واتساقها بين الأنظمة المختلفة؛ مما يسهل دعم عمليات التطوير المستمرة . وعليه، فقد اعتمدت الوكالة المساعدة للتحول الرقمي هذه السياسة بحيث تلتزم بها جميع الفرق، على أن يتم تحديثها بصورة دورية بما يحقق أهداف الوزارة.

الأهداف

  • تسهيل قراءة ومراجعة وتعديل الأكواد
  • تسهيل أتمتة اختبارات جودة الأكواد
  • تسهيل نقل المطورين بين الفرق
  • تسهيل دخول المطورين الجدد إلى الفرق  وتسريع الاستفادة منهم

نطاق الوثيقة

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


تعريفات أساسية

الواجهات الأمامية (Front-end)

هي الشاشات التي يتعامل معها المستخدمون.

الواجهات الخلفية (Back-end)

هي واجهات الويب البرمجية (Web APIs) المسئولة عن إجراءات الأعمال (business logic) وخصائص النظام وتقديمها في صورة خدمات ويب (web services).

السياسات

السياسات العامة

  • الالتزام بالتقنيات المعتمدة في الوزارة
  • الالتزام بالأدلة الإرشادية للتقنيات المعتمدة في الوزارة
  • الالتزام بالمعمارية الموضوعة للنظام وعدم مخالفتها
  • الالتزام باستخدام Azure DevOps كمنصة معتمدة للتطوير
  • يجب ربط جميع الخدمات مع منصة قيم
  • يجب التأكد من عدم تأثر سلبي لأي خدمات أخرى كخدمات التكامل و بوابة ناجز
  • جميع الخدمات المستخدمة داخل النظام نفسه أو للتكامل مع الأنظمة أوللجهات الخارجية يجب نشرها على المنصة التكامل المعتمدة في الوزارة (Apigee)
  • يجب التنسيق مع فرق البنية التقنية (إدارة الأنظمة – إدارة قواعد البيانات – إدارة الشبكات – إدارة التكامل الرقمي) منذ بدء عمليات التطوير لتجهيز الاحتياجات من البنية التحتية، مثل تجهيز الخوادم، و فتح المنافذ (Ports)، وتجهيز قواعد البيانات؛ لضمان الالتزام بسياسة اتفاقية مستوى التشغيل (Operational Level Agreement – OLA).
  • يجب التنسيق مع مركز أمن المعلومات قبل وأثناء وبعد عمليات التطوير
  • الإلتزام بسياسات تطوير وصيانة التطبيقات الصادرة من أمن المعلومات
  • يجب التقيد والإلتزام بالسياسات العامة لتجربة المستخدم
  • يجب تنفيذ توصيات التجربة الرقمية المسندة للمنتج بمنصة التطوير Azure DevOps
  • يجب التأكد من مراقبة جميع خوادم وقواعد البيانات للبيئة الحية بالتنسيق مع مركز التشغيل الذكي قبل الوصول لمرحلة الإطلاق
  • يجب أتمتة جميع عمليات الإطلاق بما يتوافق مع سياسات عمليات التشغيل (DevOps) المعتمدة في الوزارة
  • يجب استخدام أحدث إصدار من المكتبات البرمجية (code libraries) وأطر الأعمال (development frameworks)
  • الالتزام بآلية (GitHub Flow) لإدارة الأكواد
  • جميع خصائص النظام يمكن تفعيلها أو إلغاؤها (Feature Toggles)
  • اتباع أفضل ممارسات التصميم الهندسي (software engineering) مثل OOD، SOLID Principles، Design Patterns، خاصة المستخدمة في الأنظمة المشابهة (Enterprise Applications Patterns) إلخ.
  • تبسيط كتابة الكود قدر الإمكان باتباع مباديء Clean Code
  • تجنب الممارسات السيئة في كتابة الكود (code smells) وتحسين الكود المستمر بالطرق المعهودة (refactoring patterns)
  • الاحتفاظ بجميع الأكواد أو سكريبتات قواعد البيانات في نظام إدارة الأكواد (Source Code Management System) المعتمد في الوزارة، وهو Git.
  • جميع التعديلات على الكود يجب أن تكون مرتبطة بمتطلب (work item)
  • يمنع حفظ أية معلومات حساسة في الكود، مثل كلمات مرور أو عناوين خوادم أو قواعد بيانات أو خدمات على البيئة الحية.
  • الاستعانة بأدوات قياس وإلزام المطورين بالمعايير، فعلى سبيل المثال لا الحصر، يمكن الاستفادة من ReSharper، أو NDepend أو SonarQube أو JSLint أو غيرها مما يؤدي نفس الوظيفة. وأهم المؤشرات التي يجب الاستفادة منها – على سبيل المثال لا الحصر:
    • درجة التعقيد (Cyclomatic Complexity): يجب ألا تزيد عن 10،و يفضل ألا تزيد عن 3
    • الأكواد غير مستخدمة (Dead Code): صفر
    • تغطية الكود بالاختبارات المؤتمتة (Test Coverage): لا تقل عن 70% في الأجزاء التي تحتوي على قواعد عمل النظام (business rules)
    • عدد المتغيرات الممررة للدالة (Max Parameters Count): يجب ألا تزيد عن 3
    • عدد أسطر الدالة (LOC per method): يفضل ألا تزيد عن 15
    • الالتزام بقواعد التسمية (Naming Conventions): 100%

سياسات الواجهات الأمامية (Front-ends)

سياسات عامة لكل الواجهات الأمامية

سياسيات واجهات الويب الأمامية (Web browsers)

  • الالتزام بالإرشادات المقترحة من “إير بي إن بي AirBnb” (Airbnb JavaScript Style Guide) في كتابة الأكواد بلغة JavaScript.
  • الالتزام بالإرشادات المقترحة من فريق تطوير Vue.js (Vue.js Style Guide) في تطوير واجهات الاسخدام
  • الالتزام بالإرشادات المتبعة من فريق تطوير TypeScript في مايكروسوفت (TypeScript Coding guidelines)
  • الالتزام بالإرشادات المقترحة من جوجل (Google HTML/CSS Style Guide) في تصميم الصفحات بلغة (HTML) و (css).
  • الاستفادة من الإرشادات المقترحة من فريق تطوير Vue.js (Vue Test Utils) في كتابة الاختبارات المؤتمتة (Unit Tests).
  • الالتزام بدعم المتصفحات  الرئيسية: كروم (Chrome) وفايرفوكس (Firefox) وسفاري (Safari) و إيدج (Edge)، سواء على الكمبيوتر أو على الجوال.
  • الالتزام بدعم كافة أحجام الشاشات (Responsive Web Design) في بوابة ناجز. أما في الأنظمة الداخلية فحسب الحاجة.

سياسات واجهات أجهزة الخدمة الذاتية (Self-service Kiosks)


سياسات تطبيقات الجوال

التطبيقات متعددة المنصات

  • الالتزام بالإرشادات المقترحة من “آير بي إن بي AirBnB”  (Airbnb React/JSX Style Guide) في كتابى الكود باستخدام React.
  • يجب تخصيص الكود بما يتوافق مع الإرشادات المقترحة من جوجل وآبل في تصميم تجربة المستفيدين إذا خالف المنتج بوضعه الافتراضي هذه الإرشادات.

تطبيقات الآيفون

  • الالتزام بالإرشادات المقترحة من “آير بي إن بي AirBnb” (Airbnb’s Swift Style Guide) في تطوير تطبيقات الآيفون باستخدام لغة Swift.
  • الالتزام بالإرشادات المقترحة من آبل (Apple) (Human Interface Guidelines)  في تصميم تجربة المستفيدين.

تطبيقات الأندرويد

  • الالتزام بالإرشادات المقترحة من جوجل (AOSP Java Code Style for Contributors) و/أو (Code Style Guide) في تطوير تطبيقات الأندرويد باستخدام لغة Java.
  • الالتزام بالإرشادات المقترحة من جوجل (Design for Android) في تصميم تجربة المستفيدين.
  • الاستفادة من الإرشادات المقترحة من جوجل (Test apps on Android) في كتابة الاختبارات المؤتمتة

سياسات الواجهات الخلفية (Back-ends)

  • الالتزام بالإرشادات المقترحة من مايكروسوفت (Framework Design Guidelines)  في كتابة الأكواد بلغة C#.
  • الالتزام بالمعايير المعتمدة في الوزارة لتصميم واجهات الويب البرمجية (Web APIs).
  • الالتزام بالإرشادات المقترحة من مايكروسوفت في كتابة اختبارات الوحدات (Unit testing best practices with .NET Core and .NET Standard)

سياسات قواعد البيانات (databases)

  • يلزم إجراء تعديلات قواعد البيانات في مشروع قواعد بيانات (SQL Server Database Project) وإدارة التغييرات على قواعد البيانات في Git Repository مثل سائر الأكواد.
  • الالتزام بالمعايير المعتمدة في الوزارة في تسمية مكونات قواعد البيانات

سياسات ضمان الجودة (Quality Assurance)

التسليمات المطلوبة:

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

مرحلة ما بعد الاختبار وقبل الاطلاق:
(تقرير الاختبار – نتائج الأخطاء):  يجب على مسؤول الجدودة أن يسلمها لمدير المنتج بعد الإنتهاء من الإختبارات المطلوبة.

الاختبارات المطلوبة:

الاختبار المتطلب عمله من قبل مركز أمن المعلومات:

  • اختبار الأمان(اجباري) (Security Test): يجب التنسيق مع أمن المعلومات في مرحلة التطوير ليتم عمل حالات اختبار لمعرفة مدى حماية المعلومات

الاختبارات المتطلب عملها من قبل فريق الجودة:

يجب القيام بأداء اختبارات النظام (System Testing) من قبل مسؤول الجودة في الفريق:

  • اختبار التجميع (Integration Testing)
  • اختبار المهام الجديدة
  • اختبار الأدوار وصلاحية الوصول (Role based testing
  • اختبار أداء النظام (Performance testing): وأهمها: اختبار التحمل (Load Test) – • اختبار الضغط (Stress Test)
  • اختبار موافقة المستخدم (User Acceptance Testing)
  • اختبار تجربة المستخدم/سهولة الاستخدام (User experience/usability testing)
  • اختبار التوافقية (Compatibility testing)
  • اختبار التراجع (Regression Test)
  • اختبار الدخان (Smoke Test)
  • اختبار المشاكل التي تم حلها