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

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

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

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

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

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

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

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

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

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

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

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

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

المركز الثاني: الإعلان على وسائل التواصل الاجتماعي

عندما عملت في 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 Corporation - أو بالأحرى شخصيًا Thomas Watson Sr. - الحصول عليها. لسوء الحظ ، لم يستطع مندوب المبيعات القيام بذلك ، وفقدت شركة IBM العطاء. في اليوم التالي ، جاء هذا الضابط إلى مكتب السيد واتسون ووضع مظروفًا على مكتبه. لم ينظر السيد واطسون إليه - كان ينتظر موظفًا وكان يعلم أن هذا كان خطاب استقالة.

سأل واتسون عن الخطأ.

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

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

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

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

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

الأسوأ كان ذلك أفضل

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

استنتاج

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

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