"ليس من المنطقي بالنسبة لنا استخدام التحديث التحديثي": حول تطوير Android في Sberbank Online



كم عدد التطبيقات الروسية على Google Play تقول "أكثر من 5000000 عملية تثبيت"؟ من الواضح أن كل حالة من هذه الحالات هي قصة فريدة مع تفاصيلها الخاصة ، لذلك سيكون من المثير للاهتمام التحدث مع المطورين. وعندما يحصل هذا التطبيق أيضًا على تصنيف 4.6 ، فهذا يعزز الاهتمام.

فلاديمير تيبلويف هو أحد الأشخاص الذين يعملون على تطبيق Sberbank Online Android. في الربيع ، عندما شاركت Sberbank Technologies في مؤتمر Mobius الخاص بنا ، قدم تقريرًا هناك ، والآن قررنا أن نسأل فلاديمير عن ميزات عمله.


- أولا ، أخبرنا ماذا تفعل بالضبط؟

- في تطبيق Sberbank Online ، أنا منخرط في خدمة Dialogs ، التي تتيح للمستخدمين تحويل الأموال بنقرة واحدة والاطلاع على سجل التحويل بالكامل في عرض كامل. الخدمة متاحة لجميع مستخدمي التطبيق - الآن يبلغ عددهم 37 مليون شخص.

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

- لكل شخص كلمتي "Sberbank" و "تطوير الهاتف المحمول" المرتبطين بـ Sberbank Online. ولكن في هذه الشركة الكبيرة ، هل من المحتمل أيضًا وجود تطوير داخلي للهواتف المحمولة؟ هل هو مختلف عن الخارج؟

- نعم ، هناك أيضًا تطبيقات للاستخدام الداخلي. ليس لدي أي علاقة بهم ، لكنني أعلم أن React Native يستخدم بنشاط هناك. التطوير الداخلي له متطلباته الخاصة: لا توجد مراجعة صارمة للتصميم والرسوم المتحركة المعقدة ؛ التطوير أسرع باستخدام حل عبر الأنظمة الأساسية.

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

- وكيف تؤثر هذه "حتى المشكلة النادرة على الكثيرين" على العمل؟ هل يجب عليك التعامل مع بعض المشاكل الغريبة التي قد تمر بها التطبيقات الصغيرة تحت الرادار؟

- في بعض الأحيان تكون هناك مشكلات على بعض الأجهزة "الخاصة". في أحد البرامج الثابتة ، ولكن المنتشرة على نطاق واسع ، تم إطلاقه بقوة ، وكان علينا اكتشافه لفترة طويلة. اتضح أن المشكلة كانت في برنامج تشغيل اللوحة الأم للجهاز نفسه - حاول محاكاة المكتبات تحت ARMv5 ، على الرغم من أن المشروع كان فقط لـ ARMv7.

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



- في حين أن بعض الشركات الناشئة يمكن أن تضع MinSdkVersion عالية وتقول "كل شخص آخر ليس جمهورنا" ، لديك موقف مختلف ، لا يمكنك التلويح بالناس. ما هي قيمة MinSdkVersion الحالية الخاصة بك؟

- الآن أصبح 16 ، وقد رفعناه حرفياً العام الماضي من 14. نحن ننظر إلى عدد العملاء الذين لديهم SDK محدد ، ويمكننا رفع الإصدار إذا أصبح أقل من 5٪. حتى الآن ، لدينا العديد من المستخدمين على Android 4.4 KitKat ، حوالي 16٪ - نحتاج إلى دعمهم.

- هل هناك أي من الإصدارات الجديدة التي تبحث عنها الآن وتفكر ، "بمجرد زيادة MinSdkVersion ، هل نستخدمها على الفور؟"

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

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

بالطبع ، أود أن "أقوم بالتطوير فقط لنظام Android P ولا أفكر في أي شيء" - ولكن هذا هو الحال دائمًا ، لا يوجد أي مكان.

- إلى تثبيت SSL المذكور. من الواضح أن القضايا الأمنية مهمة للغاية بالنسبة للبنك. وكيف يؤثر ذلك عليك ، كيف يختلف عملك عن العمل على تطبيق غير مصرفي؟

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

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

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

- لأسباب أمنية ، تحد البنوك من وظائفها في حالة الهواتف الذكية ذات الجذور. ما هو محظور على Sberbank Online للأجهزة ذات الجذور؟

- في شهر حزيران (يونيو) ، تخلينا عن الوظائف المحدودة لمالكي الأجهزة التي تتمتع بحقوق الجذر. الآن جميع مستخدمي Sberbank Online على Android لديهم وظائف كاملة. وفي الوقت نفسه ، تظل الحماية على نفس المستوى بفضل نظام مراقبة الاحتيال.

- وباسم الأمن ، كان من الضروري تقييد شيء ليس المستخدمين ، ولكنهم أنفسهم كمطورين ، رافضين استخدامهم لولا ذلك؟

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



- السؤال الذي لا مفر منه: ماذا لديك مع Kotlin؟

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

لذلك يتم تنفيذ Kotlin في خطوات صغيرة: على سبيل المثال ، نكتب اختبارات على Kotlin ونستخدم فئات البيانات (لذلك نوفر الوقت حتى لا نكتب اختبارات للرسائل ، والمستوطنين ، والمساويين () ، و hashCode () وما إلى ذلك).

الآن يتم تشغيله ببطء ، وفي الخطوة التالية نريد كتابة DSL لدينا للاختبار على Kotlin. وبالتوازي ، نريد رفع مستوى معرفة Kotlin في الشركة: على سبيل المثال ، بمساعدة mitaps.

- في حالة "Dialogues" ، فأنت منخرط في المراسلة ، ولكن ليس نظيرًا مباشرًا لـ WhatsApp. وبالتالي من المثير للاهتمام: ما مدى فائدة حلول الآخرين لك؟ هل تستخدم برامج المراسلة مفتوحة المصدر في الشفرة؟

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

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

- أنا محاور كسول ، لذلك قررت أن آخذ فقط قائمة بالأشياء التي تتصل بها في العمل ، واسأل عن كل عنصر "أخبرنا بالضبط كيف تسير الأمور مع هذا."

النقطة الأولى: أنت في "بنية وحدة التطبيق". قلنا بالفعل عن حقيقة أن التطبيق مقسم إلى وحدات - ماذا يمكنك أن تقول عن الهندسة المعمارية؟

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

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

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

بالنسبة لطبقة العرض التقديمي ، اخترنا معيار MVP ، لكن بعض فرقنا تستخدم MVVM. في طبقة العرض التقديمي ، نحن لسنا مقيدين بأي شيء. على سبيل المثال ، رأينا محادثتنا على MVI - بشكل أدق ، حول تنفيذنا المثير للاهتمام لـ MVI ، والذي يختلف بشكل أساسي عما كتبه المطور Mosby.

ثم انتقلنا إلى الإصدار 17 من الهندسة المعمارية وقمنا بتطبيق RxJava ، مما أدى إلى تغييرات معمارية. إذا استخدمنا تعريفات صارمة ، فقد تبين الآن أن بنيتنا سداسية ، من Clean لدينا "شوكة". لكنهما متشابهان في أن كلاهما يعمل وفقًا لمبادئ SOLID ، لذلك يتدفق أحدهما إلى الآخر بسلاسة تامة. الآن نحن نعمل على ذلك.

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

- النقطة الثانية هي "تحسين العمل واستهلاك الذاكرة". ما مدى خطورة هذا السؤال ، هل يجب أن أفكر فيه باستمرار للمستخدمين الذين لديهم أجهزة قديمة؟

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

من حيث التحسين ، على سبيل المثال ، تخلينا عن PNG وقمنا بتنظيفها تدريجيًا خارج المشروع من أجل استخدام المتجه فقط. من المخطط تحسين الرسم البياني للتبعية في Dagger لهذا العام لتسريع البداية الباردة للتطبيق.

- دعنا ننتقل إلى اختبار الأسئلة: كيف يحدث معك؟

- يمكنني فقط التحدث عن فريقنا ، في حالات أخرى يمكن بناء هذه العملية بشكل مختلف.

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

مع مرور الوقت ، توصلنا إلى استنتاج مفاده أننا بحاجة إلى أتمتة الانحدار ، ونحتاج إلى كتابة اختبارات واجهة المستخدم. في البداية ، عملت أنا وشريكي في اختبارات واجهة المستخدم ، وبعد ذلك انضم إلينا قسم الجودة - المختبرون الذين اختبروا الواجهة الخلفية في الماضي. إنهم يعرفون جافا ، وهم الآن مرتبطون بمشروعنا لأتمتة الانحدار بالكامل. جلسنا ونظرنا في الحلول التالية: Appium ، Espresso ، Selenium.

توقفنا في Espresso وبدأنا في تطوير الأساليب معًا. لتسهيل الاختبار ، قمنا بتطوير إطار عملنا الخاص ، مثل Kakao. بدأنا هذا العمل في بداية عام 2017 ، والآن لدينا إطار عمل كبير ، ويتم تجميع معظم الاختبارات كمُنشئ ، نظرًا لكتابة الكثير من المباريات وألعاب الحركة لمواقف مختلفة.

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

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



- البند التالي: مراجعة الكود. هل لديك أي تفاصيل أو "مثل أي شخص آخر"؟

- هناك خصوصية سببها عدد المطورين. عندما يكون هناك عشرة مطورين للهواتف المحمولة في الشركة ، يمكن لشخصين أو ثلاثة مراجعة كل شيء. وكيف تتم مراجعة قانون مئات الأشخاص؟ قمنا بتطوير "مصفوفة المراجعة". تم اختيار من 20 إلى 30 شخصًا ، والذين نعرف عنهم على وجه اليقين أنهم يستطيعون الإعلان جيدًا وترك التعليقات وحل النقاط المثيرة للجدل في التعليقات. أخذوا هؤلاء الناس وقسموا كل الفرق بينهم.

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

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

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

- حتى في Sbertekh ، أنت مشترك في تدريب المبرمجين. كيف يبدو التدريب داخل الشركة؟

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

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

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

- المقابلات: هل لديك "مثل أي شخص آخر" ، أم أن هناك خصوصية؟

- كنت أعتقد أن "مثل أي شخص آخر" ، ولكن في النهاية اتضح أنهم ما زالوا مميزين قليلاً. في تجربتي ، هناك ثلاث طرق شائعة في السوق. يتم طرح السؤال الأول على ثلاثة أو أربعة مواضيع وتقييمها فقط. على سبيل المثال ، أتيت إلى الشركة كمطور Android ، وأعتبر شخصًا يجب أن يكون لديه معرفة ممتازة بالخوارزميات والمزامنة في Java ، وفي الوقت نفسه لا يقدر ما أقوم به في المكتبات الفائقة.قد يكون هذا بسبب حقيقة أن الشركة تحتاج إلى شخص يحتاج تمامًا إلى معرفة جزء ضيق من الإطار أو اللغة. الثاني - عند إجراء مقابلة من خلال الأكمام ، يكاد يكون محادثة مدى الحياة لمدة 30-40 دقيقة. هنا ، بالأحرى ، يكمن الأمر في كفاءات وخبرة المحاور. الثالث - عندما يتحدثون في مقابلة عن مشاكل الشركة ويحاولون الحصول على نوع من الحل على الفور. عيب هذا النهج هو أن الحل قد لا يتزامن مع رأي الشخص الذي يطرح هذا السؤال. في رأيي ، تم العثور على مثل هذه النهج في حوالي نصف الحالات.

أما بالنسبة لنا ، فقد وضعنا منهجية للنظر في مرشح في أربعة مجالات واسعة: OOP ، OOD (تصميم كائني التوجه ، والهندسة المعمارية) ، Java Core ، و Android SDK. بشكل منهجي سؤال بسؤال ننتقل إلى جميع المواضيع. إذا كان المرشح ككل يجيب بثقة على الموضوع ، فإننا نبدأ تدريجياً في التعمق ، وطرح أسئلة أكثر تحديدًا. مجازياً ، تبدو وكأنها شجرة: لدينا جذر ، حيث نذهب إلى كل موضوع ، ويمكننا أن نتعمق من خمس إلى سبع خطوات. ثم يتم تقييم المرشح بشكل إجمالي على جميع الأسئلة التي تم تمريرها. إذا كانت المقابلة سريعة ، فإننا نبدأ بالسؤال عن المكتبات ، على سبيل المثال ، Dagger 2 ، RxJava. إذا كان هناك وقت كاف لذلك ، فوفقًا لكوتلن. وبالتالي ، يتم تقييم المرشح ككل. إذا كان الشخص لا يفهم موضوعًا واحدًا ، ولكنه يعرف جيدًا موضوعًا آخر ، فهذا لا يعنيأنه مبرمج سيئ. هذا يعني أنه لفترة معينة يجب عليه تشديد هذا الموضوع.

"من مهام عملك الأخرى" البحث ومراجعة التقنيات الجديدة. " هنا أريد أن أسأل عن مثال ملموس لبعض التقنيات التي تمت مراجعتها.

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

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

لقد اعتبرنا أيضًا مكتبة TinyMachine لتطبيق آلة الحالة - المكتبة بسيطة ، وليست قابلة للتوسيع ، أي أنها ترضي أمرًا واحدًا ، ولكنها غير مناسبة للآخرين. لذلك ، رفضوا ذلك ، لأنه حتى لو قمت "بسحب" المكتبة ، عندها فقط المكتبة المناسبة للجميع. ونتيجة لذلك ، قررنا كتابة آلة الدولة الخاصة بنا ، لحسن الحظ ، هذا ليس نوعًا من علم الصواريخ ، والذي يصعب تنفيذه.

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

- نعم.النوع الأول من الوثائق هو أحواض Java. لدينا ميم محلي "التحقق من Prilutsky": لا يوجد رصيف جافا - لا يمر طلب السحب ("Prilutsky" يكرم أحد قادة فريق تطوير Android: لقد كتب كثيرًا في جميع الطلبات التي يجب وصفها وثائق الكود ، وبدون هذا ، لن يذهب الكود إلى الفرع العام الذي ولد فيه هذا الميم). الآن يفهم المطورون بالفعل أن كل طريقة عامة ، وكل فئة ، وكل مُنشئ - يجب وصف كل شيء بواسطة مستندات Java. يجب تثبيت جميع الرموز ، حتى الاختبارات. لتوضيح الغرض من كتابة هذا الاختبار ، بحيث ، على سبيل المثال ، لا تطرح أسئلة "ما هذه الدفعة؟" هل الدفع من الرسول أم الدفع من المدفوعات؟ ما هو اختبار الدفع؟ "

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

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

Source: https://habr.com/ru/post/ar422457/


All Articles