الآن وغداً

  بالشراكة مع:



الاقتصادي – الآن وغداً:

 

بقلم: جريج لافالي

 

مثّلت "مشكلة عام 2000″ (Y2K) تهديداً كبيراً خشي منه مستخدمو الكمبيوتر والمبرمجون (انتشر القلق مع اقتراب العام 2000، حيث اعتمد المبرمجون على طريقة تخزين أرقام السنة المكونة من أربعة أرقام إلى رقمين فقط لتقليل كمية الذاكرة المستخدمة). كان الخوف هو أنّ تاريخ 1/1/00 سوف يعود مجدداً، فقد تعمل بعض أجهزة الكمبيوتر على أنّ هذا التاريخ هو ذاته تاريخ الأول من كانون الثاني (يناير) عام 1900. ما الخطأ الذي كان سيحدث؟ ربما كانت السدود الكهرومائية المحوسبة للغاية ستفتح بواباتها أو ربما كانت جميع حسابات التواريخ التي تطرح من 00 ستنتهي سالبة، وكان من الممكن فجأة أن يكون رهنك العقاري قد سُدد منذ عشرات السنين.

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

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

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

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

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

الحل المكون من أربعة أرقام لـ"مشكلة عام 2000″، لا يُعتبر حلاً سوى للثمانية آلاف عام قادمة. أي عندما يأتي عام 10000 والمشكلة المتعلقة به (Y10k)، سنواجه "مشكلة عام 2000" مرة أخرى عندما نحاول طرح 9000 من 0000.

إذا كنت مطمئناً لأنّ عام 8000 هو في المستقبل البعيد، فأنت مخطئ! لأنّ هنالك خطأ جسيم آخر في عام 2038. في أنظمة التشغيل يونكس (ولينكس)، غالباً ما يُخزن الوقت بتنسيق الثواني منذ منتصف ليل 1 يناير 1970. وفقاً لمقابلة في "مجلة وايرد" مع أولئك الذين شهدوا بداية انطلاق يونكس، اختير هذا التاريخ 1/1/1970، والمعروف باسم "عصر" يونكس، عشوائياً لسهولة الأمر. على سبيل المثال، لحظة حفظ مستند عند الساعة 2:05 مساء بتوقيت شرق الولايات المتحدة في 2 يونيو (حزيران) عام 1986، كان نظام يونكس قد أعطاها وقت 518090700. يعدّ هذا جيد بما يكفي، ولكن في 19 يناير 2038 (2147483647) لن يكون هناك مساحة كافية لتخزين الثانية التالية (2147483648) في العديد من أنظمة الكمبيوتر. عوضاً عن ذلك، قد تعطي الشيفرة البرمجية نتيجة أنّ الوقت الحالي هو سالب. يُستخدم هذا التنسيق للوقت في مليارات أسطر الشيفرة البرمجية، وعلى جميع أنواع الأنظمة، ذلك لتحديد التواريخ.

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

خذ "موقع تويتر" مثالاً، فلدى كل تغريدة يجري نشرها معرّف مميز. عندما جرى تطويره لأول مرة، اختار مهندسو تويتر عدداً صحيحاً وهو 32 بت لتخزين التغريدات. هذا يعني أنّ التغريدة الأولى سيكون لها المعرف "1"، وسيكون هناك مساحة في النظام لـ 4،294،967،295 تغريدة. عندما لم يكن لدى "موقع تويتر" سوى القليل من الناس يتحدثون عن الصنف الذي سيتناولونه على الغداء، ربما بدت 4 مليارات تغريدة كافية لفترة من الوقت. ولكن بحلول عام 2009، أصبح من الواضح أنّ تويتر سيحتاج إلى مساحة أكبر لتخزين المعرفات. كما جرى إنشاء المئات إن لم يكن الآلاف من التطبيقات بالاستناد إلى تويتر (مثل تويتبوت وتويتديك وسايزمك وما إلى ذلك)، وسيحتاج القائمون على تلك التطبيقات أيضاً إلى التنبه من زيادة حجم أعمدة قاعدة بياناتهم لتخزين معرفات التغريدات. لذلك، طُلب من مطوري لغة البرمجة "جافا سكريبت" التوقف عن استخدام حقل "المعرف" الذي أرسله لهم تويتر واستخدم بدلاً من ذلك حقلاً جديداً يسمى أي دي_إس تي آر (id_str)، الذي أحاط معرفات التغريدات ضمن علامات اقتباس حتى لا تفسرها لغة البرمجة "جافا سكريبت" كأرقام وتطبيقات معطلة، وجرى بالتالي تجنب أزمة تويتر.

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

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

في جميع الأحوال، فكر بالمبرمجين في أوائل عام 2038 الذين سيعملون على دراسة الخيارات، والجدال حول الأولويات، وفي النهاية الحفاظ على رهنك العقاري.

تنويه هذه المقالة تنشر حصرياً بالتعاون بين الاقتصادي.كوم ومشروع فيوتشر تنس (Future Tense) المبادرة بين موقع سليت (SLATE) ومركز أميركا الجديدة للفكر (NEW AMERICA) وجامعة ولاية أريزونا (ASU). جميع الحقوق محفوظة.


error: المحتوى محمي , لفتح الرابط في تاب جديد الرجاء الضغط عليه مع زر CTRL أو COMMAND