وحدات أودو المخصّصة: متى تُعِدّ ومتى تخصّص وكيف تُبقي الترقيات سهلة

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

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

سلّم القرار

قبل كتابة الكود، انزل هذا السلّم وتوقّف عند أول درجة تحلّ المشكلة.

1. الإعداد. الإعدادات، والتسلسلات، والضرائب، والمواقف الضريبية، والمسارات، والإجراءات المؤتمتة، وقوالب البريد، وصلاحيات الوصول. تنتهي معظم طلبات "نحتاج إلى تخصيص" هنا متى نظر فيها شخص يعرف المنتج.
2. Studio (في Enterprise). حقول إضافية، وتعديلات على القوائم والنماذج، وأتمتة بسيطة، وتحرير التقارير. تُخزَّن تغييرات Studio كبيانات، وتصمد أمام الترقيات بشكل معقول، ولا تحتاج إلى مطوّر.
3. الوحدات الموجودة. ينشر متجر تطبيقات أودو وجمعية OCA آلاف الوحدات المصانة. وحدة OCA بمشرفين نشطين رهان أفضل عادةً من كود مخصّص لحاجة عامة.
4. وحدة مخصّصة. إجراؤك خاص فعلاً — حساب تأجير، أو قاعدة توجيه لمغسلة، أو فوترة احتجاز لمقاول — ويقدّم قيمة عمل تبرّر صيانة دائمة.

طلبات "سيكون أجمل لو" لا تصل إلى الدرجة الرابعة.

كيف تبني وحدة مخصّصة

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

• وحدة لكل شأن. acme_rental_pricing لا acme_customisations. حين يُلغى شأن، تُزال وحدته دون المساس بالبقية.
• ورِّث ولا تعدّل أبداً. وسّع النماذج بـ_inherit، ووسّع الشاشات بـXPath، وتجاوز الدوال بـsuper(). تعديل ملفات النواة يعني تبخّر تغييراتك عند الترقية — وكسر تحديثات أودو نفسها بينهما.
• أبقِ قواعد العمل في Python والعرض في الشاشات. الحقول المحسوبة والقيود مكانها النموذج؛ ولا ينبغي أن يحوي تقرير QWeb منطقاً.
• ملفات بيانات للإعداد. تُشحن التسلسلات والسجلات الافتراضية وقواعد الأمان كملفات XML أو CSV داخل الوحدة لتصل قاعدة بيانات جديدة إلى الحالة نفسها.
• الأمان أولاً. يحصل كل نموذج جديد على صفوف في ir.model.access.csv، وعند الحاجة على قواعد سجلات. يرفض أودو افتراضياً الوصول إلى النماذج التي لا قواعد لها؛ والحل ليس منح كل شيء للجميع.
• الاختبارات. يعمل إطار اختبارات أودو عند تثبيت الوحدة. حتى حفنة من الاختبارات التي تغطي قاعدة التسعير أو مسار الاعتماد تحوّل كل ترقية من "أمل" إلى "شغّل المجموعة".

تكاملات دون ألم

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

• استخدم واجهة API الخارجية (XML-RPC أو JSON-RPC) من الخارج، والمتحكّمات من الداخل، بدلاً من السماح للأنظمة الخارجية بلمس قاعدة البيانات.
• اجعل التكاملات متكرّرة الأمان (idempotent). تُعاد إرسال التسليمات؛ وتُطلق الويب هوكس مرتين. خزّن المرجع الخارجي وتجاهل التكرارات.
• ضع كل ما هو بطيء في طابور. لا ينبغي أن يعطّل إرسال إلى هيئة الزكاة أو حجز شحنة مندوبَ مبيعات يؤكّد طلباً؛ استخدم طابور مهام أودو (وحدة queue_job من OCA) أو الإجراءات المجدولة.

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

عادة الترقية

تصدر أودو إصداراً رئيسياً كل خريف وتدعم آخر ثلاثة تقريباً. يبقى النظام المخصّص قابلاً للترقية إذا:

• ثبّتَّ الإصدار في ملف بيان الوحدة وحافظت على سجل تغييرات لما تغيّره كل وحدة ولماذا.
• رقّيت كل عام، أو كل عامين على الأكثر. إصداران مشروع؛ وأربعة إعادة كتابة.
• أجريت الترقية في بيئة تجريبية أولاً. تعيد خدمة الترقية في Enterprise قاعدة بيانات مرحّلة؛ ثم تنقل الوحدات وتشغّل الاختبارات وتصلح ما تغيّر. ويستخدم Community سكربتات OpenUpgrade وعملاً يدوياً أكثر.
• حذفت ما لم تعد تستخدمه. كل وحدة مخصّصة تحملها إلى الأمام تكلّف وقتاً في كل ترقية؛ فأنهِ ما زال سببه التجاري.
• فضّلت وحدات OCA على وحداتك حين يوجد كلاهما — فـOCA تنقلها إلى الإصدارات الجديدة نيابة عنك.

يستعرض دليل الترقية إلى أودو 19 و20 الدورة بالتفصيل.

علامات نظام يحتاج إلى إنقاذ

• ملفات نواة معدّلة (يُظهر git diff مقابل أودو الأصلي تغييرات خارج addons/custom).
• وحدات مخصّصة مسمّاة بأسماء أشخاص أو تواريخ.
• لا اختبارات، ولا بيئة تجريبية، والترقيات "غير ممكنة".
• وحدة customisations واحدة تضم 40 نموذجاً.
• قواعد عمل تعيش في إجراءات الخادم والإجراءات المؤتمتة المكتوبة في الواجهة، دون توثيق.

الإنقاذ ممكن — عادةً بإعادة بناء الطبقة المخصّصة كوحدات سليمة على إصدار حديث نظيف وترحيل البيانات — وغالباً ما يكون أرخص من سنة أخرى من الحلول الالتفافية.

أهم النقاط

• انزل السلّم: الإعداد، ثم Studio، ثم الوحدات الموجودة، ثم الكود المخصّص.
• وحدة لكل شأن، ووراثة لا تعديل، وأمان واختبارات مع كل وحدة.
• تكامل عبر واجهة API بمهام مطابورة ومتكرّرة الأمان.
• رقِّ كل عام؛ واحذف الوحدات التي زال سببها.

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