مون کي هي مضمون لکڻ لاءِ چيو ويو هو ته جامد تجزيي تي مواد جي وڏي مقدار جيڪا منهنجي ڌيان ڏانهن وڌي رهي آهي. پهريون، هي ، جيڪو فعال طور تي پاڻ کي ترقي ڪري ٿو Habré تي نظرثاني جي مدد سان انهن جي اوزار پاران مليل غلطين جي اوپن سورس منصوبن ۾. تازو PVS-اسٽوڊيو لاڳو ڪيو ويو ، ۽، يقينا، IntelliJ IDEA جي ڊولپرز، جن جي تعمير ٿيل تجزيي شايد اڄ جاوا لاء سڀ کان وڌيڪ ترقي يافته آهي، .
جڏهن اهڙين تبصرن کي پڙهندا، توهان محسوس ڪيو ته اسان هڪ جادوگر جي باري ۾ ڳالهائي رهيا آهيون: بٽڻ کي دٻايو، ۽ اهو هتي آهي - توهان جي اکين جي اڳيان خرابين جي هڪ فهرست. اهو لڳي ٿو ته جيئن تجزيه نگار بهتر ٿيندا، تيئن تيئن وڌيڪ بگ پاڻمرادو ملندا، ۽ انهن روبوٽس جي اسڪين ڪيل پروڊڪٽس اسان جي طرف کان بغير ڪنهن ڪوشش جي، بهتر ۽ بهتر ٿينديون.
پر ڪو به جادوگر نه آهي. مان ان بابت ڳالهائڻ چاهيان ٿو جن بابت عام طور تي پوسٽن ۾ نه ڳالهايو ويندو آهي جهڙوڪ ”هتي اهي شيون آهن جيڪي اسان جو روبوٽ ڳولي سگهي ٿو“: تجزيه نگار ڇا نٿا ڪري سگهن، سافٽ ويئر پهچائڻ واري عمل ۾ انهن جو اصل ڪردار ۽ جڳهه ڇا آهي، ۽ انهن کي صحيح طريقي سان ڪيئن لاڳو ڪجي. .
رچچ (ذريعو: ).
ڇا جامد تجزيي وارا ڪڏهن به نٿا ڪري سگهن
ماخذ ڪوڊ تجزيو ڇا آهي، هڪ عملي نقطي نظر کان؟ اسان ڪجھ سورس ڪوڊ مهيا ڪريون ٿا جيئن ان پٽ، ۽ آئوٽ پُٽ جي طور تي، ٿوري وقت ۾ (هلندڙ ٽيسٽن کان تمام ننڍو) اسان پنهنجي سسٽم بابت ڪجھ معلومات حاصل ڪندا آهيون. بنيادي ۽ رياضياتي طور تي ناقابل برداشت حد اها آهي ته اسان هن طريقي سان معلومات جي صرف هڪ تمام تنگ طبقي حاصل ڪري سگهون ٿا.
هڪ مسئلي جو سڀ کان مشهور مثال جيڪو جامد تجزيو استعمال ڪندي حل نٿو ڪري سگهجي : هي هڪ نظريو آهي جيڪو ثابت ڪري ٿو ته اهو ناممڪن آهي ته هڪ عام الگورٿم تيار ڪرڻ جيڪو ڪنهن پروگرام جي سورس ڪوڊ مان اهو طئي ڪري سگهي ته اهو هڪ محدود وقت ۾ ڦرندو يا ختم ٿيندو. هن نظريي جي هڪ توسيع آهي , جنهن ۾ چيو ويو آهي ته ڪمپيوٽيبل فنڪشن جي ڪنهن به غير معمولي ملڪيت لاءِ، اهو طئي ڪرڻ ته ڇا هڪ صوابديدي پروگرام ڪنهن فنڪشن کي اهڙي پراپرٽي سان اندازو لڳائي ٿو هڪ الگورٿمڪ طور تي اڻٽر مسئلو آهي. مثال طور، هڪ تجزيه نگار لکڻ ناممڪن آهي جيڪو ڪنهن سورس ڪوڊ مان اهو طئي ڪري سگهي ته ڇا پروگرام جو تجزيو ڪيو پيو وڃي هڪ الگورٿم جو عمل آهي جيڪو حساب ڪري ٿو، چئو، هڪ عدد جي اسڪوائرنگ.
اهڙيء طرح، جامد تجزيي جي ڪارڪردگي ناقابل برداشت حدون آهن. هڪ جامد تجزيي ڪندڙ سڀني صورتن ۾ ڪڏهن به معلوم ڪرڻ جي قابل نه هوندو، جهڙوڪ، مثال طور، "نال پوائنٽر استثنا" جي موجودگي ٻولين ۾ جيڪا null جي قيمت جي اجازت ڏئي ٿي، يا سڀني صورتن ۾ هڪ "نال" جي موجودگي کي طئي ڪرڻ لاء. خصوصيت نه ملي آهي" متحرڪ طور تي ٽائپ ڪيل ٻولين ۾. سڀ کان وڌيڪ ترقي يافته جامد تجزيه ڪندڙ جيڪو ڪري سگهي ٿو خاص ڪيسن کي نمايان ڪري ٿو، جن جو تعداد، توهان جي سورس ڪوڊ سان سڀني ممڪن مسئلن جي وچ ۾، بغير مبالغ جي، بالٽ ۾ هڪ ڦوٽو آهي.
جامد تجزيو ڪيڙا ڳولڻ بابت نه آهي
مٿين مان، نتيجو هيٺ ڏنل آهي: جامد تجزيو هڪ پروگرام ۾ خرابين جي تعداد کي گهٽائڻ جو هڪ ذريعو ناهي. مان چوندس ته: جڏهن توهان جي پروجيڪٽ تي پهريون ڀيرو لاڳو ڪيو ويندو، اهو ڪوڊ ۾ "دلچسپ" جڳهن کي ڳولي سگهندو، پر، گهڻو ڪري، اهو ڪو به نقص نه ملندو جيڪو توهان جي پروگرام جي معيار کي متاثر ڪري ٿو.
تجزيه نگارن پاران پاڻمرادو مليل خامين جا مثال متاثر ڪندڙ آهن، پر اسان کي اهو نه وسارڻ گهرجي ته اهي مثال وڏي ڪوڊ بيس جي هڪ وڏي سيٽ کي اسڪين ڪرڻ سان مليا آهن. ساڳئي اصول جي ڪري، هيڪرز جن کي اهو موقعو آهي ته اهي ڪيترن ئي سادي پاسورڊ جي ڪوشش ڪن ٿا ڪيترن ئي اڪائونٽن تي آخرڪار اهي اڪائونٽ ڳوليندا آهن جن وٽ هڪ سادي پاسورڊ آهي.
ڇا اهو مطلب آهي ته جامد تجزيو استعمال نه ڪيو وڃي؟ يقيناً نه! ۽ بلڪل ان ئي سبب لاءِ ته اهو هر نئين پاسورڊ کي جانچڻ جي قابل آهي انهي کي پڪ ڪرڻ لاءِ ته اهو "سادو" پاسورڊ جي اسٽاپ لسٽ ۾ شامل آهي.
جامد تجزيو ڪيڙا ڳولڻ کان وڌيڪ آهي
حقيقت ۾، تجزيي ذريعي عملي طور حل ٿيل مسئلا تمام وسيع آهن. سڀ کان پوء، عام طور تي، جامد تجزيه آهي ڪنهن به تصديق جي ذريعن جي ڪوڊس جي تصديق ڪرڻ کان پهريان اهي شروع ڪيا ويا آهن. هتي ڪجھ شيون آهن جيڪي توهان ڪري سگهو ٿا:
- لفظ جي وسيع ترين معنى ۾ ڪوڊنگ انداز جي جانچ ڪندي. ھن ۾ فارميٽنگ جي جانچ ڪرڻ، خالي/اضافي قوس جي استعمال کي ڳولڻ، ميٽرڪ تي حد مقرر ڪرڻ جھڙوڪ لائينن جو تعداد/ ڪنھن طريقي جي سائڪلوميٽڪ پيچيدگي وغيره شامل آھن - ڪجھ به جيڪو ممڪن طور تي ڪوڊ جي پڙھڻ ۽ برقرار رکڻ ۾ رڪاوٽ پيدا ڪري. جاوا ۾، اهڙي اوزار چيڪ اسٽائل آهي، پٿون ۾ - flake8. هن طبقي جي پروگرامن کي عام طور تي "linters" سڏيو ويندو آهي.
- نه رڳو executable ڪوڊ تجزيو ڪري سگهجي ٿو. وسيلا فائلون جهڙوڪ JSON، YAML، XML، .properties (۽ گهرجي!) خودڪار طور تي صحيحيت لاءِ چيڪ ڪري سگهجن ٿيون. آخرڪار، اهو معلوم ڪرڻ بهتر آهي ته JSON ڍانچي کي ٽوڙيو ويو آهي ڪجهه غير جوڙيل حوالن جي ڪري خودڪار پل جي درخواست جي تصديق جي شروعاتي مرحلي ۾ ٽيسٽ جي عمل يا رن ٽائيم جي ڀيٽ ۾؟ مناسب اوزار موجود آهن: مثال طور , .
- تاليف (يا متحرڪ پروگرامنگ ٻولين لاءِ پارسنگ) پڻ جامد تجزيو جو هڪ قسم آهي. عام طور تي، مرتب ڪندڙ ڊيڄاريندڙ پيدا ڪرڻ جي قابل آهن جيڪي ماخذ ڪوڊ جي معيار سان مسئلا ظاهر ڪن ٿا ۽ نظرانداز نه ڪيو وڃي.
- ڪڏهن ڪڏهن تاليف صرف قابل عمل ڪوڊ گڏ ڪرڻ کان وڌيڪ آهي. مثال طور، جيڪڏهن توهان وٽ فارميٽ ۾ دستاويز آهي ، پوءِ ان کي HTML/PDF ۾ تبديل ڪرڻ وقت AsciiDoctor هينڊلر () ڊيڄاريندڙ جاري ڪري سگھن ٿا، مثال طور، ٽوٽل اندروني لنڪ بابت. ۽ اھو ھڪڙو سٺو سبب آھي قبول نه ڪرڻ جو پل درخواست دستاويزي تبديلين سان.
- اسپيل چيڪنگ پڻ جامد تجزيو جو هڪ قسم آهي. افاديت نه رڳو دستاويزن ۾، پر پروگرام جي سورس ڪوڊس (تبصرن ۽ لٽريلز) ۾ پڻ مختلف پروگرامنگ ٻولين ۾، بشمول C/C++، Java ۽ Python. يوزر انٽرفيس يا ڊاڪيومينٽيشن ۾ اسپيلنگ جي غلطي به هڪ نقص آهي!
- ترتيب جا امتحان (جي باري ۾ اهي ڇا آهن - ڏسو. и رپورٽون)، جيتوڻيڪ هڪ يونٽ ٽيسٽ رن ٽائم ۾ عمل ڪيو ويو آهي جهڙوڪ pytest، حقيقت ۾ پڻ جامد تجزيي جو هڪ قسم آهي، ڇاڪاڻ ته اهي انهن جي عملدرآمد دوران سورس ڪوڊس تي عمل نه ڪندا آهن.
جئين توهان ڏسي سگهو ٿا، هن فهرست ۾ ڪيگ ڳولڻ گهٽ ۾ گهٽ اهم ڪردار ادا ڪري ٿو، ۽ ٻيو سڀ ڪجهه مفت اوپن سورس اوزار استعمال ڪندي دستياب آهي.
انهن مان ڪهڙي قسم جي جامد تجزيو توهان کي پنهنجي منصوبي ۾ استعمال ڪرڻ گهرجي؟ يقينا، وڌيڪ بهتر! بنيادي شيء ان کي صحيح طور تي لاڳو ڪرڻ آهي، جنهن تي وڌيڪ بحث ڪيو ويندو.
ترسيل پائپ لائن هڪ گھڻن اسٽيج فلٽر جي طور تي ۽ جامد تجزيو ان جي پهرين اسٽيج جي طور تي
مسلسل انضمام لاء کلاسک استعارا هڪ پائپ لائن آهي جنهن ذريعي وهڪري کي تبديل ڪري ٿو، ماخذ ڪوڊ تبديلين کان پيداوار تائين پهچائڻ تائين. هن پائپ لائن ۾ مرحلن جي معياري ترتيب هن طرح ڏسڻ ۾ اچي ٿو:
- جامد تجزيو
- ڪمپني
- يونٽ ٽيسٽ
- انضمام جا امتحان
- UI ٽيسٽ
- دستي چيڪ
پائپ لائن جي Nth اسٽيج تي رد ٿيل تبديليون اسٽيج N+1 تي منتقل نه ڪيون ويون آهن.
بلڪل ائين ڇو ۽ ٻي صورت ۾ نه؟ پائپ لائن جي جاچ واري حصي ۾، ٽيسٽ ڪندڙ معروف ٽيسٽ پيرامڊ کي سڃاڻندا.
ٽيسٽ پيراميڊ. ذريعو: مارٽن فولر.
هن پرامڊ جي تري ۾ اهي ٽيسٽ آهن جيڪي لکڻ ۾ آسان آهن، تيزيءَ سان عمل ڪرڻ، ۽ ناڪام ٿيڻ جو رجحان نه آهي. تنهن ڪري، انهن مان وڌيڪ هجڻ گهرجي، انهن کي وڌيڪ ڪوڊ ڍڪڻ گهرجي ۽ پهرين تي عمل ڪيو وڃي. پرامڊ جي چوٽي تي، سامهون سچو آهي، تنهنڪري انضمام ۽ UI ٽيسٽ جو تعداد گهٽ ۾ گهٽ ضروري آهي. هن زنجير ۾ ماڻهو تمام مهانگو، سست ۽ ناقابل اعتبار وسيلو آهي، تنهن ڪري هو تمام آخر ۾ آهي ۽ ڪم صرف ان صورت ۾ انجام ڏئي ٿو جڏهن اڳئين مرحلن ۾ ڪو نقص نه ملي. بهرحال، ساڳيا اصول استعمال ڪيا ويا آهن پائپ لائن ٺاهڻ لاءِ حصن ۾ جيڪي سڌي طرح جاچ سان لاڳاپيل نه آهن!
مان هڪ ملٽي اسٽيج واٽر فلٽريشن سسٽم جي صورت ۾ هڪ قياس پيش ڪرڻ چاهيان ٿو. گندو پاڻي (نقصن سان تبديليون) ان پٽ کي فراهم ڪيو ويندو آهي؛ ان پٽ تي اسان کي صاف پاڻي حاصل ڪرڻ گهرجي، جنهن ۾ سڀئي ناپسنديده آلودگي ختم ٿي ويا آهن.
ملٽي اسٽيج فلٽر. ذريعو:
جئين توهان ڄاڻو ٿا، صفائي فلٽر ڊزائين ڪيل آهن ته جيئن هر ايندڙ cascade کي فلٽر ڪري سگهي ٿو آلودگي جي وڌندڙ جزن کي. ساڳئي وقت، ٿلهي صاف ڪرڻ واري cascades اعلي throughput ۽ گهٽ قيمت آهي. اسان جي قياس ۾، هن جو مطلب آهي ته ان پٽ معيار جا دروازا تيز آهن، شروع ڪرڻ لاء گهٽ ڪوشش جي ضرورت آهي، ۽ پاڻ کي آپريشن ۾ وڌيڪ غير معمولي آهن - ۽ اهو ئي ترتيب آهي جنهن ۾ اهي ٺهيل آهن. جامد تجزيي جو ڪردار، جيڪو اسان هاڻي سمجھون ٿا، صرف سڀ کان وڌيڪ خرابين کي ختم ڪرڻ جي قابل آهي، فلٽر cascade جي شروعات ۾ "مٽي" گرڊ جو ڪردار آهي.
جامد تجزيو پنهنجو پاڻ کي حتمي پيداوار جي معيار کي بهتر نٿو ڪري، جيئن "مٽي فلٽر" پاڻي پيئڻ لائق ناهي. ۽ اڃا تائين، پائپ لائن جي ٻين عناصر سان گڏ، ان جي اهميت واضح آهي. جيتوڻيڪ هڪ ملٽي اسٽيج فلٽر ۾ آئوٽ پُٽ جا مرحلا امڪاني طور تي هر شيءِ کي پڪڙڻ جي قابل هوندا آهن جيڪي ان پٽ اسٽيج ڪندا آهن، اهو واضح آهي ته ان پٽ اسٽيجز کان سواءِ، اڪيلي سر صاف ڪرڻ واري مرحلن سان ڪرڻ جي ڪوشش جا ڪهڙا نتيجا نڪرندا.
”مٽي ٽريپ“ جو مقصد ايندڙ cascades کي تمام گھڻا عيب پڪڙڻ کان بچائڻ آھي. مثال طور، گهٽ ۾ گهٽ، جيڪو شخص ڪوڊ جو جائزو وٺي رهيو آهي، ان کي غلط فارميٽ ٿيل ڪوڊ ۽ قائم ڪيل ڪوڊنگ معيارن جي ڀڃڪڙي (جهڙوڪ اضافي قوسون يا تمام گهڻيون ڳنڍيون شاخون) کان پريشان نه ٿيڻ گهرجي. اين پي ايز جهڙا بگ يونٽ ٽيسٽ ذريعي پڪڙڻ گهرجن، پر جيڪڏهن ٽيسٽ کان اڳ اينالائزر اسان کي اشارو ڪري ٿو ته ڪو بگ ٿيڻو آهي، اهو ان جي فڪسنگ کي تيز ڪندو.
مان سمجهان ٿو ته اهو هاڻي واضح ٿي چڪو آهي ته جامد تجزيا پروڊڪٽ جي معيار کي بهتر نه ٿا ڪن جيڪڏهن ڪڏهن ڪڏهن استعمال ڪيا وڃن، ۽ مسلسل استعمال ٿيڻ گهرجي تبديلين کي فلٽر ڪرڻ لاءِ مجموعي خرابين سان. اهو سوال ته ڇا هڪ جامد تجزيي وارو استعمال ڪرڻ سان توهان جي پيداوار جي معيار کي بهتر ٿيندو، تقريبن اهو پڇڻ جي برابر آهي، "ڇا گندي تلاءَ مان پاڻي پيئڻ جي معيار ۾ بهتر ٿيندو جيڪڏهن اهو ڪولينڊر مان گذريو وڃي؟"
وراثت واري منصوبي تي عمل درآمد
هڪ اهم عملي سوال: هڪ "معيار دروازي" جي طور تي مسلسل انضمام جي عمل ۾ جامد تجزيو ڪيئن لاڳو ڪجي؟ خودڪار ٽيسٽ جي صورت ۾، سڀڪنھن شيء کي پڌرو آهي: اتي ٽيسٽ جو هڪ سيٽ آهي، انهن مان ڪنهن جي ناڪامي ان کي يقين ڪرڻ لاء ڪافي سبب آهي ته اسيمبلي معيار جي دروازي کي پاس نه ڪيو آهي. ساڳئي طريقي سان هڪ دروازي کي نصب ڪرڻ جي ڪوشش هڪ جامد تجزيي جي نتيجن جي بنياد تي ناڪام ٿئي ٿي: وراثت ڪوڊ ۾ تمام گهڻيون تجزيي ڊيڄاريندڙ آهن، توهان انهن کي مڪمل طور تي نظر انداز ڪرڻ نٿا چاهيو، پر اهو پڻ ناممڪن آهي ته هڪ پراڊڪٽ شپنگ کي روڪڻ صرف ان ڪري ته ان ۾ تجزياتي ڊيڄاريندڙ شامل آهن.
جڏهن پهريون ڀيرو استعمال ڪيو ويو آهي، تجزيه ڪندڙ ڪنهن به منصوبي تي وڏي تعداد ۾ ڊيڄاريندڙ پيدا ڪري ٿو، جن مان وڏي اڪثريت پيداوار جي مناسب ڪارڪردگي سان لاڳاپيل ناهي. انهن سڀني تبصرن کي هڪ ڀيرو درست ڪرڻ ناممڪن آهي، ۽ گهڻا ضروري نه آهن. آخرڪار، اسان ڄاڻون ٿا ته اسان جي پيداوار مڪمل طور تي ڪم ڪري ٿي، جيتوڻيڪ جامد تجزيو متعارف ڪرائڻ کان اڳ!
نتيجي طور، ڪيترائي جامد تجزيو جي ڪڏهن ڪڏهن استعمال تائين محدود آهن، يا صرف انفارميشن موڊ ۾ استعمال ڪندا آهن، جڏهن هڪ تجزيي رپورٽ صرف اسيمبليء دوران جاري ڪئي ويندي آهي. اهو ڪنهن به تجزيي جي غير موجودگي جي برابر آهي، ڇاڪاڻ ته جيڪڏهن اسان وٽ اڳ ۾ ئي ڪيترائي ڊيڄاريندڙ آهن، پوء ڪوڊ کي تبديل ڪرڻ وقت هڪ ٻيو واقعو (ڪجهه به سنجيده ناهي) ڪنهن به نوٽيس نه ڪيو وڃي.
معيار جي دروازن کي متعارف ڪرائڻ جا هيٺيان طريقا سڃاتل آهن:
- ڊيڄاريندڙن جي ڪل تعداد تي حد مقرر ڪرڻ يا ڊيڄاريندڙن جي تعداد کي ڪوڊ جي لائنن جي تعداد سان ورهايو ويو. اهو خراب ڪم ڪري ٿو، ڇاڪاڻ ته اهڙي دروازي کي آزاديء سان نئين نقصن سان تبديلين کي منتقل ڪرڻ جي اجازت ڏئي ٿي، جيستائين انهن جي حد کان وڌي نه وڃي.
- درست ڪرڻ، هڪ خاص وقت تي، ڪوڊ ۾ سڀني پراڻي ڊيڄاريندڙن کي نظر انداز ڪيو ويو، ۽ تعمير ڪرڻ کان انڪار ڪيو جڏهن نئين ڊيڄاريندڙ واقع ٿيندي. هي ڪارڪردگي PVS-studio ۽ ڪجهه آن لائين وسيلن پاران مهيا ڪيل آهي، مثال طور، ڪوڊيسي. مون کي PVS-اسٽوڊيو ۾ ڪم ڪرڻ جو موقعو نه مليو، جيئن ته ڪوڊيسي سان منهنجي تجربي لاءِ، انهن جو بنيادي مسئلو اهو آهي ته اهو طئي ڪرڻ ته ”پراڻي“ ڇا آهي ۽ ”نئين“ غلطي ڇا آهي هڪ بلڪه پيچيده الورورٿم آهي جيڪو هميشه ڪم نٿو ڪري. صحيح طور تي، خاص طور تي جيڪڏهن فائلون وڏيون تبديل ٿيل يا تبديل ٿيل آهن. منهنجي تجربي ۾، ڪوڊيسي پل جي درخواست ۾ نئين ڊيڄاريندڙن کي نظر انداز ڪري سگهي ٿي، جڏهن ته ساڳئي وقت هڪ پل جي درخواست کي پاس نه ڪرڻ جي ڪري ڊيڄاريندڙ جيڪي ڏنل پي آر جي ڪوڊ ۾ تبديلين سان لاڳاپيل نه هئا.
- منهنجي خيال ۾، سڀ کان وڌيڪ مؤثر حل اهو آهي جيڪو ڪتاب ۾ بيان ڪيو ويو آهي "رچائڻ جو طريقو". بنيادي خيال اهو آهي ته جامد تجزياتي ڊيڄاريندڙن جو تعداد هر رليز جي ملڪيت آهي، ۽ صرف انهن تبديلين جي اجازت ڏني وئي آهي جيڪي ڊيڄاريندڙن جي مجموعي تعداد ۾ اضافو نه ڪن.
رچچ
اهو هن طريقي سان ڪم ڪري ٿو:
- شروعاتي اسٽيج تي، تجزيو ڪندڙن پاران مليل ڪوڊ ۾ ڊيڄاريندڙن جي تعداد جي ڇڏڻ بابت ميٽا ڊيٽا ۾ رڪارڊ ڪيو ويو آھي. تنهن ڪري، جڏهن توهان اپ اسٽريم ٺاهي رهيا آهيو، توهان جو ريپوزٽري مئنيجر لکي ٿو نه رڳو ”رليز 7.0.2“، پر ”رليز 7.0.2 جنهن ۾ 100500 چيڪ اسٽائل وارننگ شامل آهن. جيڪڏهن توهان استعمال ڪريو هڪ جديد مخزن مئنيجر (جهڙوڪ آرٽيڪل)، توهان جي رليز بابت اهڙي ميٽا ڊيٽا کي محفوظ ڪرڻ آسان آهي.
- ھاڻي ھر پل جي درخواست، جڏھن ٺاھيو ويو، نتيجن جي ڊيڄاريندڙن جي تعداد کي موجوده رليز ۾ موجود ڊيڄاريندڙن جي تعداد سان موازنہ ڪري ٿو. جيڪڏهن پي آر هن نمبر ۾ واڌ جي ڪري ٿي، پوء ڪوڊ جامد تجزيي لاء معيار جي دروازي کي پاس نٿو ڪري. جيڪڏهن ڊيڄاريندڙن جو تعداد گهٽجي يا تبديل نه ٿئي، پوء اهو گذري ٿو.
- ايندڙ رليز تي، ڊيڄاريندڙن جو ٻيهر ڳڻپيوڪر نمبر ٻيهر رليز ميٽا ڊيٽا ۾ رڪارڊ ڪيو ويندو.
پوءِ ٿورڙو ٿورڙو پر ثابت قدميءَ سان (جهڙوڪ جڏهن ڪو ريچٽ ڪم ڪندو آهي)، ڊيڄاريندڙن جو تعداد صفر ٿي ويندو. يقينن، سسٽم کي نئين ڊيڄاريندڙ متعارف ڪرائڻ سان ٺڳي سگهجي ٿو، پر ڪنهن ٻئي کي درست ڪرڻ. اهو عام آهي، ڇاڪاڻ ته هڪ ڊگهي فاصلي تي اهو نتيجو ڏئي ٿو: ڊيڄاريندڙن کي درست ڪيو ويو آهي، ضابطي جي طور تي، انفرادي طور تي نه، پر هڪ خاص قسم جي هڪ گروپ ۾، ۽ تمام آسانيء سان هٽائڻ وارا ڊيڄاريندڙ تمام جلدي ختم ٿي ويا آهن.
هي گراف ڏيکاري ٿو چيڪ اسٽائل وارننگن جو ڪل تعداد ڇهن مهينن جي آپريشن لاءِ اهڙي ”ريچٽ“ تي . ڊيڄاريندڙن جو تعداد گھٽجي ويو آھي شدت جي حڪم سان، ۽ اھو قدرتي طور تي ٿيو، متوازي پيداوار جي ترقي سان!
مان هن طريقي جو هڪ تبديل ٿيل نسخو استعمال ڪريان ٿو، الڳ الڳ پروجيڪٽ ماڊل ۽ تجزياتي اوزار طرفان ڊيڄاريندڙن کي ڳڻڻ، جنهن جي نتيجي ۾ هڪ YAML فائل بلڊ ميٽاداٽ سان جيڪو ڪجهه هن طرح نظر اچي ٿو:
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
ڪنهن به ترقي يافته CI سسٽم ۾، پلگ ان ۽ ٽئين پارٽي جي اوزارن تي ڀروسو ڪرڻ جي بغير ڪنهن به جامد تجزياتي اوزار لاء ريچٽ لاڳو ٿي سگهي ٿو. هر تجزيه نگار پنهنجي رپورٽ ٺاهي ٿو هڪ سادي متن يا XML فارميٽ ۾ جنهن جو تجزيو ڪرڻ آسان آهي. باقي رهي ٿو CI اسڪرپٽ ۾ ضروري منطق لکڻ. توهان ڏسي سگهو ٿا ته اهو ڪيئن لاڳو ڪيو ويو آهي اسان جي اوپن سورس منصوبن ۾ جينڪنز ۽ آرٽفيڪٽري جي بنياد تي يا . ٻئي مثال لائبريري تي منحصر آهن : طريقو countWarnings() چيڪ اسٽائل ۽ اسپاٽ بگ پاران ٺاهيل فائلن ۾ xml ٽيگ کي عام طريقي سان شمار ڪري ٿو، ۽ compareWarningMaps() ساڳي ريچٽ کي لاڳو ڪري ٿو، هڪ غلطي اڇلائي ٿو جڏهن ڪنهن به درجي ۾ ڊيڄاريندڙن جو تعداد وڌي ٿو.
"ratchet" جو هڪ دلچسپ عمل ممڪن آهي تبصرن جي اسپيلنگ، ٽيڪسٽ لٽريچر ۽ دستاويزن جي اسپيل استعمال ڪندي تجزيو ڪرڻ لاء. جئين توهان کي خبر آهي، جڏهن اسپيلنگ کي جانچيو وڃي، معياري لغت ۾ اڻڄاتل سڀئي لفظ غلط نه آهن؛ انهن کي استعمال ڪندڙ ڊڪشنري ۾ شامل ڪري سگهجي ٿو. جيڪڏهن توهان پروجيڪٽ جي ماخذ ڪوڊ جو هڪ ڪسٽم ڊڪشنري جو حصو ٺاهيو ٿا، ته پوءِ اسپيل جي معيار جو دروازو هن طرح ٺاهي سگهجي ٿو: هڪ معياري ۽ ڪسٽم ڊڪشنري سان اسپيل کي هلائڻ. ڪابه اسپيل غلطيون نه ڳوليو.
تجزيي جي نسخي کي فڪس ڪرڻ جي اهميت بابت
آخر ۾، نوٽ ڪرڻ جو نقطو اهو آهي ته توهان پنهنجي ترسيل پائپ لائن ۾ تجزيو ڪيئن لاڳو ڪيو، تجزيي جو نسخو مقرر ڪيو وڃي. جيڪڏهن توهان تجزيه نگار کي فوري طور تي اپڊيٽ ڪرڻ جي اجازت ڏيو ٿا، ته پوءِ جڏهن ايندڙ پل جي درخواست کي گڏ ڪيو وڃي ته، نوان نقص ”پاپ اپ“ ٿي سگهن ٿا، جيڪي ڪوڊ جي تبديلين سان لاڳاپيل نه آهن، پر ان حقيقت سان لاڳاپيل آهن ته نئون تجزيه نگار صرف وڌيڪ نقص ڳولڻ جي قابل آهي. ۽ اهو توهان جي پل جي درخواستن کي قبول ڪرڻ جي عمل کي ٽوڙي ڇڏيندو. تجزيي کي اپڊيٽ ڪرڻ هڪ شعوري عمل هجڻ گهرجي. بهرحال، هر اسيمبليء جي جزو جي نسخي جي سخت فڪسيشن عام طور تي هڪ ضروري گهربل آهي ۽ هڪ الڳ بحث لاء هڪ موضوع آهي.
پهچڻ
- جامد تجزيا توهان لاءِ ڪي ڪيڙا نه ڳوليندا ۽ نه ئي هڪ ايپليڪيشن جي نتيجي ۾ توهان جي پيداوار جي معيار کي بهتر بڻائي سگهندا. معيار تي مثبت اثر صرف ان جي مسلسل استعمال ذريعي حاصل ڪري سگهجي ٿو ترسيل جي عمل دوران.
- بگ ڳولڻ بلڪل به تجزيي جو بنيادي ڪم نه آهي؛ مفيد افعال جي وڏي اڪثريت اوپن سورس ٽولز ۾ موجود آهي.
- معيار جا دروازا لاڳو ڪريو جامد تجزيي جي نتيجن جي بنياد تي ترسيل پائپ لائن جي پهرين مرحلي ۾، ورثي واري ڪوڊ لاءِ ”ريچٽ“ استعمال ڪندي.
حوالن
- ڪوڊ تجزيو جي مختلف طريقن تي رپورٽ ڪريو (نه رڳو جامد!)
جو ذريعو: www.habr.com