تصوير: أليكس سميث Unsplashمساء الخير
اسمي فيكتور Pryazhnikov ، أعمل في قسم الميزات في Badoo . تتمثل المهمة الرئيسية لقسمنا في تطوير الوظائف التي يراها مستخدمو موقعنا وتطبيقاتنا. عندما صادفت مقالة كتبها مؤسس Unsplash Luke Chesser ، أدهشتني بحقيقة أنهم تمكنوا من تطوير مشروع كبير نسبيًا مع فريق صغير جدًا. إن طريقة المؤلف تثير إعجابي بواقعيته وتذكيرك بطريقة ما بأنك لست Google ، لذلك قررت ترجمتها.أحد أكثر الأشياء تسلية في تطوير Unsplash هو الحجم الكبير وشعبية المنتج.
في يوم نموذجي ، تعالج واجهة برمجة التطبيقات لدينا أكثر من
10 ملايين طلب من
unsplash.com وآلاف تطبيقات الجهات الخارجية ، تمر
ملايين الأحداث عبر
خط معالجة البيانات الخاص بنا ، ويتم إضافة
60 مليون تحديث إلى خلاصاتنا ، ونقدم
60 مليون صورة.في الوقت نفسه ، فريقنا صغير نسبيًا: اثنان من المصممين ، وثلاثة أشخاص يعملون مع الواجهة الأمامية ، واثنان مع الواجهة الخلفية ومهندس بيانات واحد. ليس لدينا مهندس DevOps منفصل ، ويقضي كل عضو في الفريق معظم وقته في تجربة وتطوير ميزات جديدة لضمان مزيد من التطوير للمنتج.
على الرغم من أننا حققنا الكثير بالفعل مع Unsplash ، إلا أننا ما زلنا في بداية رحلته كمنتج وأعمال. لا يزال لدينا شيء لإثباته ، وهذا يعني أن الفريق بأكمله يحتاج إلى التركيز على حل المشكلات الفريدة لـ Unsplash ، وليس تلك التي تمتلكها أي شركة أخرى ، مثل تنظيم الحسابات ، وأمن الشبكات ، وبناء البنية التحتية ، وإدارة التبعيات ، إلخ.
على مدى السنوات الثلاث الماضية ، قمنا بتطوير مجموعة من المبادئ التي تسمح لنا بالتركيز على النمو وتجنب مشاكل التوسع. لسوء الحظ بالنسبة لأولئك الذين يبحثون عن رصاصة فضية ، فلن تكون هنا: إنها مجرد فكرة منطقية ومجموعة من المبادئ التي اقترضناها من الآخرين.
1. استخدام حلول واضحة مملة
أو تكون براغماتية.
قبل الشروع في إدخال أداة جديدة ، أو قاعدة بيانات (RethinkDB ، RocksDB ، إلخ) ، أو نمط جديد ("كل شيء يعمل!") ، أو بنية جديدة ("خدمات صغيرة ، مساعدة!") ، جرب جميع الخيارات الواضحة.
على الجانب الخلفي ، هناك عدد قليل جدًا من المشكلات التي لا يمكن حلها بشكل فعال تمامًا باستخدام أدوات قياسية معروفة وأنماط مثبتة مثل التخزين المؤقت والمعالجة المجمعة والمعالجة غير المتزامنة والإعداد الأولي للبيانات الضرورية.
2. التركيز على حل مشكلات المستخدم ، وليس التكنولوجيا
Unsplash منتج وليس شركة تكنولوجيا. لقد تلقينا الكثير من المال من المستثمرين للتركيز على حل مشاكل منتجاتنا والسوق ، بدلاً من محاولة تحقيق تخفيض بنسبة 3 في المائة في تكاليف التشغيل لاستخدام التقنيات الشائعة.
نقضي وقتنا في استخدام التقنيات الجاهزة بطريقة تساعد على حل مشكلات مستخدمينا وزيادة مجتمع Unsplash. هذه مهام فريدة لـ Unsplash ، وإذا نجحنا في إنشاء شيء جديد وقيم ، يمكننا تأجيل التحسين حتى تاريخ لاحق ، عندما تصبح هذه التحسينات بنسبة 3 ٪ المصدر الرئيسي للنمو.
قد يخلط بين زملائنا المحتملين الذين سمعوا عن حجم Unsplash وفريق صغير ، واستخدام الصور والذكاء الاصطناعي ، والميزات المستقبلية ، من خلال حقيقة أننا نستخدم الكثير من التقنيات والخدمات والأطر الجاهزة. هذا يجعلنا ندفع أكثر قليلاً الآن ، ولكنه يسمح لنا بتأجيل التطوير الداخلي لهذه التقنيات لبعض الوقت وتحويلها إلى أكتاف زملائنا المستقبليين.
إن عملية وضع الكود ، وتكوين الخوادم ، وتبعيات النظام ، ومعالجة البيانات وتحليلها ، ومعالجة الصور والتخصيص هي أمثلة على المجالات التي اخترنا
عدم التركيز على مواردنا الهندسية ، ولكن بدلاً من ذلك استخدام خدمات جهات خارجية جاهزة لكل منها.
3. إنفاق المال على حل المشاكل التكنولوجية
يتمثل الجانب الآخر من التركيز على مشكلات المنتج في التكلفة الإضافية للوصول إلى التقنيات الجاهزة وخدمات الجهات الخارجية.
أصبحت مزحة داخل فريقنا. يقولون أن أول رد فعل لي على أي مشكلة سيكون السؤال: "هل حاولت حلها بالمال؟". لكن هذه ليست مزحة ، ولكن أحد مقاربي المفضلة لحل المشكلات.
يمثل تحسين التكاليف المرتبطة بالبنية التحتية والتكنولوجيا مشكلة شائعة مع حلول بسيطة ومتكررة بحيث لا ينبغي لأي شركة منتج مع مستثمرين أن تتعامل معها حتى تشعر أن نمو المقياس الرئيسي قد توقف عن أولوياته.
عندما ننفق الأموال على حل المشكلات التكنولوجية ، فإننا نفكك أيدي الفريق ، مما يسمح له بالتركيز على المشاكل المعقدة المتكررة مثل إيجاد طريقة لزيادة حجم قاعدة المستخدمين بنسبة 40٪ في الربع الحالي.
إذن ، هذه ثلاثة مبادئ بسيطة إلى حد ما ، ولكنها مبادئ مجردة نتبعها.
ولكن كيف تبدو في الممارسة العملية؟
إذا نظرت إلى بنية Unsplash ، فسترى أنها بسيطة للغاية ومملة تقريبًا (على الأقل وفقًا لمعايير 2017).
رسم تخطيطي مبسط للأجزاء الرئيسية التي يتكون منها Unsplashنستخدم
Heroku حيثما أمكن لتبسيط تخطيط وتهيئة واختبار ودعم وتوسيع نطاق تطبيقاتنا الأساسية. Heroku هو نوع من السحر الذي يفصل بين أجزاء التطبيق وعملية التطوير بحيث لا يحتاج أعضاء فريقنا إلى التعرف عليه من أجل تطوير التجارب وتصميمها.
نحن نقلل بقوة مقدار الشفرة التي نكتبها لمنطق الأعمال للتطبيق (المناطق الأرجوانية في الصورة). عند كتابته ، نستخدم بنشاط الأطر التي أنشأها أشخاص آخرون قاموا ، كخبراء في مجالاتهم ، بتطوير حلول تعمل بنجاح في 95٪ من حالات الاستخدام لدينا.
نحن نستخدم بنشاط Redis و Elasticsearch و Postgres في الإنتاج. في الماضي ، جربنا قواعد بيانات أخرى ، لكننا عدنا دائمًا إلى هذه القواعد الثلاثة ، لأننا على يقين من أننا نفهم كيف تتصرف تحت الحمل.
نستخدم أيضًا قوائم انتظار المهام بشكل نشط ، ومعالجة العديد من العمليات بشكل غير متزامن ، مثل تحديث البيانات وتجميعها ومزامنتها بين مصادر مختلفة.
لمعالجة البيانات ، نستخدم
Snowplow ، وهو إطار عمل متكامل مفتوح مكتوب بلغة سكالا ، والذي يلغي الحاجة إلى أن يفكر فريقنا في تنظيم الدخول والخروج ، وليس حول المعالجة نفسها.
نستخدم أيضًا مجموعة كاملة من خدمات المراقبة السحابية ، مثل
Datadog و
New Relic و
Sentry and
Logentries ، بدلاً من نشر وصيانة مجموعة StatsD أو ELK الخاصة بنا.
لقد
استعاننا بمصادر خارجية للاستضافة والبنية التحتية لتقديم صورنا إلى
imgix ، وهي شركة رائدة للعمل مع الصور الديناميكية. إذا قاموا بإضافة بعض الوظائف الجديدة ، فإن فريقنا يقوم بإجراء تغيير واحد على عنوان URL - ويحصل مستخدمونا أيضًا على هذه الوظيفة.
نحن نسجل جميع الإجراءات التي يتخذها مستخدمونا في خدمة
Stream ، باستخدام خبرتهم في بناء وتحسين الأشرطة الشخصية المحملة للغاية. يبسط Stream معالجة مليارات الإجراءات بالنسبة لنا ويوفر واجهة برمجة تطبيقات بسيطة للدخول والخروج ، والتي تعمل مع هذه الإنتاجية التي يقضي فريقنا أشهرًا أو حتى سنوات في إنشائها بمفردها.
نحن لا ندرب خوارزميات التعرف على الصور بأنفسنا ، ولكن بدلاً من ذلك نستخدم
TinEye للبحث العكسي عن الصور و
Google Vision للتعرف على الصور وتصنيفها.
نسجل جميع الأحداث السلوكية في
Vero ، وهي منصة للعمل مع الإخطارات والقوائم البريدية ، مما يسمح لنا بنقل العمل معهم إلى أيدي زملائنا من غير المطورين. يمكنهم هم أنفسهم إنشاء رسائل بمستوى عالٍ من التخصيص ، بناءً على الاستخدام المعقد للبيانات المتاحة حول سلوك المستخدم.
في الوقت نفسه ، نحن نركز على تلك الأجزاء من Unsplash التي يمكن أن توفر تحسينًا في كفاءتنا الأساسية.
على مدار العام الماضي ، قمنا
بتقسيم تطبيق Ruby on Rails الخاص بنا إلى Rails API ، تطبيق الويب Node.js + React وقمنا بإنشاء تطبيق بيانات منفصل يجمع ويعالج جميع مقاييسنا الداخلية ومعايير المنتج.
سمح هذا لفريقنا بإنشاء وظائف بدت شبه مستحيلة على مجموعتنا القديمة المكونة فقط من ريلز. بعد مشاركة مشاكل وتقنيات تطبيقاتنا ، حصل فريقنا أيضًا على فرصة لاستخدام أفضل الأدوات في كل مجال من المجالات:
- في الواجهة الأمامية ، نستخدم React و Webpack جنبًا إلى جنب مع خادم Express صغير لدعم عرض الخادم وطلبات واجهة برمجة تطبيقات الوكيل. لم نقم عن قصد بربط أدوات فريق الواجهة الأمامية بالواجهة الخلفية مع عمليات اختراق مؤقتة مثل سكك تفاعلية أو باكر الويب . يُصدر مجتمع جافا سكريبت ، بدون شك ، أفضل الأدوات للعمل مع الواجهة الأمامية ، لذا فإن العمل مباشرةً مع جافا سكريبت يسمح لفريقنا بتقديم وظائف عالية الجودة للمستخدمين بسرعة.
- في الخلفية ، يواصل فريقنا استخدام أفضل إطار لتطوير تطبيقات ويب بسيطة: Rails. يقدم النظام البيئي Ruby on Rails أفضل الأدوات للوظائف على الجانب الخلفي ، وبما أن هذا الإطار مستخدم على نطاق واسع ، فقد وجد شخص ما بالفعل أي مشكلة به ، وموثقة ، ومع وجود درجة عالية من الاحتمال ، يوجد بالفعل حل له.
- من ناحية البيانات ، يستخدم فريقنا خادم Express صغيرًا لجمع وتنظيم معالجة البيانات. تتم المعالجة نفسها في Snowplow ، والتي تعمل في مجموعة AWS ، حيث توجد صور جاهزة لها تبسط التكوين والنشر. وهذا يسمح لمهندس البيانات الوحيد لدينا ، Tim ، بقضاء معظم وقته في نقل البيانات إلى Snowplow والحصول على النتائج من هناك بطريقة تجعل من السهل على أعضاء الفريق الآخرين فهم الأفكار والحصول عليها.
نحن
نشارك بنشاط
في كتابة الاختبارات ، وقياس الأداء باستخدام أدوات مثل
Scientist و Datadog ، ووضع التغييرات في شكل تجارب
وأتمتة العمل مع بنيتنا التحتية قدر الإمكان.
نحن نعمل على تطوير
واجهة برمجة تطبيقات داخلية جديدة تستند إلى
GraphQL لتسريع تكرار التجارب والميزات والمنتجات الجديدة التي لا تعتمد على بعضها البعض ، لأننا أدركنا أن واجهة برمجة التطبيقات المستندة إلى REST تنهار بدون مستوى عالٍ من التنسيق بين البيانات والتصميم والفرق الأمامية والخلفية - أفضل سنقضي هذا الوقت على الميزات ، وليس على تغييرات JSON.
على الرغم من أنه من المثير للاهتمام العمل على هذه التغييرات ، إلا أننا لا نجريها لأننا نريد أن نطفئ حكة المبرمج لدينا ، ولكن لأنها تحل مشاكلنا الحقيقية التي تمنعنا من تقديم الوظائف والتطور بسرعة.
أعتقد أن معظم الناس الذين قرأوا على هذا المكان لديهم أحد الاستنتاجات الثلاثة في رؤوسهم:
- Unsplash بسيط للغاية ، لذلك يمكنك استخدام هذا النهج. ما أقوم به أكثر تعقيدًا ، لذلك نحن مضطرون للقيام بالأشياء بشكل مختلف.
- أنا مطور. يبدو مملًا للغاية - أريد إنشاء نظام جديد للتعرف على الصور عالي التحميل!
- رائع! لا يهمني ، فقط أعطني صورًا مجانية جميلة يمكنني استخدامها.
أيها الناس مع النتيجة رقم 1 ، أنت على حق: هناك شركات تقوم بأشياء أكثر تعقيدًا مما نقوم به. لكن ليس هناك الكثير منهم. نحن جميعًا ننشئ نفس الأنظمة ، ولكننا نركز على بعض الأشياء الأخرى ، وهذا هو السبب في أنه يمكن تجريد الحلول المستخدمة في شكل أطر وإعادة استخدامها في مشاريع مختلفة (وبالتالي ، فإن معظم المشاركات حول التوظيف متشابهة جدًا مع بعضها البعض).
الأشخاص الذين لديهم الاستنتاج رقم 2 ، يعتمد ذلك على ما تجده مثيرًا للاهتمام. إذا كنت تريد تجاوز حدود التكنولوجيا ، فابدأ العمل في شركة مهمتها القيام بذلك. لا يوجد الكثير منها ، ولكن معظم الشركات الأخرى ببساطة لا تفعل ذلك.
للناس الذين لديهم الاستنتاج رقم 3 ، سأقول: "نعم ، هذا صحيح!" في النهاية ، هذا ما نقوم به من أجل كل هذا.
إن Badoo قريبة من المبادئ التي يتحدث عنها المؤلف. والفرق الرئيسي هو أن مشروعنا أكبر بكثير وأن استخدام الخدمات الخارجية بالنسبة لنا غالبًا ما يكون مكلفًا للغاية. علاوة على ذلك ، فإن العديد من حلولنا بسيطة للغاية ونحاول أن نتعامل مع تغييراتها بعناية من خلال مقارنة تكلفة إدخال وتشغيل تقنية جديدة مع الفوائد التي سنحصل عليها منها. بعض حلولنا قديمة جدًا ، حيث تم إنشاؤها منذ فترة طويلة ، ولكن التحول إلى حلول جديدة مماثلة فقط من أجل الموضة لن يدفع مقابل الموارد التي تنفق عليها. في الوقت نفسه ، نحن على استعداد لتقديم تقنيات جديدة ، إذا أدركنا أنها يمكن أن تجلب فوائد حقيقية (على سبيل المثال ، PHP 7 ، Go ، Cassandra ، Tarantool ، Exasol ).