هذه المقالة هي قصة كيف قررنا ذات مرة تحسين أداة SelfTester الداخلية التي نطبقها لاختبار جودة محلل PVS-Studio. كان التحسن بسيطًا ويبدو أنه مفيد ، لكنه جعلنا نتعرض لبعض المشكلات. في وقت لاحق اتضح أننا تخلى عن الفكرة بشكل أفضل.
SelfTester
نحن نقوم بتطوير وتعزيز محلل الشفرة الثابتة PVS-Studio لنظام C و C ++ و C # و Java. لاختبار جودة محلل لدينا نستخدم الأدوات الداخلية ، وتسمى عموما SelfTester. أنشأنا إصدار SelfTester منفصل لكل لغة معتمدة. يرجع ذلك إلى تفاصيل الاختبار ، وهو أكثر ملاءمة. وبالتالي ، لدينا في الوقت الحالي ثلاث أدوات SelfTester داخلية في شركتنا من أجل C \ C ++ و C # و Java ، على التوالي. علاوة على ذلك ، سوف أخبرك عن إصدار Windows من SelfTester لمشاريع Visual Studio C \ C ++ ، واصفًا إياه باسم SelfTester. كان هذا الاختبار الأول في خط الأدوات الداخلية المشابهة ، إنه الأكثر تقدمًا وتعقيدًا على الإطلاق.
كيف يعمل SelfTester؟ الفكرة بسيطة: خذ مجموعة من مشاريع الاختبار (نستخدم مشاريع حقيقية مفتوحة المصدر) وتحليلها باستخدام PVS-Studio. نتيجة لذلك ، يتم إنشاء سجل محلل لكل مشروع. تتم مقارنة هذا السجل مع السجل
المرجعي للمشروع نفسه. عند مقارنة السجلات ، يُنشئ SelfTester
ملخصًا للسجلات بمقارنتها بطريقة ملائمة للمطور.
بعد دراسة الملخص ، يخلص المطور إلى التغييرات في سلوك المحلل وفقًا لعدد ونوع التحذيرات وسرعة العمل وأخطاء المحلل الداخلي وما إلى ذلك. كل هذه المعلومات مهمة للغاية: فهي تتيح لك أن تكون على دراية بكيفية تعامل المحلل مع عمله.
استنادًا إلى ملخص مقارنة السجلات ، يقدم المطور تغييرات في قلب المحلل (على سبيل المثال ، عند إنشاء قاعدة تشخيصية جديدة) ويتحكم فورًا في نتائج تعديلاته. إذا لم يكن لدى أحد المطورين أية مشكلات في سجل منتظم مقارنة ، فإنه يجعل
مرجع سجل التحذيرات
الحالي لمشروع. خلاف ذلك ، يستمر العمل.
لذلك ، فإن مهمة SelfTester هي العمل مع مجموعة من مشاريع الاختبار (بالمناسبة ، هناك أكثر من 120 منها لـ C / C ++). يتم تحديد مشاريع التجمع في شكل حلول Visual Studio. يتم ذلك من أجل التحقق من عمل المحلل في إصدارات Visual Studio المختلفة ، والتي تدعم المحلل (في هذه المرحلة من Visual Studio 2010 إلى Visual Studio 2019).
ملاحظة: علاوة على ذلك ، سأفصل بين
الحل والمشروع ، مع الأخذ في الاعتبار المشروع كجزء من الحل.
تبدو واجهة SelfTester على النحو التالي:
على اليسار توجد قائمة من الحلول ، على اليمين - نتائج فحص لكل إصدار من إصدارات Visual Studio.
تشير التسميات الرمادية "غير مدعومة" إلى أن الحل لا يدعم إصدار Visual Studio المختار أو أنه لم يتم تحويله لهذا الإصدار. تحتوي بعض الحلول على تكوين في مستودع ، يشير إلى إصدار Visual Studio محدد لإجراء فحص. إذا لم يتم تحديد إصدار ، فسيتم تحديث حل لجميع إصدارات Visual Studio اللاحقة. يوجد مثال على هذا الحل في لقطة الشاشة - "smart_ptr_check.sln" (يتم إجراء فحص لجميع إصدارات Visual Studio).
تشير العلامة الخضراء "موافق" إلى أن الفحص الدوري لم يكشف عن الاختلافات في السجل المرجعي. تشير العلامة الحمراء "Diff" إلى الاختلافات. هذه التسميات يجب أن تولى اهتماما خاصا. بعد النقر مرتين على الملصق المطلوب ، سيتم فتح الحل الذي تم اختياره في إصدار Visual Studio ذي الصلة. سيتم أيضًا فتح نافذة بها سجل تحذيرات. تتيح لك أزرار التحكم الموجودة في الجزء السفلي إعادة تشغيل تحليل الحلول المحددة أو كافة الحلول ، وجعل المرجع المختار (أو دفعة واحدة) ، إلخ.
يتم تكرار نتائج SelfTester دائمًا في تقرير html (تقرير الفرق)
بالإضافة إلى واجهة المستخدم الرسومية ، يحتوي SelfTester أيضًا على أوضاع تلقائية للتشغيل الليلي. ومع ذلك ، فإن النمط المعتاد لنمط الاستخدام المعتاد يديره المطور خلال يوم العمل. لذلك ، واحدة من أهم خصائص SelfTester هي سرعة العمل.
لماذا السرعة مهمة:
- أداء كل خطوة أمر بالغ الأهمية من حيث تشغيل الاختبار الليلي. من الواضح أنه كلما كانت الاختبارات أسرع ، كان ذلك أفضل. في الوقت الحالي ، يتجاوز متوسط وقت أداء SelfTester ساعتين ؛
- عند تشغيل SelfTester خلال اليوم ، يتعين على المطور الانتظار أقل للنتيجة ، مما يزيد من إنتاجية القوى العاملة لديه.
لقد كان تسريع الأداء هو السبب وراء التحسينات هذه المرة.
خيوط متعددة في SelfTester
تم إنشاء SelfTester في البداية كتطبيق متعدد مؤشرات ترابط مع القدرة على اختبار عدة حلول في وقت واحد. كان القيد الوحيد هو أنه لا يمكنك التحقق من نفس الحل في وقت واحد لإصدارات Visual Studio المختلفة ، لأن العديد من الحلول تحتاج إلى تحديث لإصدارات معينة من Visual Studio قبل الاختبار. خلال ذلك ، يتم إدخال التغييرات مباشرةً في ملفات مشاريع
.vcxproj ، مما يؤدي إلى حدوث أخطاء أثناء التشغيل المتوازي.
من أجل جعل العمل أكثر كفاءة ، يستخدم SelfTester جدولة مهمة ذكية لتعيين قيمة محدودة للغاية للمواضيع المتوازية والمحافظة عليها.
يستخدم مخطط على مستويين. الأول هو مستوى
الحلول ، ويستخدم لبدء اختبار الحل
.sln باستخدام الأداة المساعدة
PVS-Studio_Cmd.exe . يتم استخدام الجدولة نفسها ، ولكن مع إعداد آخر
لدرجة التوازي ، داخل
PVS-Studio_Cmd.exe (في مستوى اختبار
الملفات المصدر).
درجة التوازي هي معلمة تشير إلى عدد مؤشرات الترابط المتوازية التي يجب تشغيلها في وقت واحد. تم اختيار
أربعة وثمانية قيم افتراضية للحصول على درجة التوازي للحلول ومستوى الملفات ، على التوالي. وبالتالي ، يجب أن يكون عدد مؤشرات الترابط المتوازية في هذا التطبيق 32 (4 حلول تم اختبارها في وقت واحد و 8 ملفات). يبدو هذا الإعداد هو الأفضل بالنسبة لنا للعمل على محلل ثمانية النواة.
يمكن للمطور تعيين قيم أخرى لدرجة التوازي بنفسه وفقًا لأداء جهاز الكمبيوتر أو المهام الحالية. إذا لم يحدد المطور هذه المعلمة ، فسيتم اختيار عدد معالجات النظام المنطقي افتراضيًا.
ملاحظة: لنفترض كذلك أننا نتعامل مع الدرجة الافتراضية من التوازي.
يتم توارث جدولة
LimitedConcurrencyLevelTaskScheduler من
System.Threading.Tasks.TaskScheduler وتنقيحها لتوفير الحد الأقصى لمستوى التوازي عند العمل على
ThreadPool . التسلسل الهرمي الميراث:
LimitedConcurrencyLevelTaskScheduler : PausableTaskScheduler { .... } PausableTaskScheduler: TaskScheduler { .... }
يسمح لك
PausableTaskScheduler بإيقاف أداء المهمة مؤقتًا ، وبالإضافة إلى ذلك ، يوفر
LimitedConcurrencyLevelTaskScheduler تحكمًا فكريًا في قائمة انتظار المهام وجدولة أدائها ، مع مراعاة درجة التوازي ونطاق المهام المجدولة وعوامل أخرى. يتم استخدام برنامج جدولة عند تشغيل مهام
LimitedConcurrencyLevelTaskScheduler .
أسباب التحسينات
تحتوي العملية الموضحة أعلاه على عيب: فهي ليست مثالية عند التعامل مع حلول بأحجام مختلفة. وحجم الحلول في مجموعة الاختبارات متنوع
للغاية : من 8 كيلوبايت إلى 4 جيجابايت - حجم المجلد الذي يحتوي على حل ومن 1 إلى عدة آلاف من ملفات التعليمات البرمجية المصدر في كل ملف.
يضع المجدول الحلول في قائمة الانتظار ببساطة واحدة تلو الأخرى ، دون أي مكون ذكي. اسمحوا لي أن أذكرك أنه لا يمكن افتراضيًا اختبار أكثر من أربعة حلول في وقت واحد. إذا تم اختبار أربعة حلول كبيرة حاليًا (عدد الملفات في كل منها يزيد عن ثمانية) ، فمن المفترض أننا نعمل بفعالية لأننا نستخدم أكبر عدد ممكن من سلاسل الرسائل (32).
ولكن دعونا نتخيل موقفًا متكررًا إلى حد ما ، عند اختبار العديد من الحلول الصغيرة. على سبيل المثال ، حل واحد كبير ويحتوي على 50 ملفًا (سيتم استخدام الحد الأقصى لعدد مؤشرات الترابط) ، بينما يحتوي ثلاثة حلول أخرى على ثلاثة أو أربعة أو خمسة ملفات لكل منها. في هذه الحالة ، سنستخدم فقط 20 مؤشر ترابط (8 + 3 + 4 + 5). نحصل على قلة استخدام وقت المعالج وخفض الأداء الكلي.
ملاحظة : في الواقع ، يكون عنق الزجاجة هو النظام الفرعي للقرص ، وليس المعالج.
تحسينات
التحسن الواضح في هذه الحالة هو ترتيب قائمة الحلول التي تم اختبارها. نحتاج إلى الحصول على الاستخدام الأمثل لعدد محدد من مؤشرات الترابط التي يتم تنفيذها في وقت واحد (32) ، بالانتقال إلى اختبار المشاريع باستخدام العدد الصحيح من الملفات.
لننظر مرة أخرى في مثالنا المتمثل في اختبار أربعة حلول مع العدد التالي من الملفات في كل منها: 50 و 3 و 4 و 5. من المرجح أن تعمل المهمة التي تتحقق من حل
ثلاثة ملفات بشكل أسرع. سيكون من الأفضل إضافة حل مع ثمانية ملفات أو أكثر بدلاً من ذلك (من أجل استخدام الحد الأقصى من مؤشرات الترابط المتوفرة لهذا الحل). بهذه الطريقة ، سنستخدم 25 موضوعًا في آن واحد (8 +
8 + 4 + 5). ليس سيئا ومع ذلك ، لا تزال سبعة مؤشرات ترابط. وهنا تأتي فكرة تحسين آخر ، وهو إزالة حدود المواضيع الأربعة في حلول الاختبار. لأنه يمكننا الآن إضافة لا أحد ، ولكن العديد من الحلول ، باستخدام 32 مؤشر ترابط. دعونا نتخيل أن لدينا حلين آخرين من ثلاثة وأربعة ملفات لكل منهما. ستؤدي إضافة هذه المهام إلى إغلاق "فجوة" المواضيع غير المستخدمة تمامًا ، وسيكون هناك 32 (8 + 8 + 4 + 5 +
3 +
4 ) منها.
نأمل أن تكون الفكرة واضحة. في الواقع ، فإن تنفيذ هذه التحسينات لم يتطلب الكثير من الجهد. تم كل شيء في يوم واحد.
نحن بحاجة إلى إعادة صياغة فئة المهمة: وراثة من
System.Threading.Tasks.Task وتعيين الحقل "الوزن". نستخدم خوارزمية بسيطة لضبط الوزن على حل: إذا كان عدد الملفات أقل من ثمانية ، فإن الوزن يساوي هذا الرقم (على سبيل المثال ، 5). إذا كان الرقم أكبر من أو يساوي ثمانية ، فسيكون الوزن مساويًا لثمانية.
كان علينا أيضًا إعداد الجدولة: قم بتعليمها لاختيار الحلول ذات الوزن المطلوب للوصول إلى القيمة القصوى 32 سلاسل. كان علينا أيضًا أن نسمح بأكثر من أربعة خيوط لاختبار الحلول المتزامنة.
أخيرًا ، كنا نحتاج إلى خطوة أولية لتحليل جميع الحلول في المجموعة (التقييم باستخدام MSBuild API) لتقييم وضبط وزن الحلول (الحصول على أعداد من الملفات باستخدام الكود المصدري).
نتيجة
أعتقد أنه بعد هذه المقدمة الطويلة ، لقد خمنت بالفعل أن لا شيء قد جاء منها.
إنه جيد رغم أن التحسينات كانت بسيطة وسريعة.
هنا يأتي هذا الجزء من المقال ، حيث سأخبرك بما "دفعنا إلى العديد من المشاكل" وكل الأشياء المتعلقة به.
آثار جانبية
لذلك ، نتيجة سلبية هي أيضا نتيجة. اتضح أن عدد الحلول الكبيرة في المجموعة
يتجاوز بكثير عدد الحلول الصغيرة (أقل من ثمانية ملفات). في هذه الحالة ، لا يكون لهذه التحسينات تأثير ملحوظ للغاية ، حيث إنها غير مرئية تقريبًا: يستغرق اختبار المشروعات الصغيرة وقتًا صغيرًا جدًا مقارنة بالوقت اللازم للمشروعات الكبيرة.
ومع ذلك ، قررنا ترك التحسين الجديد "غير مقلق" ويحتمل أن يكون مفيدًا. بالإضافة إلى ذلك ، يتم تجديد مجموعة حلول الاختبار باستمرار ، لذلك في المستقبل ، ربما ، سيتغير الوضع.
وبعد ذلك ...
أحد المطورين اشتكى من تحطم SelfTester. حسنا ، الحياة تحدث. لمنع هذا الخطأ من الضياع ، أنشأنا حادثة (تذكرة) داخلية باسم "استثناء عند العمل مع SelfTester". حدث الخطأ أثناء تقييم المشروع. على الرغم من أن عددًا كبيرًا من الإطارات التي بها أخطاء تشير إلى المشكلة مرة أخرى في معالج الأخطاء. ولكن تم القضاء على هذا بسرعة ، وعلى مدار الأسبوع المقبل لم يتحطم شيء. فجأة ، اشتكى مستخدم آخر من SelfTester. مرة أخرى ، خطأ تقييم المشروع:
هذه المرة احتوى المكدس على الكثير من المعلومات المفيدة - كان الخطأ بتنسيق xml. من المحتمل ، أنه عند معالجة ملف مشروع
Proto_IRC.vcxproj (تمثيل XML الخاص به) حدث شيء ما للملف نفسه ، ولهذا السبب تعذر على
XmlTextReader التعامل معه.
وجود خطأين في فترة زمنية قصيرة إلى حد ما جعلنا نلقي نظرة فاحصة على المشكلة. بالإضافة إلى ذلك ، كما قلت أعلاه ، يستخدم SelfTester بنشاط كبير من قبل المطورين.
بادئ ذي بدء ، قمنا بتحليل الحادث الأخير. المحزن أن أقول ، وجدنا شيئا المشبوهة. فقط في حالة طلبنا من المطورين (مستخدمو SelfTester) الانتباه عن الأخطاء المحتملة والإبلاغ عنها.
نقطة مهمة: تم إعادة استخدام الكود الخاطئ في SelfTester. كان يستخدم في الأصل لتقييم المشاريع في محلل نفسه (
PVS-Studio_Cmd.exe ). لهذا السبب نمت الانتباه إلى المشكلة. ومع ذلك ، لم يكن هناك مثل هذه الحوادث في المحلل.
وفي الوقت نفسه ، استكملت البطاقة المتعلقة بمشاكل SelfTester بأخطاء جديدة:
XmlException مرة أخرى. من الواضح أن هناك مؤشرات ترابط متنافسة في مكان ما تعمل على قراءة وكتابة ملفات المشروع. يعمل SelfTester مع المشاريع في الحالات التالية:
- تقييم المشروعات في سياق الحساب الأولي لأوزان الحلول: خطوة جديدة أثارت الشك في البداية ؛
- تحديث المشاريع لإصدارات Visual Studio المطلوبة: يتم تنفيذها قبل الاختبار مباشرة (لا تتدخل المشروعات) ويجب ألا يؤثر على عملية العمل.
- تقييم المشروعات أثناء الاختبار: آلية آمنة لخيط الترابط راسخة ، معاد استخدامها من PVS-Studio_Cmd.exe ؛
- استعادة ملفات المشروع (استبدال ملفات .vcxproj المعدلة بملفات مرجعية أولية) عند الخروج من SelfTester ، لأنه يمكن تحديث ملفات المشروع إلى إصدارات Visual Studio اللازمة أثناء العمل. إنها خطوة أخيرة لا تؤثر على الآليات الأخرى.
سقط الشك على الكود الجديد المضاف للتحسين (حساب الوزن). لكن تحقيق الكود الخاص به أظهر أنه في حالة قيام المستخدم بإجراء التحليل مباشرة بعد بداية SelfTester ، فإن المختبر ينتظر دائمًا بشكل صحيح حتى نهاية التقييم المسبق. هذا المكان بدا آمنا.
مرة أخرى ، لم نتمكن من تحديد مصدر المشكلة.
ألم
طوال الشهر المقبل واصلت SelfTester لتحطم مرارا وتكرارا. حافظت البطاقة على ملء البيانات ، لكن لم يكن من الواضح ما يجب فعله بهذه البيانات. كانت معظم الأعطال مع نفس
XmlException. من حين لآخر كان هناك شيء آخر ، ولكن على نفس الرمز المعاد استخدامه من
PVS-Studio_Cmd.exe .
تقليديًا ، لا تُفرض الأدوات الداخلية متطلبات عالية جدًا ، لذلك واصلنا إثارة أخطاء SelfTester على مبدأ متبقٍ. من وقت لآخر ، شارك أشخاص مختلفون (خلال الحادث بأكمله ، عمل ستة أشخاص على المشكلة ، بما في ذلك متدربان). ومع ذلك ، كان علينا أن يصرف هذه المهمة.
خطأنا الأول. في الواقع ، في هذه المرحلة ، يمكننا حل هذه المشكلة مرة واحدة وإلى الأبد. كيف؟ كان من الواضح أن الخطأ نتج عن تحسين جديد. بعد كل شيء ، قبل أن يعمل كل شيء بشكل جيد ، ومن الواضح أن الرمز المعاد استخدامه لا يمكن أن يكون سيئًا للغاية. بالإضافة إلى ذلك ، لم يحقق هذا التحسين أي فائدة. إذن ما الذي يجب عمله؟
إزالة هذا التحسين. كما ربما تفهم ، لم يتم ذلك. واصلنا العمل على المشكلة التي خلقناها لأنفسنا. واصلنا البحث عن الجواب: "كيف ؟؟؟" كيف تحطم؟ يبدو أن تكون مكتوبة بشكل صحيح.
خطأنا الثاني. شارك أشخاص آخرون في حل المشكلة
. إنه خطأ كبير جدًا. لم يقتصر الأمر على حل المشكلة ولكن أيضًا تطلب موارد إضافية مهدرة. نعم ، جلب أشخاص جدد أفكارًا جديدة ، لكن الأمر استغرق وقتًا طويلاً لتنفيذ هذه الأفكار (بدون مقابل). في مرحلة ما ، كان لدينا برامج اختبار تدريبي للمتدربين تحاكي تقييم مشروع واحد ونفسه في سلاسل مختلفة مع تعديل مواز لمشروع في مشروع آخر. لم يساعد. لقد اكتشفنا أن واجهة برمجة تطبيقات MSBuild كانت آمنة داخل الخيط ، وهو ما عرفناه بالفعل. أضفنا أيضًا الحفظ التلقائي التفريغ المصغر عند حدوث استثناء
XmlException . كان لدينا شخص كان تصحيح كل هذا. مسكين! كانت هناك مناقشات ، فعلنا أشياء أخرى لا داعي لها.
وأخيرا ، من الخطأ الثالث. هل تعرف كم من الوقت قد مر من اللحظة التي حدثت فيها مشكلة SelfTester إلى حد حلها؟ حسنا ، يمكنك الاعتماد على نفسك. تم إنشاء البطاقة في 09/17/2018 وأغلقت في 02/20/2019. كان هناك أكثر من 40 تعليق! الرجال ، هذا كثير من الوقت!
سمحنا لأن نكون مشغولين لمدة خمسة أشهر مع هذا. في الوقت نفسه ، كنا مشغولين بدعم Visual Studio 2019 ، وإضافة دعم لغة Java ، وتقديم معيار MISRA C / C ++ ، وتحسين محلل C # ، والمشاركة بنشاط في المؤتمرات ، وكتابة مجموعة من المقالات ، إلخ. تلقى كل هذه الأنشطة وقتًا أقل للمطورين بسبب خطأ غبي في SelfTester.
أيها الناس ، تعلم من أخطائنا ولا تفعل مثل هذا. نحن لن كذلك.
هذا كل شيء ، لقد انتهيت.
حسنًا ، لقد كانت مزحة ، سأخبرك ما هي المشكلة في SelfTester :)
البنغو!
لحسن الحظ ، كان هناك شخص بيننا لديه رؤية واضحة (زميلي سيرجي فاسيلييف) ، الذي نظر إلى المشكلة من زاوية مختلفة جدًا (وأيضًا - كان محظوظًا بعض الشيء). ماذا لو كان على ما يرام داخل SelfTester ، ولكن هناك شيء من الخارج تعطل المشاريع؟ عادةً ما لم نطلق أي شيء باستخدام SelfTester ، وفي بعض الحالات ، قمنا بالتحكم الصارم في بيئة التنفيذ. في هذه الحالة ، يمكن أن يكون هذا "الشيء" ذاته SelfTester نفسه ، ولكن نسخة مختلفة.
عند الخروج من SelfTester ، يستمر مؤشر الترابط الذي يستعيد ملفات المشروع من المراجع ، في العمل لفترة من الوقت. عند هذه النقطة ، قد يتم إطلاق اختبار مرة أخرى. تمت إضافة الحماية ضد التشغيل المتزامن لعدة مثيلات SelfTester
لاحقًا ويبدو الآن كما يلي:
ولكن في هذه المرحلة لم يكن لدينا ذلك.
المكسرات ، ولكن صحيح - خلال ما يقرب من ستة أشهر من العذاب لم يهتم أحد بها. تعد استعادة المشروعات من المراجع إجراءً سريعًا إلى حد ما في الخلفية ، ولكن لسوء الحظ ليست سريعة بما يكفي لعدم التدخل في إعادة إطلاق SelfTester. وماذا يحدث عندما نطلقه؟ هذا صحيح ، حساب أوزان الحلول. عملية واحدة يعيد كتابة ملفات
.vcxproj بينما يحاول آخر قراءتها. قل مرحباً بـ
XmlException .
اكتشف سيرجي كل هذا عندما أضاف القدرة على التبديل إلى مجموعة مختلفة من سجلات المرجع إلى المختبر. أصبح من الضروري بعد إضافة مجموعة من قواعد MISRA في محلل. يمكنك التبديل مباشرة في الواجهة ، بينما يرى المستخدم هذه النافذة:
بعد ذلك ، إعادة تشغيل
SelfTester . وقبل ذلك ، على ما يبدو ، قام المستخدمون بمحاكاة المشكلة بأنفسهم بطريقة ما ، حيث قاموا بإجراء الاختبار مرة أخرى.
إلقاء اللوم والنتائج
بالطبع ، أزلنا (أي ، معطل) التحسين الذي تم إنشاؤه مسبقًا. بالإضافة إلى ذلك ، كان الأمر أسهل بكثير من إجراء نوع من التزامن بين إعادة بدء الاختبار بنفسه. وبدأ كل شيء في العمل بشكل مثالي ، كما كان من قبل. وكإجراء إضافي ، أضفنا الحماية المذكورة أعلاه ضد الإطلاق المتزامن للاختبار.
لقد كتبت بالفعل أعلاه عن أخطائنا الرئيسية عند البحث عن المشكلة ، وهو ما يكفي من الجلد الذاتي. نحن بشر ، لذلك قد نكون مخطئين. من المهم أن تتعلم من أخطائك وأن تستخلص النتائج. الاستنتاجات من هذه الحالة بسيطة للغاية:
- يجب علينا مراقبة وتقدير تعقيد المهمة ؛
- في بعض الأحيان نحتاج إلى التوقف عند نقطة ما ؛
- حاول إلقاء نظرة على المشكلة على نطاق أوسع. بمرور الوقت ، يمكن للمرء الحصول على رؤية النفق للقضية في حين أنه يتطلب منظور جديد.
- لا تخف من حذف الشفرة القديمة أو غير الضرورية.
هذا كل شيء ، هذه المرة انتهيت بالتأكيد. شكرا لك على القراءة حتى النهاية. أتمنى لك رمز بوجليس!