تشرح هذه الورقة النهج العلمي لحل المشكلات. على الرغم من أنه مكتوب لمعالجة المشكلات المتعلقة بتكنولوجيا المعلومات ، فقد تكون المفاهيم قابلة للتطبيق أيضًا في تخصصات أخرى. الأساليب والمفاهيم والتقنيات الموصوفة هنا ليست جديدة ، ولكن ما يثير الصدمة هو عدد “حل المشكلات” الذين فشلوا في استخدامها. فيما بيني سأقوم بتضمين بعض الأمثلة الواقعية.
لماذا يخمن حل المشكلات بدلاً من اتباع نهج علمي لحل المشكلات؟ ربما لأنه يبدو أسرع؟ ربما نقص الخبرة في حل المشكلات بكفاءة؟ أو ربما لأنه يبدو وكأنه عمل شاق للقيام بذلك علميًا؟ ربما بينما تستمر في التخمين وليس الحل حقًا ، فإنك تولد المزيد من الدخل وتضيف بعض الأمان الوظيفي؟ أو ربما لأنك تنتهك المبدأ الأول لحل المشكلات: فهم المشكلة.
المبدأ رقم 1. افهم المشكلة الحقيقية.
أليس من الواضح أنك بحاجة إلى فهم المشكلة قبل أن تتمكن من حلها؟ يمكن. ولكن ، في معظم الأوقات ، سيبدأ المحلل في حل المشكلة دون معرفة المشكلة الحقيقية. ما يصفه العميل أو المستخدم بـ “المشكلة” هو في العادة العرض فقط! العرض “لا يريد جهاز الكمبيوتر الخاص بي التشغيل”. قد تكون المشكلة الحقيقية أن المبنى بأكمله بدون كهرباء. العرض “في كل مرة أحاول فيها إضافة منتج جديد ، تظهر لي رسالة خطأ”. هنا يمكن أن تكون المشكلة الحقيقية “فقط آخر منتجين حاولت إضافتهما أعطت خطأ” المنتج موجود بالفعل “. مثال كلاسيكي آخر: “لا شيء يعمل” …
تبدأ التحقيق بتحديد “المشكلة الحقيقية”. سوف يستلزم ذلك طرح الأسئلة (والتحقق منها في بعض الأحيان) وإجراء بعض الاختبارات الأساسية. اطرح على المستخدم أسئلة مثل “متى كانت آخر مرة عمل فيها بنجاح؟” ، “منذ متى وأنت تستخدم النظام؟” ، “هل يعمل على كمبيوتر آخر أو مستخدم آخر؟” ، “ما هي رسالة الخطأ بالضبط؟ ” إلخ. اطلب طباعة الشاشة للخطأ إن أمكن. سيكون الاختبار الأساسي الخاص بك هو التأكد من تشغيل المعدات الكاملة. تحقق من جهاز الكمبيوتر الخاص بالمستخدم ، والشبكة ، وخادم الويب ، وجدران الحماية ، وخادم الملفات ، وقاعدة البيانات الخلفية ، وما إلى ذلك. أسوأ حالة يمكنك القضاء على الكثير من المجالات لسبب المشكلة.
مثال حقيقي من الحياة. العَرَض حسب المستخدم: “ينقطع النظام في أوقات عشوائية عند تقديم الطلبات”. البيئة: يقوم المستخدم بإدخال تفاصيل الطلب في نموذج في تطبيق حاسب مركزي. عند اكتمال كل التفاصيل ، سيقوم المستخدم بإغلاق النموذج. يرسل الكمبيوتر الرئيسي بعد ذلك هذه التفاصيل عبر برنامج الاتصال إلى نظام Oracle Client / Server في المصنع. سيقوم نظام أوراكل بتخطيط السعة وإما إرجاع خطأ أو تاريخ أمر متوقع إلى نظام الكمبيوتر الرئيسي. هذه المشكلة خطيرة للغاية ، لأنك قد تفقد العملاء إذا حاولوا تقديم الطلبات ولم يقبلها النظام! لمحاولة حل هذه المشكلة ، بدأ الأشخاص بالتحقيق في: 1) حمل وسعة أجهزة الكمبيوتر الرئيسي 2) مراقبة حمل الشبكة بين الكمبيوتر الرئيسي ونظام أوراكل 3) تعيين مستشارين لتصحيح أخطاء برنامج الاتصال 4) تصحيح سعة أوراكل نظام التخطيط بعد قضاء شهرين لم يتمكنوا من حل المشكلة.
تم استدعاء “حلال المشكلات العلمية”. استغرق الأمر أقل من يوم وتم حل المشكلة! كيف؟ يقضي المحلل يوم المستخدم ليرى ماهية “المشكلة الحقيقية”. وجد أن المشكلة تحدث فقط مع أوامر التصدير. من خلال التحقق من شاشة الالتقاط وإجراءات المستخدم ، وجد أنه مع أوامر التصدير ، يتم دائمًا ترك الحقل الأخير في النموذج فارغًا ولم يقم المستخدم بإخراج هذا الحقل. لم يكن النظام معلقًا ، فقد انتظر حتى يضغط المستخدم على “علامة التبويب” مرة أخرى. تم حل المشكلة. وتجدر الإشارة إلى أن “حلال المشكلات العلمية” لديه معرفة محدودة جدًا بالحاسوب الرئيسي ونظام التقاط الطلبات وبرمجيات الاتصالات ونظام تخطيط سعة أوراكل. وهذا يقودنا إلى المبدأ رقم 2.
المبدأ رقم 2. لا تخف من بدء عملية الحل ، حتى لو كنت لا تفهم النظام.
كم مرة سمعت “لا أستطيع لمس هذا الرمز ، لأنه تم تطويره بواسطة شخص آخر!” ، أو “لا يمكنني المساعدة لأنني مستشار موارد بشرية وهذه مشكلة مالية”؟ إذا كنت لا ترغب في تشغيل الغسالة ، فلست بحاجة إلى أن تكون مهندسًا كهربائيًا أو متخصصًا في إصلاح الغسالات أو فنيًا أو أيًا متخصصًا للقيام ببعض اكتشاف الأخطاء الأساسية. تأكد من أن القابس يعمل. تحقق من مفتاح الرحلة ، وما إلى ذلك ، يجب ألا يمنعك “لم أر هذا الخطأ من قبل من قبل” من محاولة حل المشكلة. من خلال رسالة الخطأ ومحرك البحث على الإنترنت ، يمكنك الحصول على الكثير من نقاط البداية.
يوجد في كل نظام معقد زوجان من مبادئ العمل الأساسية. يمكن أن يكون النظام A الذي يقرأ البيانات من النظام B معقدًا بشكل رهيب (ربما يكون مطيافًا مختبريًا يقرأ البيانات من كمبيوتر منطقي قابل للبرمجة عبر منفذ RS-232). ولكن ، هناك بعض الأساسيات التي يجب اختبارها: هل يتمتع كلا النظامين بالطاقة؟ هل توجد رسالة خطأ في سجل الأحداث على أحد هذه الأنظمة؟ هل يمكنك “ping” أو تتبع حزمة شبكة من نظام إلى آخر؟ جرب كابل اتصال مختلف. ابحث في الإنترنت عن رسالة الخطأ.
بمجرد تحديد المشكلة ، تحتاج إلى البدء في حلها. في بعض الأحيان ، سيوجهك التحقيق الأولي مباشرةً إلى الحل (قم بتشغيل الطاقة ، واستبدل الكابل المعيب ، وما إلى ذلك). لكن ، في بعض الأحيان تكون المشكلة الحقيقية معقدة في حد ذاتها ، لذا فإن المبدأ التالي هو حلها ببساطة.
المبدأ رقم 3. قهر الأمر بسيط.
لنبدأ هذا القسم بمثال من واقع الحياة. في ظل ظروف معينة ، سيتم تعليق إجراء مخزن. يستغرق الإجراء المخزن عادةً حوالي ساعة للتشغيل (عندما لا يكون معلقًا). لذلك ، حاول المطور تصحيح الأخطاء. قم بإجراء بعض التغييرات ثم انتظر ساعة أخرى أو نحو ذلك لمعرفة ما إذا كان قد تم حل المشكلة. بعد بضعة أيام استسلم المطور وتولى “حل المشكلات”. كان على “حلال المشكلات” تحت تصرفه معرفة أن الإجراء المخزن سيتعطل في ظل ظروف ساحرة. لذلك ، كان عمل نسخة من الإجراء تمرينًا بسيطًا ، ثم باستخدام هذه النسخة لتجريد كل التعليمات البرمجية غير الضرورية. تم تغيير جميع المعلمات بقيم مشفرة. تم تنفيذ أجزاء من التعليمات البرمجية في وقت واحد ثم تم بعد ذلك ترميز مجموعات النتائج مرة أخرى في نسخة الإجراء. في غضون 3 ساعات تم حل المشكلة. تم اكتشاف حلقة لا نهائية.
ما فعله “حل المشكلات” هو تكرار المشكلة وفي نفس الوقت حاول عزل الكود الذي تسبب في المشكلة. عند القيام بذلك ، أصبح الإجراء المخزن المعقد (والمستهلك للوقت) شيئًا سريعًا وبسيطًا.
إذا كانت المشكلة داخل أحد التطبيقات ، فأنشئ تطبيقًا جديدًا وحاول محاكاة المشكلة داخل التطبيق الجديد بأكبر قدر ممكن من البساطة. إذا حدثت المشكلة عند استدعاء طريقة معينة لعنصر تحكم معين ، فحاول تضمين عنصر التحكم هذا فقط في التطبيق الفارغ واستدعاء هذه الطريقة بقيم مشفرة. إذا كانت المشكلة تتعلق بـ SQL المضمن داخل تطبيق C # ، فحاول محاكاة SQL داخل أداة استعلام قاعدة البيانات (مثل SQL * Plus for Oracle ، Query Analyzer for SQL Server ، أو استخدم الكود في MS Excel عبر ODBC إلى قاعدة البيانات ).
في اللحظة التي يمكنك فيها تكرار المشكلة بطريقة بسيطة ، تكون أكثر من 80٪ في طريقك لحلها.
إذا كنت لا تعرف مكان المشكلة في البرنامج ، فاستخدم DEBUG.
المبدأ رقم 4. تصحيح.
تأتي معظم أدوات تطوير التطبيقات بشكل قياسي مع مصحح أخطاء. سواء كان ذلك هو Macromedia Flash أو Microsoft Dot Net أو Delphi أو أي بيئة تطوير على الإطلاق سيكون هناك نوع من مصحح الأخطاء. إذا كانت الأداة لا تأتي بشكل قياسي مع مصحح أخطاء ، فيمكنك محاكاة أحدها.
أول شيء تريد القيام به مع مصحح الأخطاء هو تحديد مكان المشكلة. يمكنك القيام بذلك عن طريق إضافة نقاط توقف في المناطق الرئيسية. ثم تقوم بتشغيل البرنامج في وضع التصحيح وستعرف نقاط التوقف التي حدثت فيها المشكلة. حفر أسفل وسوف تجد البقعة. الآن بعد أن عرفت مكان المشكلة ، يمكنك “التغلب عليها ببساطة”
تتضمن الميزة الرائعة الأخرى لمعظم أدوات تصحيح الأخطاء إمكانية مشاهدة المتغيرات والقيم والمعلمات وما إلى ذلك أثناء التنقل خلال البرنامج. باستخدام هذه القيم المعروفة في خطوات معينة ، يمكنك ترميزها في “الإصدار المبسط” من البرنامج
إذا كانت أداة التطوير لا تدعم التصحيح ، فيمكنك محاكاته. ضع خطوات في البرنامج الذي ينتج قيمًا متغيرة ورسائل “مرحبًا أنا هنا” إما على الشاشة أو إلى ملف السجل أو إلى جدول قاعدة البيانات. تذكر إخراجها عند حل المشكلة … لا تريد أن يكون نظام الملفات لديك مزدحمًا أو مليئًا بملفات السجل!
المبدأ رقم 5. هناك ثروة من المعلومات حول قاعدة البيانات الخلفية التي ستساعد في حل مشكلة ما.
تم استدعاء “حل المشكلات” للمساعدة في حل مشكلة صعبة للغاية. كان هناك مشروع يقوم بترحيل النظام من حاسب مركزي إلى تقنية خادم العميل. سارت الأمور على ما يرام أثناء الاختبار ، ولكن عندما بدأ تشغيل الأنظمة ، فجأة كان هناك عدد غير قليل من “أخطاء الحماية العامة” والعشوائية تمامًا. (كان خطأ GPF هو فخ الخطأ العام في نظامي التشغيل Windows 95 و 98). تمت محاولة تبسيط الشفرة ، وتمت محاولة التصحيح ، لكن كان من المستحيل تكرارها. في بيئة LAB ، لن تحدث المشكلة! أشار تصحيح أخطاء رسائل التتبع لملفات السجل إلى أن المشكلة حدثت بشكل عشوائي للغاية. اختبرها بعض المستخدمين أكثر من غيرهم ، ولكن في النهاية سيحصل عليها جميع المستخدمين! مشكلة مثيرة للاهتمام.
قام “حلال المشكلات” بحل هذا بعد أن بدأ في تحليل قاعدة البيانات الخلفية. لست متأكدًا مما إذا كان ذلك عن طريق الصدفة أو لأنه تحرك بشكل منهجي في الاتجاه الصحيح بسبب نهج علمي. من خلال تتبع ما يحدث على المستوى الخلفي ، وجد أن كل هذه التطبيقات كانت تنشئ المزيد والمزيد من الاتصالات بقاعدة البيانات. في كل مرة يبدأ فيها المستخدم معاملة جديدة ، يتم إنشاء اتصال آخر بقاعدة البيانات. تم تحرير المجموع الكلي للاتصالات فقط عند إغلاق التطبيق. أثناء انتقال المستخدم إلى نوافذ جديدة داخل نفس التطبيق ، يتم فتح المزيد والمزيد من الاتصالات ، وبعد عدد محدد من الاتصالات ، سيكون لدى التطبيق ما يكفي ثم يتعطل. كان هذا خطأ في البرمجة في قالب تم استخدامه من قبل جميع المطورين. كان الحل أولاً اختبار ما إذا كان مؤشر قاعدة البيانات مفتوحًا بالفعل ، قبل فتحه مرة أخرى.
كيف يمكنك تتبع ما يحدث في قاعدة البيانات الخلفية؟ لدى موفري قاعدة البيانات الرئيسيين أدوات واجهة المستخدم الرسومية (GUI) التي تساعدك على تتبع أو تحليل الاستعلامات التي يتم إطلاقها على قاعدة البيانات. سيُظهر لك أيضًا عندما يتصل الأشخاص أو ينقطعون أو يتعذر عليهم الاتصال بسبب انتهاكات الأمان. تتضمن معظم قواعد البيانات أيضًا بعض جداول قاموس النظام التي يمكن الاستعلام عنها للحصول على هذه المعلومات. يمكن أن تحكي هذه الآثار أحيانًا قصة كاملة عن سبب فشل شيء ما. يمكن أن يساعد رمز الاستعلام الذي تقوم باسترداده من التتبع في “تبسيط البحث”. يمكنك أن ترى من التتبع ما إذا كان البرنامج يقوم بالاتصال بقاعدة البيانات بنجاح. يمكنك معرفة الوقت الذي يستغرقه تنفيذ الاستعلام.
للإضافة إلى المبدأ رقم 2 (لا تخف من البدء …) ؛ يمكنك تحليل معلومات التتبع هذه ، على الرغم من أنك قد لا تعرف أي شيء عن تفاصيل التطبيق.
تذكر على الرغم من أن هذه الآثار الخلفية يمكن أن تضع ضغطًا على الموارد الخلفية. لا تتركها تعمل لفترة طويلة غير ضرورية.
المبدأ رقم 6. استخدم عيون جديدة.
هذا هو المبدأ الأخير. لا تضيع الكثير من الوقت في حل المشكلة قبل أن تطلب المساعدة. لا يجب أن تكون المساعدة من شخص أعلى منك. المبدأ هو أنك بحاجة إلى زوج من العيون المنعشة لمنظور جديد وأحيانًا القليل من الهواء النقي عن طريق أخذ قسط من الراحة. سيبحث الشخص الآخر ثم يطرح سؤالاً أو اثنين. في بعض الأحيان يكون هذا أمرًا واضحًا جدًا تم تفويته. أحيانًا بمجرد الإجابة على السؤال يجعلك تفكر في اتجاهات جديدة. أيضًا ، إذا قضيت ساعات في البحث في نفس جزء الكود ، فمن السهل جدًا البدء في البحث عن خطأ سخيف. يتم حل الكثير من مشاكل الموازنة المالية عن طريق البيرة. يمكن أن يكون تغيير المشهد ، و / أو الجو المريح هو الذي سيظهر الحل. ربما يكون الأكسجين الطازج هو الذي ذهب إلى الدماغ أثناء المشي إلى الحانة. ربما لأن المشكلة نوقشت مع شخص آخر.
استنتاج
بعد قراءة هذه الورقة ، يأمل المؤلف أن تجرب هذه في المرة القادمة التي تواجه فيها مشكلة يجب حلها. نأمل من خلال تطبيق هذه المبادئ الستة أن تدرك المزايا التي تجلبها ، بدلاً من “تخمين” طريقك إلى الحل.
