ما علاقة Star Wars ومجموعة Tatu ومجموعة Ctrl-Alt-Del برمز Legacy؟ ماذا تفعل عندما تأتي إلى مشروع كبير وتصادف هاوية الكود القديم غير المفهوم؟ وكيف يكون أكثر فعالية في إبلاغ السلطات أن تكاليف العمالة للتخلص من الديون الفنية تؤتي ثمارها؟
لا تخلو تقارير
ديلان بيتي من النكات ، لكن هذه النكات تصاحب مناقشات جادة حول قضايا التنمية الرئيسية. هذا مناسب تمامًا لنهاية المؤتمر: عندما يكون الجمهور قد سمع بالفعل الكثير من المتشددين ولم يعد بإمكانه رؤية شرائح الأكواد ، فقد حان الوقت لمزيد من الأسئلة العامة والعرض التقديمي المشرق. وعندما انتهى مؤتمر DotNext 2018 Moscow .NET من خطاب ديلان حول رمز Legacy ، كان الجمهور يعجبه أكثر من غيره.
لذلك ، الآن من أجل هبر ، قمنا بإصدار نسخة نصية مترجمة من هذا الخطاب: للمانحين ولجميع الأشخاص الآخرين. بالإضافة إلى النص ، أسفل المقطع هناك تسجيل فيديو أصلي باللغة الإنجليزية.
مرحبا ، اسمي ديلان بيتي. موضوع المحادثة قريب جدًا مني ، وأعتقد أنه مهم للغاية لكل من يشارك في تطوير البرامج: سنتحدث عن الشفرة القديمة.
أولاً ، سأقول بضع كلمات عن نفسي. بدأت في تطوير مواقع الويب في عام 1992 ، وفقًا لمعايير صناعتنا ، في عصور ما قبل التاريخ. الآن أنا مدير قسم تقنية في شركة SkillsMatter بلندن. بدأت العمل هناك هذا العام ، وبالتالي ورثت قاعدة الكود: أصبحت 75 ألف سطر من الكود غير المكتوب من جانبي مسؤوليتي. يعتمد جزء من تقريري على هذه التجربة. بالإضافة إلى ذلك ، أنا Microsoft MVP ورئيس مجموعة مستخدمي London .NET.
ما الذي يشترك فيه دكتور هو ، حرب النجوم الحديثة ، شيرلوك ، وبدينغتون؟ عند العمل عليها ، تم استخدام كود قديم. أعرف ذلك لأني عملت لمدة 15 عامًا في Spotlight. هذه شركة مقرها لندن توفر أداة عبر الإنترنت للممثلين المحترفين الذين يعملون في الأفلام والتلفزيون. تم استخدام البرنامج ، الذي كتبه أنا وفريقي ، في العمل على جميع المشاريع المذكورة والعديد من المشاريع الأخرى.
في حرب النجوم الجديدة ، لم يعجب البعض الممثلين ، والبعض الآخر لم يعجبهم. لكن لم يخرج أحد من السينما بعبارة "أنا لا أحب أن ASP الكلاسيكية استخدمت في الخلق!"
لأنه لا يهم. تم إنتاج قاعدة الشفرة هذه لفترة طويلة جدًا ، ونعم ، هناك رمز ASP كلاسيكي أقدم من .NET بأكمله - والذي لا يزال يستخدم حتى الآن في البث للأفلام والبرامج التلفزيونية. من الضروري التركيز بشكل صحيح: هذه الأفلام والبرامج التليفزيونية هي المهم ، والكود موجود فقط لحل المشاكل. حتى تقوم بتشغيله ، الكود نفسه لا يعني أي شيء. لا تنشأ القيمة إلا عند تشغيلها والقيام بشيء معها. هذا ما يدفعه الناس مقابل - Netflix أو DVD. المشكلة هي أنه من السهل جدًا نسيانها.
بشكل عام ، أود اليوم ، من بين أشياء أخرى ، أن أشارككم تجربتي في العمل مع نفس قاعدة الشفرة لسنوات عديدة. لقد شاهدت كيف تطورت ، وكيف تعرف الآخرون عليها وتعلموا كيفية استخدامها. والجانب الآخر من هذه المعادلة هو عملي الجديد ، الذي سمح لي برؤية نفس العملية من الجانب الآخر ، عندما اضطررت أنا شخصياً للتعرف على رمز شخص آخر.
ولكن أولاً ، دعنا نتحدث عن مدى تغير الأشياء في تكنولوجيا المعلومات.
ألقِ نظرة على أول هاتف iPhone - اليوم يبدو قديمًا جدًا وضخمًا. وهذا الطراز يبلغ من العمر 11 عامًا فقط ، وقد ظهر في عام 2007 ، ثم كلف 800 دولار. إذا اشتريت غسالة أو غيتار أو دراجة في 2007 ، فلا يزال بإمكانك استخدامها. لكن iPhone الأول لم يعد يعمل - حتى لو تمكنت من العثور على نسخة بها بطارية وشاحن ، فإن كل الأشياء التي جعلت الهاتف الذكي كجهاز مذهل لن تعمل فيه.
لن تتمكن من فتح الخريطة لأن خوادم الخريطة لم تعد موجودة. لن تتمكن من الانتقال إلى Twitter لأن أحدث إصدارات تطبيق Twitter تتطلب إصدار iOS لا يمكن تثبيته على iPhone 1. سيقوم عميل Twitter بالرد عليك ببساطة: "نقطة النهاية غير موجودة". في جوهرها ، سيكون لديك حفرية في يديك. والشيء الوحيد الذي سينجح فيه هو وظيفة الهاتف العادي ، فلا يزال بإمكانك الاتصال به. لأنه في هذا المجال ، على عكس تكنولوجيا المعلومات ، لم تتغير المعايير لمدة 11 عامًا.
لنأخذ القليل من الوقت للسفر. تذكر هذا واحد؟
هل تتذكر ما كان العام؟ قدم Tatu في مسابقة الأغنية الأوروبية في عام 2003. وفي عام 2003 ، كتبت رمز ASP ، والذي لا يزال يستخدم حتى الآن في الإنتاج.
يبدو لنا أن هذا كان منذ زمن طويل ، لكن هذا الرمز لا يزال يعمل. تمكن مصنعو الهواتف المحمولة من حث الناس على شراء هاتف جديد كل عامين ، حتى يتمكنوا من التخلص من التطورات القديمة ، وتعطيل واجهات برمجة التطبيقات ، ونقاط النهاية ، والخدمات. لكن العديد من الشركات ليس لديها مثل هذه الفرصة ، وبالتالي تستمر في دعم الكود المكتوب عند أداء Tatu في يوروفيجن. هذا الرمز مهم لأنه لا يزال يؤدي وظائف مهمة ، فهو يولد إيرادات - أي أنه رمز قديم.
وعلى الرغم من أننا نتفق جميعًا على أن Legacy موجود ، يبقى السؤال: ما هو بالضبط؟ هنا رمز عينة:
انظر ، فكر: هل هو إرث أم لا؟ ما رايك
اخترعت الجهاز ، أريد أن أبيع العام المقبل. قمت بإدخاله في منفذ USB ، وحدد جزءًا من الشفرة ، ويخبرك الجهاز ما إذا كان قديمًا أم لا!
الكود الذي رأيته للتو ليس إرثًا. كتبه
أندريه أكينشين (
DreamWalker ) قبل أربعة أيام. هذا
مأخوذ من BenchmarkDotNet.
حقيقة الأمر هي أنه من المستحيل تحديد ما إذا كانت الشفرة هي Legacy بمجرد النظر إليها. علاوة على ذلك ، الكود نفسه لا علاقة له به. المهم هو ما يحدث من حوله: الناس ، والثقافة ، والعمليات ، والاختبارات ، وما إلى ذلك.
إذا قمت بفتح المقالة "Legacy code" على ويكيبيديا التي تصدر باللغة الإنجليزية ، فيمكنك قراءة ما يلي: "هذا هو الكود المصدري المرتبط بنظام التشغيل أو أي تقنية كمبيوتر أخرى ، تم إيقاف دعمها أو إنتاجها." نحن مثل: "حسنا". ثم يتم كتابتها: "استخدم هذا المصطلح لأول مرة من قبل جورج أوليفيتي فيما يتعلق برمز يدعمه مسؤول لم يكتب بنفسه هذا الرمز".
في نهاية هذه الجملة ، يوجد رابط لمدونة صمويل مولن. نعتقد ، "مثير للاهتمام ، سنرى". لكن إذا فتحنا المنشور ، فسوف نرى أن هذا مولن ، بدوره ، يشير إلى ويكيبيديا!
ويبدو أنه لا أحد يعرف من كان جورج أوليفيتي. لذلك يبدو أننا يجب أن نبحث عن تعريف أفضل.
قدم واحد من التعريفات الأكثر شعبية في الصناعة من قبل مايكل فيثرز: "تراث هو مجرد رمز بدون اختبارات". وقد كتب مايكل كتابًا
كاملاً حول هذا الموضوع ، لذلك فهو يعرف بالتأكيد ما الذي يتحدث عنه. ولكن لا يزال ، أنا لا أتفق تماما مع تعريفه.
لذلك ، كنت أستخدم التعريف الخاص بي منذ عدة سنوات: "الكود الموروث هو رمز مخيف للغاية بحيث لا يمكن تحديثه ، لكن مربحًا للغاية".
فيما بعد اتضح أن تعريفًا مشابهًا جدًا قد تم
إعطاؤه بالفعل بشكل مستقل عني: "رمز مربح جدًا نخشى تغييره". وأتساءل من أين يأتي هذا الخوف. ماذا يوجد عن الاختبارات التي تحول الشفرة بدونها إلى إرث؟
واحدة من أقدم أدوات العمل في العالم هو نظام محاسبة مزدوج القيد. عمره مئات السنين ، وفيه يتم حساب كل معاملة لبنك أو شركة مرتين: في أحد الأعمدة ، أكتب المبلغ الذي دفعته ، وفي الآخر - القيمة التي تلقيتها من أجلها. علاوة على ذلك ، يجب أن تكون مبالغ كلا العمودين متساوية ، إذا كان هناك تباين ، فسيحدث خطأ في مكان ما.
يبدو لي أن الفكرة الأساسية لهذا النهج تبدو مهمة للغاية: كل القرارات التي نتخذها لها تأثيرها مرتين ، وإذا غيرت شيئًا ما ، فمن المؤكد أنك ستحصل في مكان آخر على تغييرات تحتاج إلى مراقبتها. يمكن تطبيق هذا النهج المزدوج على الكود والاختبارات ، أو على الكود ونظام المراقبة ، أو الكود والوثائق.
توجد أيضًا العديد من الأنظمة التي نعتبرها إرثًا في نسختين ، ولكن هذه إصدارات "في الشفرة وفي رأس شخص ما". وهنا ، في رأيي ، تكمن واحدة من الصعوبات الرئيسية لدينا.
أتذكر
الشريط الهزلي المؤلف من صفحة واحدة "لهذا السبب يجب ألا تقاطع مبرمجًا." ينظر المطور إلى سطر بسيط من التعليمات البرمجية ، ويبدأ على الفور في التفكير في ما يحتاج إلى إعادة كتابته في قائمة التنقل الآن ، وكيف سيؤثر ذلك على مصحح الأخطاء ، والذي يحتاج بعد ذلك إلى تغييره في التعليمات البرمجية. شخص ما يأتي إليه ويسأل: "هل تلقيت رسالتي؟" ، ثم كل هذه الشجرة المعقدة من التعديلات تطير من رأسي.
عندما نعمل ، ندخل حالة وعي متباينة ، فدماغنا يبني نماذج معقدة تشرح كيف تعمل الشفرة. عندما يتم كتابة الرمز بواسطة شخص واحد (على سبيل المثال ، في مشروع بدء التشغيل أو مفتوح المصدر) ، غالبًا ، إلى جانب النموذج الموجود في الرأس والنموذج الموجود في الكود ، لا يوجد شيء. يتيح لك ذلك العمل بسرعة كبيرة - يمكنك فقط ترجمة ما لديك في الشفرة. النموذج الموجود في الرأس صحيح ، لذلك إذا كان هناك خطأ ما في الكود ، ما عليك سوى النظر إليه ومقارنته بما هو موجود في الرأس ، وسيكون الخطأ مرئيًا على الفور. وعندما تعثر على خطأ ، فإنه يظهر لك غالبًا أنك لم تفكر جيدًا في أي جانب من الجوانب ، وتقوم بتحديث النموذج في الرأس أولاً ، ثم الرمز.
هناك
مشاركة رائعة
لجيسيكا كير ، حيث تقول ، من بين أشياء أخرى ، إن الاختراع هو كيفية الجري في الجبل ، والتحليل هو كيفية تسلق الجبل. نود كتابة التعليمات البرمجية ، إنها ممتعة وسهلة: تبدأ من الصفر وابتكار شيء جديد وحل المشكلات وكتابة الخوارزميات والأساليب والفصول. لكن قراءة الكود أمر صعب - أمامك منذ البداية مجموعة كبيرة من كود شخص آخر ، وهذا نوع مختلف تمامًا من العمل.
لذلك ، في العديد من المنظمات ، يمكنك ملاحظة ظاهرة أطلق عليها ألبرتو براندوليني اسم "سيد المحصنة": هذا هو الشخص الذي كتب النسخة الأولى من النظام. كنت هذا الشخص في Spotlight - كتبت جزءًا مهمًا من الإصدار الأول وحده ، وكتبته على ASP كلاسيكي ، بدون وثائق ودون اختبارات وحدة. لقد بدأوا في إنتاج أفلام باستخدام هذه الأداة ، وقاموا باستخدام Star Wars ، وحصلنا على المال وكان كل شيء رائعًا. لكن بعد ذلك بدأنا في توظيف موظفين جدد لم يتمكنوا في البداية من معرفة كيف كان كل هذا يعمل ، ولمدة شهرين إلى ثلاثة أشهر كان عليهم التعرف على النظام.
سرعان ما بدأ الحديث عن نقل النظام إلى .NET ، لأن ASP الكلاسيكية لا يمكن الاعتماد عليها بدرجة كافية وليس بالسرعة الكافية. ستكون هذه المحادثات دائمًا - بغض النظر عن الشفرة التي تكتبها ، سيصر شخص ما على ضرورة إعادة كتابتها. يحدث هذا لأن هذا الشخص لا يفهم الكود ، وكتابة الكود الجديد أكثر إثارة للاهتمام من الخوض في الكود القديم. البرمجة هي وظيفة تجلب المتعة ، نحبها حقًا. لذلك ، من الطبيعي تمامًا ، إذا ما قُدم لنا خيار ، فإننا نؤيد الخيار الأكثر روعة.
صاحب المحصنة هو الشخص الذي يعرف كل المآزق في الكود. إنه يعلم بالزر الذي لا يمكن الضغط عليه ، وإلا فسيتم تعطيل التطبيق ؛ تلك التي توقف عليها TODO من عام 2014 ، والتي لم يصل إليها أحد. لقد تعلمنا في صناعتنا عدم إنشاء مثل هذه الأنظمة. هذا هو السبب في أنني أحب أحداثًا مثل DotNext ومجموعة المستخدمين والمجتمع و StackOverflow: عندما تبدأ مشروعًا جديدًا ، سيتم إخبارك بالتأكيد أنك بحاجة إلى كتابة الاختبارات ، وإجراء المواصفات حسب المثال ، والتكامل ، والرصد. لذلك فإن مستقبلنا هو خدمات ميكروية بدون خوادم على F # مع تغطية مائة بالمائة من الشفرة مع الاختبارات.
لكن المشكلة ليست في البرنامج الذي يجب أن نكتبه: عالمنا مليء بالفعل بالبرمجيات. وإذا كنت تتخيل هذا البرنامج في شكل هرم ، فلن يحتل خادم # F سوى الجزء العلوي. أكثر قليلاً سيكون ASP.NET ، مغطاة بطريقة ما في الاختبارات. حتى أكثر - Visual Basic على نظام التشغيل Windows XP. ولكن منصة تطوير المنتجات التجارية الأكثر شعبية في التاريخ هي جداول بيانات Excel.
أنا مستعد للمراهنة على أنه في كل مرة تشتري فيها تذكرة طائرة أو تقيم في فندق ، يظهر اسمك بطريقة أو بأخرى في جدول بيانات Excel. لا تأخذ عملية التطوير من خلال الاختبار هذه الأمتعة الضخمة للرمز المكتوب بالفعل.
ولكن لماذا الإصرار على إعادة كتابة التعليمات البرمجية القديمة؟ في البداية ، لا يحب الناس لغة ASP الكلاسيكية ويرغبون في إعادة كتابة كل شيء على .NET. ثم اتضح أنك بحاجة إلى إعادة كتابة كل شيء في الإصدار 4.5 ، ثم 4.6 ، ثم .NET Core. JQuery ليس جيدًا ، لذا يجب عليك بالتأكيد التحول إلى Angular ، وبعد ذلك سيأتي خط React ، ثم Vue ،.
أظن أن أحد الأسباب على الأقل تكمن في السعي وراء الموضة. نتواصل جميعًا مع بعضنا البعض ، وقد تم إنجاز جزء كبير من العمل ذي الجودة العالية في صناعتنا لأن المؤلفين أرادوا تحقيق التقدير والاحترام للناس في مهنتهم. يبدو لي أنه في صناعتنا ، هناك إدمان مفرط لكل شيء جديد ولامع ، ولغات البرمجة تخضع لاتجاهات الموضة. ولكن بعد كل شيء ، أولئك الذين تعبر عن الموضة ، في حد ذاتها ، لم يتغيروا بأي شكل من الأشكال ، ظلت جميع مزاياها كما كانت.
تخيل أن هناك نوعان من السير الذاتية أمامك:
ليس هناك شك في أن أي منهم سيكون من الأفضل بالنسبة لي أن أعمل على مشاكل مهمة حقًا. ولكن إذا كنت تتحدث مع أشخاص من الموارد البشرية ، أو مع أولئك الذين أكملوا للتو دورة برمجة ، سترى أن بإمكانهم جني أموال جيدة من مهارات المبرمج الأول ، وأنهم يعتبرون مهارات الثانية قديمة. لكنها ليست قديمة على الإطلاق - لا يزال هناك العديد من المشاكل التي يمكن لهذا الشخص العمل عليها.
أعتقد أن أحد أسباب هذا الموقف هو أن الناس خائفون. غادر بعض زملائي فريقنا لأنهم أرادوا العمل على Angular أو NodeJS. عندما سألتهم عن سبب حاجتهم إليها ، أجابوا أنه إذا استمروا في العمل على .NET فقط ، فلن يتمكنوا بعد عامين من العثور على عمل. أجبهم: شباب ، لقد ساعدنا مع .NET على صنع حرب النجوم! ويقولون: نعم ، لكنه لا يزال غير زاوي.
لا تفهموني خطأ ، أنا أحترم قرارهم. لا يمكن الحديث عن أي فساد ، فقط الناس قلقون بشأن مستقبلهم ومستقبل أسرهم إذا كان عليهم البحث عن عمل. وفي صناعتنا عادةً ما يتم تفسير هذه المشكلة الأمنية بمعنى أنك بحاجة إلى تعلم كل شيء من نقطة الصفر كل عام ونصف العام ، وإلا فإنك ستفقد قدرتك التنافسية. في كثير من الأحيان ، نحن مهتمون بالتكنولوجيا بحد ذاتها أكثر من قدرتنا على حل المشكلات.
بالإضافة إلى الخوف من التخلف عن الركب والالتفاف هنا ، في رأيي ، يلعب الخوف دورًا مهمًا في تغيير نظام لا تفهمه. يعطونك رمزًا لا تعرف شيئًا عنه ، ولكن إذا حدث شيء ما ، فستكون مسؤوليتك ، وإذا وقع في منتصف الليل ، فسوف يوقظك. ومن هنا ينشأ الخوف.
كما نعلم من حرب النجوم نفسها ، يؤدي الخوف إلى الغضب ، والغضب يؤدي إلى الكراهية ، والكراهية تؤدي إلى المعاناة ، والمعاناة تؤدي إلى JavaScript. كيف نعمل مع خوفنا وخوف زملائنا؟ في رأيي ، هناك ثلاثة جوانب رئيسية:
الفهم والثقة والسيطرة .
الثقة هي أبسط وأصعب من الثلاثة. أثق في هذا الكمبيوتر المحمول لأنه لم يتعطل مطلقًا أثناء العرض التقديمي. بمجرد حدوث ذلك ، ستختفي ثقتي به. في اللغة الإنجليزية ، هناك قول مأثور ، "الثقة يتم كسبها من نقطة إلى أخرى ، ولكن يتم فقدها بواسطة الدلاء." بعد شهر من العمل مع شخص ما ، ستكون مستعدًا للاعتراف بأنه قد يكون على دراية جيدة بعمله ، حيث ستقول في اثنين أنه على دراية جيدة ، في ثلاثة ستوافق على أنه يعرف عمله جيدًا. وبعد ثلاثة أشهر ويوم واحد ، سيتم الكشف عن الضعف في حقن SQL في الكود الخاص به ، وستقول ، "آه ، لقد قلت دائمًا إنه لم يكن مفيدًا".
الثقة بالأشخاص الآخرين صعبة دائمًا ، لأنها تعني دائمًا التخلي عن قدر من السيطرة. الثقة في الكود هي أيضا موضوع مهم. بعد أن عملت مع النظام لفترة زمنية معينة ، فأنت تريد أن تعتقد أنه سيعمل وفقًا لتوقعاتك. أنظمة التشغيل لديك مستقرة وموثوقة ، وتأمل ألا تسقط. أنت تثق في قواعد بيانات معلوماتك وتتوقع أنها لن تفقدها. تتوقع من موفري الخدمات السحابية أن يضمنوا التشغيل المستمر لموقعك ولن يبيعوا معلومات عملائك في السوق السوداء.
لا توجد وسيلة سريعة لكسب الثقة. صحيح أن الثقة متعدية: إذا كنت أثق بك وتثق بشخص آخر ، فمن المرجح أن أثق بهذا الشخص أيضًا. إذا استمعت إلى رأيك ، وكنت تعتقد أنه يمكنك الوثوق في Amazon أو AWS أو Azure أو Google App Engine ، فسأكون مستعدًا للاعتقاد بأن هذه خدمات جيدة. ولكن لا توجد وسيلة سريعة لكسب الثقة.
دعنا ننتقل إلى
التفاهم . في الجامعة درست علوم الكمبيوتر لمدة ثلاث سنوات. إذا اتبع المهندسون المدنيون المبدأ الذي يقوم عليه تعليمنا ، فسيقومون في السنة الأولى ببناء حظائر خشبية ، وفي المعدن الثاني وفي الزجاج المتطور الثالث.
في السنة الأولى ، كتبنا برامج صغيرة في Lisp ، في الثاني - برامج صغيرة في Java ، وفي الثالثة - برامج صغيرة في Scheme و Prolog. لم نكتب برامج كبيرة ، والأهم من ذلك ، لم نحاول اكتشافها.
لكن المهندسين المدنيين لا يتعلمون على سبيل المثال من الحظائر ، فهم مجبرون على فهم ناطحات السحاب والجسور والجمعيات الفيلهارمونية والمباني مثل تلك التي نحن فيها الآن. هؤلاء الطلاب يتعلمون من أكبر المشاريع وأكثرها إثارة للإعجاب في صناعتهم. وإذا درسوا وفقًا لنفس المبدأ الذي يدرسون فيه علوم الكمبيوتر ، فلن يفكر الطالب ، الذي يواجه ترتيبًا حقيقيًا لأحد ناطحات السحاب ، في أي شيء آخر غير وضع الحظائر فوق بعضها البعض حتى تنفجر أبراج بتروناس.
في هذه الحالة ، يجد الطالب الذي يكمل دورة علوم الكمبيوتر نفسه ويكلف بمهمة كتابة نظام شراء تجاري موزع. تمت كتابة جزء كبير من البرنامج الحالي بنفس الطريقة تقريبًا. الأشخاص الذين كتبوها لم يكونوا مسؤولين ، ولكن ببساطة عديمي الخبرة. لقد قاموا بعمل جيد في كل ما فعلوه في الجامعة ، وهذا خلق ثقة زائفة بالنفس. كان هذا بالضبط ما كنت عليه في وقت واحد ، وأنا متأكد من أن الكثير منكم كانوا متماثلين في وقت واحد. لقد تصرفنا على النحو التالي: نكتب صفحة ويب ، وننشئ رابطًا لصفحة أخرى ، ثم ننسخ رمزًا وسيسعد الجميع - عملاءنا لديهم منتج ، وشركتنا لديها أموال ، ولدينا مكافأة. بعد خمس سنوات ، تنظر إلى هذا الكابوس وتفكر: كيف يمكن كتابة هذا؟
جزء من المشكلة هو القدرة على تعلم البرمجيات. المهندسون المدنيون يجيدون دراسة المباني ، ومهندسو الطائرات يجيدون معرفة الطائرات. خذ الأدب: في الحرب والسلام يمكن أن يكون هناك 45 ألف سطر (اعتمادا على المنشور). هذا هو واحد من أكبر الكتب في العالم ، فهو يتطلب دراسة جادة للغاية من قبل الأشخاص الذين يشاركون في النقد الأدبي. بمعنى آخر ، دراسة مثل هذا الشيء الكبير هي وظيفة. يبلغ حجم مسرحية شكسبير الطويلة ، هاملت ، 6 آلاف خط. الآن فكر: نواة لينكس هي ثلاثة أضعاف طول الحرب والسلام. ونحن نتحدث عن رمز مضغوط للغاية ، منظمة تنظيماً جيداً ، مع وثائق واسعة ومجتمع كبير. ومع ذلك ، فإن فهمها مشابه لفهم "الحرب والسلام" ثلاث مرات.
انظر إلى هذا الرسم البياني ، الذي يظهر عدد الخطوط في كتب هاملت ، موبي ديك ، الأخوان كارامازوف ، سيد الخواتم ، أطلس المهزوم ، والحرب والسلام ، وكذلك نواة لينكس ومونو .
هل هذه النسبة تبدو واقعية بالنسبة لك؟ أرجوك سامحني على تضليلك. هذا الرسم البياني هو في الواقع الأسي.
رسم بياني خطي في الشريحة التالية:
الفكرة هنا بسيطة للغاية: البرنامج ضخم ، مجرد الجلوس وقراءته أمر مستحيل. إن مطالبة شخص ما بالتعرف على نواة Linux يشبه مطالبة شخص ما بقراءة الحرب والسلام ، وأطلس مهجور ، وسيد الخواتم ، وجميع هاري بوترز على التوالي. تخيل أنك أتيت إلى شركة جديدة ، ويخبرونك من الحد الأدنى أنك تحتاج إلى دراسة جميع هذه الكتب ، وعندها فقط يُسمح لك بالحصول على الكود. بالطبع لا يفعلون ذلك.
يمكن أن تكون قراءة التعليمات البرمجية مفيدة للغاية - يمكنك فهم كيفية عمل بعض الأنماط وتعلم بعض الأمثلة. لكن لا يمكنك معرفة نظام كبير إذا قرأته بالطريقة التي تقرأ بها كتابًا. ربما يكون لهذا النهج شيء نبيل ، لكنه لا يؤدي إلى أي شيء ، كما يبدو لي. هناك الكثير من الأكواد ، وهو مكتوب أسوأ من هذه الكتب.
إذا كانت قراءة الكود غير فعالة ، فكيف ندرسها بشكل صحيح؟ أذكر ريتشارد فاينمان ، الحائز على جائزة نوبل في الفيزياء. بالنسبة له ، كانت مسألة تدريس العلوم ذات أهمية كبيرة. كان يعتقد أن من الضروري تعليم الناس ليس العلم ، ولكن كيفية القيام بالعلم بشكل صحيح. تمت دعوته إلى جامعة ساو باولو في البرازيل ، لأن الطلاب في البرازيل حصلوا على درجات عالية جدًا ، ولكن في الوقت نفسه لم يكن من الممكن إنشاء إنتاج عالي التقنية. طلب من فاينمان المساعدة في معرفة المشكلة.
لعدة سنوات ، جاء إلى البرازيل كل عام لعدة أسابيع ، وتحدث مع الطلاب. لقد رأى أن الطلاب البرازيليين يعرفون تمام المعرفة ، على سبيل المثال ، اسم الظاهرة التي تحدث عندما يتم الضغط على الجسم البلوري - التلألؤ. لكن لم يعلم أي منهم أنه إذا سحقت قطعة من السكر بزوج من كماشة في المنزل في غرفة مظلمة ، فسترى الشرر يتهاوى - وهذا هو التلألؤ. أوضح فاينمان أن الطلاب تم تدريبهم فقط في الكتب المدرسية لاجتياز الامتحانات ، لكنهم لم يجروا أي تجارب.
في رأيي ، هذا يحتوي على درس مهم لصناعتنا. , . , , , . , .
—
. , , , .
—
. , , . , , - .
. ,
.
.
, , .
, — , , . , , - , ? .
- , , - . .
- «I love LAMP», , , . — , , , . : , , , .
, , , . , . , DLL. , , . , — , . , , — .
— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? و هكذا.
, , . , , , .
, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , .
: .
,
: , . . , : , .
. , , . , , . : , , , . , - , . .
Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .
- , , . Windows 2016 , ASP, 2003 .
, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .
, . , , - . , : , -?
: , , -?
, , , , . - — -, , . — . , !
, , , - — , .
, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .
, , , . — . , , , .
, , . , , 32 64, . , , . . , , , . , , . , , , .
, 80- 90-, -, , . , . , .
. , — , . , , , , . , .
, . , , . , , . , — « » . , , , . : «, - ?»
, - — , . , , . , ; , — , . . , , . , .
, . , , . , . , . , , , , — , 12 , , , 3 .
, , , . , . , , .
, — ? «definition of done»?
, , GitHub , , , .
, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .
, , — , . — , 20 . — , .
: , . , . , . GitHub, . - , .
: , .
-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .
- , « -» « ». .
:
(control), (alter) (delete) - .
شكرا لاهتمامكم
, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .