عاجلاً أو آجلاً سيفتح أحد زملائك Odoo Studio، ويسحب حقلاً جديداً إلى إحدى الشاشات، فيحل في دقائق ما كان سينتظر أسابيع في قائمة المطور. وهذا بالضبط ما صُمم Studio لأجله. لكن المشكلة تظهر لاحقاً، حين تحمل قاعدة البيانات نفسها عشرات التغييرات الصغيرة، ولا يتذكر أحد من أجراها ولماذا، بينما ترقية الإصدار على الأبواب. لذلك فالسؤال المفيد عند الاختيار بين Studio والكود المخصص هو: كم سيكلفك كل تغيير بعد اليوم الذي أُجري فيه؟
ما يجيده Studio
Studio تطبيق من تطبيقات Odoo Enterprise، فتأكد أن خطتك تشمله قبل أن تعتمد عليه. وهو يتيح لمسؤول نظام مدرَّب أن يغيّر Odoo من الشاشة نفسها دون كتابة كود:
- الحقول. إضافة حقل إلى نموذج البيانات ووضعه في شاشة النموذج أو القائمة أو البحث.
- التخطيط. نقل الحقول أو إخفاؤها أو تغيير تسمياتها أو جعلها إلزامية، وإضافة تبويبات أو أعمدة.
- مستندات PDF. تعديل تخطيط عروض الأسعار والفواتير والتقارير المشابهة.
- قواعد الأتمتة. تعيين قيمة أو إرسال رسالة أو إنشاء نشاط عند تغيّر سجل أو حلول تاريخ معين.
- تطبيقات صغيرة. متابعة شيء لا يغطيه Odoo أصلاً، مثل إعارة المعدات أو تصاريح المركبات.
في تغييرات كهذه يكون Studio هو الإجابة الصحيحة في الغالب. فالدفع لمطور كي يضيف حقلاً مرجعياً إلى أمر بيع نادراً ما يكون إنفاقاً في محله، كما أن من طلب الحقل يستطيع التحقق من النتيجة فوراً.
ما الذي تتنازل عنه
أهم القيود لا علاقة لها تقريباً بالميزات. فتغييرات Studio تُحفظ في قاعدة البيانات، ولهذا نتائجه:
- لا مراجعة. لا طلب دمج ولا عين ثانية تراجع. وقد يُجري مسؤولان تغييرين متعارضين دون أن يعلم أحدهما بالآخر.
- تنفيذ فوري. ما لم تعمل على نسخة ثم تنقل التغييرات، يصل التعديل إلى كل المستخدمين بمجرد إجرائه.
- لا اختبارات آلية. لا شيء يؤكد أن القاعدة ما زالت تعمل كما ينبغي بعد الترقية التالية.
- تعديلات قد تنفصل. تعديل الشاشة في Studio طبقة فوق الشاشة الأصلية، فإن تغيّرت الأصلية أثناء الترقية، فقد تتوقف هذه الطبقة عن العمل وتحتاج إلى إعادة بناء.
- خروج أصعب. إلغاء تثبيت الوحدة التي تحمل أعمال Studio قد يحذف الحقول التي أنشأتها مع البيانات التي فيها. فإن أردت استبدال Studio بكود لاحقاً، فعليك نقل هذه البيانات أولاً وتجربة العملية على نسخة.
متى يكون الكود المخصص الخيار الأفضل
يستحق التطوير المخصص تكلفته حين يحمل التغيير منطقاً يعتمد عليه عملك. وهذه هي العلامات المعتادة على أنك تجاوزت حدود Studio:
- القاعدة فيها تفرعات. عمولة تعتمد على فئة المنتج وهامش الربح ومن أغلق الصفقة هي برنامج صغير. وكتابتها بمقاطع Python داخل قواعد الأتمتة لا تغيّر ذلك، بل تجعلها برنامجاً لا يراجعه أحد.
- يجب تغيير السلوك القياسي. يضيف Studio إلى شاشات Odoo ومحفزاته، أما تغيير ما يحدث عند تأكيد تسليم أو ترحيل فاتورة فيحتاج إلى تطوير.
- هناك نظام آخر في الصورة. تستطيع قاعدة الأتمتة إرسال webhook، لكن إعادة المحاولة ومعالجة الأخطاء وتسوية ما فشل كلها أعمال تطوير.
- حجم البيانات مهم. المنطق الذي يعمل على آلاف كثيرة من السجلات يجب أن يُكتب ويُختبر مع مراعاة الأداء.
- الخطأ مكلف. كل ما يمس القيود المحاسبية أو الضريبة أو الرواتب أو تقييم المخزون يستحق مراجعة واختبارات وتجربة قبل الإطلاق.
وللكود المخصص فاتورته أيضاً: يحتاج إلى مطور ودورة اختبار، وإلى من يحافظ على عمله عند كل ترقية، بما في ذلك الوحدات التي لم يعد أحد يستخدمها.
ثلاثة أسئلة تحسم أغلب الحالات
- إن تعطل هذا التغيير، فمن سيلاحظ وبأي سرعة؟ الحقل في غير مكانه مزعج لكنه ظاهر، أما الرقم الخطأ في قيد محاسبي فقد يبقى دون أن يلاحظه أحد حتى يصل المدققون.
- هل تستطيع وصف التغيير دون كلمة «إذا»؟ عبارة «أضف حقل منطقة التسليم إلى أمر البيع» تناسب Studio. أما «إذا كانت المنطقة نائية وكان الطلب دون قيمة معينة فأضف رسماً إضافياً ما لم يكن العميل متعاقداً» فلا تناسبه.
- هل سيعتمد عليه شيء آخر؟ الحقل الذي تقرأه التقارير أو التكاملات أو الوحدات المخصصة جزء من نموذج بياناتك، فاختر له اسماً مدروساً ومسؤولاً عنه. والوحدة التي تقرأ حقلاً من Studio تتعطل إذا حذفه أحدهم لاحقاً، وقد لا يعرف من يحذفه أن وحدة ما تعتمد عليه.
كيف تُبقي Studio تحت السيطرة
بضع عادات تمنع Studio من تأخير ترقيتك القادمة:
- حدّد مسؤولاً أو اثنين عنه بدلاً من إتاحته لكل من لديه صلاحيات إدارية.
- جرّب التغييرات على نسخة staging أولاً حين تكون الشاشة مستخدمة طوال اليوم.
- احتفظ بسجل قصير لما تغيّر ومن طلبه ولماذا، فقاعدة البيانات تحفظ التغيير لا سببه.
- راجع القائمة كاملة قبل كل ترقية إصدار، واحذف ما لا يستخدمه أحد.
أين يقع Plemo من كل هذا
Studio سريع بلا مراجعة، والتطوير التقليدي يخضع للمراجعة لكنه أبطأ. ويستهدف Plemo التغييرات التي تقع بينهما، حيث يستطيع من يفهم العمل أن يصف الحاجة، لكن النتيجة لا ينبغي أن تذهب مباشرة إلى الإنتاج. تصف التغيير في محادثة، فيطرح الذكاء الاصطناعي أسئلة توضيحية ويضيّق الطلبات الواسعة التي يصعب بناؤها جيداً دفعة واحدة. ثم توافق على مواصفات مكتوبة قبل أن يبدأ التطوير، وتفحص النتيجة في بيئة تجريبية قبل أن يصل أي شيء إلى بيئة الإنتاج. ولأن استخدام الذكاء الاصطناعي قائم على الأرصدة، فإن الطلب محدد النطاق أقل تكلفة أيضاً.
ومع ذلك تظل هذه دورة تطوير، وهي أكثر مما يستحقه تغيير تسمية حقل. فإن كان Studio ينجز التغيير في دقيقة ولا يعتمد عليه شيء آخر، فاستخدم Studio. وعلى الطرف الآخر، التغيير الذي يعيد تشكيل إجراء أساسي عبر عدة أقسام يحتاج إلى من يناقش الإجراء نفسه قبل بناء أي شيء. ويمكن لفريق التطوير المخصص لدينا مساعدتك في هذا القرار، وفي فرز تغييرات Studio المتراكمة لديك إلى ما تُبقي عليه وما تعيد بناءه وما تحذفه.