قرر مستخدمو Hacker News هذا الأسبوع
مناقشة السؤال "ما هو الحد الأقصى للرموز السيئة - التي لا تزال تعمل - التي رأيتها؟" (
انضم إليها لاحقًا
مستخدمو Reddit ). في التعليقات ، تم إخبار الكثير من القصص "المضحكة" عن الأشياء التي تصادفنا من وقت لآخر. لكن القصة حول رمز "DBMS المتقدم الذي تستخدمه معظم شركات Fortune 100" جذبت أكبر قدر من الاهتمام.
كان الفائز في ترشيح Lovecraft Horror مستحقًا
قصة مطور Oracle سابق عمل على Oracle Database أثناء تطوير الإصدار 12.2. كانت قاعدة التعليمات البرمجية لنظام إدارة قواعد البيانات (DBMS) في ذلك الوقت 25 مليون سطر في C - وبمجرد تغيير واحد فقط من هذه السطور ، اندلعت
آلاف الاختبارات المكتوبة في وقت سابق.
على مر السنين ، عملت أجيال عديدة من المبرمجين على الشفرة ، والذين كانوا يلاحقونهم بانتظام بمواعيد نهائية صعبة - وبفضل هذا ، يمكن أن يتحول الرمز إلى كابوس حقيقي. اليوم يتكون من "أجزاء" معقدة من التعليمات البرمجية المسؤولة عن المنطق ، إدارة الذاكرة ، تبديل السياق ، وأكثر من ذلك بكثير ؛ ترتبط ببعضها البعض باستخدام
آلاف الأعلام المختلفة. يتم ربط جميع التعليمات البرمجية بواسطة ماكرو غامض لا يمكن فك تشفيره دون اللجوء إلى دفتر ملاحظات ، حيث عليك كتابة ما تفعله الأجزاء ذات الصلة من الماكرو. ونتيجة لذلك ، يمكن أن يستغرق المطور يومًا أو يومين فقط لمعرفة ما يفعله الماكرو بالفعل.
من أجل التنبؤ بسلوك الشفرة في حالة أو أخرى ، عليك أن تفهم وتتذكر القيم والعواقب التي يمكن أن تحملها 20 (أو حتى مائة) علامة. يتفاقم الموقف بسبب حقيقة أن العديد من المطورين استخدموا أنواعهم الخاصة ، والتي كانت في الأساس نفس الشيء (على سبيل المثال ، int32) - وبالكاد يمكن لأي شخص أن يخاطر بلمس مثل هذا الإرث (يمكننا القول على وجه اليقين أن هذا هو الحال في قاعدة كود أوراكل 8i).
السؤال الذي يطرح نفسه: كيف ، مع كل هذا ، ما زالت Oracle Database قادرة على البقاء على قدميها؟ السر يكمن في ملايين الاختبارات. يمكن أن يستغرق تنفيذها الكامل من 20 إلى 30 ساعة (في نفس الوقت يتم توزيعها على مجموعة اختبار من 100-200 خادم).
كان لدى الفريق الذي عمل على المنتج في أواخر التسعينات والتزم بأفكار TDD (التطوير القائم على الاختبار) الرأي التالي: "تعني الاختبارات المؤتمتة أنك لست مطالبًا بكتابة كود يمكن فهمه - بدلاً من ذلك ، يجب عليك فكر في الاختبارات ". في المستقبل ، اضطر المطورون إلى الالتزام بالمبادئ التي وضعوها ، والآن نشهد عمليا ما تحولت إليه هذه الفكرة على المدى الطويل - مع كل الإيجابيات والسلبيات.
اليوم ، تستغرق عملية إصلاح خطأ جديد في Oracle Database من عدة أسابيع إلى عدة أشهر. في البداية ، يتعين على المطور قضاء عدة أيام فقط لمعرفة الأعلام التي يحتاجها (التفاعل الغامض الذي يتسبب في حدوث خلل) ، وبعد ذلك غالبًا ما يضطر إلى إضافة علمه الخاص ، والذي سيكون مسؤولًا عن معالجة برنامج نصي معين تسبب في الخطأ.
ثم يرسل الكود للاختبار ، وفي اليوم التالي ينتقل بهدوء إلى مهمة أخرى ، في انتظار مجموعة التجميع لتجميع تجميع Oracle DB جديد وتشغيل جميع الاختبارات عليه. إذا كان المطور محظوظًا ، فإن حوالي 100 اختبار "ستحمر". إذا لم يكن كذلك (وهذا الخيار يحدث في كثير من الأحيان) - حوالي 1000 ، وسيتعين عليه التحقق من أي من افتراضاته حول تشغيل التعليمات البرمجية الحالية تبين أنها غير صحيحة ؛ من الممكن أن يجد أنه بحاجة إلى دراسة عشرات الأعلام المختلفة ، والتي شاركت بطريقة غير واضحة في عمل الكود الذي غيره.
سيتعين عليه تكرار هذه العملية لبضعة أسابيع قبل أن يبتسم الحظ له أخيرًا وتنتهي جميع الاختبارات أخيرًا. وبعد ذلك سيتعين عليه كتابة عشرات الاختبارات - من أجل التأكد من أن المطور ، الذي سيزعج رمزه في المستقبل ، لن يكسر "إصلاحه". ثم سيتم إرسال التحسينات إلى مراجعة ، والتي يمكن أن تستغرق من عدة أسابيع إلى شهرين ، وبعد ذلك سيتم دمج الخطأ في النهاية في فرع العمل الرئيسي.
نظرًا لحقيقة أن بناء نظام إدارة قواعد البيانات (DBMS) وتشغيل الاختبارات يستغرق يومًا على الأقل ، فمن المتوقع أن يعمل كل مطور في وقت واحد على 2-3 أخطاء والتبديل بينهما أثناء انتظار نتائج الاختبار.
إذا كنت تعتقد أن حياة المطورين الذين يضيفون وظائف جديدة إلى نظام إدارة قواعد البيانات (DBMS) أسهل ، فأنت تذهب سدى. قد تستغرق إضافة ميزة جديدة صغيرة مثل وضع المصادقة الجديد من 6 أشهر إلى عام ، في الحالات المتقدمة بشكل خاص - حتى عامين.
في الحالة الموصوفة ، يسمح TDD بعدم تمزق كود "السباغيتي" ، حيث يكون من الصعب للغاية بالفعل فهم شيء ما ، والحصول على منتج يعمل عند الإخراج. في الوقت نفسه ، تستمر التكاليف في النمو ، وغالبًا ما تترك جودة الرمز الجديد الكثير مما هو مرغوب فيه. ليس فقط فريق من المطورين من الولايات المتحدة الأمريكية ، ولكن أيضًا فريق من الهند يعمل على نظام إدارة قواعد البيانات (DBMS) ، لذا فإن بعض مطوري أوراكل ، وفقًا للتقاليد الراسخة ، يلومون جودة الشفرة عليهم. آخرون يختلفون معهم ، واستناداً إلى سجل التغيير يقولون إن جودة الشفرة لا تعتمد على جغرافية الفريق ، والرمز السيئ بشكل دوري "يطير" من كلا الفريقين. مشكلة خطيرة حقًا للمنتج هي المطورين الذين يرون المشروع على أنه "يدخل في الصناعة" ويعملون على نظام إدارة قواعد البيانات لمدة لا تزيد عن 1-2 سنة ؛ خلال هذا الوقت ، من المستحيل فهم تعقيدات المشروع بشكل كبير.
وفقًا لمطور آخر كان ينقل قاعدة رمز Oracle 8i إلى أحد إصدارات Unix في أواخر التسعينيات ، كان الرمز بالفعل في ذلك الوقت عبارة عن كرة "السباغيتي" التي كان من المستحيل فهمها تمامًا. يدعي مطور آخر عمل مع كود DBMS في أواخر الثمانينيات أن قاعدة الشفرة كانت عبارة عن مجموعة ضخمة من مصادر C ومجموعة من ملفات makefiles للتجميع - كان العديد منها أكثر تعقيدًا بكثير من رمز النواة نفسه. بالطبع ، من الجدير أن نكون واقعيين - بالكاد يكون الوضع أفضل في المنتجات المماثلة ، قادة الصناعة ، التي تم تطويرها لعدة عقود.