أهلا ومرحبا.
في هذه المحاضرة أود أن أتحدث عن تصحيح الأخطاء.
هذا مفهوم مهم للغاية تحتاج إلى فهمه على وجه التحديد ، فأنت بحاجة إلى فهم بعض الأدوات
وبعض الطرق التي يمكنك استخدامها للعثور على الأخطاء وإصلاحها.
لذا فإن التصحيح هو عملية البحث عن الأخطاء وإصلاحها في البرنامج.
عادة الأخطاء المنطقية.
وسأخبرك بالفرق بين الأخطاء المنطقية والنحوية ، ولكن يمكن أن تتضمن أيضًا أخطاء
في بناء الجملة.
إنها العملية الكاملة لأخطاء بناء الجملة.
التصحيح هو فهم ما يخبرك به المترجم.
تريد دائمًا التركيز على إصلاح المشكلة الأولى المكتشفة.
أريد أن أتصفح بعض أخطاء المترجم الشائعة والتحذيرات التي قد تحصل عليها ، ولكن أحد
الأشياء التي تريد دائمًا معرفتها عن المترجم هو أن المترجم قد يعطيك عددًا
من الأخطاء.
تريد دائمًا التركيز على الخطأ الأول لأن هذا الخطأ الأول قد يؤدي إلى أخطاء أخرى.
لذلك قد يكون الأمر مضللًا للغاية إذا رأيت خمسة أخطاء في برنامج يخبرك بها المترجم ، فقد يكون لديك خطأ واحد
فقط وقد يتسبب هذا الخطأ الأول في حدوث أخطاء أخرى.
لذلك من المهم دائمًا إلقاء نظرة على أول خطأ رئيسي وإصلاحه أولاً.
في هذا المثال البسيط للغاية ، لدينا العديد من الأخطاء في هذا الرمز.
ليس لدينا ملف.
ليس لدينا قوس بداية أيسر ، قوس مجعد.
ليس لدينا فاصلة منقوطة.
نحن نعيد سلسلة.
لذلك عندما نحفظ هذا ونذهب لتجميعه وترى في الواقع بعض الأخطاء الحمراء
، عندما نذهب لتجميعها ، فإنها تخبرنا في الواقع أن لدينا ثلاثة أخطاء.
لا ترغب أبدًا في تحديد الخطأ الأخير في السطر السابع ، على الرغم من أنه في هذه الحالة خطأ فعلي.
تريد دائمًا إصلاح الخطأ الأول فقط.
لذلك ترى الخطأ الأول مدرجًا هنا وتقوم بإصلاح الخطأ الأول ثم تقوم بإعادة التحويل البرمجي وتشغيله مرة
أخرى.
لكن سبب القيام بذلك هو فقط لإصلاح خطأ المستوى الأعلى لأن هذا الخطأ قد يسبب مشاكل
أخرى.
لذلك ركز دائمًا على إصلاح تصحيح الأخطاء الأول وعملية البحث عن الأخطاء وإصلاحها يمكن أن تكون معقدة
للغاية من العثور على أخطاء بسيطة إلى جمع كميات كبيرة من البيانات للتحليل.
كل هذا يتوقف.
في بعض الأحيان لا تتوفر لديك أية معلومات باستثناء التسجيل ، وفي هذه الحالة يتعين عليك
تحليل الأشياء.
في بعض الأحيان سيكون لديك أخطاء لا يمكن تكرارها.
لا يمكنك إعادة إنتاجه لأنه يحدث في مثل هذه المناسبة النادرة.
هذا عادة عندما يتعين عليك تحليل السجلات أو بعض الاختلافات في ذلك.
القدرة على التصحيح من قبل المبرمج هي مهارة أساسية.
إنها حقًا مهارة لحل المشكلات يمكن أن توفر لك قدرًا هائلاً من الوقت والمال.
لذا فهي مهارة مهمة يجب تعلمها.
إنها مهارة مهمة يجب تطويرها.
يتطلب الأمر ممارسة.
أنت لن تذهب فقط إلى أنها لن تأتي إليك فقط.
هناك تقنيات معينة يمكنك تطبيقها وطرق يمكنك تطبيقها لتجعلك أفضل في تصحيح
الأخطاء.
أعرف عددًا غير قليل من المطورين الذين يجيدون حقًا كتابة البرامج في كتابة التعليمات البرمجية.
إنهم يفهمون اللغة جيدًا ، لكن مهاراتهم في تصحيح الأخطاء ضعيفة جدًا.
قد يحصلون على خطأ وميلهم الأول إلى حل هذا الخطأ هو في الحقيقة نوع من الانحراف عن المسار الصحيح.
ومرة أخرى ، يأتي هذا مع الممارسة.
ستصبح أفضل وأفضل في تصحيح الأخطاء وفهم كيفية العثور على المشكلات وإصلاحها ،
ولكن هذا شيء يجب أن تتعلمه أيضًا.
مرحلة الصيانة هي أغلى مرحلة في دورة حياة البرنامج.
مرحلة الصيانة بعد إطلاق منتجك وعليك الآن صيانته.
يعني الحفاظ عليه إصلاح أي أخطاء جديدة تأتي وكذلك إضافة ميزات جديدة.
لذلك ، على سبيل المثال ، عندما يقوم Windows بإصدار نظام تشغيل جديد مثل Windows 10 ، فإنهم لم ينتهوا
من إنتاج هذا البرنامج.
سيكون في الميدان لمدة عشر سنوات على الأرجح.
ولا تزال مسؤولية Microsoft عند ظهور أي أخطاء جديدة أو العثور على أخطاء جديدة لهذا البرنامج لإصلاحها.
ولهذا السبب يدفعون التحديثات التلقائية ويقومون بأشياء من هذا القبيل.
وبعد ذلك سيلاحظون أيضًا أن نظام التشغيل سيخرج ميزات جديدة مع تغير السوق ومع
تغير التكنولوجيا.
لذا فإن الصيانة مهمة للغاية.
ونتيجة لذلك ، فإن العثور على الأخطاء وإصلاحها أمر مهم للغاية.
افهم ، مع ذلك ، أن الأخطاء لا مفر منها.
جميع البرامج بها أخطاء.
لا أحد يستطيع كتابة كود مثالي ولا يتعلق الأمر بالضرورة بكتابة كود مثالي.
إنها مجرد أشياء تتغير بمرور الوقت.
لذلك قد ينتج عن ذلك أخطاء أيضًا.
عليك أن تفهم أن مجرد احتواء البرنامج على أخطاء لا يعني أنه مكتوب بشكل سيء.
إنه نوع لا مفر منه.
لذلك لا بأس من وجود أخطاء ، كما تعلم ، عندما تجدها وتصلحها ، يكون الأمر أكبر لأنك تشعر
في الواقع أنك تنجز شيئًا ما.
مشاكل شائعة.
وسنتحدث أكثر عن مشاكل محددة تتعلق بالرؤية.
لكن المشاكل الشائعة عند محاولة التصحيح هي أخطاء منطقية.
لا تتعلق الأخطاء المنطقية بعكس نوع الأخطاء النحوية التي تجمعها شفرتك بالفعل.
إنه يعمل ، لكنه لا يفعل ما ينوي القيام به.
لذلك هناك نوع من المنطق أو الوظيفة المقصودة غير صحيحة.
ربما يكون لديك عبارة IF وأنت تقفز إلى عبارة if على الحالة الخاطئة.
ربما لديك حلقة والحلقة لا تنفذ العدد الصحيح من المرات أو أنك لا تقوم بالفرز بشكل
صحيح.
الوظيفة معطلة ، لكن المترجم يقول ، مرحبًا ، كل شيء يبدو جيدًا.
هذا مثال على خطأ منطقي.
الخطأ المنطقي هو المكان الذي يكون فيه بناء الجملة صحيحًا ، لكن النتائج المرغوبة غير صحيحة بسبب نوع من المشاكل
المنطقية.
لذلك في هذه الشفرة ، ترى أن الحلقة for تحتوي على فاصلة منقوطة في نهايتها وهي صحيحة من الناحية التركيبية.
لكنك تتوقع أن يتم تشغيل حلقة التكرار هذه خمس مرات.
لكنها ليست كذلك.
إنه ذاهب إلى وقت تشغيل واحد فقط.
لذلك إذا قلنا إنشاء وبناء هذا المشروع ، فإننا نرى تحذيرًا ، وهو أمر رائع ويجب عليك دائمًا إصلاح جميع
تحذيراتك.
لكنها جمعت بنجاح.
لذلك عندما نقوم بتشغيل هذا المشروع ، ستلاحظ أنه في الواقع يعمل مرة واحدة فقط ويطبع Hello
World مرة واحدة.
إذن هذا مثال على خطأ منطقي.
ترتبط أخطاء بناء الجملة مباشرة بالمترجم.
هذه أشياء لا تتبع قواعد اللغة.
ليس لديك فاصلة منقوطة في نهاية العبارة.
ليس لديك نهاية ، أليس كذلك؟
أقواس مع أقواس يسار.
أنت تفتقد قوس.
أنت لا تستخدم الكلمة الأساسية الصحيحة ، أشياء من هذا القبيل.
عادة ما تحدث أخطاء في بناء الجملة بسبب أخطاء المنطق للمترجم والتي ستحدث من قبل المبرمج
أثناء مرحلة الاختبار.
يعد تلف الذاكرة أيضًا مشكلة شائعة ، خاصة في C.
إذا لم تقم بتحرير ذاكرتك بعد تخصيصها بشكل صحيح ، فيمكنك الحصول على
أشياء مثل المراجع المتدلية ويمكنك أيضًا أن تواجه مشكلات في الذاكرة تتعلق بالذاكرة التي لم يتم استخدامها.
يمكن أن يكون لديك تسرب في الذاكرة.
هنا مثال على خطأ في الذاكرة.
في هذا الكود المعين ، لدينا بالفعل تسرب للذاكرة ، لذلك لم نتحدث عن المؤشرات بعد.
لم نتحدث عن تخصيص الذاكرة الديناميكي.
لكن في C يمكنك تخصيص ذاكرة أثناء تشغيل البرنامج.
يمكنك استخدام وظيفة malloc.
وها نحن هنا نضع علامة ، نخصص ذاكرة ، لكننا لا نحررها أبدًا.
لذلك يمكننا بناء هذا الرمز ويمكننا تشغيله وكل شيء على ما يرام ، لكننا في الواقع لا نحرر هذا
الخطأ.
إذن ما يتعين علينا فعله بالفعل لتصحيح خطأ الذاكرة هذا هو أنه يتعين علينا أن نقول مجانًا ثم علينا
أن نقول مجانًا و X لتحرير هذا المؤشر.
لكن عندما تخصص ذاكرة ، لا تحررها.
هذا تسرب للذاكرة.
ومثال آخر هو إذا لم نخصص الذاكرة ، إذا أنشأنا مؤشرًا ثم حاولنا تعيينه ، فسنواجه
تلفًا في الذاكرة لأن هذه الذاكرة ليس لها أي تخصيص لها ونحن ' إعادة محاولة
إسناد قيمة لها.
هذا مجرد القليل ، قليل من بعض الأمثلة للذاكرة والفساد والأداء وقابلية التوسع.
قد تكون هذه مشكلة حيث تكون وظيفتك مقصودة كما هي وتكون التعليمات البرمجية الخاصة بك صحيحة من الناحية
التركيبية ، ولكنها ليست فعالة جدًا أو ليس لديك الأجهزة التي تدعمها.
لذلك إذا كنت تقوم بتشغيل خادم وليس لديك أجهزة كافية لدعم جميع الطلبات ، فسيتم
تشغيلها ببطء شديد.
أو إذا كتبت برنامجك للعمل مع عشرة مستخدمين ، ولكن عندما يحصل على الكثير من المستخدمين ، فربما لا
يكون بالسرعة نفسها لأن قاعدة البيانات تتعثر أو مهما كانت الحالة.
يعمل الكود ، لكنه لم يتم تصميمه بشكل صحيح للتعامل مع العديد والعديد من أعداد المستخدمين أو مهما كانت
الحالة.
عدم التماسك.
يمكن أن يكون هذا مشكلة في التعليمات البرمجية الخاصة بك مما يقلل من الجودة المتعلقة بالكود الخاص بك يقوم بالكثير أو أن الوظيفة
تقوم بالكثير من المهام.
إنه ليس تركيزًا واحدًا أو حتى أن التطبيق يحتوي على الكثير من الوظائف ، وله ميزات
لا يتم استخدامها أبدًا ، وبالتالي قد يتطلب ذلك إعادة تصميم.
هذا مثال على برنامج لن يكون نمطيًا ، وهذا ليس متماسكًا.
لديك وظيفة واحدة كبيرة تقوم بأشياء كثيرة جدًا ، مئات الأسطر من التعليمات البرمجية ، وآلاف الأسطر من التعليمات
البرمجية.
تريد تقسيم وظيفة إلى وظائف مساعدة ، وحدات منفصلة.
هذا يجعل برنامجك أكثر تماسكًا ويسهل الحفاظ عليه.
لذا فبدلاً من وجود طريقة رئيسية كبيرة تقوم بتهيئة إدخال القراءة ، ابحث عن بعضها ، واعثر على
الاختلاف ، وابحث عن المنتج ، والعثور على حاصل القسمة ، يمكنك إنشاء كل هذا الرمز ووضعه في وحدات
مساعدة وفصل الكود وبالتالي يمكن للفصل أن يساعد في العثور على وإصلاح الأخطاء الخاصة بك أسهل بكثير.
التماسك مهم دائمًا في لغة C وعادة ما يتم حله حيث يكون لديك تماسك عالٍ من خلال توفير
طرق مساعدة.
اقتران ضيق.
هذا أيضًا له علاقة بجودة الكود.
هذا هو المكان الذي لديك فيه الكثير من التبعيات.
اقتران يختلف عن التماسك.
التماسك هو تركيزك الوحيد.
الاقتران هو المكان الذي يكون لديك فيه تبعيات بين ربما وظائف أو بين الكائنات.
تحدثنا عن الاقتران ، وتحدثنا عن المتغيرات العالمية.
إذا تم استخدام متغير عام في العديد من الوظائف المختلفة ، فقد يتسبب ذلك في تبعيات
بين هذه الوظائف.
لذا فإن ما تريد السعي لتحقيقه عندما تكتب رمزًا وتكتب رمزًا عالي الجودة هو أنك
تريد أن يكون لديك تماسك عالٍ جدًا واقتران منخفض جدًا.
عملية التصحيح.
أول شيء عليك القيام به قبل أن تجد أي خطأ وإصلاحه هو أن تفهم المشكلة.
هذا مرتبط فقط بعدم الغوص والبدء في النظر إلى الكود ، والجلوس مع المختبِر
، وفهم المتطلبات ، وفهم ما يحدث.
لأنه إذا لم تفهم ما يحدث ، فلن تكون قادرًا حتى على ذلك.
يجب ألا تحاول حتى محاولة حلها.
بمجرد فهم الخطأ ، حاول إعادة إنتاجه لأن إعادة إنتاج الخطأ يمكن أن يساعدك في جمع المزيد
من المعلومات.
ليس من الممكن دائمًا إعادة إنتاج الأخطاء لأنها قد تحدث في ظروف نادرة حقًا.
على سبيل المثال ، قد تحدث الأخطاء التي لها ظروف عرقية أو حتى تلف الذاكرة فقط في
حالات استخدام محددة جدًا وقد تكون مشكلات متقطعة.
وهل هذا هو الحال؟
ولا يمكنك إعادة إنتاجه.
سيصبح تصحيحه أكثر صعوبة وأصعب.
إذا كنت قادرًا على إعادة إنتاجه ، فيمكنك عادةً جمع معلومات كافية لإصلاحه.
معظم المشاكل قابلة للحل.
أيضًا ، يمكن أن تواجه مشكلات في عدم القدرة على إعادة إنتاج مشكلة إذا كنت تستخدم بيئة متعددة مؤشرات
الترابط أو عمليات متوازية أو مشكلات خيوط.
من الصعب جدًا تصحيح هذه الأخطاء ، لكن حاول بالتأكيد إعادة إنتاجها بمجرد اكتشاف
المشكلة في الواقع من حيث قدرتك على فهم ما إذا كنت قادرًا على التكاثر ، إذا لم تكن كذلك
، فحينئذٍ تريد محاولة الاقتراب من تطبيق نوع من فرق تسد.
أنت تريد محاولة عزل الخطأ ، وتبسيط المشكلة ، لأن القدرة على تقليلها ستعيد لك المعلومات
، ولكنها قد لا تخبرك بالضرورة عن جزء الكود الذي يوجد به الخطأ.
لذا ما يمكنك القيام به لمحاولة تبسيط المشكلة هو إزالة أجزاء من حالة الاختبار الأصلية بحيث
لا تختبر الكثير.
يمكنك عزل المشكلة بشكل أصغر بقول ، أوه ، هذا يحدث فقط في هذه الحالة المحددة.
يمكنك أيضًا التعليق على الكود.
تحدثنا عن الدوال التي تحتوي على أبتر فقط وليس لها تنفيذ.
في بعض الأحيان يتم استخدام هذا في الاختبار بحيث يمكن أن يحد من مجموعة المشكلات.
أيضًا ، إذا قمت بالتعليق على الكود ، فستحصل على كود أقل حيث يمكن أن يحدث الخطأ بالفعل.
لذا ، أثناء قيامك بالتعليق على التعليمات البرمجية أو التراجع عن التغييرات ، قد يختفي الخطأ وإذا اختفى الخطأ
، فإن هذا يخبرك أن الشفرة التي علقت عليها ربما تسبب في ذلك.
ما تريد القيام به أساسًا هو تحويل برنامج كبير إلى الكثير من البرامج الصغيرة ، إما عن
طريق الاختبار أو التعليق.
أسلوب آخر شائع هو إجراء اختبارات وحدة حول التعليمات البرمجية الخاصة بك.
إذا فشل اختبار الوحدة ، فيمكن أن يخبرك ذلك بالضبط بالمكان الذي قد يكون فيه المنطق أو المشكلة في التعليمات البرمجية الخاصة بك.
بمجرد عزل الخطأ ، ستساعدك أنت وهذا في العثور على أصل المشكلة في الكود ، الرمز المحدد
الذي يسبب المشكلة.
في بعض الأحيان سيستخدم هذا استخدام أدوات التصحيح مثل مصحح الأخطاء.
سنتحدث عن مصحح أخطاء في التفاصيل ، ولكن اعتمادًا عادةً على تطوير IDE المتكامل الذي
تستخدمه ، توجد مصححات أخطاء تأتي مع IDE.
هناك أيضًا مصححات يمكن أن تصل إلى مستوى مستقل.
المصحح المهم الكبير الذي سنستخدمه لبرمجة لغة سي يسمى GDB.
إنه مصحح أخطاء GNU ، لذا فهو أداة رائعة هي في الواقع أداة رسومية حيث يمكنك
إيقاف تنفيذ برنامجك وإضافة نقاط توقف.
وبعد ذلك ، عندما توقف التنفيذ ، يمكنك الانتقال سطراً بسطر في التعليمات البرمجية الخاصة بك وإلقاء نظرة على قيمة المتغيرات.
حتى تتمكن من رؤية ما يحدث بالضبط في التعليمات البرمجية الخاصة بك أثناء تشغيلها.
إنها أداة لا تقدر بثمن.
انها مجرد مفيدة جدا.
سنقوم بتشغيل مصحح الأخطاء.
سأوضح لك كيفية إضافة نقاط التوقف.
سأوضح لك كيفية إعداد ساعة حتى تتمكن من إلقاء نظرة على المتغيرات أثناء تغيرها وأيضًا التنقل خلال
الشفرة.
بعد تحديد أصل المشكلة ، عليك حينئذٍ إصلاحها.
هذا يتطلب الكثير من الخبرة والممارسة.
فقط لأنك وجدت أصل المشكلة ، قد لا تتمكن من إصلاحها فقط بناءً
على تجربتك.
يتضمن هذا أحيانًا إعادة تصميم أو إعادة هيكلة التعليمات البرمجية الأخرى التي قد تضطر إلى إعادة التصميم
خاصة مع مشاكل قابلية التوسع أو مشاكل الأداء للسماح لبرنامجك بأن يكون أكثر قابلية للتوسع.
لذلك ليس من السهل دائمًا العثور على المشكلة ثم إصلاحها.
المشكلة في بعض الأحيان ، خاصة حتى المشكلات الأكثر صعوبة مثل الخيوط أو المعالجة
المتوازية ، يصعب إصلاحها.
ولكن كلما كتبت المزيد والمزيد من الأكواد ، سيصبح القيام بذلك أسهل.
ثم أخيرًا ، عليك أن تختبر بجنون.
اختبر دائمًا العديد من الحدود المختلفة.
حالات جيدة ، وحالات سيئة بين الحالات للتحقق من أنك قد أصلحت المشكلة بالفعل.
بعض التقنيات والأدوات المتوفرة.
إحدى الأدوات الشائعة والمستخدمة للغاية هي استخدام بيانات الطباعة.
يمكنك استخدام بيانات الطباعة لتتبع التعليمات البرمجية بشكل أساسي.
لذلك في C ، يمكنك استخدام عبارة print F ويمكنك وضعها في عدة أسطر في التعليمات البرمجية الخاصة بك للإشارة
إلى مكانك.
هذا مفيد أيضًا ومفيد جدًا عند تعطل برنامجك.
يمكن أن يساعد في تحديد مكان تحطمها.
أثناء قيامك بإضافة عبارات الطباعة هذه التي تتتبع من خلال التعليمات البرمجية الخاصة بك ، يمكنك
إضافة مخرجات في عبارات الطباعة لمعرفة قيمة المتغيرات لأن قيمة المتغيرات قد تؤثر على الحالة
وقد تسبب مشاكل منطقية.
لذا فإن مجرد إضافة تعليمات الطباعة أمر مفيد للغاية.
يمكن أن يظهر تدفق التنفيذ ويمكن أن يساعد في عزل الخطأ.
المصححات كما ذكرت في GDB ، هؤلاء يمكنهم مراقبة تنفيذ البرنامج.
يمكنك إيقافه ، يمكنك تشغيل سطر بسطر ، وإعادة تشغيله ، وتعيين نقاط التوقف ، ومشاهدة المتغيرات والذاكرة.
مفيد جدًا جدًا عند محاولة تشخيص مكان وجود مشكلة.
ملفات الدخول.
تعد ملفات السجل مفيدة جدًا أيضًا ، خاصةً بالنسبة للأخطاء التي لا يمكن إعادة إنشائها.
يمكنك تحليلها في وقت لاحق لترى بالضبط ما كان يحدث عندما حدث الخطأ.
هذا يعني أنه يجب عليك تقديم بيانات تسجيل جيدة في التعليمات البرمجية نفسها حتى
يكون هذا مفيدًا.
لذلك يمكنك إنشاء ملف السجل الخاص بك ثم الكتابة إلى ذلك السجل أثناء تشغيل البرنامج بحيث إذا كان لديك خطأ
، فيمكنك إرسال هذه السجلات إلى المطورين.
نحن نستخدم هذا كثيرًا في Xerox لأنه عندما نواجه مشكلات ، لا يمكننا دائمًا إعادة إنتاجها
أو قد نواجهها في الميدان.
نحتاج إلى أن نكون قادرين على الوصول إلى تلك السجلات لمعرفة ما كان يحدث عندما حدث هذا الخطأ.
برمجيات المراقبة.
هناك برنامج يمكنه مراقبة استخدام الذاكرة وتحليل وقت التشغيل وتهديد حركة مرور الشبكة ومعلومات
الكائن.
يمكن أن يخبرك هذا إذا ربما كنت تخصص الكثير من الذاكرة ولا تحذفها.
إذا كان لديك أداة لحركة مرور شبكة استخدام الذاكرة يمكنها إخبارك بما إذا كنت ترسل
الكثير من الحزم أم لا أو ما إذا كان برنامجك قابلاً للتطوير أم لا ، إذا كان لديك زيادة
في حركة مرور الشبكة وترى أن استجابتك الوقت مهين.
يمكنك أيضًا مراقبة معلومات الخيوط والكائنات للمعالجة المتوازية لمعرفة ما يحدث في خيوط
معينة وما يحدث في سلسلة رسائل أخرى.
سيساعدك ذلك في تشخيص أي نوع من مشاكل الخيط.
بعض أدوات تصحيح الأخطاء الشائعة الأخرى التي يمكنك استخدامها للعثور على أخطائك وإصلاحها.
يمكنك استخدام معالجة الاستثناءات.
العديد من لغات البرمجة لديها معالجة استثناء.
لسوء الحظ ، فإن C ليس معالج استثناء سيمنع بالفعل الأعطال ويفعل الكثير من الأشياء في وقت
التشغيل.
لا ينطبق الأمر على الرؤية ، لكن لا يزال من الجيد فهمه.
كتل Trycatch ، أشياء من هذا القبيل.
محللات ثابتة.
هناك العديد من أجهزة التحليل الاستاتيكية المتاحة لأجهزة التحليل الاستاتيكية C.
تحليل شفرة المصدر بدون الملف القابل للتنفيذ الفعلي.
لا يحتاج تشغيل البرنامج إلى التشغيل.
يذهب سطرا بسطر وينظر في شفرة المصدر.
وحيث إنه يقوم بتحليل الكود المصدري ، فإنه يبحث عن أي مشاكل معروفة.
حتى تتمكن من التحقق من الدلالات.
يمكنه التأكد من ذلك.
هذا كل شيء.
ليس لديك أي متغيرات غير مهيأة إذا كنت تقوم بتخصيص ذاكرة جديدة تقوم بحذفها.
إذا كان لديك أي كود معطل حيث لم يتم تنفيذ الكود بالفعل ، يمكنك حذف هذا الرمز.
كما أنه يحلل أشياء مثل ظروف السباق والمآزق.
نحن نوظف اثنين من المحللين الاستاتيكيين حيث أعمل.
لدينا واحدة تسمى Coverity ، وهي شائعة جدًا ، وهناك أداة ترميز سونار نستخدمها أيضًا ، وسنقوم بتشغيلها
على خط الأساس بالكامل ، مجموعة المصادر بالكامل.
وكلما قدمنا ملفات جديدة ورمزًا جديدًا ، سيتم تشغيل هذه الأداة على هذا الرمز وستكون قادرة على تحديد المشكلات
العاجلة مع الكود فيما يتعلق بالمتغيرات غير المهيأة وتسرب الذاكرة وما إلى ذلك.
لا يحلل بناء الجملة.
هذا هو الغرض من المترجم.
هناك أيضًا عدد من مجموعات الاختبار التي تشغل مجموعة من الاختبارات الشاملة للنظام الشامل والتي يمكنك
تشغيلها على برنامجك.
يعد الاختبار دائمًا أمرًا مهمًا ، ولكن إذا كان بإمكانك جعله آليًا بطريقة ما لتشغيل اختبارات معينة في كل مرة تقوم
فيها ببناء جديد ، على سبيل المثال ، فقد يكون ذلك مفيدًا للغاية ويمكن أن يؤدي ذلك بالفعل إلى منع الأخطاء
، ولكنه يساعد أيضًا في تشخيص الأخطاء أيضًا.
تصحيح أخطاء البرنامج بعد تعطله.
سنتحدث عن شيء يسمى مكدس المكالمات.
هذه آلية مفيدة للغاية لمعرفة ، خاصة في لغة مثل C ، حيث يكون لديك تعطل وكل المعلومات الوحيدة
التي تحصل عليها هي شيء مثل خطأ التجزئة.
عندما يكون لديك هذا الانهيار ، ما يحدث كثيرًا من الوقت ، اعتمادًا على كيفية تعطله ، سيتم إنشاء
ملف أساسي ويمكنك تحليل الملف الأساسي لإلقاء نظرة على مكدس الاستدعاءات لمعرفة مكان توقف هذا البرنامج
بالضبط.
سيخبرك سطر الكود حيث توقف البرنامج.
ولذا سوف نتعرف على مكدس الاستدعاءات.
وبقدر ما يتعلق بتحليل الملفات الأساسية ، فهذه أكثر من تقنية متقدمة.
ولكن في لغة C ، يمكن إنشاء ملف أساسي ويمكنك تحليله.
هذه تقنية أكثر تقدمًا ، ولكن هذه طريقة أخرى يمكنك من خلالها تصحيح الأخطاء على برنامجك.
ماذا عن منع الأخطاء؟
نحن نعلم أن تصحيح الأخطاء هو العثور على الأخطاء وإصلاحها ، ولكن إذا كان بإمكانك منع الأخطاء ، فهذا أفضل.
تتمثل إحدى الطرق التي يمكنك من خلالها منع الأخطاء في كتابة رمز عالي الجودة.
هذا في الحقيقة لا يركز على العديد من مهندسي البرمجيات.
يكتب الكثير من مهندسي البرمجيات الكود ، وطالما أنه يعمل ، هذا كل
ما يهمهم أو طالما أن المخرجات صحيحة ، فإنهم يعتبرون أنفسهم قد أنجزوا.
ولكن هناك شيء اسمه كود رديء الجودة ولا تريد أن تكتبه.
لقد أوضحت بعضًا من هذا خلال المحاضرات ، لكن أشياء مثل استخدام أسماء متغيرة ذات مغزى
مهمة جدًا.
أو إذا كتبت رمزًا غير فعال حيث تستخدم الحلقات ، فربما تكون أكثر مما تحتاج إليه ، أو تستخدم
عبارة if أو لا تحتاج إلى فعل ذلك.
كل هذه الأنواع من الأشياء تشكل كودًا ذا جودة رديئة.
إذا كانت لديك وظيفة تقوم بـ 100 شيء آخر ولم تكن متماسكة ، إذا كان لديك 5000 سطر في دالة
، أو إذا لم يتم تنظيم الكود بطريقة معيارية أو إذا كان لديك العديد من التبعيات
بين الوظائف ، مرة أخرى ، كل هذا سيئ رمز الجودة وتريد أن تسعى جاهدة لعدم القيام بذلك.
تريد استخدام تقنيات حيث يتم تنظيم برنامجك.
من السهل صيانتها ، وهي متماسكة للغاية ، ولديها اقتران منخفض ، وتستخدم أسماء متغيرة ذات
معنى.
مهم جدا جدا.
مرة أخرى ، إنه مهم جدًا أيضًا لأن مرحلة الصيانة باهظة الثمن جدًا.
إذا قمت بكتابة كود رديء الجودة ، يصبح الحفاظ عليه أكثر صعوبة.
يصعب عزل الأخطاء ويصعب إضافة ميزات جديدة.
لذلك الموظف تقنيات عالية الجودة عند كتابة التعليمات البرمجية الخاصة بك.
اختبارات الوحدة.
تساعد اختبارات الوحدة على منع الأخطاء بشكل كبير.
عادةً ما يتم تنفيذ اختبارات الوحدة تلقائيًا عند تجميع اختبارات الوحدة التي يمكن أن تساعد في تجنب الانحدار.
هذا أحد أهم العوامل.
يحدث الانحدار عندما تكتب رمزًا جديدًا وتقوم بإدخال خطأ في شيء كان يعمل سابقًا.
لقد كسرت القانون القديم.
أنت لا تريد أن تفعل ذلك.
إذا كانت بعض البرامج تعمل ثم هناك شيء جديد قمت بتكسيره ، فأنت تريد أن يتم إعلامك على الفور ويمكن
أن تساعد اختبارات الوحدة في القيام بذلك لأن اختبارات الوحدة ستعمل على هذا الكود القديم وسيقول ، مرحبًا
، لقد كان هذا يعمل ، لقد أصبح الآن فشل.
يمكنه أيضًا العثور على أخطاء في الكود الجديد قبل تسليمه ، لأنه مرة أخرى ، يتم تشغيلها بعد الإنشاء
وسيخبرك على الفور بوجود خطأ ما.
هناك مفهوم للتطوير المدفوع بالاختبار والذي أصبح شائعًا حقًا.
هذا هو المكان الذي تكتب فيه اختباراتك أولاً ثم تطور الكود الخاص بك بعد ذلك.
والهدف هنا هو عندما تكتب الاختبار الأول ، فإن اختبارك يفشل ، ثم تكتب الكود
لاجتيازه.
هناك الكثير من المزايا لـ TDD وهي طريقة عكسية في التفكير.
عادةً عندما يكتب الأشخاص رمزًا ، يكتبون الرمز أولاً ثم يكتبون الاختبار بعد ذلك.
لكن مع TDD ، يمنحك في الواقع طريقة مختلفة في التفكير بحيث تعمل في أجزاء صغيرة جدًا
وتميل إلى كتابة رمز متماسك جدًا وليس لديك رمز ، وليس لديك الكثير من التبعيات
لأن التخمين ماذا؟
إذا كنت قادرًا على اختبار الكود ، فهذا يعني أن الكود لا يحتوي على العديد من التبعيات.
إذا كان اختبار الوحدة الخاص بك كبيرًا حقًا وكنت تسخر من كل هذه الأشياء المختلفة
، فعادة ما يكون هذا مؤشرًا كبيرًا على أن شفرتك تعتمد بشكل كبير جدًا على أشياء أخرى.
لذلك ، من خلال استخدام TDD ، فإنه يجبرك على كتابة تعليمات برمجية مترابطة بشكل غير محكم لا تحتوي على تبعيات
ويجبرك على أن تكون وظائفك متماسكة للغاية.
هناك الكثير من مزايا TDD.
تريد أيضًا تقديم وثائق جيدة وتريد القيام بالتخطيط المناسب.
لا تغوص في الكود فقط وابدأ في التنفيذ.
اكتب تصميمك على الورق.
استخدم الكود الكاذب.
يمين.
خطط للكود الخاص بك.
إذا كنت تخطط للرمز الخاص بك ، فأنت تفهم المتطلبات ولديك تصميم مدروس جيدًا ، يمكنك منع
العديد والعديد من الأخطاء.
وقد ذكرت هذا طوال الدورة التدريبية ، ولكن من المهم جدًا جدًا أن يكون لديك أسلوب
فرق تسد ، والعمل في خطوات صغيرة واختباره باستمرار بعد كل خطوة ، ولا تكتب 1000 سطر من التعليمات البرمجية
ثم قل ، حسنًا ، قم بتجميع والاختبار.
هذا ليس نهجا جيدا.
تجنب الكثير من التغييرات دفعة واحدة.
عند إجراء التغييرات ، قم بتطبيقها بشكل تدريجي ، وأضف تغييرًا واحدًا ، ثم اختبرها جيدًا قبل البدء في الخطوة
التالية.
يمكن أن يساعد ذلك في تقليل جميع أنواع الأخطاء كما أنه يحد من مجموعة المشكلات الخاصة بك.
لذلك إذا كان لديك خطأ ، فأنت تعرف على الفور مكانه في الكود لأنك جمعت
للتو وأضفت هذا السطر أو عدد الأسطر.
مرة أخرى ، لا يمكنني التأكيد على أهمية تصحيح الأخطاء في كتابة تعليمات برمجية عالية الجودة ، ومنع الأخطاء.
ستوفر لك تقنيات حل المشكلات هذه الكثير من الوقت وتجعلك أفضل مبرمج من الدرجة
الأولى.
لذا في المحاضرات القليلة القادمة ، أريد أن أتحدث عن بعض الأخطاء الشائعة التي نراها في لغة البرمجة
c c.
أيضًا ، أريد أن أتحدث قليلاً عن مكدس المكالمات.
أريد أن أتصفح مصحح الأخطاء الذي يقدم لك خيارات القائمة وكيف يمكنك إيقاف الساعات وتشغيلها
وما إلى ذلك.
وأريد أيضًا المساعدة في تحديد بعض أخطاء المترجم الشائعة التي تراها في كيفية تفسير المحولات وتحذيرات وأخطاء
المحول البرمجي.
ماذا يعني إذا قال المترجم هذا؟
ماذا يعني إذا أعطاك المترجم هذا التحذير؟
شكرًا لك.