يومي 22 و 23 نوفمبر ، تم عقد مؤتمر DotNext 2018 التالي لعشاق .NET في موسكو. اسمي مكسيم سميرنوف ، أتولى رئاسة مركز الكفاءات في بنك ألفا وأريد أن أقدم لكم نسخة نصية من أحد المقابلات التي أجريت على هامش DotNext.
حول الحياة والمغامرات في مصرفنا ، حول التعايش مع Java ومشاكل التنفيذ - تحت الخفض.
كم هو .NET في ألفا بشكل عام ولماذا نحن في حاجة إليها
في الآونة الأخيرة ، لقد نمت بشكل ملحوظ من حيث استخدام .NET. إذا لم يكن هناك الكثير من الفروع في Alpha قبل 5 سنوات (بشكل رئيسي في تطبيقات الشركات ، والإقراض لأعمال الشركة ، والاستثمارات ، وما إلى ذلك) ، فقد تعامل ما يقرب من 16-20 شخصًا مع مثل هذا الحمل. والآن يعمل البنك بنشاط على تطوير قطاعات من الشركات الكبيرة والمتوسطة ، والتي أصبحت قوة دافعة جيدة لتطوير أنظمة الائتمان.
وقد واجهنا خيارًا - إما لإعادة كتابة كل هذا في Java ، التي كانت دائمًا وجهة نظرنا القوية ، ولا تزال سائدة في مجال البيع بالتجزئة ، أو الاستمرار في تطوير كل شيء على .NET ، والذي سيتعين علينا تعيين مجموعة من الجهات المانحة والذهاب إلى المقدمة لنفس التقنيات المماثلة للهندسة المعمارية microservice كما هو الحال في جافا.
بالطبع ، تم تهديد مثل هذه الخطوة على الفور ، لأن مخاطر [تطبيق تقنية جديدة تقريبًا. إد.]. ولكن تمكنا من تحمل هذه المخاطر على أنفسنا ، فقد أثبتنا لزملائنا أن .NET يمكن أن يعمل بشكل كافٍ على نفس المجموعات وحلول البنية التحتية التي تشعر جافا بأنها عظيمة. أنا هنا أشير إلى ما يسمى بمجموعة "الجبهة المتحدة" ، أباتشي ميسوس - ماراثون. وبدأنا في اتخاذ القرارات على الخطوط الأمامية ، بما في ذلك القسم الأوسط بالنسبة لهم. بقي الجزء الأمامي كما هو الحال في Java ، بقي الجزء الأوسط في مكان ما في Java ، في مكان ما في .NET.
ونذهب بعيدًا - قبل 5 سنوات ، تعامل 20 شخصًا كحد أقصى مع .NET ، والآن هناك العديد من المهام التي لدينا 75 من الشباب الشجعان ، ونواصل التوسع - الآن نحن نبحث عن
مهندس معماري والمزيد من
المطورين . على الرغم من أن Java لا يزال ما مجموعه أكثر من عام ونصف إلى اثنين ، لأنه يسيطر بشكل ثابت على تجارة التجزئة والشركات الكبيرة. نحن في .NET يتقن في إطار الشركات والإقليم المتوسط ، بالإضافة إلى القنوات الإلكترونية حتى الآن ، بطبيعة الحال.
تحقق - يثبت - تنفيذ
لكي يعمل شيء ما بشكل مستمر ، من الضروري تنفيذ هذا الأمر في عمليات البنك. لتنفيذه بشكل طبيعي ، عليك أن تثبت لجميع المسؤولين أن هذا لن يفسد الوضع الحالي وأن التطبيق سيؤدي إلى حفنة من الإيجابيات.
أصعب شيء كان مع البنية التحتية. كان لدينا مطلب ملموس ملموس منهم - أن كل هذا سوف تتكشف في عامل الميناء وتعمل بشكل طبيعي في لينكس. وهنا تجدر الإشارة إلى أنه لا يوجد حتى الآن. NET Core 2.0 ، ثم لم يكن هناك سوى الإصدار الأول ، الذي لم يكن فيه كل الخير الذي تم إصداره في الإصدار الثاني ، بشكل عام ، اتضح أننا نحن أنفسنا لا نعرف بالضبط أي نوع من الماء تحت الماء قد نواجه جبال جليدية ، لكنهم قالوا إننا سنبذل قصارى جهدنا كما ينبغي. تمكنا من إثبات هذا الأمر لرجال الأعمال من خلال إطلاق البرامج التجريبية الأولى - Alfa-Credit ، وهو تطبيق للإقراض عبر الإنترنت ، وإصدار الشرائح والمزيد.
ثم كان على المؤيدين إثبات جدوى الفكرة. لقد احتاجوا إلى توضيح أنهم أنفسهم لا يحتاجون إلى معرفة .NET لمرافقة حاوياتنا (لسبب ما كانوا متأكدين من العكس). لقد أثبتوا لهم أنه لن يكون هناك أي مشاكل في الأداء ، لقد كنت من أوائل من قاموا بجمع كل هذا على مجموعة - لقد نشرنا الحاوية ، أزلنا مجموعة من المقاييس منها ، وشاهدنا مقدار تحميل وحدة المعالجة المركزية ، مقارنة كل هذا مع Java. لقد حصلنا على شفرة Java في حاوية أصدرت تعليمات لعملاء البيع بالتجزئة. حسنًا ، من أجل نقاء التجربة ، قدمنا الخدمة ذاتها تمامًا ، ولكن على .NET ، حتى نتمكن من مقارنتها بصدق من حيث الأداء وسرعة الاستجابة وتحميل الذاكرة. لقد كتبت اختبارات الإجهاد لكل هذا ، كنتيجة - كل شيء كان يعمل لدينا ، وفي هذه اللحظة تعمل 6 فرق في هذا الوضع.
نحن الآن نتخلص ببطء من Legacy - نلفه في الخدمات ونعيد كتابته وظيفيًا إلى خدمات micros.
. NET Framework VS. NET Framework
سأنبه مرة أخرى إلى أننا قمنا بتنفيذ .NET Core. لذلك ، لا يزال هناك عدد من المشاكل ، بمعنى أن هناك بعض الأشياء الرائعة في .NET Framework ، ولكنها ليست موجودة في .NET Core ، ولا تزال غير موجودة. على سبيل المثال ، خدمات الصابون.
فقط تخيل. أنت بنك ، لديك نظام يستهلك نظامًا آخر. وقد اعتدت على SOAP للاستهلاك ، وليس لديك. عموما. لم نجد تطبيقًا عاديًا واحدًا لخدمات WCF باستخدام SOAP وأشياء مماثلة. ربما بدت سيئة ، كل شيء ممكن. لذلك ، كان لا بد لي من إخراج وكتابة طبقات على .NET Framework القديم.
المجموعة الثانية من أشعل النار هي واجهة برمجة تطبيقات REST. لا توجد مشاكل مع الخدمات الجديدة حيث يتم تنفيذها. وإجبار الخدمات القديمة على استخدام واجهة برمجة تطبيقات REST بدلاً من SOAP هي قصة أخرى ؛ وسيتعين علي إعادة كتابة جميع الأنظمة التابعة الأخرى. ومرة أخرى ، الطبقات ، والبقع ، والعكازات.
وكذلك التواصل مع الطوابير. نحن نستخدم بنشاط IBM MQ في Alpha ، وهو ناقل مؤسسة نموذجي لقوائم انتظار الرسائل. يوجد عميل تحت .NET Framework ، أصلي من IBM. لكن ليس لديهم عميل لـ .NET Core. وعلى حد علمنا ، لم يتم التخطيط لذلك. لا يوجد سوى تطبيق على بروتوكول AMQP المفتوح ، حاولنا التواصل مع قوائم الانتظار بمساعدتها ، ولكن كان هناك عدد من المشاكل أيضًا. الحل؟ نعم ، مرة أخرى الطبقات.
بشكل عام ، كان لدينا تكرار في محاولة لجعل كل هذه الأشياء تعمل بشكل طبيعي من خلال بروتوكول AMQP وليس غبيًا. لكن الرجال من آي بي إم ألغوا اشتراكنا ، كما يقولون ، آسف ، يا شباب ، لكنه أهمل لنا ، حسناً. وأنهم سيستخدمون بروتوكول الملكية فقط لأسباب معينة. بشكل عام ، نجلس الآن ونفكر في كيفية إعادة كل هذا. على الأرجح ، سنكتب عميلنا بدلاً من عميل IBM ، وهذا هو المصدر المفتوح.
الجبهة ، .NET و NodeJS
بالنسبة للجزء الأكبر ، نحن نستخدم React JS للجبهة ؛ إنه يعمل مع العقدة بشكل طبيعي. عندما بدأنا لأول مرة ، كان لدينا عدد من مشاريع MVC القديمة. هناك ، اضطررت إلى إعادة توجيه المقدمة بحيث يكون عرض جانب الخادم طبيعيًا ، من خلال ReactJS.NET.
الآن نحن نتجنب هذا ، قررنا فصل الذباب عن الكستليتات ، في النهاية اتضح أن هناك جبهة منفصلة مع العقدة ، وأن NodeJS يستخدم خدماتنا على واجهة برمجة التطبيقات الباقية في تطبيق الويب. وفي الواقع ، هذا كل شيء. على .NET ، نحن ننفذ بالفعل الوسط. ونحن لا نفعل ذلك على وجه التحديد ، لأنني لاحظت مع .NET و Angular أنه من السهل عدم الفصل بينهما على الإطلاق ، لأننا نسعى جاهدين لتطوير التخصصات في الناس.
إذا كنت تعرف جيدًا الواجهة النقية ، فيمكنك الذهاب بأمان مع فريق java لكتابة الواجهة الأمامية لها. هذا مناسب ، بحيث يمكنك التدفق من فريق إلى فريق. وإذا كنت تعرف مكدسًا كاملاً ، فيمكنك إنشاء تطبيقات شاملة. والخلفية مع .NET ، والوسط ، والجبهة على رد الفعل. هنا لدينا معيار التكنولوجيا الموحدة.
تكامل الهاتف المحمول
ليس لدينا الكثير منه. حيث يوجد ، فهو يستخدم ببساطة خدماتنا على الويب api. نحن لا نكتب تطبيقات المحمول على .NET بأنفسنا ، لم تكن هناك حتى محاولات. تلك الأصلية لا تزال أفضل للقيام به. إذا كنت تستطيع أن تأخذ على الفور والكتابة الأم ، فمن الأفضل أن تأخذ والكتابة على الفور. نعم ، هناك أشياء مفيدة مثل Xamarin من Microsoft ، ولكن هذا أمر منطقي عندما تحتاج إلى بداية سريعة وعالمية. ولكن إذا كان هناك سؤال يتعلق بملاءمة التطبيق لكل منصة ، مع الأداء ، فستظل موجودًا بالفعل وسوف تكتب عادةً باللغة الأصلية. وكان لدينا الأم في البداية.
حول مقاومة الجديد
عندما يكون لديك شركة كبيرة (وحتى مجرد فرق قليلة) ، ستكون دائمًا غير راضي عن إدخال أدوات جديدة. عموما دائما ، وهذا أمر طبيعي. الفنانون الذين يرون هذا ، وهذا كل شيء.
عندما تقدم شيئًا لا يحظى بشعبية كبيرة من الأعلى ، أو شيء لا يحبه المطورين ، سيجد الأشخاص دائمًا مجموعة من الطرق لتخريب العملية ، وحتى يُظهروا في العملية ما أحمق أنت الذي بدأ كل هذا. كان الأمر كذلك عندما قدمنا StyleCop لـ .NET. ولكن مع مرور الوقت ، قبلها الجميع على أي حال ويستخدمها الآن بنشاط. ساعد حجة بسيطة - الإعدادات من StyleCop هي أشياء شائعة جدا. والنتيجة هي جميلة وأكثر أو أقل وضوحا للجميع رمز. على الرغم من أنني لدي شكوك ، إلا أن اثنين من المطورين ما زالوا يشحذون سنًا. بعد كل شيء ، كل شخص لديه معاييره الخاصة ، كل شخص لديه فهمهم الخاص لجمال الكود ، وأي محرر خاص بهم وحيل.
وقد تعرض شيء مماثل للضرب بشكل جيد في سلسلة وادي السيليكون. هناك ، كان لدى الرجال نقاش حول ما يجب استخدامه - علامات تبويب أو مسافات. أنا شخصياً لا أهتم ، ولكن ، كما تظهر الممارسة ، بالنسبة لبعض الناس ، ويمكن أن تكون هذه بداية لصيد السمك.
بالطبع ، إذا كتبت كل شيء في المرئي ، تتم إزالة هذا السؤال بشكل عام.
شخص ما هنا يكتب التعليمات البرمجية في Visual Studio ، في حين أن البعض الآخر لا. عندما تحولنا إلى الكتلة ، اتضح أن هناك عددًا من التقنيات التي لا تعمل تحت Windows. على سبيل المثال ، Ansible. يوجد جزء عميل على Windows ، ولكن لم يعد بالإمكان رفع جزء الخادم. لذلك ، اذهب وانتقِ جهازًا افتراضيًا على Linux ، أو فقط افعل كل شيء على خادم Linux.
بشكل عام ، نحن نعيش هكذا. إذا كان لديك أي أسئلة حول .NET في البنك ، و .NET من حيث المبدأ - الكتابة ، سأكون سعيدًا بالإجابة.