في 19 يونيو 2025 حضرت PiterJS #79 في سانت بطرسبرغ. كان موضوع الأمسية بعيدًا عن البريق المعتاد، وهذا تحديدًا ما جعله مفيدًا: ليس كيف نطلق الميزة التالية، بل كيف نحافظ على ما بُني بالفعل — monitoring وdeployment وrefactoring.
كان البرنامج منسجمًا جدًا مع هذه الفكرة. تحدث Pavel Shlykov عن تحسين monolith قديم، وتناول Alexander Panfilov موضوع FrontOps، بينما تحدث Igor Antonov عن مقاييس أداء تطبيقات الويب. خرجت بملاحظات عملية من الموضوعات الثلاثة.
أما الجزء غير المتوقع فكان جلسات Q&A. انتهى بي الأمر إلى الفوز بجائزتين عن أفضل الأسئلة خلال الجلسات. ليس هذا إنجازًا تقنيًا ضخمًا، لكنه أصبح أكثر تفاصيل الأمسية رسوخًا في ذاكرتي لأنه أكد لي سبب استمراري في تقدير اللقاءات التقنية الحضورية: لست مضطرًا إلى الاكتفاء باستهلاك عرض مُعد مسبقًا. يمكنك اختبار فهمك بينما الأشخاص الذين قدموا الموضوع ما زالوا في القاعة.
الموضوع المفيد كان الصيانة لا مطاردة الجديد
من السهل أن تتحول فعاليات frontend إلى استعراض متواصل لأطر عمل وواجهات API وتجريدات جديدة. كان PiterJS #79 أكثر واقعية. الموضوع المعلن كان دعم البرمجيات الموجودة أصلًا.
وهذا مهم لأن جزءًا كبيرًا من العمل الهندسي يبدأ بعد أول إصدار ناجح. وجود monolith قديم لا يعني تلقائيًا أن النظام سيئ، كما أن «التحديث» لا يعني تلقائيًا إعادة كتابة كل شيء. السؤال العملي يكون عادة أضيق: ما القيد الذي يؤذي النظام فعلاً الآن، وما التغيير الذي يخفف هذا الألم من دون أن يخلق مخاطر أكبر من تلك التي يزيلها؟
لهذا شعرت أيضًا بأن العروض الثلاثة تكمل بعضها. Refactoring يغير الكود. FrontOps يغير طريقة بناء الـfrontend وتغليفه وتسليمه وتشغيله. والعمل على الأداء يغير طريقة قياس النتيجة. هذه طبقات مختلفة للمشكلة نفسها: كيف نحافظ على نظام حقيقي مفهومًا وقابلًا للسيطرة بعد أن يكبر.
FrontOps أوسع من مجرد Dockerfile
إحدى ملاحظاتي من اللقاء كانت عن تطبيق FrontOps باستخدام Docker. والتمييز المهم هنا هو أن Docker أداة، وليس تعريف FrontOps.
مسؤولية frontend لا تنتهي بالضرورة عندما ينجح npm run build. في production لا يزال على أحدهم التفكير في builds قابلة للتكرار، وكيفية تغليف الـartifacts، ووصول الإعدادات إلى التطبيق، وrollback للإصدارات، وسلوك cache، وكيفية ملاحظة الأعطال. قد تجعل containers بعض هذه العمليات أكثر قابلية للتوقع، لكنها لا تستبدل القرارات التشغيلية نفسها.
هذا تصحيح مفيد لنموذج ذهني شائع: نجاح build يثبت أن عملية build انتهت. لكنه لا يثبت أن التطبيق سيُنشر بصورة صحيحة، أو سيتصرف بصورة صحيحة في production، أو سيكون سهل الاستعادة عندما يحدث خلل.
الأداء يبدأ بتحديد معنى «بطيء»
كان عرض الأداء عمليًا بشكل خاص في الطريقة التي صاغ بها موضوع القياس. النطاق المعلن شمل العوامل المؤثرة في سرعة التحميل، ومقاييس frontend المختلفة، وطرق تحويل مفهوم «البطء» إلى شيء قابل للقياس، وحتى السؤال عن سبب عدم ضرورة التحسين دائمًا.
من السهل التقليل من أهمية النقطة الأخيرة. عبارة «اجعله أسرع» تبدو موضوعية، لكن من دون metric ومشكلة يراها المستخدم فعلًا قد تتحول إلى تخمين مكلف. تبدأ عملية تحسين مفيدة بتحديد ما هو البطيء فعلًا، ثم قياسه، وتحديد عنق الزجاجة، وتغيير شيء واحد ذي صلة، ثم القياس مرة أخرى.
الـmetric ليست تجربة المستخدم بحد ذاتها، لكنها تمنح النقاش وحدة مشتركة. من دون قياس قد يتحول عمل الأداء إلى مجموعة تغييرات مثيرة تقنيًا، لكن من دون دليل واضح على أنها حسنت المشكلة التي كانت مهمة فعلًا.
غيّرت جلسات Q&A قيمة اللقاء بالنسبة لي
كان يمكنني مشاهدة التسجيلات وجمع الروابط لاحقًا. ما يصعب إعادة إنتاجه بالطريقة نفسها هو التفاعل الذي يحدث حول العروض. طرح سؤال جيد يجبرك على ضغط مساحة عدم اليقين لديك إلى شيء محدد بما يكفي لكي يجيب عنه مهندس آخر.
الفوز بجائزتين كان ممتعًا، لكن الدرس الأكثر فائدة كان أبسط: الذهاب مستعدًا للمشاركة يمنح اللقاء الحضوري قيمة أكبر بكثير من التعامل معه كأنه قائمة تشغيل YouTube مباشرة.
السؤال التقني القوي يتضمن عادة سياقًا وقيدًا. بدلًا من «ما أفضل architecture؟» قد يكون من المفيد أكثر أن تسأل كيف يتغير الـtrade-off عندما لا يستطيع الفريق إعادة كتابة legacy system، أو عندما يجب أن يبقى deployment متوافقًا مع الإصدارات السابقة، أو عندما تتحسن metric من دون فائدة مقابلة يلاحظها المستخدم.
لا يعني ذلك أن كل سؤال يجب أن يكون ذكيًا أو لافتًا. المطلوب أن يساعد في كشف الافتراضات أو الحدود أو failure modes.
ما الذي سأحمله معي إلى اللقاء التقني القادم
- أن أعرف لماذا يهمني العرض. أكتب قبل بدايته مشكلة حقيقية أو نقطة غير واضحة لدي.
- أن أفصل تجربة المتحدث عن نظامي. الـcase study الجيدة دليل مفيد، وليست وصفة عالمية.
- أن أسأل عن trade-offs. سؤال «متى لن تستخدم هذا؟» يكشف غالبًا أكثر من «ما أفضل أداة؟»
- أن أسجل خطوة متابعة واحدة. تصبح الملاحظة أكثر فائدة عندما تقود إلى شيء أتحقق منه أو أختبره أو أقرأ عنه بعد اللقاء.
- ألا أخلط بين عرض مقنع ودليل production. قرارات architecture وdeployment والأداء ما زالت تحتاج إلى التحقق داخل بيئتي الخاصة.
ما الذي بقي معي
لا أريد المبالغة في ما يمكن أن يغيره لقاء واحد. لم أخرج من PiterJS بوصفة architecture تصلح للجميع، كما أن العرض الجيد لا يستبدل documentation أوprofiling أوtesting أوproduction data.
ما خرجت به كان أكثر تحديدًا: ملاحظات مفيدة عن تحديث monolith قديم، وFrontOps باستخدام Docker، وقياس أداء الويب؛ جائزتان من Q&A؛ وتذكير آخر بأن مجتمعات المطورين المحلية تستحق أن نذهب إليها ونشارك فيها شخصيًا.
يمكن للتسجيل أن يحفظ العرض. أما الجزء الأصعب في الأرشفة فهو الحوار الذي يدور حوله.