مشكلات الشيفرات البرمجية المتعلقة بالتواريخ

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

مشكلة عام 2000 المتعلقة بالبرمجيات

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

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

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

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

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

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

الخطأ القادم عام 2038

إذا كنت مطمئناً لأنّ عام 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 الذين سيعملون على دراسة الخيارات، والجدال حول الأولويات، وفي النهاية الحفاظ على أقساط الديون العقارية التي قمت بسدادها.