ما الذي تحصل عليه كمطوّر
- ترمينال كامل: تثبّت حزم npm أو حزم النظام، وتشغّل git كما تعرفه (
git cloneوgit pull). - أي لغة: Node و Python و PHP و Go وقواعد بيانات SQLite أو PostgreSQL أو MySQL، كلها عبر أوامر التثبيت المعتادة.
- GitHub: دفع المشروع إلى مستودعك برمز وصول شخصي بصلاحية repo، واستيراد مستودع قائم عند إنشاء مشروع جديد.
- أسرار: مفاتيحك في مخزن منفصل تصل لتطبيقك كمتغيرات بيئة، ولا تظهر في المحادثة.
- نشر: بناء إنتاجي حقيقي، لا نسخة التطوير، مع SSL تلقائي ونطاق مخصص.
3 حالات استخدام
المطوّر لا يحتاج من يكتب عنه كل شيء، بل من يختصر الأجزاء المملة. هذه ثلاث حالات يكون فيها الوصف أسرع من الكتابة.
الحالة 1: لوحة إدارة فوق API موجود
عندك خدمة Express تعمل لتطبيق توصيل في الرياض، والفريق يحتاج لوحة إدارة لمتابعة الطلبات والسائقين. استورد المستودع، ثم صف اللوحة: الجداول والفلاتر والصلاحيات. أوترا تقرأ الكود القائم وتبني اللوحة متوافقة معه، وتراجع أنت الفرق قبل أن تدفعه.
هذا المستودع فيه API بـ Express لطلبات التوصيل. ابنِ لوحة إدارة بـ React داخل مجلد admin تستدعي المسارات الموجودة: جدول الطلبات بفلتر الحالة والحي، صفحة السائقين، وتسجيل دخول للمشرف. لا تغيّر مسارات الـ API الحالية، واكتب لي قائمة الملفات التي أضفتها.
الحالة 2: نموذج أولي لفكرة قبل الالتزام بها
تريد اختبار فكرة أداة داخلية تقرأ ملفات CSV من نظام المحاسبة وتُظهر تقريرًا. بدل نصف يوم من الإعداد، تحصل على نسخة تعمل في الجلسة نفسها، فتقرر هل تستحق الاستثمار. إن استحقت، ترفع جودتها بيدك؛ وإن لم تستحق، لم تخسر يومًا.
ابدأ بوضع Plan
راجع الخطة قبل التنفيذ: بنية المجلدات، المكتبات، وشكل قاعدة البيانات.
نفّذ بوضع Code
يُبنى المشروع ويُشغَّل ويُختبر في متصفح حقيقي.
راجع بوضع Review
اطلب مراجعة لما بُني، ثم عدّل يدويًا ما لا يعجبك.
الحالة 3: نقل مشروع جانبي من أداة أخرى
بدأت مشروعًا جانبيًا في أداة بناء أخرى، وتريد بيئة تتحكم فيها أكثر. إن كان الكود في GitHub، فاستورده وأكمل عليه. وإن كان يعتمد على خدمة خلفية بعينها، فأضف مفاتيحها في «البيانات السرية». اقرأ نقل مشروع من Replit لمثال عملي.
git checkout -b feature/admin-filters
npm install date-fns
npm test
git add -A && git commit -m "Admin: filter orders by district"
git push origin feature/admin-filtersالباقة المناسبة لك
المطوّر يستهلك رصيدًا أقل غالبًا لأنه يكتب جزءًا من الكود بنفسه، لكنه يحتاج موارد بناء أكبر للمشاريع الثقيلة.
| الباقة | السعر الشهري | موارد كل مشروع | المواقع المنشورة |
|---|---|---|---|
| البداية (Hobby) | مجانًا | 2 أنوية و5 جيجابايت | لا نشر |
| النمو (Pro) | 99 ر.س | 6 أنوية و30 جيجابايت | 1 |
| النمو+ (Pro+) | 199 ر.س | 6 أنوية و60 جيجابايت | 3 |
| الأعمال (Studio) | 399 ر.س | 6 أنوية و100 جيجابايت | 10، مع 5 مقاعد |
إن كنت تبني مشاريع بمكتبات كثيرة أو تبني صورًا ثقيلة، فمساحة البناء في النمو+ أريح. وإن كنت تعمل مع فريق، فالأعمال تجمع الفوترة في حساب واحد.
مثال: كيف يبدو يومك مع أوترا
مثال توضيحي لمطوّر افتراضي، وليس تجربة مستخدم حقيقي.
نواف مطوّر Backend في شركة ناشئة بالرياض. صباحًا يطلب من أوترا صفحة إعدادات للمستخدم بثلاث تبويبات، وأثناء بنائها يكتب في الترمينال سكربت ترحيل بيانات بنفسه. يضيف مفتاح خدمة الرسائل من نموذج الأسرار، فلا يلصقه في المحادثة.
بعد الظهر يظهر خطأ في الاستيراد، فيستخدم وضع Debug ويقرأ التشخيص، ثم يصلح سطرين بيده. قبل نهاية اليوم يطلب مراجعة بوضع Review، ويدفع الفرع إلى GitHub لزميله الذي يعمل من VS Code.
الفرق الذي يلاحظه ليس في كتابة الكود نفسه، فهو يكتبه منذ سنوات، بل في كل ما حوله: لم يثبّت قاعدة بيانات محليًا، ولم يضبط شهادة SSL، ولم يكتب ملف نشر. وحين يعود للمشروع بعد أسبوع، تبدأ الجلسة من ذاكرة المشروع فلا يعيد شرح أن الفريق يستخدم PostgreSQL وأن مسارات الـ API لا تُغيَّر.
حدود يجب أن تعرفها
- أوترا ليست محرّرك المحلي. إن كنت تفضّل بيئتك تمامًا، فاستخدمها لتوليد البداية ثم تابع عبر GitHub. للمقارنة اقرأ Cursor مقابل أدوات البناء.
- راجع كل ما يُكتب قبل الإنتاج الحساس، فالاختبارات التلقائية تقلّل الأخطاء ولا تلغي مسؤوليتك.
- عضو المشروع يرى كل الأسرار. لا تضف إلى مشروع الإنتاج إلا من تثق به.
- المنتجات الضخمة متعددة الخدمات تحتاج تصميم بنية من فريقك، وأوترا تسرّع التنفيذ داخلها لا أكثر.