ميخائيل ماتروسوف ( mmatrosov ) هو مهندس تطوير رائد في مكتب موسكو للبحث والتطوير في Align Technology. تخصصه غير عادي للغاية - يقوم بتطوير نظام CAD متخصص لتصميم أجهزة تقويم الأسنان.
شارك ميخائيل في مؤتمر C ++ Russia منذ المؤتمر الأول. هذا العام ، في C ++ Russia 2019 Piter ، سيقدم عرضًا تقديميًا عن "التصفيات ، التصفيات والقوالب" . يمكنك أيضًا معرفته في الدورات التدريبية من Yandex "أساسيات تطوير C ++: الحزام البني" و "أساسيات تطوير C ++: الحزام الأسود" في كورسيرا ، والتي شارك مايكل في تأليفها.
كان المؤتمر قاب قوسين أو أدنى من الآن ، ولكن في الوقت الحالي ، أجرى مقابلة مع ميخائيل ، حيث ناقشنا عمله في Align Technology ، وترحيل الكود القديم ، وإعداد الدورات والتقارير عبر الإنترنت ، بالإضافة إلى ميزات C ++. تم طرح الأسئلة من قِبل بافيل فيلونوف (لجنة برنامج سي + + روسيا) وأوليج تشيروخين (صحفي في مجموعة JUG Ru).
عند تقاطع التكنولوجيا والطب
بافيل: أخبرني ماذا تفعل شركتك.
مايكل: Align Technology هي شركة رائدة ورائدة في مجال تقويم الأسنان النظيف. هذا شيء يجري القيام به في جميع أنحاء العالم الآن بدلاً من الأقواس. إذا كان في وقت سابق ، تم وضع سلك معدني لاستقامة الأسنان ، وأنها ركضت معها ، والآن بدلاً من ذلك وضعت حراس فم بلاستيكية شفافة (بطانات) ، والتي يتم تصنيعها بشكل فردي لكل مريض. لقد اختبرت مؤخرًا منتجات شركتنا بشعور مضحك للغاية!
بافيل: إذن لديك مثل هذا الطعام ، نعم ، اتضح؟
مايكل: نعم ، نوعا ما. في الواقع ، إذا كنت لا تعرف ذلك ، فمن الصعب للغاية ملاحظة أن الشخص موجود في الخطوط. لا تظهر عيوب الكلام الصغيرة إلا في البداية ، لكن يصعب حتى ملاحظة ذلك.
بافيل: وما علاقة C ++ به ، والتي سنتحدث عنها كثيرًا اليوم؟
مايكل: سؤال رائع. عندما كانت الشركة في مهدها ، أخذ باكستانيان بهيجان بعض المواد البلاستيكية الخاصة (لا أعرف من أين وجدوا) ، والتي يجب أن تكون غير سامة وخاملة مع اللعاب ومواد أخرى في الفم.
ثم أخذوا نموذجًا لفك المريض ، وكانوا يعرفون كيفية القيام به لفترة طويلة جدًا. على سبيل المثال ، لصنع تيجان ، أعطيت شخص لدغة شيء مثل البلاستيسين خاص. كان هناك مجموعة من الأسنان التي كانت مليئة بالمواد. حتى أنهم حصلوا على نسخة من الفك ، وقاموا بسحبها من البلاستيك (بطريقة ما قاموا بتسخينها) ، وكانت الناطقة بلسان جاهزة. وهذا هو ، كان هذا السوق بأكمله حرفيا قبل 20 عاما التناظرية تماما.
الآن يبلغ حجم الإنتاج في المنطقة 300-400 ألف خط يوميًا (يرجى تقييم المقياس). هذه هي المصنوعات العملاقة ، وبالتالي فهي مؤتمتة بالكامل.
لإنشاء بطانة ، نطبع على قالب طابعة ثلاثي الأبعاد خاص. هذه ، في الواقع ، نسخة من فك المريض أثناء العلاج. نحن نمثل كيف سيبدو الفك خلال أسبوع أو اثنين أو شهر أو سنة. ثم نبدأ عملية التشكيل الحراري - نأخذ شريطًا بلاستيكيًا ونسخّنه ونسحبه على القالب. قطع والحصول على بطانة بلاستيكية.
في الوقت الحالي ، لا يوجد أحد يلقي المرضى بالفعل ويستخدمون ماسحات ضوئية ثلاثية الأبعاد. لدينا رجال يفعلون ذلك في مكتب قريب. ربما هذا هو الجزء الأكثر نجاحا في إنتاجنا. هناك ، في الوقت الحقيقي ، فوهة خاصة تقود على طول الفك وتبني شكلها. يتم تحميل المعلومات إلى خوادم الشركة ومعالجتها وإرسالها إلى المتخصصين لدينا (الفنيين). يمكنهم تحرير المسح ، وإزالة الضوضاء.
ثم يتم التخطيط للعلاج في نظام CAD متخصص. هذا شيء معقد للغاية ، لأنه لا أحد يعرف ماهية اللدغة الصحيحة. كل طبيب لديه وجهة نظره الخاصة في هذا الشأن. نحن نعمل حاليًا على إضفاء الطابع الرسمي على النهج العلاجية ، ولكن هذا لم يحدث بعد.
لكن العودة إلى C ++. هناك مثل هذه المشكلة ، على سبيل المثال. تتم طباعة القوالب على طابعة ثلاثية الأبعاد خاصة باستخدام تقنية الطباعة المجسمة بالليزر. هناك ضريبة كبيرة مع سائل فوتوبوليمير خاص. يلمعونها بالليزر ويصلب. أولاً ، يلمعون في أسفل النموذج المطبوع ، ثم أعلى قليلاً ، أو أعلى ، إلخ. وهكذا ، داخل السائل ، يظهر نموذج صلب من أسفل إلى أعلى في طبقات.
طباعة قالب واحد تلو الآخر سيكون غير عملي. الضريبة كبيرة جدًا ويمكنك وضع حوالي مائة قالب فيها. ولكن يجب أن يتم ترتيبها بشكل مضغوط. يشبه شكل القالب حدوة الحصان - وهذا غير محدب ومعقد إلى حد ما. وكلهم مختلفون. اتضح مهمة مثيرة للاهتمام من تبليط مستطيل مع شخصيات معقدة.
هنا في هذا الفيديو من الطابع الزمني المحدد يمكنك أن ترى كيف يبدو.
هذا مجرد مثال واحد ، هناك الكثير من المهام.
بافل: وصفك يشبه الحسابات ذات التقنية العالية. اللغات مثل فورتران قد أدت تاريخيا بشكل جيد فيها. على الأقل لا يزال بإمكانك رؤية الأصداء. لماذا بالضبط C ++؟
مايكل: حسنًا ، ليس فورتران ، سيكون قويًا جدًا. في بداية التطوير ، كان المنتج الرئيسي هو نظام CAD المتخصص للغاية - تطبيق سطح مكتب لنظام Windows. لذلك ، كانت هناك حاجة إلى لغة من أجل الحوسبة الفعالة وفي الوقت نفسه لتطوير التطبيق نفسه. لم يكن هناك الكثير من الخيارات في ذلك الوقت - فقط C ++.
لدينا الآن مجموعة من اللغات: JavaScript و TypeScript للويب ، و Java لتطبيقات الأجهزة المحمولة ، و Go for Servers ، و Python للأتمتة ، وهناك الكثير من الأشياء الصغيرة. في الأساس ، كومة قياسية. وفي التطبيقات التي تتطلب الكثير من العلوم والمعقدة حسابيًا ، تظل C ++.
كلما كان الموقف أعلى ، كانت الآفاق أوسع.
بافيل: لقد ذكرت موقفك كمهندس رئيسي. وهكذا لاحظت مثل هذا الغرابة. إذا سئل أحد مطوري C ++ المبتدئين من شركتك عما كان يفعله ، فسيقول إنه كان يدور نوعًا ما من الإطار الفائق استنادًا إلى القوالب التي تعتمد على تعزيز الخادم وتوازن الخادم ، وستتراجع التقنيات فورًا.
عندما تُسأل عما تفعله شركتك ، تبدأ القصة بأكملها حول العمل: أين هو المال ، ولماذا هو مهم ، إلخ. هل هذا يرتبط بطريقة ما بموقفك؟ ما هي وجهة النظر هذه من العمليات والتقنيات والأدوات؟
مايكل: نعم ، ربما. لكن بالإضافة إلى ذلك ، إذا بدأتُ على الفور في الحديث عن كيفية عبور الأشجار (رغم أنني لا أفعل ذلك بنفسي) ، فلن يكون الأمر واضحًا للجميع. على سبيل المثال ، يمكن أن تبدأ Kaspersky Lab بالتكنولوجيا لأن الرجال يعرفون منتجاتهم. نحن نتحدث عن المتشددين ، والتي يعرف عنها عدد قليل من الناس. لذلك ، من الضروري شرح ما هو عليه.
فيما يتعلق بكيفية ارتباط هذا المنشور. في تقديري ، يجب أن أفهم على الأقل عناصر سير العمل الخاص بنا للأنظمة الحالية التي تعمل معًا. بعد كل شيء ، إذا تغير شيء ما ، فإن هذا يمكن أن يؤثر على الإنتاج وموقع الأطباء والواجهة التي يتفاعل معها الفنيون والأطباء ومحللو الأعمال. هذا هو ، نعم ، هناك علاقة. مع نمو الصف ، تحتاج إلى رؤية أفضل لما يحدث في الشركة.
بافيل: هل فكرت كيف سيؤثر إدخال تقنيات جديدة ، مثل تلك المتعلقة بـ C ++ ، على سير العمل؟ قليل من الناس ينظرون إلى ميزات جديدة للغة. وإذا لم يكن الأمر كذلك ، فأخبرنا عن كيفية قيامك بتنفيذ الأدوات مؤخرًا؟
مايكل: لا أتذكر أمر C ++ المفاجئ. إذا أخذنا الأدوات ، فإن آخر شيء قمنا به هو نظام تسجيل يستند إلى مجموعة النظراء. نحن نستخدم خصيصا Splunk لهذا الغرض. في البداية ، كانت المنصة تحت سطح المكتب ، وأصبحت الهجرة إلى السحابة على قدم وساق. لذلك ، نحن نربط ، على وجه الخصوص ، التسجيل القائم على السحابة. تعلم مديرنا بسرعة تقديم طلبات وإنشاء لوحات معلومات جميلة ، وعرض مخططات في الوقت الفعلي. كنت سعيدا جدا. لقد أرسلتها إلى الجميع وقلت ، انظر كيف نغير وقت تشغيل مثل هذه الخوارزمية المعقدة ، ما هو السبب؟ بدأوا يفهمون ، أدركنا أنه ليس لدينا تقريبًا أي مؤشرات ترابط على وكلاء الاختبار. يجري باستمرار تقديم شيء ما.
C ++ ، وراثي ، عبر منصة وكل شيء ، كل شيء ، كل شيء
أوليغ: هل أفهم بشكل صحيح أنه لديك عرض في المستعرض؟
مايكل: نعم ، هناك.
أوليغ: تقنيات المتصفح تتغير باستمرار. هل يؤثر بطريقة ما؟ على سبيل المثال ، JS الجديدة ، لغة التظليل ، شيء من هذا القبيل.
مايكل: إنه يؤثر ، لكنه ممل بعض الشيء هنا. من حيث التقديم ، المشهد بسيط للغاية. ليس لدينا أي مؤثرات خاصة لا تصدق.
بافل: جيد. لكنك قلت إنك بدأت باستخدام أحد تطبيقات سطح المكتب ، حيث كان C ++ هو أفضل حل يجمع كل المزايا. عندما بدأت الأعمال تنمو مع المنتج ، بدأت في تطوير منصات أخرى. ذهبت بعض الرموز إلى المتصفح ، وبعضها إلى الواجهة الخلفية ، وبعضها إلى الهواتف المحمولة. هل بقي جوهر "إيجابي" على جميع المنصات؟
مايكل: بدأت الحركة إلى المنصات الأخرى منذ عامين ، ولحجمنا هذا وقت قصير. لذلك ، كان الحل السحابي الأول الخاص بنا عبارة عن مجموعة متجانسة من سطح المكتب ، تم طرح واجهة المستخدم الرسومية بها تقريبًا. منذ عام ونصف تقريبًا ، عزلنا النواة الشرطية والربط المحيط بها ، لذلك تمكنا من تجميعها وتشغيلها بالفعل في نظام Linux. لقد كان إنجازا كبيرا. كان نظام Linux مهمًا في المقام الأول نظرًا لأن أجهزة Linux السحابية أرخص بكثير.
الآن نريد فصل جوهر الحوسبة في C ++ ، حيث ستجري جميع العمليات الحسابية المعقدة ، من منطق العمل الذي يصف ما يجب القيام به وبأي ترتيب ، ومن أين جاءت القضية ، ونوع المنتج ، وما يحق للطبيب القيام به وما لا ، و هذا كل شيء.
بافيل: ربما لديك بالفعل خريطة طريق لهذه العملية ، لأنك تتحدث جيدًا عنها.
مايكل: حاولنا عدة مرات إنشاء خارطة طريق. نحن نتفهم حيث يبدو أننا قادرون على التحرك ، مع مراعاة 20 عامًا من Legacy (لا يمكنك الوصول إلى هناك بنصف دولار ، ما عليك سوى التفكير في الأمر).
يتم الآن التفاعل بين المشروعات الإيجابية بطريقة بسيطة. من بين هذه ، فإن واجهات C ++ هي التي تلتزم بها ، لذلك يجتمعون فقط للتأكد من وجود مترجم واحد. ما مجموعه حوالي 250 مشروعًا ، يذهب كل منها إلى مكتبته الديناميكية الخاصة به. ونجمعها بطرق مختلفة لأداء مهام محددة.
حوالي 10 فرق تعمل على النظام. يقوم كل فريق بتوظيف مجموعة فرعية من هذه المشروعات ، عادةً ما يتراوح بين 50 و 70. الآن نحن نتحرك في اتجاه أن يتم إنشاء بعض الخدمات على أساسها. نحدد واجهة برمجة تطبيقات صارمة للخدمة (استنادًا إلى protobuf أو أي شيء آخر) ، ونقوم بوضع مخطط قياسي للتفاعل بين الخدمات. من الصعب تسمية العملية بالفصل بين الحساب والمنطق ، ولكن هذه هي المحاولات الأولى للتكوين.
لقد بدأ فريقي وعدة أشخاص آخرين فعل ذلك. تشعر على الفور كم هو أكثر تسلية عندما تقوم بتجميع مجموعة من 250 مشروعًا فقط ، ولكن فقط من 70 مشروعًا. ولم يعد هناك موقف حيث قام شخص ما بتغيير وحدة نمطية أخرى تتفاعل مع أشياء تبدو غير مرتبطة تمامًا ، وكسر شيء ما . لها تأثير نفسي بارد. وفي الوقت الذي نحاول فيه الابتعاد عن متراصة سطح المكتب الصحي عن طريق تخصيص 10 متراصة صغيرة مشروطة لخدماتنا.
بافيل: وخلال هذه العملية لم تفكر فيما إذا كانت الوحدات التي على وشك أن يتم تحميلها في شكل ما يمكن أن تساعده في أي من المستويات؟
مايكل: كانت هذه العملية وعملية ترحيل Linux هي التي ساعدتنا كونان . واجهنا مشكلة خطيرة في إدارة الطرف الثالث. تحدثت عن كيف استخدمنا كونان في C ++ Russia 2019 في موسكو.
تساعد الوحدات النمطية "plus" في حل بعض المشكلات مع وقت التحويل البرمجي ، حيث بدأ كل شيء في الواقع ، لماذا يريد الجميع الوحدات النمطية. يعد إعادة استخدام الوحدات الإيجابية للتفاعل مع الخدمة أمرًا أحمقًا ، لأنها ستتواصل على مستوى غير ملائم للغة (protobuf) ، وهي محقة في ذلك. ربما سنكون قادرين على تنفيذ عمليات التهيئة وعدم بناء 250 مشروعًا من المصدر في كل مرة ، لكننا نضعها في حزم كونان. وإذا كان ، على سبيل المثال ، dlls القابلة للطي غير مريح لأسباب معينة ، فإن التجميع في الوحدات النمطية يعد خيارًا.
لكن لا يمكنني القول إننا ننتظر بعض الميزات التي ستغير نهجنا في التنمية.
بافيل: لقد ذكرت أن كونان يساعدك في حل مشاكل إدارة الحزمة. في رأيي ، منذ حوالي 3 سنوات ، تحدث مجتمع C ++ عن هذا فقط. ظهرت التقارير الأولى ، أول الشروط المسبقة. والآن تقول أنه يعمل بالفعل في الإنتاج.
أخبرنا عن تجربتك في تطوير المشروع. هل كانت العملية الانتقالية مؤلمة وتستحقها؟
مايكل: بالتأكيد يستحق كل هذا العناء. نحن راضون عن كونان. هناك بعض العيوب ، ولكن إدارة التبعيات في C ++ مهمة صعبة للغاية. لذلك ، من الواضح أنه لن تكون هناك أداة بسيطة لحلها.
مع كونان والعملية على ذلك ، حققنا توازن المهمة وتعقيد الحل. قلنا في البداية: "حسنًا ، نريد تسليط الضوء على مثل هذه المجموعات والعديد من المترجمات والتكوينات ، ثم بناء مكتبات ديناميكية (بدلاً من المكتبات الثابتة) بشكل افتراضي ، ووضع مجموعة صغيرة من القيود" ، وبدأنا في بناء نظام ضمن هذه المجموعة من القيود. لدينا صفحة ويكي "كيفية إنشاء وصفة كونان لمكتبة" ، والتي تأخذ في الاعتبار جميع تفاصيل نظامنا. الصفحة كبيرة جدًا وليست بسيطة جدًا. لكن ، مرة أخرى ، وصلنا إلى توازن التعقيد ، لذلك أنا سعيد بالانتقال.
بافيل: وهنا ، بالمناسبة ، في C ++ Russia 2019 Piter ، سيتحدث Denis Panin من NVIDIA عن البديل الذي يمثله vcpkg . هل سيكون من المثير بالنسبة لك أن تذهب إلى التقرير وتستمع إلى كيفية عملها في أدوات أخرى؟
مايكل: نعم ، سيكون من المثير للاهتمام. لقد استخدمت vcpkg قليلاً ، ولكن ، في رأيي ، هناك القليل جدًا من المرونة في vcpkg. ولا أستطيع أن أتخيل كيف يمكننا بناء نظام مع متطلباتنا على أساس vcpkg. ولكن إذا كنت بحاجة إلى أخذ مكتبة من نوع ما واختبارها بسرعة ، فلن أقوم بتنزيلها وقراءة تعليمات البناء ، التي تحتاج إلى تحديد كيفية تسجيل التبعيات ، فهذه كلها سلة مهملات. سوف نرى ما إذا كان في منافذ vcpkg. إذا كان هناك ، ثم وضعه بسرعة ، وتجربته. إذا كان كل شيء على ما يرام ، فسوف أكتب وصفة كونان لها.
بافيل: دعنا نستمر في إدخال أدوات وأساليب جديدة. هل واجهت حقيقة أن المهندسين يركضون بعيون مشتعلة من المؤتمر ، حيث قيل لهم عن شيء جديد رائع ، ويريدون إدراجه في المشروع؟ كيف تتفاعل عادة مع مثل هذه الأشياء؟ أو هكذا تلجأ بعد كل مؤتمر؟
مايكل: هناك مجرد قصة رائعة. عندما بدأت للتو العمل في الشركة ، كتبوا ميزة ، وكان من الضروري إجراء تكوين لها. علاوة على ذلك ، يمكن أن تحتوي الميزة على عدة إصدارات مختلفة ، ويمكن البحث عن قيم الخصائص المحددة بين إصدارات مختلفة. وقد توصلت إلى مخطط رائع قائم على YAML حيث كان هناك وراثة وإعادة تعريف الممتلكات. لقد كتبه لمدة أسبوع تقريبا ، وغطاه بالاختبارات. وفي البداية ، جاء إلي المدير وقال لي: "اسمع يا مايكل ، ربما لا تحتاج إلى إضاعة الوقت الآن وجعل مثل هذا المخطط مرنًا؟" لكنه لم يستطع إقناعي. كانت عيني محترقة للغاية.
بعد بضع سنوات ، أنظر إلى هذا الرمز ولا أفهم لماذا كان من الصعب للغاية القيام به. يحدث هذا ، لكن لحسن الحظ ، أصبحت أكثر ذكاءً منذ ذلك الحين. بالإضافة إلى ذلك ، عادة ما يكون المطورون أشخاصًا عقلانيين جدًا ، يمكنك التحدث إليهم.
كان من المعتاد أن يقوم شخص ما بقرارات طرف ثالث مشكوك فيها. لم يكن من الواضح من الذي قاموا بتطويره ، وكان آخر تحديث قبل 5 سنوات ، ولم يتم التحقق مما إذا كان يعمل في نظام Linux ، ويقومون بإنشاء أي تقارير بتنسيق خاص لا يمكنك تحويله إلى أي شيء. ونحن نجلس ولا نفهم ماذا نفعل بعد ذلك. تمت إضافة معظم هذه الأطراف الخارجية منذ سنوات عديدة ، ولكن يحدث أن يحدث شيء مشابه الآن.
لذلك ، توصلنا إلى شيء بسيط إلى حد ما - قائمة مراجعة لجهة خارجية. إذا كنت ترغب في سحب جهة خارجية ، فما عليك سوى الاطلاع على عناصر قائمة التحقق: النظام الأساسي ، ومستوى الدعم ، والترخيص ، الذي يماثل النظير ، ومستوى دعم التنمية (عدد الدعم الذي يدعمه أي مجتمع ، أو أي مجتمع). جميع النقاط واضحة ، ولكن هناك الكثير منها ، وعندما تكتب جهة خارجية ، لن تتذكر كل شيء على الفور. أصبح الوضع أفضل ، ونحن نراقب ما يتم إضافته.
من الرائع أيضًا أن يكون من السهل سحب جهة خارجية وتجميعها ، على سبيل المثال ، فقط في إصدار تحت Windows و 32 بت. الآن ، من حيث المبدأ ، لا يوجد مثل هذا الاحتمال ، حيث يجب عليك وضعه في كونان. وإذا سحبت طرفًا ثالثًا ، فسيتعين عليك التأكد أو الإشارة صراحة إلى أنه في بعض التهيئة لن يتم ذلك. بفضل هذا ، بدأت إضافة الجهة الخارجية اليسرى أقل من ذلك بكثير.
أوليغ: وماذا عن الطرف الثالث ، الذي يعيش القليل جدًا؟ على سبيل المثال ، بعض لوحة اليسار من JavaScript. يذهب في قائمة المراجعة الخاصة بك. غالبًا ما يتم تحديثه وصيانته بواسطة حزم.
مايكل: لا يوجد شيء من هذا القبيل. في C ++ ، يكون الطرف الثالث عادةً أمرًا سميكًا. ولا يتم استخدام حلول الجهات الخارجية التي تؤدي وظائف صغيرة. في الواقع ، في C ++ ، ليس من السهل إضافة جهة خارجية. وهذا ليس JS ، حيث لكل واحد وحدة خاصة به.
لقد سحبنا بشكل مشروط 80 طرف ثالث ، نصفه لم أره من قبل. أو نوعًا من الهندسة الجهنمية التي كتبت قبل 15 عامًا في بعض الجامعات ، ونحن لدينا.
أوليغ: مع كونان ، من السهل إضافة طرف ثالث.
مايكل: كونان أسهل ، لكن لا يزال بعيدًا عن نفس بايثون حيث تكتب تثبيت النقطة وتنتهي. يحتوي C ++ على نظام بيئي معقد للغاية: أنظمة تشغيل مختلفة ، مترجمين ، سلسلة أدوات ، مكتبات ، معايير. تحتوي معظم المكتبات على مجموعة من الخيارات.
يحلو لهم أن يسألونا: "لماذا تكتبون وصفات مكتبتك ، ولكن لا تأخذونها من مركز كونان؟" نظرت بشكل دوري من الوصفات ، لكنها لا تناسبنا. نحن نفعل ما هو أفضل. على سبيل المثال ، تتولى الوصفات الخاصة بنا العناية برموز الخصم ، وإضافة ارتباط إلى المصادر الموجودة بها. لذلك عندما تحصل على مكتبة خارجية من مصحح الأخطاء من Visual Studio ، يتم تحميل المصادر تلقائيًا.
لذلك مع كونان هو أفضل بكثير ، ولكن لا يزال بعيدا عن راحة اللغات الأخرى.
أوليغ: هل هناك أي عيوب في كونان نفسها أود تصحيحها؟
مايكل: نعم ، هناك عيوب ، لكنها تقنية.
لدى Conan أساليب مسؤولة بشكل مشروط عن إنشاء الحزم وتوصيل الحزم التي تم إنشاؤها بحلك. من الناحية الأيديولوجية ، هذه مرحلتان مختلفتان ، ويمكنني تغيير أحدهما دون تغيير الآخر. عندما أقوم بتغيير طريقة اتصال الحزم ، لا أرغب في إعادة إنشاء الحزم الثنائية ، لأنها ستكون هي نفسها تمامًا. لا يمكنك القيام بذلك في كونان ، لأن الوصفة هي كيان واحد. إذا قمت بتغيير الوصفة ، فعليك رسميًا تغيير الإصدار وإنشاء ثنائيات جديدة ، وهو أمر غير مريح.
ميزات الانتقال إلى معايير جديدة
بافيل: دعنا نتحدث عن معايير جديدة. بالإضافة إلى ذلك ، منتجك لديه بالفعل بعض التاريخ.
نأتي الآن إلى المؤتمر ، حيث يخبروننا كل ثلاث سنوات عن ميزات رائعة جديدة. على سبيل المثال ، في C ++ Russia 2019 Piter ، سيكون هناك ثلاثة تقارير حول التغييرات القادمة في اللغة. هل لديك أي خبرة في ترحيل قاعدة الشفرة القديمة ، والتي تتوافق مع المعايير القديمة ، إلى ما تم تقديمه أو سيتم تقديمه؟
ميخائيل: نعم ، كانت لدي تجربة من هذا القبيل ، وتحدثت قليلاً عنها في C ++ Russia 2019. كان لدينا هجرة من Visual Studio 2013 إلى Visual Studio 2017 و gcc ، أي أضفنا دعم Linux ومترجمين محدثين من Microsoft في وقت واحد.
كانت المشكلات في التعليمات البرمجية أقل بكثير بالمقارنة مع المشكلات التنظيمية والفنية والبنية التحتية و CI وبقية التوليف. وكانت مشاكلنا في الكود مرتبطة في المقام الأول بـ UB ، والتي بدأت بعد إطلاق المترجم في إطلاق النار. على الرغم من انتشار C ++ تعفن لسنوات من التوافق مع الإصدارات السابقة ، لكنه يساعد. نحن الآن نجمع كل شيء تحت C ++ 17.
لا تتم مزامنة Vorings عندما يجمع المطورين تحت Windows ، ويدخلون إلى CI وفقط بعد ذلك يبدأون في التجمع تحت Linux. ولكن لم تكن هناك مشاكل كبيرة.
في الإصدار C ++ 17 ، تمت إزالة بعض الأشياء القديمة ، لكننا أمضينا بضع ساعات فقط في التخلص منها. على سبيل المثال ، استخدمت مكتبة log4cplus std :: auto_ptr في الرؤوس ، ولكن في الإصدارات الجديدة تم استبدالها بالفعل بـ std :: unique_ptr ، لذلك كان يكفي تحديث المكتبة ببساطة.
لذلك كانت الهجرة إلى المعيار الجديد غير مؤلمة نسبيا. ونظراً لحجم قاعدة الكود الخاصة بنا ، فقد فوجئت بعدد المشاكل التي واجهناها.
حول الحزام البني والأسود في C ++
بافيل: أنت وأنا نتحدث بالفعل عن العمليات الحالية ، حيث يعمل المطورون ذوو الخبرة بالفعل. دعنا نوفر طعامًا للمطورين المبتدئين الذين يتعلمون فقط. ما هو معيار C ++ الذي تنصحون به بداية؟
مايكل: يجب أن نأخذ أحدث المعايير على الفور. لن تتعلم لغة STL بنفس C ++ 98 ، حيث أن STL بدون lambdas لا معنى له. إذا نظرت إلى الدورات التدريبية "أساسيات التنمية في C ++: الحزام البني" و "أساسيات التنمية في C ++: الحزام الأسود" على كورسيرا ، فإننا نكتب بالفعل في C ++ 17 هناك. على سبيل المثال ، نستخدم الارتباطات المنظمة.
: , . , . , ?
: , . , C++. , C++, , . , , . , , , , . , . , , , Align Technology.
: , , . لماذا؟
: -, — . , . , . , , , . -, , , . . -, - ( ), -, . . . . . . , , , , . , , tutorial . -, , .
: , . , . ?
: , . , .
: , «» . , . «» , ?
: , , . . , - . , .
C++ . , . , . , , . . - , .
, . , , , . , . « ?». , .
. C++ Russia . ?
: . , , . , , . , .
: , . , ? 2015, 2019 2020 ?
: , , , , . - . , , , . , , . , .
CppCon 2018 . , , . C++ . , , .
. , — , .
: ?
: const, volatile, static, constexpr, inline, extern . , , ..
: consteval constinit?
: . , , . , 3-4 , .
: , , Visual Studio constexpr?
: Visual Studio . , . , constexpr-.
: , : , , .
: Visual Studio , . , 2010 : , . Microsoft .
: . : const, constexpr, constinit, consteval , , final. final , , constfinal?
: final, , . . , constfinal, .
: , , , , . ?
: , , . , , .
: ?
: , JUG Ru Group , ().
: . ?
: , — . , , , . .
: . , ?
: , . , ().
C++ Russia 2019 Piter «, » . , .