تحسبًا لـ AppsConf 2018 ، أجرينا مقابلات مع متخصصين من الشركات الكبيرة حول الميزات والعمليات المميزة للفرق الكبيرة المشاركة في تطوير تطبيقات الهاتف المحمول. ما هي أساليب العمل المستخدمة ، وما المزالق التي تنتظر التجديف في الوصول إلى مطبخ ضخم. ما إذا كان الأصل الأجنبي للشركة يترك بصمة على إجراءات العمل - اقرأ كل شيء عن هذا تحت الخفض.
فيليب أوفاروف ، مطور Android في Spotify. تعمل الشركة منذ ستة أشهر - في أحد فرق النظام الأساسي التي تدعم المطورين الآخرين في Spotify. يعيش في السويد. قبل Spotify ، كان يعمل في شركة سويدية ، وحتى في وقت سابق في Avito.
أرتيوم أولكوف ، كبير مطوري IOS في Odnoklassniki. وهو يقود حاليًا تطوير iOS لأحد المنتجات. بالإضافة إلى التطوير نفسه ، فهو مسؤول عن الهندسة المعمارية والتصميم وتخصيص المهام والتنسيق مع التصميم وواجهات برمجة التطبيقات الخلفية وما إلى ذلك. في المجموع ، لدى Odnoklassniki الآن حوالي 60 مهندسًا متنقلًا مقسمون إلى فرق أصغر. فريق Artem - 11 شخصا.
مكسيم إيفيموف ، مهندس برمجيات أول في أوبر. لقد عمل في الشركة لمدة عامين ، وهو يعمل في تطوير Android. وهي جزء من فريق مدفوعات الراكب ، الذي يعالج كل ما يتعلق بالدفعات في تطبيق Uber للركاب. قبل ذلك ، طور لنظام Android في شركات أخرى - بشكل أساسي عند الطلب ، وحتى قبل ذلك - كتب في C ++ (حلول الخادم لأنظمة SCADA). في Uber ، كجزء من قسم الدفع ، هناك العديد من الفرق المماثلة للتطبيقات الأخرى ، بالإضافة إلى فرق البنية التحتية - ما مجموعه عدة عشرات من الفرق.
إيفجيني سوفوروف ، رئيس تطوير وحدة الهندسة المعمارية المتنقلة في Avito: تم تطوير تطبيقات الهاتف المحمول لمدة ثماني سنوات تقريبًا. جربت الألعاب ، العمل الحر ، عملت في شركات الاستعانة بمصادر خارجية ، في شركة كبيرة ، وبعد ذلك تحولت إلى تطوير المنتجات.
لنبدأ بالميزات. ما الفرق بين عمل الفرق مع عدد كبير من المطورين في الشركة؟Artem Olkov (Odnoklassniki): في رأيي ، فإن الخصائص ليست مرتبطة بحجم الشركة ، ولكن مع كيفية ترتيب العمليات داخلها وما هو الدور الذي يلعبه الفريق في هذه العمليات. بشكل تقريبي ، إذا كان فريقك يصنع منصة متنقلة تعتمد عليها التطبيقات أو الخدمات الأخرى للشركة ، فسيصل إليها 1000 طلب من زوايا مختلفة وبدون مدير منتج جيد ، فإن التطوير سيغرق. إذا قدم الفريق خدمة قائمة بذاتها بدون تكاملات معقدة ، فستبدو العملية أسهل بكثير.
مكسيم إيفيموف (أوبر): في رأيي ، فإن الميزة الأكثر تميزًا هي سرعة العمل.
تعمل الفرق الصغيرة ، من حيث المبدأ ، بشكل أسرع. ولكن في الوقت نفسه ، تمتلك الفرق الكبيرة منتجًا نهائيًا نهائيًا للمطور ، بالطبع ، لأن مجموعة كاملة من الأشخاص منخرطون في نفس الشيء تقريبًا. ومن هذا يتبع وجهة نظر مختلفة لكيفية تنفيذ المشاريع بشكل عام.
في الشركات الصغيرة ، غالبًا ما نلائم الشروط ، بشروط ، حتى يوم أو حتى أسبوع. يمكننا حساب وتخطيط كل شيء مسبقًا. في الفرق الكبيرة ، يصعب القيام بذلك ، لأن كل شيء مرتبط بعدد كبير من الناس. لذلك ، يختلف نهج التخطيط إلى حد ما. يتم تنفيذ المشاريع بتفاوتات معينة من حيث الوقت ، والجودة والميزات التي نصنعها لها أهمية قصوى. وفقط بعد ذلك الحاجة للتوافق مع المواعيد النهائية.
نقطة أخرى مثيرة للاهتمام: كيف تتفق الفرق مع بعضها البعض. إذا كان خمسة إلى عشرة أشخاص يعملون في المشروع ، فيمكن تجميعهم بسهولة في غرفة الاجتماعات ، وبعد قضاء ساعتين إلى ثلاث ساعات ، حل جميع المشاكل. ويمكنك الذهاب إلى أبعد من ذلك للقيام بالمشروع. ولكن عندما يشارك مئات الأشخاص في المشروع ، فلن ينجح ذلك. في Uber ، لدينا آليات اتصال معينة تسمح للفرق بعدم التدخل مع بعضها البعض ، والاندماج بشكل فعال ، إلخ. في الشركات الصغيرة ، كل هذا ، من حيث المبدأ ، ليس كذلك.
فيليب أوفاروف (Spotify) : أعتقد أن الميزة الرئيسية هي أنني لا أعرف جميع مطوري Android شخصيًا. ولدينا أيضا مسؤوليات منقسمة للغاية. يتيح لك هذا أن تكون دائمًا في سياق ما تفعله ، وبسرعة كافية لتقديم المنتجات في اتجاهك.
كيف يتزامن فريقك مع الآخرين داخل الشركة؟إيفجيني سوفوروف (أفيتو): ترتبط فرقنا من خلال تطبيق جوال واحد - أفيتو. جميعهم يساهمون في هذا المنتج ، أي نقطة المزامنة في قاعدة التعليمات البرمجية ووظائفنا.
Philip Uvarov (Spotify) : لدينا فرق متعددة الوظائف تتعامل مع قضايا محددة (على سبيل المثال ، كيفية تطوير التحليلات لعملاء الجوّال) يتم دمجها في قسم واحد كبير - نحن نسميها "القبيلة" (القبيلة). كقاعدة عامة ، تكون الفرق داخل القبيلة الواحدة مترابطة بشكل وثيق تمامًا ، لديهم تبادل نشط للخبرات. بالإضافة إلى ذلك ، بالطبع ، لدينا عملاء - هؤلاء هم مطورين آخرين ، لذلك ندعم الحلول التي نبتكرها لهم.
مكسيم إيفيموف (أوبر) : لدينا فرق صغيرة لا يزيد عدد أفراد كل منها عن 20 شخصًا. إنهم متحدون في الوحدات الهيكلية المسؤولة عن مساحات كبيرة ، على سبيل المثال ، تطبيق الهاتف المحمول. في الوقت نفسه ، فإن الفرق نفسها مستقلة تمامًا ، لأنه إذا قللنا كل شيء إلى نظام تحكم واحد مع خضوع مباشر ، فسوف نحصل على نظام غير فعال للغاية.
يتم نقل فكرة المنتج العامة للفرق الفردية من خلال مديري المنتجات أو مالكيها. هناك هيكل منفصل يجمع هؤلاء الناس ويساعد على بناء فهم لكيفية وأين نتحرك. في بعض المستويات العليا ، يمكن تحديد الأهداف الاستراتيجية مثل العناية بسلامة الركاب. حسنًا ، يتم حل التفاصيل بمستوى إلى مستويين أدناه. على سبيل المثال ، لدينا آليات أمنية معينة في البلدان التي يستخدم فيها الأشخاص الأموال في الغالب للدفع.
أرتيم أولكوف (Odnoklassniki): نحن منخرطون في خدمة منفصلة. لنفترض أننا شركة ناشئة داخل شركة كبيرة. بالطبع ، نحن نعيش في نفس البنية التحتية. وفي كل شيء آخر ، نحن منفصلون للغاية. حتى في إطار التكامل ، غالبًا ما نستخدم واجهة برمجة التطبيقات العامة لأدواتنا.
هل هناك أي مشاكل نموذجية للفرق الكبيرة؟ ما الذي عليك التعامل معه؟إيفجيني سوفوروف (أفيتو) : في رأيي ، تتأثر العمليات في فريق كبير في المقام الأول.
جميع الرجال ، كقاعدة عامة ، من ذوي الخبرة ، حتى الصغار قادرون على حل المشاكل التقنية. لكن مشاكل العمليات يمكن أن تبطئ بسهولة الجميع ، لذا من الأفضل أتمتة العمليات.
وهذا يعني التكامل المستمر عالي الجودة ، والتسليم المستمر ، وأتمتة الاختبار.
فيليب أوفاروف (سبوتيفي) : أعتقد أن المشكلة الأكبر هي نشر المعرفة داخل الشركة. قد لا يكون لدي فكرة عما يحدث في بعض الفرق البعيدة. وينطبق الشيء نفسه في الاتجاه المعاكس: العديد من الفرق ليس لديها فكرة عن وجود فريق تحليلات في Spotify. هذا هو المكان الذي يشعر به المقياس.
النقطة الثانية هي سرعة اتخاذ قرارات مبتكرة: تكييف نفس تقنية Kotlin وغيرها من التقنيات الجديدة. هناك شيء قادم وأخبر خمسة مطورين: "من اليوم نكتب على Kotlin" ، ولكن قول شيء لـ 100 مطور شيء آخر تمامًا. هناك بنية تحتية ضخمة تحتاج إلى الترجمة لدعم هذه الابتكارات بطريقة أو بأخرى (CI ، وما إلى ذلك).
Artem Olkov (Odnoklassniki): نعم ، هناك بالفعل مشكلتان: نقل المعرفة وتنسيق الإجراءات ، بما في ذلك التحديث.
هل لدى الشركات الكبيرة أي طرق مثبتة لحل هذه المشاكل؟فيليب أوفاروف (سبوتيفي) : لحل المشكلة الأولى - تبادل المعرفة - لدينا ما يسمى بالنقابات. هذه مجموعة من المطورين حسب الوظيفة ، على سبيل المثال ، نقابة Android ، التي تعقد كل أسبوعين بعض الأحداث: العروض التقديمية ، ووجبات الغداء ، حيث يمكنك مناقشة المشاكل الملحة أو مشاركة شيء ما ، وما إلى ذلك. لدينا أيضًا نقابات مرة أخرى تعقد مؤتمرات داخلية. بالإضافة إلى وجود قوائم بريدية ، إلخ. تبقى مشكلة بشرية بسيطة: من الصعب مواكبة كل هذا.
أود أن أسلط الضوء على التدريب الداخلي (التدريب المتقدم) كخط منفصل. لدينا جامعة البيانات الخاصة بنا ، حيث يمكنك تعلم كيف تصبح مهندس بيانات. يفكر الزملاء الآن في إنشاء نفس المخطط للتعلم المتنقل.
أرتيم أولكوف (زملاء الدراسة): ليس لدينا نقابات
معلنة .
بطريقة أو بأخرى ، يتقاطع الرجال الذين تجمعهم مهمة واحدة في اجتماعات مختلفة - فهم يعرفون بعضهم البعض ، ويتواصلون في غرفة تدخين أو في الغداء. هناك غرف دردشة منفصلة ، على سبيل المثال ، لألقاب iOS فقط. داخل الفريق ، بالطبع ، يتم حل المشكلة بسهولة - كلنا نجلس في نفس "ديزي".
إذا كان لديك أي أسئلة ، ارفع يدك ، ووجه إلى ما تحتاجه - وهو يجيبك. لنقل المعرفة ، نستخدم أيضًا مسيرات صباحية مدتها 15 دقيقة ، حيث يخبر الجميع ماذا وكيف ولماذا ولماذا فعلوا. لا تزال هناك طبقة معينة من الوثائق حيث يتم أخذ النقاط الرئيسية.
المشكلة الثانية - تنسيق الإجراءات - تحلها الإدارة المختصة.
مكسيم إيفيموف (أوبر): في الواقع ، في نفس تقاسم المعرفة ، لا أرى المشكلة. أرى أن آلية المشاركة نفسها مختلفة. في الفرق الصغيرة ، يتم ذلك ببساطة على أي حال. تجمع - تحدث. ولدينا عمليات ملائمة تسمح لنا بتنظيم كل شيء حتى يعمل. بالمناسبة ، سأتحدث عنها في
خطابي في AppsConf 2018. الفكرة هي أن جميع التطويرات تقريبًا في شركتنا شفافة تمامًا. يمكن للأشخاص من أي فريق النظر إلى ما يفعله المطورون الآخرون واستخدام بعض هذا في المنزل.
إيفجيني سوفوروف (أفيتو): ننظم أيضًا اجتماعات مرتين في الأسبوع. نحن نحب الأتمتة ، وهذه المهمة مؤتمتة أيضًا. هناك عملية يلقي فيها الناس خلال الأسبوع على الموضوعات التي يرغبون في التحدث عنها في اجتماع عام لمطوري iOS أو Android. وإذا كان هناك أمر استدعاء ، فسنقوم بذلك. خلال الاجتماعات ، تتحدث فرق المنتج عن الميزات التي تم تنفيذها في المنتج ، وإلا فإنه من الصعب تتبع كل ما يحدث.
التقينا منذ البداية ، ولكن مع نمو الشركة أصبحت هذه الاجتماعات أكثر أهمية.
بالإضافة إلى وجود غرف دردشة حيث يمكنك مناقشة أي قضايا محددة.
ما المبدأ المنطقي لتقسيم العديد من المطورين في الشركة - حسب النظام الأساسي أو حسب الوظيفة أو بطريقة أخرى؟Artem Olkov (Odnoklassniki): لا يزال الأمر يعتمد على ما تفعله وكيفية كسب المال.
من الناحية النظرية ، يمكنني أن أتخيل هيكل شركة الاستعانة بمصادر خارجية حيث يعمل قسم ، على سبيل المثال ، على أساس منصة. ولكن بالنسبة لشركة طعام ، بالكاد أستطيع تخيل شكل مختلف من التقسيم ، باستثناء الفرق الوظيفية.
لأنه إذا وضعت جميع ألقاب iOS في كومة ، فقم بإلقاء المهام فيها ، دون وجود جسر قصير جدًا من التواصل مع التصميم أو الواجهة الخلفية أو الاختبار ، سيكون عليك قضاء الكثير من الوقت في التنسيق.
فيليب أوفاروف (سبوتيفي) : نتشارك جميعًا في المنتج. على سبيل المثال ، ينخرط فريقنا في التحليلات ويتضمن iOS ومطوري الخلفية والعديد من الآخرين. في رأيي ، هذا تقسيم معقول للغاية للفرق ، مما يؤدي أيضًا إلى مشاكل معينة ، ولكن في نفس الوقت يعمل بشكل جيد على هذا النطاق.
Maxim Efimov (Uber): يبدو لي أن فكرة تقسيم الفرق حسب النظام الأساسي - iOS و Android و backend - على نطاق واسع لن تعمل بشكل جيد للغاية. إنه يفصل المطورين عن بعضهم البعض كثيرًا ، ونتيجة لذلك ، ستتكلف المزامنة ، على سبيل المثال ، تطبيقين محمولين لمنصات مختلفة ، أكثر من ذلك بكثير. والربح من حقيقة أن الأشخاص في الفريق يرون فقط الأشخاص من منصتهم ، كما يبدو لي ، ليس كثيرًا. نعم ، تقاسم المعرفة أسهل ، ولكن هل يستحق ذلك؟ لا أعتقد ذلك.
بالإضافة إلى ذلك ، تبدو فكرة أن بعض الفرق تفعل أشياء أساسية يستخدمها أي شخص آخر ، على سبيل المثال ، بعض الأزرار والقوائم وحقول إدخال النص ، تبدو مثيرة للاهتمام بالنسبة لي.
إيفجيني سوفوروف (أفيتو): أوافق
، مثل هذا الهيكل ناجح تمامًا وقد قمنا بتطبيقه مؤخرًا في أفيتو ، على الأقل في جزء البقالة من العمل.
أصبح فريقنا كبيرًا ، ربما ، عندما كان لدينا خمسة مطورين - لأنه حتى مع وجود مثل هذا التنظيم الذاتي الكمي كان صعبًا. أصبح من الصعب على الرجال رؤية ميزة واحدة ، وكان عليهم فصلها بطريقة أو بأخرى ، وتوليدها في زوايا مختلفة ، وفي ميزات مختلفة. بدأت الخلافات في المسائل المعمارية وغيرها ، وأصبحت الاتصالات أكثر تعقيدًا.
في مرحلة ما ، كان لدى Avito فريقان كبيران - تطوير iOS و Android ، كل منهما 15 شخصًا. وفي هذه المرحلة بدأنا في اقتحام فرق المنتجات: برزت المجموعات "تجربة المشتري" ، "تجربة البائع" ، المراسلة الفورية ، التسليم ، وما إلى ذلك. هذا حل المشكلة مع الأولويات. في السابق ، كان الكثير من مديري المشاريع يأتون إلى الفرق مع طلبات الميزات ، وبالنسبة لهم فإن كل واحدة من هذه الميزات لها الأولوية رقم واحد. ونتيجة لذلك ، لدينا 20 مشروعًا وأولوياتها الشاملة ليست واضحة. كان على الآباء إدارة هذا يدويًا. بعد تسليط الضوء على فرق متعددة الوظائف ، كل منها لديه خط التطوير الخاص به ، وأولوياته وموارده ، أصبح كل شيء أبسط.
في الوقت نفسه ، لا يزال لدينا فرق منصة صغيرة تتخذ ، كما نسميها ، قرارات "أفقية" يتم طرحها لجميع فرق المنتجات.
هل تتم عمليات إعادة تنظيم الفريق في كثير من الأحيان؟فيليب أوفاروف (سبوتيفي) : يحدث نوع من الحركة كل أسبوع. في شركتنا ، تكون الفرق صغيرة ومستقلة. إذا رغبت في ذلك ، يمكنك بسهولة الانتقال من واحد إلى آخر. يعتمد عدد مرات حدوث ذلك على الفريق والاتجاه الذي تعمل فيه. حيث أعمل ، هذا غير واضح. لكن Spotify مشهورة بحقيقة أننا نعمل على رشيقة وبطرق عديدة مثل OKR ، وما إلى ذلك. لذلك ، لا تخشى إدارة الشركة تغيير الأولويات ، إذا أدركت فجأة أن شيئًا ما لا يعمل. ننتقل فقط إلى شيء آخر.
مكسيم إيفيموف (أوبر): أجرينا إصلاحات واسعة النطاق ، تتعلق في المقام الأول بالنمو السريع جدًا لمكتب أمستردام. خلال العام ، تضاعف عدد الموظفين تقريبا. أصبحت تلك الفرق التي تم تجنيد الأشخاص فيها كبيرة جدًا وكان من الصعب على مدير واحد إدارة مثل هذا الهيكل. في هذا الصدد ، تم تقسيم الفرق ببساطة إلى عدة "أوامر فرعية" ، كل منها كان يعمل في منطقة أضيق. يبدو لي أن هذه عملية طبيعية.
هل توافق على فكرة أنه في فريق كبير ، بحيث لا تعاني جودة الرمز ، يجدر تجنب توظيف كبار السن وكبار السن المؤهلين؟فيليب أوفاروف (سبوتيفي) : لا أعتقد هذا ولا ذاك. في كل عام ، يقوم Spotify بتجنيد الكثير من خريجي الجامعات من خلال التدريب الصيفي (يتلقى بعض الأشخاص بعد الممارسة دعوة للعمل). وبالمثل ، فإننا نأخذ بسهولة الأشخاص الحاصلين على الدكتوراه.
المهارات التقنية رائعة ، ولكن يمكنك تعليمها. إذا كان الشخص لا يعرف كيف يعمل في فريق ، فسيكون ذلك صعبًا للغاية. لذلك ، تولي هذه الشركات اهتمامًا أكبر تقريبًا للمهارات الشخصية.
ولكي لا تتأثر الجودة ، فنحن بحاجة إلى مقابلات جيدة تسمح لنا باختيار مطورين لا يقل عن بعض المستويات الأساسية.
مكسيم إيفيموف (أوبر): نحن نبدأ من مبدأ مختلف قليلاً. لدينا نسبة مرغوبة من المطورين ذوي الخبرة ويونيو. فقط حتى لا يكون هناك وضع عندما يكون هناك حشد من dzhuns ، ولا يوجد أحد لمساعدتهم وشرح كيفية العمل. لذلك ، نحاول الحفاظ على التوازن.
إن التمسك بمبدأ "عدم تجنيد الكثير من اللوردات" لا يرى النقطة. العثور على رب مهمة صعبة نوعًا ما. هناك العديد من الشركات في السوق ، والمنافسة للمطورين شديدة. يستقر الأشخاص ذوو الخبرة بنجاح في أي مكان تقريبًا ، لذا فإن التخلي عن الموظفين المؤهلين اليوم ثم توظيفهم غدًا غير واقعي إلى حد ما. لن يجلس هؤلاء الناس وينتظروا حتى نريد دعوتهم. وفي ممارستي ، إذا كان الشخص لديه كفاءات جيدة ، فليس هناك مشكلة في العثور عليه مكانًا في الشركة. ولكن يجب أن ننطلق من وضع معين. نحتاج إلى اتخاذ قرار ، اعتمادًا على طموحات كل فرد في الفريق ، وأن ننظر في المشاريع القادمة ، وما إذا كان يمكننا سحبها بأنفسنا ، ومن نحتاج. أي أنه من الضروري النزول إلى التخطيط منخفض المستوى.
إيفجيني سوفوروف (أفيتو): في رأيي ، عند تجنيد كبار السن ، يجب ألا تخاف من وجود ملك خاص بهم في رؤوسهم أو أنهم لن يطيعوا.
في شركتنا ، يقدم المطورون أنفسهم طرقًا لحل بعض المشكلات. وكثيرًا ما يكون لدى كبار السن حلول عالية الجودة. لديهم خبرة ، وبالتالي ، مع مشاركتهم ، يمكن حل المشاكل بشكل أسرع. هناك مشكلة أخرى - قد لا تبدو مهامك ممتعة لكبار السن أو طموحة.
يحتاج جونيورز أيضًا إلى الاقتراب بشكل فردي. عندما كنا ما زلنا فريقًا واحدًا ، كان هناك شعور بديهي من وقت لآخر بأن الفريق يمكن أن يخرج يونيو آخر. وفي تلك اللحظة كان من الممكن أن نأخذ رجلًا طموحًا رائعًا نشأ بسرعة ليصبح مهندسًا عالي الجودة. في فريق لديه عمليات راسخة ، يكون التدريب سريعًا حقًا. نعم ، والأفراد مختلفون - بعضهم يأتي بعد الجامعة بعيون مشتعلة ، لكنهم لا يستطيعون فعل أي شيء ، بينما البعض الآخر لديهم سبع سنوات من الخبرة في الخلفية ، تحولوا إلى تطبيقات الهاتف المحمول.
أي أننا لسنا خائفين من صغار السن ، لكننا نركز على مشاعر الفريق - سواء احتاجه أم لا.
الجدولة والمزامنة وتوزيع المهام
هل يتطلب تخطيط ومزامنة المطورين داخل شركة كبيرة (حتى في الفرق الصغيرة) الكثير من الطاقة؟Philip Uvarov (Spotify) : هذا مجرد تقسيم للفرق حسب المنتج وليس حسب الوظيفة: فنحن نخطط فقط لمنتجنا الصغير داخل الشركة ، وكثيرًا ما لا نهتم بما يفعله باقي الملايين من المطورين.
Artem Olkov (Odnoklassniki): هنا يمكنني التحدث فقط عن فريقنا المحدد. لقد بدأنا في التطوير ، وهذا يعطي بعض الانغماس - يتيح لك أن تكون أكثر حرية. في الوقت الحالي ، لدينا فقط مسيرات يومية مدتها 15 دقيقة حول الوضع الحالي وإغلاق الساعة السابقة / التخطيط للسباق التالي مرة واحدة في الأسبوع. تقرر كل شيء آخر على أساس شخصي.
مكسيم إيفيموف (أوبر): في حالتنا - ليست كبيرة جدًا. ربما تكون 1.5-2 مرة أكثر مما شغلتني عندما عملت على الاستعانة بمصادر خارجية.
صحيح أن هناك بعض العمليات في الشركة ، مثل مراجعة الكود ، تعوق التطوير. تحدث تقريبًا ، حتى ينظر بعض الفريق المسؤول عن جزء الرمز الخاص به في التزامك ، فقد يستغرق الأمر بعض الوقت. ولكن لا أعتقد أن هذا يشير إلى رسوم التزامن. إنه أكثر حول كيفية إعداد هذا المخطط بأكمله على مستوى منخفض - من يقوم بمراجعة من وكيف يتم ترتيب الانتظار ، وما إلى ذلك.
إيفجيني سوفوروف (أفيتو): قمنا في البداية بحل مشكلة المزامنة مع الإصدارات المتكررة. ونتيجة لذلك ، تستغرق المزامنة نفسها الآن القليل. كل شيء آلي تقريبًا.
هل أحتاج إلى توزيع المهام بطريقة خاصة حتى لا تتأثر جودة الكود؟Philip Uvarov (Spotify) : في الفرق الكبيرة ، من المنطقي توزيع المنتج حسب مجال المسؤولية. وبالتالي ، سيكون هناك دائمًا أشخاص سيقتربون منهم بمسؤولية لأنهم سيعيشون معه لاحقًا. لا يتغير سياقها ، أي , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
ولكن بالتأكيد لا يمكنني أن أوصي بدورة أسبوعين أو أسبوعية لجميع المطورين. كما ذكر أحد الزملاء ، هناك منتجات تقاس فيها دورة الإصدار لأشهر ويرجع ذلك إلى اختبار دقيق للغاية للوظيفة. ولكن هناك عمليات معقدة للغاية. ونحاول تبسيط كل شيء. نحن أكثر ارتياحًا للتكرار العالي للإصدارات حتى لا تتمكن الفرق من التفكير في الموعد التالي ، ولكن فقط القيام بالوظائف الضرورية. في أسوأ الأحوال ، سيبدأ الإنتاج في غضون أسبوعين.فرق كبيرة لديها اختلافات أخرى. سيتحدث المتحدثون وزملاؤهم عن التفاصيل في AppsConf 2018ApplsConf 2018 . ستكون هناك محادثات حول الأدوات ومبادئ تنظيم فرق واسعة النطاق.