قررت أن تكتب إطار العمل الخاص بك. هل كان يستحق؟

كما قال الكلاسيكيات ، "علمت أننا سنصل إلى ذلك عاجلاً أم آجلاً". لذلك ، بعد سنوات عديدة من الحياة الهادئة مع Symfony في العاملين و ReactPHP في مشاريع الحيوانات الأليفة ، أتوافق مع إنشاء إطار العمل الخاص بي.



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



مرحبا! هنا نسخة جزئية من البودكاست الخاص بي "بين الأقواس" - مقابلات مع أشخاص مثيرين للاهتمام من عالم PHP. في هذه الحلقة ، سنتحدث إلى Alexander Lisachenko ، مبتكر إطار عمل يستند إلى Java والذي غالبًا ما يكون Google Googled.

إذا كنت أكثر راحة في الاستماع ، فهناك المزيد من الأمثلة التقنية في النسخة الصوتية .

على الأرجح ، لم نواجه جميعًا شيئًا مثل AOP - البرمجة الموجهة إلى الجانب في PHP. وتعثر ساشا واتخذ قراره الخاص بسحب هذا الشيء إلى تطبيقاتنا.



سيرجي جوك ، Skyeng و DriftPHP: لنبدأ من الصفر - ما هي AOP وما المشكلة التي تحلها؟



الكسندر ليسشينكو ، PHP روسيا وانطلق ! AOP : الفكرة ليست جديدة. تم اختراع AOP في Xerox لمعالجة مشكلة الوظائف الشاملة. وفي عالم Java ، يتم استخدام هذا الأسلوب بنشاط للتحقق من الوظائف مثل التفويض والمصادقة والتخزين المؤقت والتسجيل وإدارة تبديل الميزات وقواطع الدائرة.



يمكن حل مجموعة كبيرة جدًا من المهام باستخدام الجوانب. دعنا نستخدم الأمثلة:

• . , . , , . — , .
• — . , - . , , - .
• : , , . Xdebug — .
• , — circuit breaker, , , , .

إذا نظرنا إلى التطبيق ، فسنرى أن أجزاء التعليمات البرمجية هذه موجودة في كل مكان وليس من السهل جدًا التعامل معها. هذه الوظيفة المزعومة من طرف إلى طرف موجودة في جميع أنحاء التطبيق.

ولا توجد طريقة جيدة لتصنيفها بطريقة أو بأخرى باستخدام البرمجة التقليدية الموجهة للكائنات.

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



سيرجي جوك: حسنًا ، فهمت. ولكن لهذا كان هناك بالفعل بعض امتدادات PECL ، حتى أن إطار العمل موجود. لماذا قررت أن تكتب خاصتك؟



ألكسندر ليسشينكو: نعم ، لقد لاحظت بشكل صحيح أنه كان هناك بالفعل عدد من الحلول. لكن بدا لي أن لديهم عيوبًا كبيرة.



حاولت بعض الحلول تحويل الكود المصدري ، على الفور تضمين نصيحة محددة في فئة معينة - جزء من الكود يتكرر من طريقة إلى أخرى. مع xlt يولدون فئة واحدة ويضعون كل شيء هناك. بشكل عام ، من الأفضل عدم فتح هذا الرمز على الإطلاق)



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



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

وأدركت أنه في PHP لن يكون من الممكن تنفيذها بشكل سلبي. ربما كانت تلك هي اللحظة الأكثر إثارة للاهتمام.

بشكل عام ، كانت عملية كتابة الإطار برمتها صراعًا مستمرًا مع "لا" و "مستحيل". يبدو أنني لا أستطيع تنفيذ الأمور الأساسية ، لكن التعامل معها كان أكثر إثارة للاهتمام.



سيرجي جوك: لا يسعني إلا أن أسأل. لماذا Go AOP؟ تم إطلاق الإصدار الأول من إطار العمل في أوائل عام 2013 ، وكانت لغة Go موجودة بالفعل ، وكان لديك PHP. يشبه الأمر مع JavaScript وجافا ، أليس كذلك؟)



ألكساندر ليسشينكو: الالتزام الأول لا يساوي بداية التطوير المحلي على جهاز الكمبيوتر الخاص بي) في ذلك الوقت ، لم يكن Go مشهورًا بعد. لقد بحثت في موقع Google ، ورأيت أن هناك نوعًا من التطوير الداخلي من قِبل Google ، فهي تحتل مكانة خاصة بها ... ولم تهتم.



اخترت اسم الإطار نفسه ، بناءً على الرغبات الداخلية ، إذا جاز التعبير. من go - "go" ، "forward" ، "do".



سيرجي جوك: ثم لم تكن هناك أفكار لإعادة التسمية؟



ألكساندر ليسشينكو: الاسم الكامل لـ Go! AOPPHP . لكن مع مرور الوقت ، قمت بإزالة PHP ، لأنه تم تثبيته من خلال Composer ويبدو أنه لا جدوى من جعل الزيت زيتيًا.



حتى الآن ، أحصل على حركة مرور إضافية: الكثير من الأشخاص الذين يحاولون العثور على AOP for Go ينتهي بهم الأمر في إطار عمل PHP الخاص بي. ربما سيكون من الضروري في بعض الإصدارات المستقبلية التأكيد على أن هذا لا يتعلق بـ Go. حتى الآن ، لم يبدأ أحد مشكلة على GitHub في هذا الصدد. لم تكن هناك شكاوى من Google أو المجتمع أيضًا.



سيرجي جوك: حسنًا ، كيف يتم تنفيذ ذلك من حيث رمز العميل؟ لدي هنا تطبيق ، على سبيل المثال ، على Laravel ، هناك تكاملان مع خدمات الجهات الخارجية ، أريد تسجيل هذه المكالمات.



Alexander Lisachenko: توجد بالفعل وحدة خاصة لـ Laravel. سيضع كل ما تحتاجه في النظام ، ويقوم بتكوينه. ستحتاج إلى كتابة جانب - ستكون خدمة ، وسوف تقوم بوضع علامة عليها وسيتم التقاطها تلقائيًا بواسطة AOP core. في الجانب ذاته ، تحتاج إلى فهم ما هي النقاط في التطبيق ، وفي أي فئات وطرق تريد تنفيذ وظيفة التخزين المؤقت. يمكنك تحديد طريقة مباشرة بتوقيع (لكن الخيار ليس مرنًا جدًا ، لذلك يمكن إعادة تسمية الطريقة ، لكنها تظل في الجانب) ، أو يمكنك تمييز الطريقة بتعليق توضيحي. الخيار الثاني أكثر مرونة: عندما يكون من الضروري التخزين المؤقت ، ما عليك سوى تحديده على أنه قابل للتخزين المؤقت ، وسيقوم المحرك بالتخزين المؤقت نيابة عنك واستدعاء رد الاتصال ، الموجود في رمز الجانب.



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

لا أحب النودلز من الداخل وقررت تقسيم الفصل إلى قسمين.

تظل الفئة الأصلية دون تغيير تقريبًا - يتغير الاسم فقط. ويظهر الفصل الثاني مع اسم الفئة الأصلي ، والذي يمتد إلى الفئة الرئيسية ويمكن ، إذا لزم الأمر ، تجاوز عدة طرق.



لماذا الميراث في الواقع. هناك العديد من الطرق والفئات التي تعيد المثيل مرة أخرى. على سبيل المثال ، طريقة السلسلة المعروفة: نسمي سلسلة العمليات على الكائن ، وتعيد $ this. إذا قمنا بالتزيين ، فستعمل المكالمة الأولى ، ولكن بعد ذلك سينخفض ​​الجانب. إلى جانب الوراثة ، يتم حفظ الذاكرة - لأنه لا يزال هناك مثيل واحد في الذاكرة.



سيرجي جوك: كل هذه الهندسة ، المحرك ، هل فكرت في كل شيء منذ البداية أم؟



الكسندر ليسشينكو:كان هناك الكثير من الأشياء للغوص فيها. على سبيل المثال ، لم أكن على دراية جيدة بـ AST ، لذلك درست العديد من التخصصات المتعلقة بوصف القواعد النحوية. وإذا نظرت إلى إطار العمل الخاص بي ، فإن Pointcut الخاص بي ينفذ قواعد نحوية كاملة وله بناء جملة خاص به - ربما يكون هذا أحد الإنجازات العظيمة. يمكنك كتابة أي عدد تريده من التعبيرات المعقدة ، على سبيل المثال ، "استدعاء أي طريقة عامة لا تبدأ بالأصل ، وتنفذ الواجهة كذا وكذا المساحة الداخلية لكذا وكذا".



كما أنني حفرت كثيرًا داخل PHP. شاهدت ما هي الإضافات وكيف تعمل. في مكان ما جلست مع التنميط ، وتحسين شيء ما ، وضبطه: ولكن الآن ، إذا قمت للتو بتوصيل إطار عمل AOP ، فسيضيف التطبيق بعضًا من 7-10 ميلي ثانية. على مستوى الاستجابة الكلاسيكية البالغة 100 مللي ثانية ، فمن غير المحسوس أن يتم استدعاء مثل هذا الإطار الضخم تحت الغطاء.



سيرجي جوك: هل هناك خصوصية لأطر PHP المختلفة؟



Alexander Lisachenko: من حيث المبدأ ، تم تصميم إطار عمل AOP كمكتبة عامة لا تتطلب ارتباطًا محددًا. الشرط الأساسي هو استخدام Composer. لكنها ليست ودية للغاية مع Symfony.

هناك الكثير من السحر الأسود في Symfony ، وعندما يتعارض مع السحر في إطاري ، يفوز Symfony الأقوى.

بشكل عام ، فكرة Symfony هي أن هناك حاوية ، تحتاج إلى استخدامها وليس ابتكار أطر عمل منفصلة للحصول على وظيفة AOP. هناك طرق تقليدية أكثر: قم بتضمين حزمة - على سبيل المثال ، JMS AOP أو حزمة Symfony Go AOP الخاصة بي .



سيرجي جوك: لنتحدث عن المجتمع والمنافسين. هل هم معك؟



ألكساندر ليسشينكو: على حد علمي ، هناك ثلاثة أطر الآن. هناك راي. اوبلكنها لن تكون مفيدة للإنتاج ، لأنها لا تعرف كيفية العمل بفعالية مع Composer. يقدم مؤلفو Flow إطار عملهم باستخدام الصلصة التي لدينا هنا AOP. يوجد شيء آخر بجانب الأطر الصينية ، وهناك أحزمة أعلى Swoole - ولكن هذا كله على مستوى الامتدادات ، ولا يمكن للمسؤولين تفويت الامتدادات لأسباب أمنية. لا يزال لدي إطار عمل كلاسيكي ، ويبقى على قيد الحياة على أي إصدار.



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

, - Z-Engine — c , , PHP.

أخطط ، بمجرد أن يصبح الوقت مجانيًا ، لمواصلة العمل على Z-Engine وإنشاء الإصدار التالي من إطار العمل ، بناءً على الهياكل الداخلية للغة نفسها. ستعمل تقريبًا مثل Java's AspectJ. الهدف هو الوصول إلى PHP 8.



سيرجي جوك: هذا تقريبا إعادة كتابة كاملة للإطار؟



ألكسندر ليسشينكو: لا ، لقد تحلل كل شيء. تتغير عملية إدخال الكود فقط: توجد فعليًا عدد قليل من الفئات المسؤولة عن إجراء تعديلات على فئة معينة. وفي هذه الحالة ، لن تقوم هذه الفئة بإنشاء ملفات في ذاكرة التخزين المؤقت بهياكل مختلفة ، ولكنها ستغير OPcache في وقت التشغيل وتعديل هياكل PHP في الذاكرة.



سيرجي جوك: وما هو الموقف العام لمجتمع PHP من هذا الموضوع؟ أنا مغرم بـ PHP غير المتزامن ، فهو يترك قلة من الناس غير مبالين. كيف حالك مع ذلك؟



ألكساندر ليسشينكو: سيكون هناك دائمًا من يقول إنه يمكننا القيام بذلك بدون AOP ، فلماذا نحتاج إليه في التطبيقات. جوابي هو أنك إذا لم تعمل في مؤسسة ، فلن تكون الجوانب مفيدة لك. وإذا كنت تعتقد أن لديك مؤسسة ، ولكن لديك خدمة واحدة و 2-3 مطورين ، فهذا لن يعمل معك أيضًا) تعمل AOP بشكل جيد في فرق حيث يوجد العشرات من الأشخاص ، كل منهم يكتب بأسلوبه الخاص ، هناك ، عادة تطبيقات متعددة ، وعادة ما تكون بنية الخدمات المصغرة.



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



سيرجي جوك: هل تقوم بأي أنشطة تعليمية؟ إطار العمل الخاص بك قديم بما يكفي ، لكنني قمت بإلقاء نظرة سريعة على البرامج التعليمية - بشكل قليل. أعتقد أنه إذا سألت عشرة أشخاص عن ماهية AOP ، فسيقول تسعة إنهم لا يعرفون.



ألكساندر ليسشينكو: نعم ، هذا صحيح.



سيرجي جوك: على الرغم من أنه من الجيد أنهم لا يعرفون؟



الكسندر ليسشينكو:هذه نقطة خلافية) ولكن هناك مشكلة أواجهها وما زلت أواجهها - إنها التوثيق. لا أحب كتابة الوثائق بطبيعتها. يمكنني كتابة حلول رائعة ، يمكنني ابتكار أشياء غير عادية ، مكتبات ، لكن مع التوثيق ، هذا مجرد ألم.



حتى في لحظة ما اقترح عليّ صديق من صربيا: لنكتب. وحتى بدأوا في كتابته ، ولكن بعد فترة انتهى الفتيل أيضًا ... وهكذا اتضح أنهم ليسوا ثريين في التوثيق ، دعنا نقول.



سيرجي جوك: إذن ، الانتقاء الطبيعي؟ الأكثر ثباتًا ، الذين تسلقوا ،



وحفروا أعمق ، استخدموه ... ألكسندر ليسشينكو: نعم ، وهؤلاء هم الأشخاص الذين لديهم مستوى كافٍ حتى لا يفسدوا .



سيرجي جوك: هل تلقيت أي ملاحظات من الأشخاص الذين استخدموا إطار العمل بطريقة لم تكن لتخمنها؟



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



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

في الواقع ، تمكنوا من تنفيذ إعادة بناء الكود التلقائي دون تغطيتها بالاختبارات.

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



ملاحظة شكرا لكم على قراءة والاستماع إلى النهاية! يمكن العثور على المزيد من حلقات البودكاست هنا .