نشأت منصات منخفضة الكود (منصات تطبيق منخفضة الكود ، LCAP) كرد فعل على التعقيد ومجموعة متنوعة من أدوات تطوير البرمجيات الحديثة.
وفقًا لـ Gartner ، يعد Mendix أحد أشهر اللاعبين في هذا المجال. بيع سيمنز لمساحة 700 مليون دولار يؤكد هذا. لذلك سوف أستخدم هذه المنصة كمثال ، على الرغم من أن الاستنتاجات المماثلة ستكون صحيحة بالنسبة لـ Outsystems و Appian و Kony و Betty Blocks وغيرها.
لذلك ، فإن استهداف المبيعات لكبار المديرين ، يعد بائعو الأنظمة منخفضة الكود بأن المستخدمين العاديين سيكونون قادرين على إنشاء تطبيقات تجارية بمفردهم.
وهذا هو ، لم تعد هناك حاجة المطورين؟!
حسنًا ... بعد بضع سنوات ، يضطر Mendix إلى الاعتراف:
"الآن يحتاج المطورون أكثر من أي وقت مضى."
هذا تطور!
يبدو أن Mendix أدركت أنه بالنسبة لشيء أصعب من العمل الأساسي مع البيانات ، لا يزال هناك حاجة إلى مطور محترف ، تمامًا مثل الحاجة إلى ميكانيكي احترافي لخدمة سيارة.
لسوء الحظ ، لم يتم تصميم المنصات الحديثة ذات الكود المنخفض للمطورين ، والاعتماد عليها على المدى الطويل أمر محفوف بالمخاطر بالنسبة للأعمال التجارية. إذا كانت شركتك تدرس بجدية استخدام المنصات ذات الكود المنخفض في التشغيل الصناعي ، فمن الجدير موازنة هذا الحل مرة أخرى. أدناه سأحاول أن يجادل هذا.
أداة عظيمة النماذج
Mendix هو خيار رائع حقًا لأتمتة العمليات البسيطة أو النماذج الأولية ، وهو متاح للمحللين أو المستخدمين المتقدمين.
يتيح لك المحرر المرئي وصف نموذج البيانات ، وإنشاء شاشات بسرعة باستخدام مجموعة من الحاجيات والقوالب ، وحتى وصف المنطق باستخدام ما يسمى microflows :
عند الانتهاء ، يمكنك نشر التطبيق الخاص بك في سحابة Mendix بنقرة واحدة والبدء في العمل معها. بهذه البساطة التي تبدو وكأنها السحر! ويبدو أنها تبيع جيدا.
ومع ذلك ، بعد اجتياز مرحلة النموذج الأولي ، يكون تفاعل النظام مع المستخدم ومنطق العمل معقدًا حتميًا تقريبًا. لتطوير المشروع أكثر ، مطلوب المهنية. لذلك ، دعونا ننظر إلى Mendix من خلال عيون المطور.
التطور البطيء
يجب أن يوصف أي منطق - سواء كان ذلك في الحوسبة أو تفاعل المستخدم - في مخطط انسيابي للتدفق الدقيق ، كما هو موضح أعلاه.
هناك العديد من القضايا هنا.
أولاً ، إنه وقت طويل . من الواضح ، أنه من الأسرع كتابة 10 سطور من الأكواد في IDE جيد من السحب والإفلات وتخصيص والانضمام إلى عشرات الكتل.
ثانيا ، سهولة القراءة . الكتل تبدو جميلة ، ولكن ماذا يعني هذا التحقق من صحة التسجيل الفرعي ؟ من المستحيل فهم هذا دون الوقوع في الكتلة. بمجرد أن ينمو عدد الكتل إلى عدة عشرات ، سيصبح من الصعب للغاية فهم المنطق.
كبديل للحالات المعقدة ، يدعم Mendix مكالمات Java البرمجية من microflows. يمكنك كتابة الكود في Eclipse ، وهو أمر جيد عمومًا ، رغم أن الكثيرين يفضلون IDE أكثر شيوعًا. الجانب السلبي هو الافتقار إلى الشفافية: جميع نقاط الدخول في microflows ، وبالتالي فإن المنطق منتشر بين بيئتين مترابطتين بشكل فضفاض. نتيجة لذلك ، تصحيح الأخطاء وتعقب تبعيات صعبة.
آخر شيء أردت ذكره هو التحكم في الإصدار.
والخبر السار هو أنه هو. الشيء السيئ هو أنه نسخة مجردة من التخريب. نسيان تدفق جيت.
عدم السيطرة
لا يمكن لأي شخص مطلع على نظام جافا البيئي التقليل من قوة المصدر المفتوح. عندما يظهر خطأ في مكان ما على المكدس ، ترى في أي جزء من الكود حدث هذا. يمكن تصحيح التعليمات البرمجية لفهم ما يجري بالضبط. يمكنك جوجل الحل. يمكنك إرسال طلب سحب. في الحالات القصوى ، يمكنك شوكة المكتبة. أنت في السيطرة الكاملة على المشروع.
مع Mendix ، يمكنك نسيانها. هذا إطار تجاري مغلق ، وما يحدث داخلها هو صندوق أسود حقيقي. كل ما تبقى بالنسبة لك هو شراء الدعم المدفوع أو الانتظار لشخص ما للمساعدة في منتدى مع ما يقرب من 200 سؤال شهريًا (مقارنة مع علامة #spring على stackoverflow !).
تبعية البائع
Mendix ربما في كثير من الأحيان توبيخ هذا. لقد نشروا مقالًا يقول إنه لا يوجد بالفعل إدمان. إذا كنت تقرأ بين المصطلح ، فإنه يقرأ:
يمكنك الحصول على بياناتك و DDL وموارد واجهة المستخدم ورمزها (يتم تحويل microflow بطريقة سحرية إلى كود Java).
هل سيتم تنفيذه أو تجميعه دون وقت تشغيل و API Mendix؟ هل يمكن الحفاظ على هذا وتطويره؟ أسئلة بلاغية. في الواقع ، سوف تحتاج إلى إعادة كتابة كل شيء بالكامل. كنت تعتمد على منصة الملكية. أنت لا تملك النظام الذي أنشأته.
قابلية محدودة
يركز Mendix marketing على أكبر الشركات ، لذا فإن مصطلح "قابلية التوسع" يضيء باستمرار في مواد التسويق.
في عام 2017 ، قدمت Mendix وقت تشغيل بدون جنسية - أي ، يتم تخزين جميع معلومات الجلسة إما على جانب العميل أو في مساحة تخزين ثابتة.
من الناحية النظرية ، هذا يعني قابلية التوسع الأفقي غير المحدود. يبدو رائعا ، ولكن كالمعتاد هناك فارق بسيط - قاعدة البيانات.
تتحول قاعدة البيانات دائمًا إلى عنق الزجاجة في أحد تطبيقات الشركات. لذا ، ماذا يخزن البيانات خلف العديد من خوادم Mendix عديمي الجنسية؟ لا مفاجآت - هذه قاعدة بيانات قديمة جيدة. في السحابة Mendix - بوستجرس. علاوة على ذلك ، فإن Mendix DDL الذي تم إنشاؤه ، بعبارة ملطفة ، ليس مثاليًا تمامًا. على سبيل المثال ، رأيت جدولًا متوسطًا يُستخدم بشكل شائع لنموذج علاقات N: M ، تم إنشاؤه لعلاقة 1: N.
يمكن حل مشكلة قابلية التوسع عبر الطرق القياسية: تحسين بنية قاعدة البيانات ، أو التخزين المؤقت ، أو حتى استخدام حلول مثل Citus. ولكن بطبيعة الحال لا يوجد مثل هذا الاحتمال.
الطريقة الوحيدة لتوسيع نطاق قاعدة البيانات هي القياس باستخدام النسخ المتماثلة للقراءة (على سبيل المثال ، Amazon RDS). ولكن بالنسبة للسجل ، هذا لن ينجح.
تلخيصًا لما تقدم ، لدى Mendix قيودًا أساسية على قابلية التوسع ولا توجد وسيلة لتحسين الأداء.
قضية الموارد البشرية
البحث عن الموظفين المؤهلين هو دائما مهمة صعبة. يبدو أنه في هذا Mendix هو حلم أي مدير ، لأن متطلبات التأهيل تقلصت بحدة.
في الواقع ، لقد اكتشفنا بالفعل أن معظم المشاريع تتطلب فريقًا محترفًا ، بغض النظر عن الأداة. لكن من غير المحتمل أن يوافق أي مطور يحترم نفسه على العمل مع Mendix ، لأن هذا طريق مسدود واضح في حياته المهنية.
أسعار
أخيرًا وليس آخرًا تبدأ تكلفة ترخيص تطبيق واحد بسعر 1875 دولارًا شهريًا ، ويخضع هذا الاشتراك لمدة ثلاث سنوات ، ويقتصر الترخيص على 50 مستخدمًا داخليًا.
يبدأ سعر ترخيص الشركات مع إمكانية النشر المحلي عند 7825 دولارًا ، أي ما يقرب من 100000 دولار سنويًا.
شركة متوسطة الحجم مع عدة مئات من المستخدمين سوف تدفع سنويا فواتير عشرات الملايين من روبل.
لا تنس أننا نتحدث عن تطبيقات بسيطة نسبيًا ، كما يمكنك أن تفهم مما سبق. بالنسبة لي ، هذا مجنون. نموذج التسعير هذا يجعل من المستحيل عملياً تكرار التطبيقات التي قمت بإنشائها.
ثم لماذا لا تزال LCAPs شعبية؟
في رأيي ، يكمن السبب في خيبة الأمل في العمليات الحالية. إدارة فريق التطوير في مؤسسة كبيرة - سواء كان فريق داخلي أو الاستعانة بمصادر خارجية - معقدة للغاية.
تخطيط الميزانية ، والموافقات التي لا نهاية لها ، ونقص الأشخاص المستعدين لتحمل المسؤولية - أعتقد أن هذا مألوف لدى الكثيرين.
الأمر المضحك هو أن أول ما يتبادر إلى الذهن عندما تتحرك مشاريع تكنولوجيا المعلومات ببطء شديد هو توظيف المزيد من المطورين ، وبالطبع المديرين. وغني عن القول ، هذا فقط تفاقم الوضع. أنا أعرف اثنين من البنوك التي لديها أكثر من 10000 (!!!) مطورين ، ونصفهم على الأقل يقومون بعمل عديم الفائدة.
في يأس ، يبحث قادة الأعمال عن حل في "صنف سحري" مثل LCAP ، من المفترض أنهم قادرون على حل جميع المشاكل.
كيفية الخروج من هذه الحلقة المفرغة هو موضوع لمقال منفصل. لكن هذه مسألة إدارة وليست تكنولوجيا.
دون الخوض في التفاصيل ، إذا تمكنت من إنشاء فريق صغير مؤهل من 3 إلى 10 أشخاص يشاركون بشكل كامل في المشروع ، مع اتصال مباشر مع صانع القرار ، فستحصل على نتائج ممتازة أسرع وأرخص مما تتوقع.
ما هي البدائل؟
الآن هناك مجموعة كبيرة من الأدوات والأطر للمطورين.
على سبيل المثال ، يعد Spring Framework هو أكثر التقنيات مفتوحة المصدر شعبية لإنشاء برنامج للمؤسسات يعمل بشكل جيد مع أطر الويب مثل React أو Angular. وقد قامت أدوات مثل Spring Initializr و JHipster بتبسيط عملية إنشاء المشاريع بشكل كبير خلال السنوات القليلة الماضية.
إذا كنت ترغب في الحصول على النتيجة بشكل أسرع ، فيجب عليك التفكير في أدوات RAD مثل CUBA Platform .
يعتمد على إطار Spring نفسه ، ويكمله بأدوات التطوير المرئي وعدد كبير من المكونات الجاهزة. ربما يكون هذا هو البديل الأقرب لـ LCAP ، حيث يوفر المرونة وعملية التطوير المريحة.
يجب أن يعتمد الاختيار النهائي على المهمة ، وكذلك على مهارات الفريق وتفضيلاتك.
استنتاج
تعد الأنظمة الأساسية ذات الكود المنخفض رائعة للنماذج الأولية. إنها تضييق الفجوة بين مستخدمي الأعمال وتكنولوجيا المعلومات ، والتي تتيح لك الحصول على نموذج أولي سريع للعمل وتشكيل رؤية للنظام المستقبلي.
نظرًا لوجود عدد قليل جدًا من مستخدمي النموذج الأولي ، فإن التكاليف في هذه المرحلة صغيرة أيضًا. وهو في هذه اللحظة يستحق التوقف!
عند استخدام LCAP لتطوير نظام كامل ، ستنخفض سرعة العمل بشكل حتمي ، وستعتمد على النظام الأساسي الخاص المكلف الذي يحدك.