لماذا تحتاج إعداداتك إلى نفس الانضباط الذي تتعامل به مع الكود

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

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

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

المشكلة مع فصل الإعدادات

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

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

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

الإعدادات لها تأثير حقيقي

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

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

ما تحصل عليه عندما تتعامل مع الإعدادات مثل الكود

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

الفرق بين الطريقتين القديمة والجديدة واضح في الممارسة:

flowchart TD subgraph Old[الطريقة القديمة: إعدادات خارج التحكم بالإصدارات] A[قيم ثابتة في الكود] --> B[تعديل يدوي على الخادم] B --> C[لا يوجد سجل تغييرات] C --> D[استرجاع مستحيل] D --> E[خطر التوقف عن العمل] end subgraph New[الطريقة الجديدة: الإعدادات ككود] F[إعدادات في التحكم بالإصدارات] --> G[طلب سحب ومراجعة] G --> H[فحوصات آلية] H --> I[تسجيل تاريخ الإصدارات] I --> J[إمكانية الاسترجاع] J --> K[تغييرات آمنة وقابلة للتدقيق] end

1. سجل تغييرات كامل

يتم تسجيل كل تعديل على الإعدادات. تعرف من غير ماذا ومتى ولماذا. إذا حدث حادث في الإنتاج الساعة 2 مساءً وقام شخص بتغيير قيمة إعدادات الساعة 1:45 مساءً، يمكنك رؤية ذلك فورًا. لا مزيد من التخمين. لا مزيد من السؤال في قنوات الدردشة.

2. القدرة على الاسترجاع

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

3. المراجعة قبل النشر

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

ما يعتبر إعدادات

قبل أن تتمكن من إدارة الإعدادات بشكل صحيح، تحتاج إلى معرفة ما ينتمي إلى هذه الفئة. إليك قائمة عملية بالأشياء التي يجب أن تعيش خارج قاعدة الكود الخاص بك ويتم التعامل معها كإعدادات:

  • سلاسل اتصال قاعدة البيانات وبيانات الاعتماد
  • مفاتيح API ورموز الخدمات الخارجية
  • أعلام الميزات ومفاتيح التبديل
  • مدد المهلة الزمنية وحدود إعادة المحاولة
  • مستويات السجل ووجهات التسجيل
  • مسارات الملفات ومواقع التخزين
  • أرقام المنافذ وعناوين الشبكة
  • حدود الموارد (الحد الأقصى للاتصالات، الحد الأقصى لحجم الملف، الحد الأقصى لحجم الطلب)
  • أسماء البيئات ومعرفاتها
  • عناوين URL للخدمات الخارجية

أي شيء يتغير بين البيئات، أو قد يحتاج إلى التغيير دون تعديل منطق التطبيق، هو إعدادات.

قائمة تحقق عملية لإدارة الإعدادات

إذا كنت تبدأ في التعامل مع الإعدادات بشكل أكثر جدية، إليك قائمة تحقق قصيرة لتوجيه منهجك:

  • قم بتخزين الإعدادات في التحكم في الإصدارات، وليس على الخوادم
  • احتفظ بالإعدادات منفصلة عن الكود (ملفات أو أدلة مختلفة)
  • استخدم ملفات إعدادات خاصة بالبيئة أو متغيرات بيئة
  • لا تقم أبدًا بتضمين الأسرار بشكل ثابت في ملفات الإعدادات (استخدم مدير أسرار أو خزنة)
  • راجع تغييرات الإعدادات من خلال طلبات السحب
  • اختبر تغييرات الإعدادات في بيئة غير الإنتاج أولاً
  • وثق ما تفعله كل قيمة إعدادات ونطاقها المتوقع
  • ضع خطة استرجاع لتغييرات الإعدادات

الخلاصة

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