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