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

المركز الثالث - مترجم C من مايكروسوفت

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

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

عاقدة العزم على كتابة أفضل رمز آلة لكل حالة ممكنة ، ألقيت بنفسي في البركة. إذا كانت كثافة توزيع القيم عالية ، فقد قمت بإدخالها القفز على الطاولة. إذا كان لديهم قاسم مشترك ، فقد استخدمته لجعل الجدول أكثر كثافة (ولكن فقط إذا كان من الممكن إجراء القسمة باستخدامه تحول قليلا). عندما كانت جميع القيم قوى لاثنين ، قمت بإجراء تحسين آخر. إذا كانت مجموعة القيم لا تفي بشروطي ، فقد قسمتها إلى عدة حالات مُحسَّنة واستخدمت الكود المُحسَّن بالفعل.

لقد كان كابوس. بعد سنوات ، قيل لي أن المبرمج الذي ورث الكود الخاص بي كان يكرهني.

الدرس المستفاد

كما كتب ديفيد باترسون وجون هينيسي في هندسة الكمبيوتر وتصميم نظام الكمبيوتر ، فإن أحد المبادئ الرئيسية للهندسة المعمارية والتصميم هو جعل الأشياء تعمل بأسرع ما يمكن بشكل عام.

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

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

كنت بحاجة إلى الاتصال بمطور متمرس والتفكير معه في ماهية الحالات العامة والتعامل معها على وجه التحديد. سأكتب كودًا أقل ، لكنه جيد أيضًا. كما كتب مؤسس Stack Overflow جيف أتوود ، فإن أسوأ عدو للمبرمج هو المبرمج نفسه:

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

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

الوصيف: إعلانات وسائل التواصل الاجتماعي

عندما كنت أعمل في Google على إعلانات الوسائط الاجتماعية (هل تتذكر Myspace؟) ، كتبت شيئًا كهذا في C ++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

الدرس المستفاد

يعتقد الكثير من الناس أن مثل هذا الخطأ الكبير سيكلف بالتأكيد الشخص المسؤول عن الفصل ، لكن هذا ليس كذلك: أولاً ، كل المبرمجين يرتكبون أخطاء ، وثانيًا ، نادرًا ما يرتكبون نفس الخطأ مرتين.

في الواقع ، لدي صديق مبرمج وهو مهندس لامع تم طرده لخطأ واحد. بعد ذلك ، تم تعيينه بواسطة Google (وسرعان ما تمت ترقيته) - تحدث بصدق عن الخطأ الذي ارتكبه في المقابلة ، ولم يُعتبر قاتلاً.

إليك ما يخبار حول توماس واتسون ، الرئيس الأسطوري لشركة IBM:

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

سأل واتسون ما الخطأ الذي حدث.

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

اقترب منه واطسون عند الباب ، ونظر في عينيه وأعاد الظرف بالكلمات: "كيف يمكنني السماح لك بالرحيل؟ لقد استثمرت للتو مليون دولار في تعليمك.

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

المركز الأول: App Inventor API

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

الأسوأ هو الأفضل

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

افعل ذلك بشكل صحيح: يجب أن يكون التصميم بسيطًا في التنفيذ والواجهة. تعد بساطة الواجهة أكثر أهمية من بساطة التنفيذ.

الأسوأ هو الأفضل: يجب أن يكون التصميم بسيطًا في التنفيذ والواجهة. سهولة التنفيذ أهم من بساطة الواجهة.

دعونا ننسى ذلك لمدة دقيقة. لسوء الحظ ، لقد نسيت ذلك لسنوات عديدة.

مخترع التطبيق

أثناء عملي في Google ، كنت جزءًا من الفريق مخترع التطبيق، بيئة تطوير بالسحب والإفلات عبر الإنترنت لمطوري Android المبتدئين. كان ذلك في عام 2009 ، وكنا نسارع إلى إصدار نسخة ألفا في الوقت المناسب لتقديم دروس رئيسية للمعلمين خلال فصل الصيف الذين يمكنهم استخدام البيئة للتدريس في الخريف. تطوعت لتنفيذ العفاريت ، الحنين إلى الطريقة التي اعتدت بها كتابة الألعاب على TI-99/4. بالنسبة لأولئك الذين ليسوا على دراية ، فإن الكائن عبارة عن كائن رسومي ثنائي الأبعاد يمكنه التحرك والتفاعل مع عناصر البرامج الأخرى. ومن أمثلة العفاريت سفن الفضاء والكويكبات والبالونات والمضارب.

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

الفرق الرئيسي بين الكرة والعفريت هو ما يتم رسمه بالضبط - دائرة ممتلئة أو خطوط نقطية. منذ أن قمت بتطبيق النقوش المتحركة لأول مرة ، كان من المنطقي تحديد إحداثيات x و y للركن الأيسر العلوي للمكان الذي توجد فيه الصورة.

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

في الواقع ، كان من الضروري تحديد إحداثيات x و y لمركز الدائرة ، كما يعلمنا كل كتاب رياضيات وأي مصدر آخر يذكر الدوائر.

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

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

الدروس المستفادة

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

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

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

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

اختتام

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

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

المصدر: www.habr.com