كوردا: كوتلن

عندما ينظر شخص ما إلى كود Corda ، يلاحظ على الفور أنه مكتوب بلغة Kotlin - لغة البرمجة الجديدة من JetBrains ، والتي يمكن تجميعها لـ JVM و Javascript. لقد كان خيارًا غير معتاد ، وفي هذه المقالة ، أود أن أشارك بعض أسباب هذا القرار وتجربة "عامنا مع Kotlin في الإنتاج".

لماذا كوتلن؟

يمكن تقسيم هذا الحل إلى قسمين:

1. أي منصة تستخدم؟ JVM أو .NET أو Node أو Python / Ruby أو Go أو Haskell أو أي شيء تم تجميعه (في رمز الجهاز)؟
2. ما اللغة التي ستستخدمها إذا اخترت JVM؟ جافا؟ إذا لم يكن كذلك ، فلماذا؟ وإذا لم يكن الأمر كذلك ، فماذا أيضًا: Scala أو Ceylon أو Clojure أو Kotlin أو Python أو Ruby أو Javascript أو Haskell (لأنهم جميعًا لديهم تطبيق لـ JVM).

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

في بداية العمل على Corda ، لم يكن للمشروع اسم وكان من الصعب تخيل أنه سيتطور في المستقبل إلى منتج. في الواقع ، عندما بدأ المشروع الذي أصبح كوردا في ديسمبر 2015 (في أول يوم لي في العمل) ، لم تكن هناك خطة لإنشاء نظام محاسبي موزع جديد للشركات. بدأت Corda كمجموعة من النماذج الأولية لاستكشاف الأفكار والمتطلبات الجديدة التي كانت مجموعة عمل هندسة المجموعة مهتمة بها ، خاصة تلك المتعلقة بالرؤية المحدودة للبيانات ونموذج البيانات الذي يوفر قابلية التوسع لـ "مجموعة UTXO من صفائف مخرجات المعاملات" جنبًا إلى جنب مع قابلية برمجة عقود Ethereum الذكية الحتمية بشكل عام.

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

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

لم يتم النظر في الكتابة الديناميكية - إن فوائد الصواب وأدوات التطوير والأداء التي توفرها الكتابة الثابتة أكبر من أن يتم تجاهلها.

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

ونتيجة لذلك ، تركتنا هذه المتطلبات مع Kotlin و Scala و Ceylon. هذه اللغات متشابهة للغاية ومثيرة للاهتمام. لقد اخترنا Kotlin للأسباب التالية:

• تكامل سلس تقريبًا مع Java
  
  • على وجه الخصوص ، تستخدم برامج Kotlin نسخة محسنة (محسنة للمترجم) من مجموعات JDK القياسية ، مما يضمن عدم وجود مشاكل في التكامل بسبب استخدام مكتبات مجموعات أخرى. نحن ننقل ونستقبل المجموعات من وإلى مكتبات جافا في كل مكان ، لذا من المهم ألا يسبب ذلك مشاكل.
  • من فئات Kotlin ، نحصل على واجهة برمجة تطبيقات Java ذات مظهر بسيط مع أساليب get / set / وفقًا للأنواع. لا توجد تعليقات توضيحية أو إجراءات أخرى مطلوبة لهذا الغرض. نظرًا لأن Corda توفر واجهة برمجة تطبيقات مصممة للاستخدام الشفاف من قبل مطوري Java ، فهذه ميزة رائعة: من التعليمات البرمجية العادية ، يمكنك الحصول على واجهة برمجة تطبيقات لا يمكن تمييزها عن Java API مع عدد قليل من التحذيرات (على سبيل المثال ، الاستثناءات المحددة الصريحة من Java تتطلب صراحة طريقة الشرح)
• تضمين وظائف صغيرة مثل map / filter / fold / groupBy (بدلاً من أن يأمل أن يقوم JVM بنفسه) بواسطة المترجم. لسوء الحظ ، فإن المترجم JIT JVM ، على الرغم من كونه ممتازًا بشكل عام ، لا يزيل في جميع الحالات النفقات العامة للاستخدامات الوفيرة لوظائف النظام الأعلى. يعوض استخدام Kotlin هذا ، بالإضافة إلى السماح لك بالتحكم في تنفيذ البرنامج من داخل وظائف لامدا (ملاحظة: على سبيل المثال ، العودة غير المحلية ). هذه واحدة من الميزات غير المعروفة ، ولكن في نفس الوقت ، مفيدة. لأن في كل مكان نكتب فيه كود بأسلوب وظيفي ، فعندئذ إذا تم ترجمته بشكل سيء إلى كود الآلة ، فيمكننا أن نخلق مشاكل في الأداء لأنفسنا.
• نظرًا لحقيقة أن الرمز الموجود على Kotlin يُترجم إلى رمز Java مشابه إلى حد ما ، فإن جميع الأدوات القائمة على Java تعمل تقريبًا خارج الصندوق . هذا ليس صحيحًا دائمًا في حالة اللغات الأخرى. على سبيل المثال ، يواجه Quasar صعوبة في كتابة رمز Scala لأنه يحتاج إلى تعليقات توضيحية للطريقة ، ويترجم Scala lambdas إلى طرق لا يمكن التعليق عليها. عادة ما يتم تضمين Kotlin lambdas (انظر أعلاه) ، أو يمكن وضع تعليقات توضيحية خلاف ذلك.
• وثائق ممتازة ومكتبة قياسية صغيرة تجعل التعلم سريعًا جدًا. لم نوضح في الوظائف الشاغرة لدينا الحاجة إلى الخبرة في Kotlin ، وقمنا بتوظيف أشخاص دون علمه بعد مرور 1-3 سنوات ، وبعدها تمكن عضو جديد من الفريق من كتابة رمز اصطلاحي.
• بناءً على اختيار المرشحين الذين أجروا مقابلات معنا ، فإن IntelliJ هي IDE الأكثر شعبية (كان لديهم اختيار مجاني للأدوات). من بين لغات ما بعد Java ، يدعم IntelliJ Kotlin على أفضل وجه.
• لقد كان لدي بالفعل تجربة مرضية معه ، وبالتالي ، كنت على يقين من أن زملائه الجدد سيحبونه أيضًا.

إذا لم يكن لـ Kotlin ، فربما اخترنا Scala: Kotlin مستوحاة إلى حد كبير منه وكلاهما لغتان جيدتان.

سنتنا مع Kotlin

كيف يبدو الأمر - عام للعمل بلغة جديدة في سياق تطبيق مؤسسي؟

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

فيما يلي بعض المشاكل التي غالبًا ما تظهر في بيئة تطوير المؤسسة بعد Java / C # التي واجهناها نحن أنفسنا:

• يبدو الرمز مختلفًا اعتمادًا على من كتبه. بشكل عام ، ليست مشكلة كبيرة. على عكس Go ، الذي يتطلب نمطًا معينًا من التصميم ، قد يبدو رمز Kotlin للمؤلفين المختلفين مختلفًا. لكن IntelliJ لديه أداة تنسيق توفر نمطًا أساسيًا لتعليمات برمجية موحدة. إنها محدودة أكثر من Java ، لكن هذا يكفي. هناك مشكلة أكثر دقة ، خاصة مع رمز Scala ، هي معارضة نمط ترميز Java-OOP و Haskell-FI. قد يكون من الصعب قراءة كود سكالا الذي يستخدم مكتبات مثل سكالاز للمطورين الذين يتوقعون رؤية جافا محسنة . في هذا النقاش ، Kotlin بقوة إلى جانب Java المحسنة . وعلى الرغم من البرمجة الوظيفية ، بطريقة معينة ، ربما في Kotlin ، فإن المجتمع (على الأقل في الوقت الحالي) لم ينقسم إلى مخيمات. كانت لدينا حالات عندما تم كتابة الشفرة كما لو كانت هاسكل ، ولكن تم العمل على مراجعة التشفير.
• مكتبات في Corda نستخدم أكثر من 50 مكتبة مفتوحة المصدر ولم تكن هناك أي مشاكل مع أي منها. لم نكتب أبداً أغلفة أو طبقات من المحولات. نظرًا لأن أنظمة البناء في المشاريع على Kotlin أو Maven أو Gradle تُستخدم عادةً - لا يوجد بديل رسمي خاص بـ Kotlin لهذه الأدوات (على الرغم من أن Gradle قد قدم دعم Kotlin كلغة برمجة نصية جديدة!).
• DSL و SQL. تحتوي C # على LINQ و Java على JOOQ و Kotlin مكشوف . هذه واحدة من المجالات التي تكون فيها Kotlin أضعف إلى حد ما من منافسيها - Exposed هو مثال رائع على استخدام قدرات Kotlin لبناء DSL ، لكن المكتبة نفسها لديها واجهة برمجة تطبيقات غير مستقرة وهي مشروع ثانوي. بالطبع ، يمكن استخدام JOOQ مع Kotlin ، وبالنظر إلى الوراء ، يبدو أن هذا هو الخيار المفضل.
• IDE / مجموعة الأدوات. البرنامج المساعد Kotlin لـ IntelliJ ، بالطبع ، مكتوب بواسطة JetBrains ، وبشكل عام ، رائع. ومع ذلك ، فهي أقل تعقيدًا عند مقارنتها بدعم Java. يجب أن يتم نقل ميزات المحرر الجديدة ، مثل تلميح المعلمة ، يدويًا إلى Kotlin ، ويتخلف الدعم نفسه ، على هذا النحو ، عن المكونات الإضافية Java القديمة. لاحظنا أيضًا أن المكوِّن الإضافي IDE غالبًا ما يخطر بالأخطاء الداخلية ، على الرغم من انخفاض تكرار استثناءات IDE بشكل ملحوظ خلال العام (ويبدو أنها لا تؤثر على أي شيء). استخدام أدوات أخرى أيضا لا يسبب مشاكل ، لأنه ما هو مكتوب لجافا يعمل عادة من خارج منطقة الجزاء . الاستثناء هو الأدوات التي تعمل مع شفرة المصدر بدلاً من رمز البايت ، والتي ، من الواضح ، لا يمكن إعادة استخدامها. مع كل هذا ، لم يتم تصحيح برنامج التحويل البرمجي Kotlin والمكون الإضافي IDE كما هو الحال في حالة Java ، حتى بعد عام من إصدار 1.0. على الأرجح لن تواجه أبدًا أخطاء داخلية في javac ، ولكن على الرغم من أنه نادرًا جدًا ما زلنا نراها في كوتلن.
• اعتراف المستخدمين. غالبًا ما يكون مستخدمو Corda مؤسسات مالية كبيرة ومحافظة. تفضل هذه الشركات استخدام اللغات الشائعة الراسخة. من الواضح أن كوتلن ، كونه ليس أحدهما أو الآخر ، تسبب في بعض المفاجأة في الوقت الذي بدأنا فيه. "لماذا كوتلن؟" - هذا سؤال اختفى عمليا خلال العام الماضي ، لأنه ألقى الناس نظرة فاحصة وأدركوا أن هذا ليس خطرًا كما هو الحال عادةً مع لغات البرمجة الجديدة. لقد حاولنا أيضًا تسهيل التبني من خلال تقديم أمثلة برمجية توضح أن بناء التطبيقات باستخدام النظام الأساسي لا يتطلب معرفة Kotlin. لم تكن نتائج هذا ناجحة للغاية - لا يزال العديد من المطورين الذين يعملون لأول مرة مع Corda يبدأون باستكشاف Kotlin. ليس من الواضح تمامًا ما إذا كان هذا نتيجة لحقيقة أننا لم نقدم أمثلة ووثائق استخدام موجهة نحو Java بشكل كاف ، أم أن هذا مجرد عذر جيد لتعلم أداة رائعة جديدة. لقد ساعدنا أيضًا الاعتماد المتزايد لـ Kotlin داخل البنوك الاستثمارية الكبرى. على مدار العام الماضي ، سمعنا من العديد من أعضاء الكونسورتيوم أن فرق التطوير الداخلي الخاصة بهم بدأت في النظر بجدية إلى Kotlin لمنتجاتها الخاصة: غالبًا ما يكون ذلك مدفوعًا بتوافر الأدوات التي تحول Java إلى Kotlin ، والتي توفر اندماجًا أقل إيلاما إلى حد كبير في قاعدة التعليمات البرمجية الحالية.
• الدعم التجاري. يتمثل خطر استخدام لغات غير معروفة في أنها قد تتوقف عن التطور ، أو لديها أهداف لا تتوافق مع الاحتياجات التي تم تشكيلها حول المنتج ، ومجتمع المستخدمين (على سبيل المثال ، في حالة لغات البحث ، فإن الهدف الرئيسي للمطورين هو إنشاء مقالات علمية). السبب الرئيسي الذي يجعلنا نشعر بالثقة مع Kotlin هو أن JetBrains هي شركة مستقرة ومربحة في السوق منذ أكثر من 15 عامًا. بدأ JetBrains بسرعة في تذوق أداتهم الخاصة من خلال إدخال Kotlin في رمز المنتجات الرئيسية. وبالتالي ، فإن خطر إنهاء الدعم صغير نوعًا ما. بالإضافة إلى ذلك ، تعد JetBrains بالفعل شركة في منتصف العمر ، ولم يعد السوق المستهدف (IDE وأدوات المطور) جديدًا أو عصريًا بشكل خاص ، مما يقلل من خطر الاستحواذ المحتمل على الشركة ، مما قد يؤدي إلى تغييرات استراتيجية غير متوقعة. وعلى الرغم من عدم وجود حزمة دعم تجاري لـ Kotlin ، إلا أن الفريق يقوم عمليًا بإصلاح المشكلات المعروفة بسرعة. في الوقت الحالي ، تعتزم JetBrains إصدار تحديث اللغة التالي بعد عام منذ الإصدار 1.0. تشبه دورة الإصدار هذه تمامًا دورة التطوير في بيئة الشركة.

الاستنتاجات؟

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