ما هي المشاكل التي تنشأ عند زيادة فريق المحمول بمقدار 10 مرات؟ لأي أسباب ، في نفس الشركة ، يفضل مطورو Android استخدام مكتبات مشهورة ، وكثيراً ما يكتبون في iOS حلولهم الخاصة؟ كيف هي الحياة لمطوري المحمول في fintech؟
شارك مركز التقنيات المالية في مؤتمر Mobius الخاص بنا ، وفي هذا الصدد ، طلبنا من اثنين من موظفي CFT:
كيريل زويف كان مسؤولاً عن iOS ، وكان
ميخائيل إميليانوف مسؤولاً عن Android.
تحول النص إلى توسيع كبير لدرجة أننا قمنا بتكوين جدول محتويات حتى يكون من السهل الانتقال إلى جزء محدد:
عن الشركة
JUG.ru Group: سؤال تمهيدي: أخبرنا عن الشركة وماذا تفعل شخصيا في ذلك.كيريل : من المستحيل القول لفترة وجيزة ، نظرًا لأن مجالات أعمال CFT متنوعة للغاية. لكن جرب "اللمسات الكبيرة" حول المنتجات والخدمات الأكثر شعبية.
تعمل CFT في سوق fintech الروسي للعقد الثالث ، ونقول إننا فعلنا fintech عندما لم يكن هذا المفهوم موجودًا.
اليوم ، تقوم CFT بمعالجة وإنتاج البرامج لعدد كبير من المؤسسات المالية وشركات التأمين والشركات الحكومية وتجارة التجزئة.
هذا هو النظام البيئي Golden Crown ، والذي يتضمن مجموعة من الخدمات بتنسيق b2c و b2b: تحويل العملات عبر الإنترنت ، والتحويلات النقدية عبر الإنترنت ، وتسديد القروض ، وبرامج الولاء ، والنقل ، والبطاقات الاجتماعية.
مركز المعالجة "KartStandart": إصدار والحصول على بطاقات أنظمة الدفع ماستر كارد ، فيزا و "مير".
يجمع النظام الفيدرالي "City" عدة عشرات الآلاف من الخدمات المختلفة: من دفع رياض الأطفال والمرافق العامة إلى دفع الضرائب وتجديد بطاقات النقل.
يتم استخدام الخدمات المصرفية عبر الإنترنت Faktura.ru من قبل أكثر من 130 بنك. يتم استخدام الأنظمة المصرفية الآلية CFT من قبل منظمات أكثر مختلفة.
توظف CFT أقسام كبيرة من البحث والتطوير و ML و AI ، والتي يتم دمجها في جميع مجالات الشركة تقريبًا. لدينا فريق قوي لأمن المعلومات. بشكل عام ، هناك أكثر من 3000 شخص كانوا مشغولين بحل مهام fintech على مدار الـ 26 عامًا الماضية.
يعتمد أحد منتجات CFT "الناشئة" على خدمة "التاج الذهبي - تحويل الأموال" (التي يبلغ عمرها بالفعل 16 عامًا) - وهي "تحويل الأموال عبر الإنترنت" ، وهو اتجاه أطلقناه في عام 2016. واليوم هي قاطرة تطوير الأجهزة المحمولة في CFT: في المجموع ، 70 شخصًا يعملون عليها في iOS و Android. وهذا الرقم مستمر في النمو ، نخطط للنمو إلى مئات بحلول نهاية العام.
هناك أيضًا اتجاهات متنقلة في أقسام "البطاقات مسبقة الدفع" (تعمل على تطوير حلول لبطاقات "الذرة" ، "الخط المباشر" ، "كاري" ، إلخ) ، في Faktura.ru ، نظام "المدينة".
و Misha وأنا فقط في قسم "تحويل الأموال عبر الإنترنت" المنخرطين في تطوير الفريق ، والتوسع ، ومقدمة لعمليات التطوير. في البداية ، عملنا في مديرية "البطاقات مسبقة الدفع" ، وكانت الفرق صغيرة ، ومنصة ، وقد عشنا في المفاهيم التي كانت في 2014-2015.
ميخائيل : عندما يجلس الجميع في نفس المكتب ، فإنهم يعملون ويتواصلون.
كيريل : فرق صغيرة دافئة ومصباح ، تتسع من 10 إلى 15 شخصًا ، مع مراعاة كل شيء - كل من الاختبار والواجهة الخلفية. والآن لدينا تحديات جديدة.
مايكل : نعم ، إن تنظيم أعمال 10 مطورين شيء ، و 50 شيء آخر. يشمل ذلك جميع عمليات التطوير ، وتوسيع نطاق الفريق ، وتطويره المهني ، والمشروع نفسه: إذا حل مهندسونا المشكلات الفنية ، فإننا نشارك في تطوير بنية المشروع. نحن نبحث عن المشاكل التي تتداخل مع توسيع نطاق هذا المشروع ، ومحاولة حلها بكل طريقة.
مجموعة JUG.ru: سنعود إلى قضايا النمو ، ولكن الآن أخبرني ما يلي: كيف يختلف تطوير الهاتف المحمول في CFT عن الشركات الأخرى ، وما هو الشيء المماثل؟ ما تحتاج لمعرفته حول أولئك الذين لم يسبق لهم العمل في fintech؟ هل تحتاج إلى معرفة خاصة في مرحلة المقابلة بالفعل؟كيريل : عندما نتحدث مع المرشحين الذين يأتون من الاستعانة بمصادر خارجية ، لديهم الرغبة في العمل في فريق المنتج ، والرغبة في الاستقرار. لكن لديهم دائمًا مخاوف: هل fintech هو نوع من المستنقعات ، يخضع للتنظيم الصارم ويحيط به الأمن ، والذي سيكون من غير المريح الانخراط في تطوير الذات من وجهة نظر المطور.
نقول دائمًا أنه في حالتنا ، يكون تطوير الهاتف المحمول هو نفسه تمامًا مثل أي تطوير لمنتجات السوق. Fintech ليست كلمة لوصف طريقة الحياة ، ولكن ببساطة خط عمل ، شيء نواجهه كل يوم.
هؤلاء هم نفس عملاء الخدمات المصرفية عبر الهاتف المحمول ، والمدفوعات المختلفة ، وخدمات الدفع بدون اتصال وما إلى ذلك. ولكن هذا لا يعني أنك بحاجة إلى أي مهارات أو معرفة خاصة: أي مطور متنقل لطيف قادر على البدء في تنفيذ fintech إذا كان مهتمًا.
بالطبع ، نحن بحاجة إلى الحد الأدنى من المعرفة في المستوى الأساسي: كيف تبدو البطاقة المصرفية ، ما هو الحساب المصرفي. ولكن إذا كانت هناك معرفة أعمق ، فإن ذلك يجعل من الأسهل والأسرع فهم رغبات المحللين. هناك مطورون يريدون فهم ليس فقط "كيفية القيام بالمهمة" ، ولكن أيضًا "لماذا".
هناك أيضًا خصوصية خاصة به ، على سبيل المثال ، متطلبات الجهة الرقابية الممثلة بواسطة البنك المركزي. ولكن ، كقاعدة عامة ، يتم أخذ ذلك في الاعتبار في متطلبات الأعمال ويكفي قراءته وطرح الأسئلة اللازمة وسيكون كل شيء واضحًا.
هناك بعض النقاط من وجهة نظر أمن المعلومات ، وهذا أمر مفهوم: fintech يدور حول الأمن. لكن لا يمكنني القول أن مطوري الأجهزة المحمولة هم خط الدفاع الأول. ومع ذلك ، تم تصميم منتجات fintech بطريقة آمنة على الجانب الخلفي وتخزين البيانات.
نعم ، يحدث أن يأتي أحد المطورين من بدء التشغيل ويبدأ في قول أنه يمكن تصميم واجهة برمجة التطبيقات (API) بشكل أفضل: يقولون ، هنا يمكنك تقديم طلب واحد ، ونحن نقوم بثلاثة. ولكن هذا يرجع إلى حقيقة أن واجهة برمجة التطبيقات قد صممت بطريقة لا تعطي مجمل المعلومات. وعندما يفهم المطور أن هذا قرار هندسي ، وليس خطوة غبية من جانب المطورين ، فإنه يقبل على الفور.
ومن وجهة نظر أمن تطبيقات الهاتف المحمول ، كان لدينا تقرير عن الماضي Mobius. لم نكتشف أمريكا هناك ولم نظهر حيل اختراق ، لكن أظهرنا قائمة مرجعية يجب أن يطورها مطور تطبيقات fintech حتى لا يرتكب أخطاء سخيفة:
نحن لا نلتزم بها ، نظرًا لوجود مراجعة للشفرة ، وهناك توصيات من فريق الأمان الذي جعلنا قائمة مراجعة ممتازة ، حيث يوضح أين يجب معالجة مشكلة عدم الحصانة ومن يقوم بذلك (إلى جانب ذكاء الأعمال أو مطور الواجهة الخلفية أو مطور الهاتف المحمول أو المختبر ). جميع مجالات المسؤولية هذه معروفة لنا ، نحن فقط نتبع القواعد.
من المهم أن نفهم أننا لا ننشر العلب المملة فحسب ، بل نحاول تحويل وجوهنا إلى العملاء ، بما في ذلك الجانب التكنولوجي. لذلك ، نحن دائمًا على الابتكارات مثل المدفوعات غير التلامسية.
احتلت بنوك IOS التابعة لنا في عام 2018 المركزين الرابع والخامس في
تصنيف Markswebb في فئة الخدمات المصرفية اليومية.
نحن نحاول أن نكون تطبيقًا "لا يخجل من إظهار أمي" ، والتي يمكن أن يستخدمها أشخاص بعيدون عن الهواتف الذكية ، وأولئك الذين يفهمون الكثير عن التكنولوجيا. لماذا بعض البنوك المتنقلة ناجحة والبعض الآخر لا؟ لأنها مصنوعة من الناحية التكنولوجية ، مع الرسوم المتحركة ، وربما حتى مع نوع من المراجع الثقافية.
مايكل : سأضيف باختصار أننا نركز اهتمامنا حقًا على العملاء - الأشخاص الذين يمشون في الشوارع. نظرًا لأننا ننفذ عمليات بأموال ، فإننا نسعى جاهدين لجعلها قابلة للاستخدام قدر الإمكان ، وأسهل للناس.
في الوقت نفسه ، عندما يأتي إلينا الموظفون ، فإنهم بحاجة إلى فهم ما يجب فعله حقًا "من أجل الأشخاص" ألا يكون خربشة "كما أرى" على ركبهم. قبل العمل في CFT ، فعلت ما يقرب من كل التصميم و UX بنفسي دون مصمم. لكن الشركة لا تعمل بالنسبة لنا هكذا. يوجد مختبر UX بالكامل مع مصممين يقومون بإجراء التجارب ، وهناك مجموعات تركيز تختبر الفرضيات.
وعندما يأتي إلينا شخص ما ، يجب عليه أن يفهم أن كل شيء سوف يركز على تسهيل استخدام العميل للمنتج ، حتى لا يموت عند ملء نموذج من 50 حقلًا. يركز العمل على احتياجات المستخدم النهائي.
والثاني هو متطلبات جودة الرمز. لدينا متطلبات عالية بالفعل للجودة والمراجعة والبنية النظيفة وتطبيق مبادئ SOLID على جميع الطبقات. من غير المقبول بالنسبة لنا التضحية بالجودة من أجل الوقت.
وهذا مجاور للتكنولوجيا الحديثة ، وليس هناك تأخر في هذه الصناعة. تتم كتابة جميع منتجات Android الآن في Kotlin و iOS على Swift. في Android ، نستخدم Rx ، Dagger ، في بعض المشروعات. عندما يأتي مطورون جدد ، نطلب بانتظام تقديم ملاحظات لفهم ما يحبه الأشخاص ويكرهونه. ولا أتذكر أن الموظفين اشتكوا من أن شيئًا ما قديمًا وعرض عليهم تغيير شيء ما. لدينا فقط وقت لإلقاء الأفكار ، "دعونا نجرب MVI في مثل هذه الوحدة النمطية" ، ويبدأ الجميع في التوليد.
عندما يأتي شخص إلى فريقنا ، يجب أن يكون مستعدًا لفهم مجموعة التقنية الحديثة وأن يكون قادرًا على التنقل فيها. نحن نرحب بهذا. ربما يكون هذا مفارقة: يذهب الشخص إلى التكنولوجيا المالية ، إلى التنمية المصرفية ، ويتوقع المحافظة ، وهو ملزم بمعرفة كيف يعمل Rx و Kotlin مع كل الأشياء الجيدة. هذا ، كما يبدو لي ، ميزة فريدة من نوعها.
نمو فريق المحمول
مجموعة JUG.ru: لقد قلت بالفعل أنك تقوم بحل المشكلات التي تنشأ مع نمو الفريق. هل هناك مثال ملموس؟مايكل : على سبيل المثال. عندما يجري ستة أشخاص في فريق مراجعة طلب السحب ، 3-4 أشخاص في طلب سحب ، فإنهم يمرون بسرعة كافية (خاصة إذا كان الأشخاص في نفس المكتب). يتغير الموقف بشكل كبير عندما يعمل الموظفون في مدن ومناطق زمنية مختلفة ، وينمو الفريق ويظهر داخله خلايا منفصلة (فرق التطوير متحدة بقيادة فريق واحد).
لقد لاحظنا أنه مع زيادة عضوية في عدد المراجعين ، بدأت طلبات السحب في الانتظار حتى 5-6 أيام بالفعل. كانت هذه مشكلة: لم نتمكن من تقديم ميزات إلى العمل في الوقت المحدد.
كانت هناك أيضًا مشكلة في تدفق git: إذا كنت تجلس في فرع واحد ورأيت لفترة طويلة ، في ذلك الوقت ، يمكن للفريق الآخر أيضًا رؤية 2-4 ميزات في الفروع الأخرى ، وبعد ذلك يتم تجميد كل ذلك في الفروع بحلول تاريخ الإصدار ، فنحن نشعر بالألم في شكل تعارض دمج.
تم حل المشكلة الثانية عن طريق تغيير تدفق بوابة. لقد بدأوا في تطبيق نهج التطوير المستند إلى الجذع ، أي أن يتدفقوا مباشرة إلى فرع التطوير ، على فروع الميزة المهجورة. ولكن نظرًا لأنه من المستحيل صب الوظائف غير الفعالة ، فسوف يؤدي ذلك إلى قطع المشروع ، ثم طبقنا طريقة تبديل الميزة. وبالتالي قلل من مدة إصدار الوظيفة إلى فرع الإصدار بعدة أيام. تحدثت أكثر عن هذا على
Twittermobileunderhood .
كانت هناك مشكلة في المراجعة. في السابق ، شارك حوالي 4-5 أشخاص فينا ، نظرًا لأن جودة الشفرة مهمة بالنسبة لنا ، لدينا مبادئ وأساليب صارمة إلى حد ما بالنسبة للجودة. كنا خائفين من أننا إذا قللنا عدد المراجعين ، فسوف تتدهور جودتنا. في هذه الحالة ، بالنسبة لـ 50 مطورًا ، على سبيل المثال ، هناك 30 مراجعات للجودة ، والباقي هم مطورون مبتدئون أو متوسطون لم يطوروا مهارة حقيقية بعد.
لذلك ، اتخذنا مسارًا مختلفًا وتوصلنا إلى الصيغة "1 lead + 1 developer + 1 any developer". في البداية ، استخدمنا هذه الصيغة في إطار فرق العمل: على سبيل المثال ، يصدر مطور الفريق "أ" طلب سحب ، ويضع مراجعة مع المنسق وبعض المطورين الفرديين. تظهر حوالي 20 قطعة من طلبات السحب في يوم ونصف: إذا أجرينا في الصباح مراجعة للجميع ، فسيكون هناك حوالي 20 طلبًا جديدًا بحلول منتصف اليوم التالي.
لكن واجهنا مشكلة أخرى. إذا وضع أحد المطورين قيادته بشكل مستمر وقيادة مجاورة من فريق آخر ، فستصبح الزيادات محتملة. هم أقل مشاركة في التنمية وقضاء المزيد من الوقت في المراجعة. حوالي 20 طلب سحب هي عمل جاد إذا كنت تتعامل معها من الناحية النوعية.
وذهبنا أبعد من ذلك. لقد تركوا ثلاث فتحات للمراجعين ، وتركوا الأدوار نفسها (الفريق الفني ، والمطور الرئيسي ، وأي شيء آخر) ، لكنهم لم يكلفوا أنفسهم عناء أن يكونوا من فريقك. والآن لدينا طلبات السحب تتم في يوم واحد ، بحد أقصى واحد ونصف. لا مزيد من القصص الطويلة.
كل هذا مع تركيبة لتبديل الميزات: عندما يأخذ المطور إحدى الميزات ، يقوم أولاً بوضع علامة تعطيل في الكود بحيث تكون في بداية باردة. ثم يبدأ التطوير. يتم فحص كل هذا في يوم واحد ، بغض النظر عن المدينة التي يوجد فيها الفريق.
قصة منفصلة مع المناطق الزمنية. إذا قمنا بطلب سحب في سانت بطرسبرغ ، فإننا نتبرع بحلول المساء ، ثم في نوفوسيبيرسك +4 ساعات ، وبينما لدينا ليلة أخرى ، فإنهم بالفعل يشاهدون طلبات السحب في الصباح. يتركون العمل - نحصل على طلبات السحب ومشاهدة. اتضح دفق مستمر مستمر في المناطق الزمنية التي تعمل في متناول اليد.
كيريل : نعم ، بالعودة إلى سؤال حول الشركة: بالإضافة إلى حقيقة أن لدينا أكثر من 3000 موظف ، توجد مراكز التطوير الخاصة بنا في ثلاث مدن (تومسك ، نوفوسيبيرسك وسانت بطرسبرغ) ، ويتم توزيع فرق متنقلة فيما بينها. من الأمور المعقدة بعض الشيء أن هناك فارقًا مدته أربع ساعات ، لكن يوم العمل الكلي للشركة يمتد إلى 12 ساعة.
مايكل : المناطق الزمنية تساعد أكثر من مجرد مراجعة. لقد قمنا بتطوير نظام أندرويد واحد ، لا يوجد شيء في كل مدن مختلفة. فرقنا متعددة الوظائف ، لكن متحدة بخصائص المنصة ، كمجتمعات. هناك معايير ومبادئ عامة وممارسات مقبولة ، بما في ذلك نمط الكود وما شابه. وبالتالي ، إذا ظهرت مشكلات فجأة تتطلب إصلاحًا سريعًا أو إجراءً عاجلاً آخر ، فيمكنني التعامل مع أولئك الذين لديهم ساعات عمل الآن ، حتى لو لم يكونوا مسؤولين أصلاً عن هذا الرمز. يمكن للأشخاص في مدن أخرى المساعدة أثناء النوم ، والعكس صحيح.
مجموعة JUG.ru: عندما ينمو فريق ما ، لا يمكن لأي مطور معرفة قاعدة الشفرة بأكملها أو أنه من السهل توضيح أي شيء من شخص يجلس في مكان قريب. في هذه الحالة ، ربما ينشأ تحدٍ آخر: حفظ السجلات؟كيريل: من الجدير قول ذلك: عندما خططنا لنمو الفريق 10 مرات ، أدركنا أننا لن نصدر ميزات أكثر بعشر مرات (أو حتى 7 مرات). مع هذا النمو ، فقط للحفاظ على المستوى السابق من الجودة ، يلزم بذل جهود إضافية. وكان أحد التدريبات للمطورين الجدد هو كتابة الوثائق قبل البدء في القيام بشيء ما.
وبالتالي ، في وقت قصير غطينا المكونات الرئيسية للتطبيق في الوثائق. وبدأوا في السماح لـ jones بدخول هذه المكونات ، لأنه مع مثل هذه الوثائق من الممكن بالفعل تحمل مراجعات واختبار الكود. لقد كان "تأخر العادم" التكبير.
الآن بعد مرور عام ، قمنا بإعداد القاعدة ، والآن نأتي بالمطورين الذين وصلوا قبل عام إلى مستوى الإنتاجية الكامل. كلما ذهبنا ، أصبح الأمر أسهل. بناءً على الوثائق التي تم إنشاؤها ، قمنا ببناء قوائم مرجعية بهيكل المكونات وتفاعلها ، مع تكاملنا مع الخدمات الرئيسية ، والآن لا يتسبب كل هذا في حالة من الذعر: "لقد أتيت إلى البرنامج ، ولديك مؤسسة هنا."
مايكل : سأكمل كيرلس. بعد أن كان لدى الفريق أكثر من 30 موظفًا ، كانت هناك فترة قضى فيها قادة الفريق وكبار المطورين الكثير من الوقت على واحد أو اثنين من المطورين الخاضعين للإشراف ، لأنهم ينقلون المعلومات باستمرار. لقد فهمنا ذلك مقدمًا وبدأنا في العمل. لذلك ، خصص Android مساحة منفصلة في Confluence وجمع كل المبادئ والممارسات والاتفاقيات لتطوير ليس فقط في هذا المشروع ، ولكن أيضًا في غيرها.
عندما يأتي موظف إلى فريق ، يجلس أولاً ويدرس كيفية إجراء التطوير ، وما هي القواعد والممارسات ، وما بنية المشروع. حتى أنه لا يأخذ الشفرة أثناء الدراسة. ثم يجيب على أسئلة التحكم. أي تدريب دون أسئلة أمنية ليست فعالة بما فيه الكفاية.
لقد ذهبنا الآن إلى أبعد من ذلك ونقوم بإنشاء نظام التدريب الآلي Galileo. جوهرها هو في عدة مستويات من تدرج التعليم ، من مبادئ التنمية والمنهجيات ، من المبادئ المعمارية إلى مبادئ لغات Kotlin.
بعد هذا الانغماس ، تم مسح نصف الأسئلة. ما فعلته القيادة من قبل أصبح آلياً الآن. عندما يذهب المطور مباشرة إلى الإنتاج ، في غضون أسبوع أو أسبوعين ، يسأل أسئلة مدببة ، وهي ليست مشكلة. وقبل ذلك كان هناك حقا مشكلة.
أعتقد أنه حتى لو كان المشروع مخصصًا لعشرة أشخاص ، فلا تزال بحاجة إلى تقديم الوثائق مقدمًا. لا تصطدم بهذا الأمر ، لكن ضع بعض المبادئ. سيكون هناك تحجيم - لن ، وعلى أي حال ، عند وصول مطور جديد ، تزيل الوثائق مجموعة من الأسئلة وتوفر الكثير من وقت المنسق.
لدينا وثائق النظام الأساسي (لنظامي Android و iOS) ، وهناك مشاريع (سيناريوهات العمل وما شابه).
كيريل : لقد تحولنا إلى بعض التعهيد الجماعي. عندما يصل وافد جديد ، يقولون له: "انظر ، هذا ما يجب قراءته في اليوم الأول ، هنا في اليوم الثاني." هناك ، إعداد ، توفير مختلف الوصول ، والأدوات ، وهلم جرا. وإذا كان الشخص يواجه مشكلة ، فإن إحدى مهامه هي كتابة المشكلة في قائمة الاختيار نفسها للوافد الجديد التالي. تسعى هذه الأشياء إلى تحقيق أهداف مختلفة في آن واحد: نحن نعد أيضًا الوثائق للأجيال القادمة ، ونعلم المبتدئين قيمة توثيق ما يفعله. وليس لديه خوف مما يكتب.
يبدأ الحماس بشكل خاص فورًا في رسم مخططات UML ، والتي يتم تشجيعها. بمجرد أن يقدم شخص ما مثالاً جيدًا ، يشارك الجميع. ونحن لا نضرب أحداً ، لأننا ندرك أن هناك حاجة إلى الوقت ، ونحن نعطي هذه المرة.
مكتبات الطرف الثالث ضد التطوير الداخلي
مجموعة JUG.ru: أود أن أتحدث أكثر قليلاً عن "المطبخ الداخلي" في سياق iOS و Android. بقدر ما نفهم ، لديك على نظام iOS سياسة رفض حلول الطرف الثالث ، ولكن في البداية حاول أندرويد أيضًا كتابة كل شيء بنفسه ، ثم تركه. لماذا؟مايكل : لقد كان Android تاريخيا بهذه الطريقة. في عام 2013 ، عندما كنا نصنع بنكًا متنقلًا للحصول على بطاقة Kukruza ، لم تكن هناك أي معايير للبنية والمكتبات في تطوير Android. حتى جوجل نفسها لم تفهم أين يجب أن تطور أندرويد. بدأنا التطوير عندما لم يكن هناك Android 5 بعد ، كان لدينا KitKat 4.4 كإصدار أقصى.
نظرًا لعدم وجود مكتبات ، نكتب أنفسنا. , , . : , HTTP-
Volley , API- Retrofit ( ). , . , . Dagger , , Retrofit, «», .
- , , , - . Volley . , , - .
, - . , , Rx , . , . . . , - .
, : «, , », : «- - , », .
, , , -. Kotlin, - 1.0 . , best practices . .
« » « », . , -. .
, : , - , , . , , , , , - . , . , -, .
: iOS, , . . - — , . - AFNetworking, — 40-50 ( ). .
Mobius (
): third-party . , , , , . , , .
— , SSL- , - , .
, , . , ReactiveCocoa, 4-5 . -, , -, , ? , Swift, .
, , , . Android Dagger , , Google. Apple - , . , Swift, , , Swift.
6 , 2011 . 6-8 : , ? , , — SnapKit ( ) , , — , -, . , , .
— . , , , , , , .
: iOS Swift. — , , , . UI-, , -.
Swift — , Objective-C , . , , , , , , …
3 « » VIPER -, : «, MVP, VIPER». MVP- - . , , .
Swift Kotlin
مجموعة JUG.ru: كتب Michael inmobileunderhood "نترك جافا تمامًا ، نعيد كتابة كل شيء على Kotlin". عادةً ، حتى عندما يكون الكود الجديد مكتوبًا بالفعل في Kotlin ، فإن اللغة الموجودة في Java تتغير ببطء شديد ، ويمكن أن تظل قيد الإنتاج لسنوات عديدة أخرى. لماذا قررت أن تفعل ذلك بشكل أكثر نشاطا؟ وهل تتخلص من كود Objective-C بنشاط في نظام iOS؟مايكل : كنت دائما أحب جافا. لقد أحببتها دائمًا ، حتى حصلت على شهادة Oracle ، وكانت على ما يرام معي. لكن تطوير Java في Android وتطوير Java في المؤسسة هما شيئان مختلفان. وقبل بضع سنوات ، عندما كانت Kotlin قد بدأت للتو ، بدأ استخدام Java في شكله العاري بدون مكتبات. المنشآت الطويلة ، القليل من السكر النحوي ، هنا قام بعض الزملاء مع C # بإلقاء ما لديهم ، لكننا لم نفعل ذلك ، فقد تم إبطاله بشكل عام. كنت أرغب في كتابة التعليمات البرمجية التي تعمل المنطق ، وقضاء وقت أقل في كتابة هذا الرمز نفسه ، واستخدام المزيد من الأشياء الجيدة ، فمن الأسهل لفهم وقراءة التعليمات البرمجية.
ثم جاءت أشياء مثل لومبوك. في البداية أعجبتني ، ثم توقفت ، لأنها مكتبة إضافية تسمح لك بتبسيط الشفرة ، ولفها بالسكر النحوي ، لكن هذا مجرد مكون إضافي ، وليس برنامج التحويل البرمجي لـ Java نفسه. و Kotlin Data Class وفئة Java العادية مع جميع الممتلكات وطرق تغليف get / set هما أشياء مختلفة تمامًا.
وقررنا لفترة طويلة لأول مرة تجربة Kotlin على مستوى مشروع واحد. لقد كتبنا ذلك ، لقد أربكتنا بعض الأشياء - حسنًا ، Kotlin و Kotlin ، لقد جربناها جيدًا ، حسنًا ، هناك مشروع واحد ، نعود إلى Java. لقد عادوا ، وبعد بعض الوقت أدركت أنه لم يعد بإمكاني تطوير جاوة. هذا كل شيء ، لقد سئمت منها ، ولم أعد أستطيع رؤيتها بعد الآن.
على ما يبدو ، اعتدت على بعض الأشياء النحوية ، إلى الحد الأدنى من الكود. وفي النهاية ، تقرر أننا بحاجة إلى استخدام Kotlin. ومن الأفضل إدراكه وقراءته. كان بعض المطورين ضدها ، ولكن يبدو لي أن هذه مسألة عادة. الممارسة المقدمة: اكتب مشاريع جديدة على Kotlin. وظلت المشاريع القديمة في جاوة. ولكن عندما حدثت بعض إعادة التوطين الرئيسية ، قمنا بنسخ كل شيء إلى Kotlin. لقد اكتسبنا خبرة للقيام بذلك بسرعة. هذا لا يعني أننا قمنا بتحويل ملفات Java إلى Kotlin باستخدام مفاتيح التشغيل السريع ، ثم إصلاح هذا الرمز - نحن أنفسنا أعدنا كتابته على الفور بنمط Kotlin.
هناك حرفيًا مشروعان متبقيان من برنامج Java ، والانتقال يحدث بشكل تدريجي أيضًا: وحدات نمطية جديدة مكتوبة في Kotlin ، واختبارات جديدة في Kotlin ، والمنطق القديم في Java. إذا تغير المنطق بسبب إعادة البناء ، نكتب في Kotlin. واحد من هذه المشاريع يمر بالكثير من إعادة بيع العقارات في الوقت الحالي. وهكذا ، وضعنا عملية الترحيل على البث ، وبعد عامين مع Java ظل هناك واحد ونصف المشروع.
لم يعارض أحد بشكل خاص. كان هناك بعض الشك "Kotlin هو مجرد ضجيج" ، بالطبع ، لكن ذلك ساعدنا كثيرًا عندما اعترفت Google رسميًا بتطوير Kotlin لنظام Android ، لأنها كانت مجرد قنبلة. لم يعد من الضروري إقناع المهندسين: إما أن تكون على عاتق جميع المطورين الحديثين ، أو خارج هذا السوق.
كيريل : ومع سويفت ، كان الاجتماع الأول على هذا النحو: احتجت إلى تقديم عرض تقديمي صغير لأحد مؤتمراتنا في نوفوسيبيرسك ، وعندما أحضرت رمزًا على الشاشة في Objective-C ، أصبح من الواضح أنه لا يمكن قراءته بأي حجم شاشة. ثم كتبت تلك الشفرة للعرض التقديمي في Swift ، على الرغم من عدم وجود سطر "سريع" واحد في المشروع.
ثم جربنا Swift في مشروع Golden Crown Transport Card ، الذي كتبناه من الصفر. ركضنا بعض لحظات اللغة هناك. كان من المثير للاهتمام ما كنا نفعله بشكل خاطئ ، بدأنا العمل من أجل إنشاء دليلنا الخاص. من "سويفت" الثاني ، "انتقلنا" أيضًا إلى الثلث ، وأخذنا رشفة من الحزن ، التي تطارد الجميع.
وإذا نظرت إلى طلبات السحب التي لدينا الآن ، تتم كتابة 95٪ من رمز Swift هناك. ليس لدينا مهمة فائقة لنقل جميع الأكواد المتاحة من Objective-C إلى Swift بأي ثمن. ومع ذلك ، فإن حصة رمز Swift في تطبيق Mobile Transfer هو 60-65٪ ، ونحن نصدر "ملخص سريع" نرسم فيه رسمًا بيانيًا لملفات Swift / Objective-C ، لخطوط التعليمات البرمجية ، ويعتمد على الإصدار والتاريخ كل شيء مرئي. لا تعني المشاركة بنسبة 65٪ أننا قمنا بنسخ 6 ملفات من أصل 10 - أي في المقام الأول نمو بسبب الملفات الجديدة.
لقد جربنا تقنيات انتقال مختلفة ، على سبيل المثال ، في بنك الهاتف المحمول لبطاقة Corn ، أجرينا عملية انتقال أحادية الاتجاه (أي أن كود Swift الخاص بنا يستند إلى Objective-C ، لكننا لا ننقل تصميمات Swift مرة أخرى إلى Objective-C). لا نقوم بسحب وظيفة Swift لتسريع عملية التبديل إلى Swift بهذه الطريقة. في هذه الحالة ، عندما يصبح الأمر سريعًا ويتطلب رمز Objective-C جميع تبعيات Swift ، يمكننا أن نقول إن الوقت قد حان للمكون للتبديل بالكامل إلى Swift.
نظرًا لأن منتجات خدمة Golden Crown - Money Transfer هي أكثر أهمية من سرعة التطوير من مجرد زيادة حصة Swift ، لدينا قصص ثنائية الاتجاه. قد تبدو أقل جمالا من وجهة نظر أتباع سويفت ، ولكن بما أن هذا النهج يمنح المنتج القدرة على التحرك بشكل أسرع.
جاء المطورون دون أي معرفة سويفت ، تم إتقان اللغة في غضون أسبوعين ، للعمل. في بعض الأحيان يخشون أن يكون لدينا 60 ٪ سويفت ، ولكن لا بأس ، لم تكن هناك حالة حيث لم يكن الموظف قادرا على السيطرة عليها. هناك قصص معاكسة - عندما يكتشفون أن لدينا 40٪ من الهدف- C ، يبدأون في القول بأننا رجوع إلى الوراء ، وعليك أولاً إعادة كتابة كل شيء على Swift ، ثم قص الميزات. ولكن هنا كل شيء فردي ، ونحن نعمل مع كل على حدة.
هناك مشاريع مختلطة ، ومشاريع مختلطة أحادية الاتجاه ، وهناك مشاريع نظيفة على سويفت ، حاولنا كل شيء. كل شيء يعمل بشكل جيد ، لا يوجد رصاصة فضية.
مجموعة JUG.ru: حول Swift و Kotlin يقولون "نظرًا لأنها متشابهة ، أصبح من المناسب لمطوري Android و iOS النظر في كود بعضهم البعض." هل لديك مطورون لمنصات مختلفة يبحثون في كود بعضهم البعض أم لا؟كيريل : أتذكر القصص عندما نظر مطورو Android الذين كتبوا في Java إلى رمز مطوري iOS على Objective-C والعكس بالعكس ، عندما كتبنا أحد المكونات الأكثر تعقيدًا في تطبيق الهاتف المحمول لخريطة Corn - مصمم النماذج الشهير ، مثال على بنية واجهة المستخدم الخلفية المدعومة. هناك تفاعل مكثف للغاية مع الواجهة الخلفية من خلال بروتوكول معين ، وعدم القيام بذلك كان مجرد إجرامي. بالطبع ، نحن مختلس النظر.
والآن لدينا مناهج معمارية مختلفة في التطبيقات ، وتستند التطبيقات إلى أبنية واجهة المستخدم المختلفة. الحد الأقصى الذي يمكننا من خلاله رؤية طبقة العمل ، وحتى ذلك الحين يجب علينا البحث في اتجاه أدوات الاختبار التي تتيح لك الكتابة بإحدى لغات البرمجة.
التطبيقات ، في الواقع ، هي عميل لهذه الخدمة. بالنسبة للجزء الأكبر ، فإنه يستجيب لإدخال المستخدم ويعرض البيانات من الخادم. في مكان ما لكتابة شيء خاطئ تماما أمر صعب للغاية. وفي هذا المعنى ، ربما ، هناك بعض الأمثلة.
مايكل : لدي أمثلة. نظرًا لأن لدينا الآن فرقًا متعددة الوظائف ، يقوم مطورو iOS و Android في نفس الوقت تقريبًا بوظائف الأعمال نفسها على منصات مختلفة ، فهم ينظرون إلى كود بعضهم البعض بشكل أقل وأقل ، لأنه لا يوجد شيء يمكن النظر إليه ، ويمضي التطوير بأكمله بسلاسة.
ولكن عندما يمضي شخص ما قدما ، في الوقت نفسه ، يدرك الشخص أنه يتم تنفيذ بعض من أكثر الرقائق ، عندما تلمح الأعمال إلى "كيفية إجراء Android" ، والتحليلات غير جاهزة بعد ، هناك أوقات يكون فيها المطورون من كلا الجانبين يمكن أن تسقط ونرى كيف يتم ذلك. وهنا يساعد حقا أن سويفت وكوتلين متشابهة جدا.
في حالة الغموض المتنقل ، شاركت تجربتي التي مررت بها عندما عملت في مشروع لم يكن لدينا فيه فريق متعدد الوظائف ، ولكن نوعًا من الشركات الناشئة لسداد القروض. وأحببت النظر في تطوير نظام التشغيل iOS ، كان من المثير للاهتمام كيف يحلون بعض المشاكل ، وربما يلقي بهم شيء ما. وكانوا يحبون رميي. ونحن باستمرار ، لساعات يمكن أن نقف على السبورة ونتحدث عن الشكل التعددي النقي في iOS و Android ، وكيفية طبخه.
يتعلق الأمر بمناقشة ماهية التجريد ، لنوع من المفاهيم الرسمية ، ويحدث كل ذلك ممتعًا ، ويبدأ بالكود المعتاد. أنت تنظر وتفكر: لماذا فعلت هذا ، هل هناك الكثير من النفقات العامة؟ ويوضحون لي أن كل شيء تم التخطيط له وضمه ، حتى لا يقضي 2-3 أيام في البحث عن أفضل حل ، إذا ، على سبيل المثال ، يتغير هذا الكود من خلال العدو. أعتقد: أيها الرجال الأذكياء ، نحتاج إلى القيام بذلك في بعض الأحيان ، وعدم التفكير لمدة خمسة أيام في نوع ما من الهندسة الداخلية ، والتي تبين فيما بعد أنها ليست ضرورية.
نتيجة لذلك ، غالبًا ما أتيت ونظرت إلى رمز سويفت. نظرت إلى الهدف- C أيضًا ، لكني أحب Swift أكثر. على الرغم من أنني لم أقم بتطويرها ، لا أعتقد أنه ستكون هناك أي صعوبات في كتابة التعليمات البرمجية. مطورو Android لديهم نفس الشيء.
كيريل : بشكل عام ، ليس لدينا فقط فريق منصة ، نقول لهم في الداخل: "أنت الأفضل لأن أبل قدمت مثل هذه الأداة". يتفاعل اللاعبون من iOS و Android ، ويشاركون في التخطيط معًا ، ويعملون على حل المشاكل مع محللي النظام.
ويعملون أيضًا معًا فيما يتعلق بمطوري الواجهة الخلفية إذا حاولوا التوصل إلى واجهة برمجة تطبيقات غير مناسبة. وفي هذا التعايش ، يمكنهم تجسس كل شيء في المستودع ، ولدينا نظام مفتوح ، ويمكن لجميع المطورين الوصول إلى المستودع.
في مديرية "البطاقات مسبقة الدفع" ، كانت لدينا قصص عندما تم خياطتها ، ثم قام مطورو Android بإعداد البيئة والبيئة وقاموا بتصوير اثنين من إصلاحات الأخطاء ، فقط للمساعدة.
مايكل : تذكرت حالة حديثة للغاية. هناك ، من أجل أن يكون العميل أكثر دقة بالنسبة لنا ، تحتاج الخلفية إلى القيام بمزيد من العمل ، ثم تضافرت حيلنا المتنقلة وبدأت في المضي قدمًا في فكرتهم العامة. اجتمعوا جميعًا ، ناقشوا كيف سيكونون مريحًا على كلا النظامين ، وذهبوا إلى مطوري الواجهة الخلفية وأعلنوا كيف أنهم أكثر راحة في العمل وما ينتهك مفهوم العميل الرقيق. وافق الداعمون معهم.
الآن ، إذا قال أحد المنصات: "سنفعل كل شيء" ، والثاني رفض ، قائلًا إنه صعب ، ثم يجبرون الثانية على الاتفاق والقيام بطريقة أو بأخرى. وحدث كل ذلك معا. لذلك ، التآزر ، تطوير الفريق يعمل. واللغات تساعد حقا في هذا. بعد كل شيء ، إذا كانت كل من Java و Objective-C نصفي مختلفين تمامًا من حيث التركيب والمبدأ ، فإن Kotlin و Swift أصبحا بالفعل أقرب كثيرًا.
سيريل : بالمناسبة ، هناك أمثلة عندما أصبح الرجال محولات ، وحتى محولات مزدوجة ، التبديل بين المنصات. كان هناك شخص قام بالتبديل إلى نظام iOS ، وتعرف ، و "وضع يديه عليه" ، وعاد إلى Android. ثم غادر على الإطلاق في DevOps. في هذا الصدد ، نحن منفتحون أيضًا ، هذه اللحظات مبسطة.
إنه لأمر رائع أن الرجال يريدون التطوير المهني ، حتى على الطائرات المختلفة. نحن نوفر الفرص ، وهم أنفسهم يختارون الطريقة التي يريدون تطويرها ، ويتم تحفيز جميع اللاعبين لدينا تقريبًا بواسطة المنتج ، من خلال المهام التي يعملون عليها ، وهو أمر رائع جدًا.
JUG.ru Group: السؤال الأخير: ماذا عن تطوير الأنظمة الأساسية؟كيريل : لدى شركتنا منتج قيد التطوير لنظام Federal City. حيث يتم اختيار React Native للتنفيذ. ونحن لا نشعر بالغيرة لذلك ، لأنه من المثير للاهتمام دائمًا إجراء تجربة ومعرفة كيف ستنتهي. علاوة على ذلك ، لدينا مطورين متقدمين يدركون جيدًا أعمالهم ، ومن المثير للاهتمام تجربة شيء جديد ودخول منصات جديدة.
مايكل : لدينا مشاريع على React Native ، لكن هذا خطأ بعض الشيء ، لأنه يتم تنفيذه بواسطة مطوري الواجهة الأمامية ، ولا يتداخل مطورو iOS و Android كثيرًا.
بالنسبة للنظام الأساسي ، فأنا شخصياً أراه للفرق الصغيرة: عندما يكون هناك القليل من الموارد على نظامي التشغيل iOS و Android ، ويتعين القيام بالمشروع لكلتا المنصتين ، لم لا. لدينا ما يكفي من الموارد ، والمنتجات متطورة تقنياً ، يمكننا تحمل تكلفة تطوير منفصل لنظامي التشغيل iOS و Android.
كما حدث تاريخيا أنه عندما قمنا بمعظم مشاريعنا ، لم يكن هناك منصة مشتركة بعد. الآن ، بطبيعة الحال ، سوف نفكر في فصل جزء من منطق العمل والمنطق التجريدي إلى وحدات عامة ، لأن لا أحد يحب القيام بوظيفة واحدة. ولكن تاريخيا ، ليس لدينا هذا.
ومع ذلك ، هذا لا يعني أنه سيكون دائما كذلك. لدينا العديد من المهام والمشاريع الواعدة من قطاع الأعمال ، وهناك نماذج أولية ، وسنحاول عاجلاً أم آجلاً تجربة Kotlin Multiplatform من JetBrains أو Flutter ، والتي تعد أكثر إثارة للاهتمام بالنسبة لنا.
لم يتم توحيد المنصة المشتركة في شكل صناعي ، حيث يمكنك استخدامه واستخدامه في مؤسسة ما. إذا حكمنا من خلال التواصل مع مطوري البرامج المشتركة وتقاريرهم ، هناك الآن "تشغيل أشعل النار" المستمر وحل المشكلات. لذلك ، يمكنك أخذ مشروع وتقديمه ، ولكن في كثير من الأحيان سيكون مجرد معركة ضد أشعل النار ، ولا أعتقد أنه يمكن نشر ميزات الأعمال بكفاءة. في الآونة الأخيرة ، سُئل JetBrains في التقرير عما إذا كان من الممكن استخدام الإصدار متعدد المنصات من Kotlin في الإنتاج على الإطلاق ، ويقولون إنه لا يزال في شكل تجريبي.
في الطرف الآخر هناك رفرفة ، التي انطلقت في العام الماضي ، وهذا الشيء المثير للاهتمام حقا ، جوجل ليست مستثمرة ضعيفة في هذا العمل. وأنا أعلم أن العديد من المشاريع الحيوانات الأليفة على رفرفة ، والتي وضعت بالفعل في متاجر التطبيقات. وهذا هو أكثر إثارة للاهتمام بالنسبة لنا. لقد سئمنا من Kotlin قليلاً ، مع Kotlin / Native يجب أن نجمع الكثير من المكابس ، لكن Flutter with Dart شيء جديد تمامًا.
نحن نحب كل شيء جديد ، لذلك سيكون لدينا بالتأكيد تطوير عبر الأنظمة الأساسية. ليس على وجه التحديد في تطبيق Money Transfer ، ولكن في بعض التطبيقات الصغيرة المنفصلة ، سيكون ذلك.
مجموعة JUG.ru: شكرًا على الإجابات المفصلة!