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

قد لا تحتاج إلى هذا

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

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

ما الفرق عن التصميم؟

في الموقع التعريفي تغيير الصفحة يعني تغيير النص. وهنا تغيير قاعدة واحدة يؤثر في كل الشاشات والصلاحيات والتقارير المرتبطة بها.

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

بأي تقنية تكتبون؟

نختار بناءً على ثلاثة أسئلة: هل سيبقى مدعومًا مدة طويلة، وهل يمكن إيجاد مبرمج يتسلّمه، وهل تستطيع محركات البحث قراءة المحتوى دون تشغيل ⁨JavaScript⁩؟

ما لا نستخدمه يستحق الذكر أيضًا: ⁨Flash⁩ و⁨FrontPage⁩ و⁨Fireworks⁩ و⁨ASP⁩ الكلاسيكية لا مكان لها في أي من مشاريعنا اليوم. إن كان موقعك مبنيًا بها فالعمل المطلوب ليس تحديثًا بل إعادة كتابة.

ما نوع الأعمال التي تنفّذونها؟

• لوحات الموزعين ومراكز الخدمة: سعر حسب الدور، وإدخال الطلبات، ومتابعة الحسابات
• إدارة كتالوج المنتجات والمستندات التقنية، وجداول المتغيّرات والمقاسات
• مسارات عروض الأسعار: من النموذج إلى عرض ⁨PDF⁩، مع متابعة الموافقة والتعديل
• أنظمة الحجز والمواعيد، مع الطاقة الاستيعابية والتذكير
• لوحات الإدارة الداخلية: الطلبات والمهام والمستندات والصلاحيات
• عمليات الربط: ⁨ERP⁩، والمحاسبة، والشحن، والفاتورة الإلكترونية، وبوابات الدفع، والمتاجر الكبرى
• استلام المشاريع: قراءة الشيفرة، والتوثيق، والتجديد على مراحل

كيف يُبنى الربط بين الأنظمة؟

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

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

• ⁨ERP⁩ والمحاسبة: نقل المنتجات والمخزون والحسابات والأسعار
• الفاتورة الإلكترونية والأرشيف الإلكتروني: إصدار المستندات عبر وسيط معتمد
• الشحن: إنشاء الإرسالية، والباركود، ومطابقة رقم التتبع
• الدفع: بوابة بنكية أو مزوّد خدمات دفع؛ بيانات البطاقة لا تصل إلينا إطلاقًا
• المتاجر الكبرى: مزامنة المنتجات والمخزون، وسحب الطلبات

ماذا تفعلون في جانب الأمان؟

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

• كل بيانات قادمة من المتصفح يُعاد التحقق منها على الخادم؛ الفحص في جانب العميل تسهيل للمستخدم لا أكثر
• كلمات المرور تُلخَّص بـ ⁨bcrypt⁩ ولا تُحفظ كنص صريح في أي مكان
• فحص الصلاحية يجري على الخادم؛ الزر المخفي ليس حدًّا للصلاحية
• تحديد لمعدل الطلبات، ومصيدة للروبوتات، وتحقق من كون المرسل إنسانًا، على نقاط الدخول والنماذج
• استعلامات قاعدة بيانات ذات معاملات، وفحص لنوع الملف المرفوع وحجمه
• بيانات البطاقة لا تنزل على خادمنا أبدًا، بل تبقى داخل إطار مزوّد الدفع
• جرد للبيانات ومدد حفظ وإجراء حذف، كما يوجب قانون ⁨KVKK⁩، وهو قانون حماية البيانات التركي
• بعد إعداد النسخ الاحتياطي تُجرَّب الاستعادة فعليًا؛ النسخة التي لم تُجرَّب ليست نسخة

لمن يصبح البرنامج؟

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

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

وحين يُتفق على نقل الشيفرة يحتوي ملف التسليم على مستودع ⁨Git⁩، ونسخة احتياطية لقاعدة البيانات وملفات المخطط، وقائمة متغيّرات البيئة، وحسابات الخدمات الخارجية، ودليل التركيب، وقائمة النواقص المعروفة. البند الأخير نكتبه عمدًا. لا يُسلَّم برنامج كاملًا بلا نقص؛ والصادق هو من يضع النقص على الورق.