غالبًا ما نقرأ عن أفضل الممارسات في البرمجة ، أو حول ميزات إطار العمل الجديدة أو الجديد في الإصدار التالي من PHP. نقرأ كيفية تغيير " هذا إلى هذا " ، ولماذا تكون بعض التقنيات جيدة أو سيئة ، أو ما هي الحزمة الجديدة التي يمكنك استخدامها في مشروعك. ولكن كل هذا هو المضاربة فقط عن الماضي أو الحاضر.
أنا الانتهاء من قراءة كتاب « من لا مفر منه » ، الذي كتبه مؤسس مجلة وايرد فيه فقط حول المستقبل. مستوحى من هذا الكتاب ، أقترح النظر في مستقبل البرمجة.
نحن اليوم نحارب الديون التقنية (مهما كان ذلك يعني) ، رمز قديم يصعب الحفاظ عليه وتعديله مكلفًا ، ولكنه يدر الكثير من المال في نفس الوقت. بشكل منتظم ، يتعين علينا إعادة تشكيل الكود ، واتباع مبادئ DDD ، وكتابة الاختبارات ، وتحديث إصدار PHP لأغراض الأمان ، وتثبيت أحدث إصدارات البرامج على الخادم وأتمتة التخطيط.
هناك الكثير من الأعمال الروتينية الحالية بحيث لا يوجد وقت مطلقًا للنظر في العشرات من المشاريع الأخرى التي تدعمها شركتنا ... أو على الأقل تخزينها في مكان ما على خوادمنا. يجب أن نوظف خبيرًا للمساعدة في تحسين كل جانب على الأقل قليلاً. ليس لأن هذه المشاريع سيئة ، ولكن ببساطة بسبب وجود العديد من التقنيات التي يمكننا استخدامها ، وحتى المزيد من التعليمات البرمجية التي يتعين علينا الحفاظ عليها.
وكيف سيحدث كل هذا في المستقبل؟
سيستخدم IDE الذكاء الاصطناعي
في المستقبل ، ستصبح كتابة التعليمات البرمجية أسهل. سيتم تشغيل IDE الخاص بنا بواسطة الذكاء الاصطناعي ، والذي يتعلم من البيانات المجهولة لمشاريع PHP الأخرى وجميع المشاريع مفتوحة المصدر على Github و Gitlab.
بفضل الذكاء الاصطناعي هذا ، عندما نبدأ في كتابة "class HomepageC ..." ، سيعرف IDE أننا نقوم بإنشاء وحدة تحكم للصفحة الرئيسية ، وأننا نستخدم Symfony ، بالإضافة إلى نسخته من composer.json ، وسيعرض إضافة مُعدِّلات الإنهاء تلقائيًا إلى باقي الكود وأنواع قوية ، بناءً على معرفة إصدار PHP المستخدم ، وكذلك من composer.json. سينشئ نموذجًا لمحرك القالب الذي نستخدمه وسيحاكي المحتوى الموجود في القوالب الأخرى الموجودة بالفعل في مشروعنا.
بفضل الكم الهائل من البيانات والبيانات المجهولة من مخازن الرموز العامة ، ستعرف منظمة العفو الدولية أفضل طريقة لاختبار وحدة التحكم وستستخدم هذه المعرفة لإنشاء اختبار تحكم أمثل.
أفضل ممارسة تم التحقق منها
عندما نتحدث عن "أفضل الممارسات" ، فإننا لا نعني ما كتبته أنا أو أي شخص آخر في منشور أو كتاب يعتمد فقط على التجربة الشخصية. غالبًا ما تستند هذه الآراء إلى تجارب من عدد قليل من المشاريع وتكون مشحونة عاطفياً.
في المستقبل ، سيُستبدل مفهوم "أفضل الممارسات" بـ "الممارسة التي تم التحقق منها" وستستند إلى البيانات الحقيقية المرتبطة بمؤشرين صارمين - الدين الفني وكفاءة التشفير. سيكون للديون التقنية معادل مالي يوضح مقدار تكلفة الحفاظ على كل سطر من التعليمات البرمجية في المستقبل. هل أنت حر في كتابة كود ثابت بدون فصول مكتوبة؟ قد "تكلف" السلسلة 10 دولارات. هل تكتب فصول نهائية بأنواع قوية وطريقة عامة واحدة؟ في هذه الحالة ، سيكلف الخط 2 دولار.
لن تكون هذه الأرقام عشوائية ، ولكنها ستعتمد على التحليل المستمر لكمية هائلة من البيانات الضخمة ، مجهولة المصدر لجميع المشاريع التي تختار استخدام هذه الميزة. ستتم مقارنة الكود بالتكاليف المالية المطلوبة لصيانة المشاريع وتحسينها. من خلال هذه التعليقات ، ستعرف منظمة العفو الدولية أيضًا الإصدار الأكثر فائدة لمشروعك الخاص.
سيعرف الذكاء الاصطناعي سياق مشروعك ويقارن البيانات وفقًا لذلك. هل لديك مشروع CLI؟ ستتم مقارنتها برمز مشاريع CLI الأخرى في هذا المجال. هل تقوم بإنشاء موقع على شبكة الإنترنت؟ سيتم مقارنتها بتصاميم من مواقع أخرى.
سيتم تحديد كفاءة الترميز من خلال مقياس "الصيانة" للمشروع. سيتم قياسه على مقياس من 0 إلى 100 ، حيث يعني 0 أن الأمر يستغرق عدة ساعات لفهم الكود ، وقد يستغرق الأمر أيامًا أو حتى أسابيع لإجراء التغييرات. سيكون من السهل على المطور المبتدئ فهم الكود الذي يحصل على 100 درجة وسيكون قادرًا على تغيير الكود على الفور تقريبًا.
تحقق IDE من الإكمال التلقائي
سيكون IDE على دراية بهذه المقاييس وسيتبع الأنماط المستخدمة في التعليمات البرمجية الخاصة بك. عندما تبدأ في كتابة جزء من الكود تكون كفاءته 40-50 نقطة ، سيظهر الإكمال التلقائي مع اقتراح رمز بنفس الوظيفة ، ولكن بكفاءة 80-90. هذا مشابه للعمل الذي يقوم به Rector أو PHPStan اليوم.
سيتم أيضًا إجراء تحليل الأداء جنبًا إلى جنب مع تحليل أداء الترميز. سيتم قياس الأداء تلقائيًا عندما يتغير الرمز في الخلفية في حاوية Docker ، وسيتم إبلاغك بأي تسرب للذاكرة أو زيادة في وقت التشغيل. سيكون هذا التحليل دقيقًا جدًا لدرجة أنه سيحدد السطر أو الأحرف المحددة التي تسببت في التسرب ويقترح إصلاحًا عليك قبوله فقط.
إعادة بيع ديون AST
ستكون إعادة الهيكلة أقوى مما هي عليه اليوم. سوف يعتمد على شجرة التركيب المجرد (AST). سيقترح IDE أفضل إعادة هيكلة تخطط للقيام بها الآن ، بناءً على بيانات مجهولة المصدر من جميع المشاريع المفتوحة والمغلقة.
بدلاً من الإشارة إلى أفضل الممارسات ، ستعرف أن:
- سيكلفك الحل "أ" 3 دولارات لكل سطر من الديون الفنية ، وسيتم تصنيفك بـ 95 للكفاءة و 45 للأداء
- سيكلفك الحل B دولارًا واحدًا لكل سطر من الديون الفنية ، مع تصنيف كفاءة يبلغ 70 وتقييم أداء يبلغ 50
هل تقوم ببناء شركة ناشئة وترغب في اختبار فكرتك؟ ثم ستختار الخيار "أ". ماذا لو كانت شركتك مستقرة ويجب أن تظل كذلك في المستقبل؟ ومن ثم ، فإن الأمر يستحق التحول إلى الخيار ب ، وهو أرخص في الدعم والأداء ، ولكنه أبطأ قليلاً في التطوير.
لن تضطر إلى المجادلة مع زميل أو مع رئيسك في العمل لماذا يجب عليك استخدام هذا الحل أو ذاك. تقارن الأرقام ثم تقرر بناءً على أولوياتك الحالية.
هندسة السياق
سيكون للكود الخاص بك بنية سياقية. سيعرف الذكاء الاصطناعي متى يتنقل بين السياقات بناءً على بيانات من مشاريع أخرى والتكلفة النهائية للانتقال إليها. هل تبدأ مشروع WordPress؟ لا بأس. ولكن ماذا لو أصبح مشروعك أكثر شهرة وتحتاج إلى التبديل إلى بعض أطر عمل PHP التي تناسب احتياجاتك بشكل أفضل؟ سيطالبك IDE بالتبديل إلى Laravel. نقرة واحدة وتنتهي.
بعد ثلاث سنوات ، ينمو مشروعك وسيكون لديك العديد من المهام لدمج خدمات الجهات الخارجية المضمنة بالفعل في إطار عمل Symfony. يطالبك IDE بالترحيل ... انقر ... وازدهار ، فأنت تستخدم Symfony 9. هل وجدت أنه لا يوجد ما يكفي من مطوري Symfony في السوق للتعامل مع تطوير مشروعك؟ نقرة واحدة وسيقوم IDE بنقل المشروع إلى إطار عمل يوجد به عدد كافٍ من المطورين بتكلفة معقولة.
إجابات إصدار StackOverflow
سيقوم IDE بفحص الكود الخاص بك وتحليل عادات الترميز الخاصة بك. عادة ما تكتب وظيفة في 15 دقيقة ، ولكن الآن تستغرق ما يقرب من ساعتين؟ في السنوات القادمة ، سيكون IDE جيدًا لدرجة أنه سيلاحظ انخفاضًا طفيفًا في سرعة كتابة التعليمات البرمجية في غضون ثوانٍ.
سيقوم IDE بعد ذلك بالتحقق من التعليمات البرمجية الخاصة بك ، وفحص الردود على StackOverflow ، ومطابقة الردود مع الإصدارات الموجودة في composer.lock ، ويقترح عليك استخدام جزء معين من التعليمات البرمجية باعتباره الأنسب.
هل أنت قلق من نسخ هذا الجزء من الكود بشكل عشوائي وكسر مشروعك؟ لم يعد تصنيف الإجابة يعتمد على تصويت المستخدم ، ولكنه الآن يأخذ في الاعتبار النسبة المئوية لاستخدام الإجابة إذا تم دمجها بنجاح في كود المشروع.
تم اختبار مقتطفات التعليمات البرمجية
بالإضافة إلى ذلك ، يتم اختبار قصاصات التعليمات البرمجية يوميًا بواسطة StackOverflow نفسها ، وأيضًا قبل نسخها في مشروعك. إنه مع إصدار بيئتك المحلية ، لذلك يمكنك التأكد من أن الكود سيعمل. لم يعد الناس يكتبون نسخًا من هذه الإجابات بأنفسهم ، كما فعلوا في الماضي. يتم تحديث الكود في الاستجابة تلقائيًا مع كل إصدار للتقنية أو إطار العمل الذي يستخدمه. تم إعطاء بعض الإجابات لـ Symfony 5. ماذا سيحدث عند إصدار Symfony 6؟ سيتم تحديث الكود القديم في الإجابة بوصفة AST التي تم إصدارها باستخدام Symfony 6. وبهذه الطريقة ، يمكن للإنسان و IDE العمل معها بسهولة.
المصدر المفتوح التمويل القائم على النشاط
سيتم إنشاء مشروع جديد يربط بين الشركات التجارية والمساهمين مفتوحين المصدر. سيتم تمويل المشروع مفتوح المصدر من قبل الشركات التي تستخدمه. سيتم تمويل المطورين الذين يساهمون من خلال نظام واحد يعتمد على التدفقات النقدية الواردة ، دون أي رسوم إضافية لتغطية التكاليف.
سيتم تحديد التمويل باستخدام مقاييس مثل تأثير الميزة وعبء العمل والوقت المستغرق وكفاءة الكود ، إلخ. وبالتالي ، سيتم تطوير الكود بشكل أكثر تناسقًا مما كان عليه عندما تم تطويره من قبل مساهمين مستقلين في أوقات فراغهم. في الواقع ، سيحصل مطور مشروع مفتوح المصدر على وظيفة بدوام كامل يمولها هذا المشروع.
ما الذي ستحصل عليه هذه الشركات كمكافأة؟ الترويج الخاص بالمجتمع ، والإصدارات السابقة للإصدارات الجديدة ، والوصول المباشر إلى المستشارين الخبراء الذين قاموا بإنشاء مشاريع مفتوحة المصدر تستخدمها (هذه الشركات).
توحيد الأطر
سيتم دمج 10 إطارات PHP الموجودة حاليًا. ستتعلم المجتمعات حول أطر عمل PHP التعاون أكثر ، بدلاً من تطوير نسخ متطابقة تقريبًا من أطر العمل باستخدام نهج MVC.
بفضل عمليات الترحيل AST ، يمكنك التبديل إلى أي إطار عمل PHP. سيؤدي ذلك إلى تضييق نطاق الاختيار إلى 3-4 أطر. إذا كان الترحيل بين أطر العمل يتعلق بنقرة واحدة في IDE الخاص بك ، فلن يكون هناك المزيد من المنافسة بناءً على الادعاء "تاريخيًا" والعادات ، ولكن فقط على الجودة.
سيؤدي تقليل عدد الأطر إلى ضيق أفقها - حيث يتفوق إطار واحد في API ، والآخر في CLI ، والثالث في المواقع ذات تجربة المستخدم الرائعة.
عندما يركز مجتمع PHP بأكمله على عدد أقل من أطر العمل ، فإنه سيسمح لنا باستثمار الجهد الموفر في تطوير تقنيات وميزات جديدة.
إصدار PHP واحد ثابت فقط
بفضل عمليات الترحيل التلقائية AST ، لن يكون هناك سوى نسختين من PHP - مستقرة وإصدار مطور. نظرًا لأن تحديث أي حزمة أو مشروع سيصبح سريعًا ورخيصًا جدًا ، فلا يوجد سبب لعدم التحديث إلى أحدث إصدار. قد يستغرق مجتمع PHP عامًا أو عامين لقبول هذا والحفاظ على مزامنة جميع المشاريع. ولكن عندما يحدث هذا ، في غضون شهر بعد إصدار الإصدار الجديد من PHP ، فإن النظام البيئي مفتوح المصدر بأكمله سيستخدمه كحد أدنى للإصدار.
تحديثات الكود تلقائية وفورية بالكامل
لا يلزم تحديث كود PHP يدويًا. سيكون لكل إصدار من PHP "وصفة" تحديث كاملة تعتمد على AST والتي يمكنك استخدامها لتحديث الشفرة تلقائيًا في مشروعك. سيتعامل GitHub مع هذه "الوصفات" ، لذلك عند إصدار إصدار جديد من PHP ، سيبدأ GitHub تلقائيًا في إرسال طلب سحب إلى مستودعك. ستكون هناك تحديثات تلقائية ليس فقط لـ PHP ، ولكن أيضًا لأي إطار عمل أو حزمة. مثل Dependabot ، الذي تم دمجه مؤخرًا في GitHub ، ولكن الآن مع تحديث التعليمات البرمجية وجميع مشكلات التوافق مع الإصدارات السابقة.
مطور GitHub
إذا كنت لا ترغب في تولي جميع العلاقات العامة بنفسك ، فيمكنك الاشتراك في برنامج التحديث التلقائي حتى يقوم GitHub بذلك نيابة عنك. سيقوم أيضًا بتحديث الإصدارات و SemVer الخاصة بهم بشكل صحيح.
الفصل الآلي
لن يكون هناك نقاش حول ما إذا كان التغيير هو كسر التوافق مع الإصدارات السابقة أو مجرد تصحيح. ستقوم منظمة العفو الدولية بتحليل الكود قبل وبعد ، وبناءً على ذلك سوف تتخذ القرارات. سيكون ذكيًا جدًا لدرجة أنه سيكون قادرًا على تحديد مدى أهمية تأثير تغيير معين. إذا لم يؤثر ذلك على أي كود في مشاريع أخرى ، فسيتم إصداره كتصحيح.
PHP RFC على أساس الدروس المستفادة
سيكون نفس تحليل كسر التوافق مع الإصدارات السابقة ممكنًا لأي RFC في كود PHP الأساسي. تريد أن تقترح ثوابت مكتوبة؟ سيخبرك الذكاء الاصطناعي عن عدد المشاريع من بين أفضل 10000 مشروع على Github والتي سيتم كسرها كنسبة مئوية. يتم الآن إجراء شيء مشابه يدويًا في بعض طلبات التعليقات.
فاصل إعادة التفكير في التوافق مع الإصدارات السابقة
سيساعدك الذكاء الاصطناعي أيضًا في إنشاء "وصفات" ترحيل AST ، لذا يمكن للتحديث الفوري التعامل بشكل كامل مع مقاطعة التوافق مع الإصدارات السابقة. سيؤدي هذا إلى تغيير في المفهوم ذاته. تحدث فواصل التوافق مع الإصدارات السابقة فقط عندما يتعذر حدوث تحديثات تلقائية ويكون مطلوبًا من الإنسان تغيير الرمز.
جرب RFC محليًا
بالإضافة إلى ذلك ، يمكن لأي شخص تجربة ميزة RFC محليًا بعد إنشاء العلاقات العامة مباشرة على GitHub. كيف؟ سيقوم Github تلقائيًا بإنشاء إصدار مؤقت بعلامة مطور خاصة ودفع إصدار PHP هذا إلى سجل الحزمة. يمكنك إنشاء RFC لإضافة ثوابت مكتوبة ، وإرسالها كـ PR إلى GitHub وبعد دقيقة واحدة يمكنك تشغيل sudo apt-get install php-dev-typed-Constant للحصول على PHP مع RFC هذا على جهازك المحلي.
وبالتالي ، سيتمكن المبرمجون من تجربة هذه الميزة حتى قبل تضمينهم في الفرع الرئيسي وحتى قبل التصويت على RFC. في هذه الحالة ، حتى التصويت على الميزات الجديدة سيعتمد على بيانات وخبرات حقيقية ، وليس على العواطف والآراء والحجج الذاتية.
ماذا يحمل لنا المستقبل؟
في المستقبل ، لن تكون قدراتنا مقيدة بتاريخنا أو خياراتنا السابقة أو التقنيات سريعة التطور التي تجعل كودنا عفا عليه الزمن بسرعة. بنقرة واحدة فقط ، تكون جميع أدواتنا هي الأكثر تقدمًا في السوق اليوم.
سيسمح لنا هذا بإجراء المزيد من التجارب واختبار افتراضاتنا والحصول على ردود فعل حقيقية. سيؤدي ذلك إلى أتمتة أفضل لعمليات الترميز والاختراعات في اللغة والأنماط وبنية التطبيقات التي لا يمكننا حتى تخيلها اليوم.
"إن أفضل طريقة للتنبؤ بالمستقبل هي إنشائه".
خلق سعيد!