النهج التقني

التميّز ليس مصادفة، بل ثمرة انضباط استمر سنوات

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

ثمة درس واحد بنينا عليه لسنوات في عالم البرمجيات: عبارة «إنه يعمل» لا تكفي. فبين أن يبدو المشروع «عاملًا» على المسرح، وأن يظل بعد ثلاث سنوات سهل التطوير وآمنًا وسريعًا، هوة تساوي ملايين الدولارات. على أحد جانبيها كود يحاول إنقاذ اليوم، وعلى الجانب الآخر كود يبني الغد. وفي Partnerfy يُكتب كل سطر وفق مبادئ محددة تُبقيه على الجانب الصحيح من هذه الهوة. ولم نخترع هذه المبادئ بأنفسنا، بل أخذناها من الأدبيات الهندسية الدولية، واختبرناها ميدانيًا، ودمجناها في عقدنا. والنتيجة أن الكود المسلَّم إلى عميل وكالتك ليس كودًا «يعمل في اليوم الأول»، بل كود «سيظل يعمل بعد عشر سنوات». وتشرح هذه الصفحة كيف يُطبَّق هذا الانضباط خطوة بخطوة، وما آليات التصفية التي تضمن ألا يُطلق أي سطر دون موافقتك.

بين «الكود الذي يعمل» و«الكود عالي الجودة» هوة سحيقة

في هذا القطاع، يكفي مطوّر مبتدئ كفء لامتلاك «كود يعمل». فالكود الذي يعمل يعني فقط أنه يعطي النتيجة الصحيحة لدورة عمل (Sprint) واحدة، أو ميزة واحدة، أو سيناريو مستخدم واحد. لكن عمر البرمجيات ليس دورة عمل واحدة. فبعد ثلاثة أشهر حين يُراد إضافة ميزة جديدة، وبعد ستة أشهر حين يتعين استيعاب ارتفاع مفاجئ في الزيارات، وبعد عام حين تحين فاتورة الدين التقني، عندئذ تظهر الهوة بين «الكود الذي يعمل» و«الكود عالي الجودة». فالأول ينتج خطأً جديدًا مع كل لمسة، بينما يواصل الثاني نموه بهدوء. وفي ثقافة Partnerfy الهندسية، لا تُستخدم كلمة «يعمل» وحدها أبدًا، بل تتحول إلى التزام مكتوب نصه: «يعمل وتكلفة صيانته منخفضة». فالسنة الثالثة جزء من عقدنا بقدر يوم التسليم الأول.

نقوم على ثلاث منهجيات هندسية حديثة

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

المنهجية الرشيقة (Agile / Scrum)

دورات عمل (Sprints) مدتها أسبوعان، وتقدير بنقاط القصة (Story Points)، ومراجعات ختامية (Retrospectives)، وقياس لسرعة الفريق (Velocity). ويظهر تقدم المشروع أسبوعيًا، وعند حدوث أي انحراف تتدخل بوابة التحكم في اليوم نفسه ضمن دورة العمل.

التطوير القائم على الاختبارات (TDD / BDD)

نكتب الاختبار قبل أن نكتب الكود. فقبل تطوير أي ميزة، تكون سيناريوهات الاختبار التي تصف سلوكها المطلوب مكتوبة بالفعل. وهكذا تُكتشف الأخطاء قبل أن تتشكل، لا بعد وقوعها.

التكامل والتسليم المستمران (CI/CD) وDevOps

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

تكلفة الكود المتشابك لا تظهر يوم التسليم

ثمة حقيقة تجاهلها قطاع البرمجيات سنوات طويلة: الكود المكتوب على عجل، الضعيف البنية، غير الموثق، يبدو أنه «يعمل» يوم التسليم الأول. فالعميل راضٍ، والوكالة راضية، والمطوّر راضٍ. لكن قنبلة موقوتة تكون قد ضُبطت في ذلك اليوم. فالبنى المعروفة في هذا القطاع باسم «الكود المتشابك» (Spaghetti Code)، حتى لو عملت دون أخطاء في اليوم الأول، تتحول تدريجيًا إلى مبانٍ لا يمكن دق مسمار فيها، ثقيلة ومكلفة وهشة. فإضافة ميزة جديدة تعني «فهم الكود أولًا»، وإصلاح خطأ قائم يعني «معرفة مكان التعديل أولًا». وتسمي الأدبيات الهندسية ذلك «الدين التقني». وفي Partnerfy ندرك المسؤولية الملقاة على كل وحدة برمجية نكتبها. ولذلك نُسند إلى كل صنف (Class) مهمة واحدة، ونُبقي كل دالة أصغر ما يمكن، ونطبق على كل اسم المعيار المتبع في الأدبيات. حتى إذا فتح مهندس آخر المشروع بعد ثلاث سنوات، استطاع أن يقرأ ما يفعله الكود، وإن لم نعد هناك.

رحلة سطر الكود إلى الإطلاق: ثلاثة مرشحات لا ترحم

في فريق Partnerfy الهندسي، لا يستطيع أي مطوّر إرسال كوده مباشرة إلى النظام الرئيسي. فكل سطر ملزم بعبور ثلاث بوابات مختلفة قبل الإطلاق.

1. المراجعة البشرية (Code Review)

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

2. الاختبارات الآلية (CI Pipeline)

يُنقل الكود الذي اجتاز المراجعة البشرية إلى خوادم الاختبار الآلي. وتُحاكى اختبارات الوحدة (Unit Tests) واختبارات التكامل (Integration Tests) وسيناريوهات الاختبار الشامل (E2E) في ثوانٍ. ويُفحص عبر مئات السيناريوهات ما إذا كان الكود يعطل جزءًا آخر من النظام. وإذا فشل اختبار واحد، يُعاد الكود.

3. النشر على Staging دون توقف (Zero-Downtime)

يُنقل الكود الذي اجتاز الاختبارات إلى بيئة الاختبار النهائي (Staging)، وهي نسخة طبق الأصل من النظام المباشر. وبعد فحص أخير في ظروف قريبة من البيانات الحقيقية، يُطلق دون أن يشعر المستخدم بذلك (Zero-Downtime). وإذا حدث خلل، يعيد التراجع التلقائي (Rollback) النظام إلى الإصدار السابق خلال دقائق.

لا يُطلق أي شيء دون موافقتك

حتى المشروع الخالي من العيوب الذي اجتاز المرشحات التقنية الثلاثة لا يصل إلى أنظار عميلك قبل أن يُسجَّل توقيعك في النظام.

تجعل مرشحاتنا التقنية ثلاثية المراحل المشروع «جاهزًا للنشر»، لكن كلمة «جاهز» عندنا لا تعني «تم الإرسال». فكل مشروع نطوره يُعرض عليك أولًا عبر لوحة ID.Partnerfy من خلال رابط Staging خاص بك ومغلق أمام الجميع. وفي هذه المرحلة لا يرى عميلك شيئًا بعد. وتتولى بنفسك فحص التصميم والوظائف والمحتوى من لوحتك. فإذا كان لديك طلب تعديل، ترسله عبر اللوحة، وإلا تمنح موافقتك بالضغط على زر «إطلاق». وفي اللحظة التي يُسجَّل فيها توقيعك الرقمي وموافقتك في النظام، يُطلق المشروع تلقائيًا على النطاق الفعلي. وهذه الآلية ليست مجرد واجهة، بل قرار معماري تلتقي فيه ثلاثة أوجه من الانضباط. فهي أولًا تضع خطوة إضافية بيننا وبين عميلك، وثانيًا تضمن نفاذ كلمتك الأخيرة في القرار التقني، وثالثًا تتيح اكتشاف أي خطأ تقني قابل للتدارك «خلف الكواليس لا على المسرح». فزر «إطلاق» ليس زرًا فحسب، بل هو قرارك.

زر واحد في ID.Partnerfy: «إطلاق»

شاشة الموافقة في لوحة ID.Partnerfy هي أكثر مخرجات معمارية شراكتنا واقعية. فلكل وحدة نطورها ترى في اللوحة أربعة أمور: (1) رابط المعاينة (Staging URL): رابط يعرض الصورة النهائية للمشروع قبل الإطلاق؛ (2) ملاحظات التطوير: الميزات التي أُضيفت أو أُصلحت في دورة العمل (Sprint) هذه؛ (3) تقارير الاختبار: نتائج الاختبارات الآلية؛ (4) زر «إطلاق»: أحمر وكبير وبارز. وما لم تضغط هذا الزر، لن تُحدث الوحدة أي تغيير في النظام المباشر الذي يراه عميلك. وفي اللحظة التي تضغطه تبدأ عملية النشر التلقائي، ويتغير الإصدار دون أي توقف (Zero-Downtime)، وعند الانتهاء يصلك إشعار في اللوحة. وإن رغبت، يمكنك فتح صلاحية هذا الزر لأشخاص محددين في فريقك. فقدرة مدير علاقات العملاء لديك، أو مدير المنتج، أو حتى عميلك النهائي على الضغط عليه هي خيارك التنظيمي. لكن أيًا كان من يضغطه، تُسجَّل سلسلة الصلاحيات لحظة الضغط.

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

100%

اجتياز مراجعة الكود (Code Review)

لا كود دون موافقة بشرية

85%+

تغطية الاختبارات

خط اختبارات مؤتمت

<5 دقائق

زمن التراجع (Rollback)

عند حدوث أي خلل

ستة مستندات تُسلَّم مع الكود

تسليم البرمجيات لا يعني إرسال كود يعمل فحسب. فسرعة الفهم المنتظرة من مهندس آخر يفتح المشروع بعد ثلاث سنوات تكمن في جودة التوثيق الذي سلّمناه.

توثيق API

بتنسيق (OpenAPI / Swagger): مخططات الإدخال والإخراج لكل نقطة نهاية (Endpoint)، وأمثلة أزواج الطلب والاستجابة، وقائمة رموز الأخطاء، ومتطلبات التفويض. وبذلك تستطيع فرق الواجهات الأمامية (Frontend) أو شركاء التكامل البدء في كتابة الكود دون أي محادثة إضافية.

مخطط المعمارية

مخطط رفيع المستوى للنظام: أي خدمة تتواصل مع أي خدمة، ومن أين تتدفق البيانات وإلى أين، وأي تكامل يستخدم أي طبقة. وتُرفق معه مبررات القرارات المعمارية (Architecture Decision Records).

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

مخطط الكيانات والعلاقات (ER)، وأوصاف الجداول، وخرائط العلاقات، واستراتيجية الفهرسة، وأنواع البيانات. أما ملفات الترحيل (Migration) فتوجد في المستودع (Repository) خاضعة للتحكم في الإصدارات ومرتبة تسلسليًا.

دليل النشر

خطوات مكتوبة تفصيليًا لنشر المشروع: متغيرات البيئة (env) المطلوبة، وأوامر البناء (Build)، وعمليات مسح ذاكرة التخزين المؤقت (Cache)، وترتيب عمليات الترحيل في قاعدة البيانات. ويرد إجراء التراجع (Rollback) في المستند نفسه.

دليل التشغيل (Runbook)

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

التوثيق داخل الكود

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

بعد سنوات، حين يفتح مهندس آخر هذا الكود، سواء كنا هناك أم لا، سيشرح الكود نفسه بنفسه

الكود المكتوب جيدًا هو أفضل توثيق.

السؤال الأخير الذي ينبغي أن يطرحه المهندس على نفسه هو: «بعد خمس سنوات، حين يفتح هذا الكود مطوّر لم ألتقِ به قط، هل سيفهمه حتى في غيابي؟» فإذا كان الجواب «لا»، فإن الكود لم يُكتب جيدًا بما يكفي. وفي Partnerfy نعيد الإجابة عن هذا السؤال مع كل عملية Commit نجريها. فكل صنف ودالة ومتغير نكتبه يُكتب كأنه لشخص سيرث المشروع منا. فالأسماء تشرح ما تفعله، ومبررات القرارات المعمارية موجودة في الكود، والتوثيق ليس ملف Word منفصلًا عن الكود، بل يعيش إلى جانبه، في أسطر التعليقات وفي ملف README داخل المستودع. والمكسب طويل الأمد للوكالة التي تعمل معنا هو هذا: حتى لو توقفت عن العمل معنا، يبقى الكود الذي تركناه لدى وكالتك، ويمكن لفريق آخر مواصلته، لأنه كُتب ليشرح نفسه بنفسه. فسمعتنا ليست ما تحصل عليه أثناء العمل معنا فحسب، بل طبقة الجودة التي نتركها خلفنا عند الرحيل.

تواصل معنا للاطلاع على نهجنا التقني بالتفصيل

املأ النموذج أدناه، وسنرسل إليك ورقة تقنية مفصلة (White Paper) تتضمن معاييرنا الهندسية، ونموذجًا لتوثيق API ومخططًا لسير عملية التطوير. ويمكنك كذلك استخدام الرقم ⁦0850 259 30 04⁩ للتواصل معنا مباشرة.

لأي استفسار، يمكنك التواصل معنا في أي وقت عبر: [email protected]

تم استلام طلبك!

سنراجع طلب الشراكة الخاص بك ونتواصل معك عبر الرقم في أقرب وقت ممكن.

الاسم الأول

اسم العائلة

البريد الإلكتروني

رقم الهاتف

—

ما نوع شركتك؟

اسم الشركة

ما نوع الدعم الذي تحتاج إليه؟

المواقع الإلكترونية مشاريع البرمجيات المخصصة تطبيقات الجوال تطبيقات سطح المكتب الخوادم والبريد الإلكتروني ودعم تقنية المعلومات

الرسالة

عدد العملاء المستهدف

500

1 1.000

العدد الشهري التقديري للعملاء المستهدفين (من 1 إلى 1,000)

حدد المربع للموافقة على

تعرّف على Partnerfy

لماذا Partnerfy؟

الموارد والدعم