الدروس المستفادة من أزمة نزف القلب (2)

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

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

 

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

 

لكن لو انتبهنا إلي أن معظم مبرمجي البرمجيات مفتوحة المصدر يستخدمون أنظمة تشغيل مفتوحة المصدر (و علي رأسهن توزيعات الـGNU\linux بطبيعة الحال) فسنجد أن المسألة ربما لا تكون بالضبط كما قلنا منذ قليل؛ حيث أنه ربما تكون هناك أدوات لا تتوافر إلا للأنظمة التجارية مثل الـwindows و الـmac os x و لا تتوافر للأنظمة المفتوحة، و هو ما قد يعني حرمان مبرمجي البرمجيات مفتوحة المصدر من استخدام تلك الأدوات حتي يتم توفير إصدارات منها تعمل علي الأنظمة مفتوحة المصدر، أو علي الأقل تكون هناك حيلة لجعل إصدارات الأنظمة التجارية تعمل علي أنظمتهم، مثل استخدام برامج wine و/أو crossover لجعل برامج الـwindows تعمل علي الـGNU\linux.

 

و لكن هذا لا يصلح في كل الأحوال، و في حالة البرمجيات شديدة التعقيد مثل الـvisual studio فلا أظن أن الأمر ينجح، خاصةً و أنه مكتوب من الصفر ليكون تام التعلق بالـwindows و هو الأمر الذي سيجعل تشغيله علي نظام آخر قطعةً من العذاب (إن تم من الأصل)، و هكذا لا يكون أمامهم إلا البحث عن بديل مشابه يقوم بذات الوظيفة في عالم البرمجيات مفتوحة المصدر. بينما لا يواجه منتجو البرمجيات مغلقة المصدر أمثال هذه العقبات بسبب أنهم في الغالب يستخدمون أنظمة تشغيل مغلقة المصدر تتوافر لها معظم الأدوات البرمجية التي يحتاجونها، حتي و إن كان ذلك نظير مقابل مادي.

 

لكن الغريب أن كثيراً من المبرمجين يغفلون أساساً عن استخدام تلك البرمجيات المساعدة رغم توافرها لهم !؛ فمثلاً حينما ظهرت الثغرة الأمنية بالغة الخطورة في أكواد الـSSL في أنظمة تشغيل Apple، تيقن الجميع أنها ليست خطأ في الخوارزم algorithm بل كانت مجرد خطأ بسيط للغاية في التركيب المنطقي للأكواد، حيث كان هناك تكرار لجملة goto بدون داعي، و هو ما أدي إلي أن الجزء الذي يليها من الكود لا يتم تفعيله مطلقاً (و هو الأمر الذي يدل علي أن تكرار الجملة كان خطأ غير مقصود من المبرمج، ربما نتج عن قيامه بلصق الأمر -أثناء تعديله للكود- مرتين لا مرة واحدة).

 

حينها كان السؤال المنطقي الوحيد هو: “لماذا بحق الله لم يستخدم مبرمجوا Apple آدوات تيسر لهم اكتشاف مثل هذه الأغلاط المنطقية شديدة التفاهة ؟!”

المسألة ليست في أن مبرمجاً مخضرماً ارتكب مثل هذه الغلطة التافهة؛ فالكل معرض لمثلها مهما كان مستواه التقني و عبقريته، و ليست المسألة أن المراجعة التي تمت للأكواد لم تؤد لاكتشاف هذا الخطأ؛ فنحن بشر في النهاية و يمكن -قَدَراً- أن يقع المبرمج و المُراجِع في نفس الغفلة و لا ينتبهان لهذه الغلطة، صحيح أن هذا الموقف شديد الندرة (خصوصاً مع المستويات شديدة العلو للمهارات التقنية لهؤلاء المبرمجين و المراجعين، و التي أدت لحصولهم علي هذه الوظيفة الهامة للغاية في شركة مثل Apple). و لكن الكارثة أن هؤلاء المبرمجين لم يتعبوا أنفسهم باستخدام أدوات تعينهم علي اكتشاف مثل تلك الغلطات المنطقية آلياً، أو أن الأدوات التي يستخدمونها ضعيفة المستوي و لم يبذلوا جهداً لتقويتها من أجل القيام بهذه الأمور بالغة الأهمية لبرامجهم شديدة الخطورة (لا تنسوا أننا نتحدث عن أنظمة تشغيل mac os x و iOS اللذين تمتلكهما Apple و أعداد مستخدميهما بمئات الملايين) !.

 

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



لكن هذا ليس معناه أن الـNetBeans سوف تكون ملاكي الحارس الذي يغنيني عن المراجعة البشرية؛ فهناك من الأخطاء ما لا تلاحظه رغم أنه يراه كل كفيف.

و انظروا إن أحببتم إلي المثال التالي:




حيث أن الأمر “return null” لن تم تنفيذه مطلقاً؛ بسبب أن جملة if دائماً ما يكون شرطها true و سيتم تنفيذها كل مرة لا محالة. و هو ما يجعلنا نتيقن من أن وجود العامل البشري في المُراجَعات لا مفر منه، فعلي الأقل في المرحلة الحالية يمكن للبشر اكتشاف أخطاء منطقية بسيطة أو عويصة لا تتمكن الأدوات البرمجية المساعدة علي اكتشافها.

 

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

و قد يبدو في النظرة الأولي أن البرمجيات مفتوحة المصدر تتفوق علي مغلقة المصدر في نقطة القدرة علي تعديل الأدوات المتاحة لتوائم احتياجاتنا؛ بسبب طبيعة كليهما، لكن النظرة المدققة توضح أن منتجي البرمجيات المغلقة المصدر قد يقومون بالتعديل علي البرمجيات المفتوحة لمصلحتهم (انظروا إن أحببتم إلي تعاون microsoft مع فريق عمل نواة الـlinux لتروا ما أتحدث عنه!). كما أظن أن هناك بعض البرمجيات مفتوحة المصدر التي تتيح لمن يرغب أن يقوم بإجراء تعديلاته الخاصة عليها ثم الاحتفاظ بتلك التعديلات مغلقة المصدر.

 

 

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

 

تم نشر هذا المقال لأول مرة علي موقع Drolint.com