🤲🏼 🙏 💭 العرض في لندن في يوم واحد: كيفية الحصول عليه وماذا تفعل بعد الانتقال 👨‍👨‍👧‍👧 🖕🏾 🙎🏼

مرحبا يا هابر!

لدينا خطط كبيرة لعام 2020. نحن عازمون على تطوير Badoo و Bumble بنشاط ، لذلك نقوم بتوسيع الفريق الفني بجدية. واليوم نعلن عن التوظيف الضخم لمطوري PHP في مكتبنا في لندن.

في عام 2017 ، جربنا تنسيق بحث جديدًا - حدث توظيف: نجلب مطورين رائعين إلى موسكو ، ونجري مقابلات في يوم واحد ونقدم فورًا عرضًا للمرشحين المناسبين. بالطبع يتم تكبد جميع نفقات رحلة إلى العاصمة.

لقد نجح التنسيق بشكل جيد ، ولدينا العديد من المراكز المفتوحة مرة أخرى ، لذلك نحن نعلن عن حدث توظيف PHP جديد.

القواعد هي نفسها: إظهار نتيجة اختبار عالية قبل 1 مارس ، واجتياز المقابلة بنجاح في 21 أو 22 مارس في موسكو - وفي نفس اليوم تلقي عرضًا لمكتب Badoo لندن.

UPD: تم الانتهاء من الاختبار ، وذلك بفضل جميع المشاركين! لقد قمنا بالفعل بإبلاغ المرشحين النهائيين وحذرنا من تأجيل مواعيد المقابلة إلى أجل غير مسمى لراحة وسلامة المرشحين.

تحت القطع ، سأخبرك:

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

إذا كنت من PHP shnik وتريد الانتقال إلى لندن ، فمرحبًا بك في kat!

كيفية اجتياز الاختبار

يتكون الاختبار من خمس مهام. يتم تخصيص 90 دقيقة بالضبط للقرار: لن يعمل على تأخير أو إيقاف العملية. قبل أن تبدأ ، تأكد من أن لديك الوقت الكافي.

في ثلاث مهام ، تحتاج إلى كتابة استعلامات التعليمات البرمجية / SQL ، وفي المهمتين المتبقيتين نتوقع رؤية إجابات تفصيلية للأسئلة. تم نشر الاختبار على HackerRank. نوصي بممارسة المهام الاختبارية للنظام الأساسي من أجل الارتياح مع الواجهة.

يتم اتخاذ القرارات حتى 2020-03-01 23:59:59 UTC. بناءً على نتائج الاختبار ، سنختار ما يقرب من 60 مرشحًا سنقوم بدعوتهم إلى موسكو لإجراء مقابلة.

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

ما يفعله فريق تطوير الخادم

نحن مسؤولون عن الواجهة الخلفية لخدمات التعارف Badoo و Bumble. بالإضافة إلى التمرير سريعًا لليسار واليمين للعثور على شريك ، تحتوي التطبيقات على دفق فيديو ، والدردشة مع الرسائل الصوتية ، والبحث عن الأشخاص القريبين ، والتكامل مع خدمات الدفع والمزيد. تخفي واجهة بسيطة نسبيًا الكثير من المنطق في PHP و Go (وهي تحصل على المزيد والمزيد).

يضم فريقنا أكثر من 40 شخصًا. يمكن تقسيم العمل إلى قسمين كبيرين:

وظائف جديدة في التطبيقات ،
المشاريع الفنية - تحسين الأدوات ، والتحسين ، والعمل مع الديون التقنية.

سأتحدث عن المشاريع الأكثر إثارة للاهتمام التي قمنا بتنفيذها على مدى العامين الماضيين.

رقائق باردة في المنتج

إن سوق تطبيقات المواعدة ديناميكية وتنافسية ، وبالتالي فإن هدفنا الرئيسي هو تطوير المنتج: يجب أن يظل مثيرًا للاهتمام وآمنًا للمستخدمين.

تعلمت إخفاء الصور "الشخصية" أيضًا

يرسل بعض المستخدمين صور دردشة ذات طبيعة مثيرة ، حتى لو لم يطلب المحاور مثل هذه الهدايا.

كانت المهمة التي كان علينا حلها هي تعليم التطبيق لتمييز الصور "الخاصة" (18+) من الصور العادية وإظهارها في الدردشة في الدردشة ، مما يسمح للمستلم أن يقرر بنفسه ما إذا كان يريد رؤيتها بالكامل.

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

نجري جميع المهام من خلال اختبارات A / B ، ونغطي أيضًا بعناية النقاط الرئيسية للوظيفة الجديدة بالإحصاءات. لذلك ، اكتشفنا أنه يتم إرسال حوالي 200.000 صورة يوميًا من "الصور الخاصة" ، وأيضًا - غالبًا ما يتم عرض هذه الصور ولا تشكو من المرسل.

تمت إضافة رسائل الدردشة الصوتية والمرئية

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

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

يتم شحذ API المحمول (بروتوكول ثنائي) من خلال تبادل الأوامر القصيرة وفي ذروة يمر من خلال نفسه أكثر من 100000 طلب في الثانية ؛
تم ضبط CDN للعمل مع الوسائط المتعددة وقادرة على تقديم 200،000 صورة في الثانية ( تحدثنا عن تحسينات CDN بالتفصيل في مؤتمر يوم التشغيل).

من وجهة نظر CDN ، لا يهم نوع الملف الذي تم تنزيله كثيرًا ، ولدينا بالفعل تحويل فيديو. يمكننا فقط معالجة الأنواع الجديدة (الصوت والفيديو) بشكل صحيح في بروتوكول واجهة برمجة تطبيقات الجوال.

تعلمت كيفية بناء نماذج ML بدون R&D

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

هذا الإطار قادر على جمع المئات من المقاييس ، سواء العالمية (الجنس ، العمر ، النشاط في التطبيق) ، والمحددة ، المهمة لكل نموذج محدد. يتم تكوين خوارزميات إنشاء نماذج ML بشكل مرن ، وتتوفر الرسوم البيانية للنتائج للتحليلات "من خارج الصندوق". عند الإخراج ، يوفر إطار العمل نموذج عمل يستجيب بسرعة كافية (في غضون 10-100 مللي ثانية) بحيث يمكن استدعاؤه من PHP مباشرة في طلبات المستخدم دون التضحية بتجربة المستخدم.

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

بعد تقييم النتائج ، توقفنا عن إرسال رسائل البريد الإلكتروني بأقل فرصة للنقر على الروابط. ونتيجة لذلك قمنا بما يلي:

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

تم تشغيل دفق الفيديو

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

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

لقد حددنا وظائف الإصدار الأول (MVP) - وبعد شهر أطلقنا ميزة في بلد تلو الآخر. لعدة أسابيع طرحناها في بلدان مختلفة ، واليوم يتوفر بث الفيديو في كل مكان.

بث رسائل المستخدم على أربات

لقد كان عرضًا ترويجيًا غير اعتيادي للغاية: أرسل مستخدمو Badoo جميع رسائل أكتوبر إلى لوحة إعلانات فيديو ضخمة تقع على Novy Arbat في موسكو طوال شهر أكتوبر. في غضون شهر ، تم إرسال 23000 رسالة إلينا ، تم الإشراف على 12000 منها بنجاح وضرب الشاشة.

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

بالطبع ، أراد جميع المستخدمين رؤية الرسالة المرسلة على الشاشة بأعينهم. لجعل هذا ممكنًا ، كان علينا أن نجيب على السؤال عندما تظهر كل رسالة هناك.

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

كانت الصعوبة هي أن الموفر ، من جانبه ، لم يوفر القدرة على التحكم في وقت الإعلان وتتبعه ، لذلك كان من الضروري مزامنة جدولنا الماكر مع جدول الموفر ، والمراقبة والتعديل باستمرار إذا لزم الأمر. لقد ساعدنا أننا لاحظنا (التسجيل هو كل شيء لدينا!) أنه قبل بضع ثوانٍ من عرض الفيديو التالي ، يقوم التلفزيون الذكي بإعادة تحميل الصفحة. كان من المستحيل التركيز على هذا الوقت ، ولكن يمكن للمرء أن يلاحظ تغيرات في الجدول الزمني ، والتي وصلت في بعض الأحيان إلى 15-30 ثانية. أنشأنا مراقبة التحولات من جانبنا وفي لحظات التشغيل بدأنا بطلب وقت أقرب عرض من المزود.

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

مشاريع فنية

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

مشروع Liveprof مفتوح المصدر

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

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

مرة واحدة في اليوم ، يتم تشغيل برنامج نصي يجمع النتائج لكل علامة تجارية ونظام أساسي وطريقة API. وهكذا ، يمكننا أن نرى نتائج التنميط لطلبات محددة من Badoo iOS (في شكل شجرة وفي شكل رسم بياني لهب) ، يمكننا أن نرى النسبة المئوية للمجموعة التي تتطلبها لاستدعاء وظيفة فردية (على سبيل المثال ، كم يكلف جمع عنوان URL لصورة) ، وأضفت مؤخرًا ناتج هذه المعلومات مباشرةً إلى PhpStorm.

الهجرة إلى PHP 7.4

يسر الإصدارات الجديدة من PHP تحسين الأداء. كان قسمنا مسؤولاً عن التحولات الأخيرة (من 7.0 إلى 7.2 ومن 7.2 إلى 7.4). يبدأ

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

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

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

اذهب لتجميع الطلبات

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

قررنا إجراء تجربة بسيطة. لقد حددنا جزءًا من الأوامر التي لا تعتبر استجابة الخادم حاسمة لها (على سبيل المثال ، إرسال إحصائيات من العميل أو اختيار الخيار "لا" في لعبة التمرير السريع) ، وكتبنا خدمة على Go تقبل هذه الطلبات وتحفظها ثم ترسلها إلى الخادم في حزمة ( لكل مستخدم). وبالتالي ، يمكننا بسهولة التوفير عند تهيئة التطبيق دون إعادة كتابة الكود الرئيسي.

تبين أن التجربة كانت ناجحة: وفقًا لتقديراتنا ، يمكننا توفير نسبة قليلة من وحدة المعالجة المركزية (والتي في حالتنا أكثر من عشرة خوادم) دون إعادة كتابة الكود الرئيسي ، ولكن على حساب تعقيد العملية ومنطق العمل. لإكمال الصورة ، قررنا انتظار نتائج التجارب مع PHP 7.4 التحميل المسبق و RoadRunner من أجل اختيار الحل الأمثل وفقًا لنسبة المكاسب وتعقيد التنفيذ.

تحسين الصورة

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

في أكتوبر 2018 ، قررت إحدى علاماتنا التجارية ، Bumble ، دخول السوق الهندية. نظرًا لأننا لم نكن نعرف شيئًا عن سرعة الإنترنت المحلية ، فقد قررنا إجراء سلسلة من التجارب على جودة وحجم الصور.

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

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

كانت المهمة التي أردنا حلها هي اختيار التنسيق الأمثل (JPEG و WebP و PJPEG) والحجم وجودة الصورة. من الناحية النظرية ، يجب أن يكون تنسيق WebP هو الأفضل ، ولكنه الأكثر تكلفة من حيث التحويل السريع: بدلاً من توفير حركة المرور ، تحتاج إلى شراء المزيد من خوادم ذاكرة التخزين المؤقت للصور. بالإضافة إلى ذلك ، قررنا اختبار كيف ستساعد شبكات CDN في المنطقة على تحسين تجربة المستخدم.

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

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

دفق الفيديو الخاصة

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

بمساعدة محول الشفرة الجاهز (لضغط دفق الفيديو من المستخدم) وخوادم Edge (لتوزيع الدفق إلى المستخدم) ، كان علينا بناء نظام مشابه للحل المحاصر الخارجي. وبالطبع ، كان عليّ تحسين الكثير باستخدام "ملف" أثناء التنقل.

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

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

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

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

تحسين الأداء

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

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

نشارك بنشاط المعرفة المكتسبة خلال عمل التحسين في المؤتمرات والاجتماعات. يمكن العثور على مزيد من التفاصيل حول مشاريعنا ودراساتنا في المقالات والتقارير التي كتبها باشا مورزاكوف:

السيطرة على التعليمات البرمجية القديمة وغير المستخدمة

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

نحاول إبقاء قاعدة الكود "نظيفة" من أجل الحفاظ على وتيرة عالية للعمل:

إنشاء المهام تلقائيًا لإزالة الرمز بعد الانتهاء من تجربة المنتج ؛
التتبع الآلي للإصدارات القديمة من التطبيقات وأنظمة التشغيل وفروع الرموز المستخدمة فيها ؛
أدخلت أدوات للبحث تلقائيًا عن التعليمات البرمجية غير المستخدمة.

يمكنك معرفة المزيد عن نتائجنا في Badoo PHP Meetup ، الذي سيعقد يوم السبت 15 فبراير.

بالطبع ، هذه ليست كل المشاريع التي أريد التحدث عنها. على مدار العامين الماضيين ، ناضلنا مع مرسلي البريد العشوائي والنهاش ، ورأينا المكوّن الإضافي لـ PhpStorm ، واختبرنا مستودعات KV المختلفة (واختاروا Aerospike) ، واختبرنا الكثير ، وشاركنا المعرفة في المقالات ، في المؤتمرات وليس فقط.

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

ونعرف أيضًا كيفية الفوتوشوب.

عند الانتقال إلى لندن والمكتب في سوهو سبق أن قلنا ، لذلك لن نتطرق إلى التفاصيل في هذه المقالة - فقط نعرض صورتين.

صورة كبيرة

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

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

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

حظا طيبا وفقك الله

العرض في لندن في يوم واحد: كيفية الحصول عليه وماذا تفعل بعد الانتقال