د جامد کوډ تحلیل کونکي هڅه کول اسانه دي. مګر د دې پلي کولو لپاره، په ځانګړې توګه د یوې لویې زړې پروژې په پراختیا کې، مهارت ته اړتیا لري. که په غلطه توګه ترسره شي، شنونکی کولی شي کار اضافه کړي، پرمختګ ورو کړي، او ټیم کم کړي. راځئ چې په لنډ ډول د دې په اړه وغږیږو چې څنګه د پراختیا پروسې کې د جامد تحلیلونو ادغام ته په سمه توګه رسیدنه وکړو او د CI/CD برخې په توګه یې کارول پیل کړو.
پېژندنه
په دې وروستیو کې زما پام خپرونې ته راجلب شوی "". له یوې خوا، دا یو ښه مقاله ده چې د لوستلو وړ ده، له بلې خوا، ماته داسې ښکاري چې دا لاهم بشپړ ځواب نه ورکوي چې څنګه په یوه پروژه کې د ډیری میراث سره په بې درده توګه د جامد تحلیل پلي کول. کوډ. مقاله وايي چې تاسو کولی شئ تخنیکي پور ومنئ او یوازې په نوي کوډ کار وکړئ، مګر هیڅ ځواب نشته چې وروسته د دې تخنیکي پور سره څه وکړي.
زموږ د PVS-Studio ټیم پدې موضوع خپل نظر وړاندې کوي. راځئ وګورو چې څنګه د جامد کوډ تحلیل کونکي پلي کولو ستونزه په لومړي ځای کې رامینځته کیږي ، دا ستونزه څنګه له مینځه ویسي ، او څنګه پرته له درده په تدریجي ډول تخنیکي پور له مینځه ویسي.
مسلې
دا معمولا ستونزمن نه وي چې په لاره واچول شي او وګورئ چې یو جامد شنونکی څنګه کار کوي []. تاسو ممکن په کوډ کې په زړه پورې غلطۍ یا حتی ډارونکي احتمالي زیانونه وګورئ. تاسو حتی کولی شئ یو څه سم کړئ، مګر بیا ډیری پروګرام کونکي پریږدي.
ټول جامد تحلیل کونکي غلط مثبت تولیدوي. دا د جامد کوډ تحلیل میتودولوژی ځانګړتیا ده، او د دې په اړه هیڅ شی نشي کیدی. په عمومي حالت کې، دا یوه نه حل کیدونکی ستونزه ده، لکه څنګه چې د رایس د تیورم لخوا تایید شوی []. د ماشین زده کړې الګوریتم به هم مرسته ونه کړي []. حتی که یو څوک تل نشي ویلای چې ایا دا یا دا کوډ غلط دی ، نو تاسو باید د دې برنامې څخه تمه ونه کړئ :).
غلط مثبتونه کومه ستونزه نده که چیرې جامد شنونکی لا دمخه تنظیم شوی وي:
- غیر اړونده مقررات غیر فعال شوي؛
- ځینې غیر اړونده تشخیصونه غیر فعال شوي؛
- که موږ د C یا C++ په اړه وغږیږو، نو بیا میکرو په نښه شوي چې ځانګړي جوړښتونه لري چې په هر ځای کې چې دا ډول میکرو کارول کیږي د بې ګټې اخطارونو د څرګندیدو لامل کیږي؛
- خپلې دندې په نښه شوي چې د سیسټم دندو ته ورته کړنې ترسره کوي (خپل انالوګ حافظی او یا چاپ) [];
- غلط مثبت په ځانګړي ډول د نظرونو په کارولو سره غیر فعال شوي؛
- او هم
په دې حالت کې، موږ کولی شو د 10-15٪ په اړه د ټیټ غلط مثبت نرخ تمه وکړو []. په بل عبارت، د 9 تحلیل کونکي اخطارونو څخه 10 به په کوډ کې ریښتینې ستونزه په ګوته کړي، یا لږترلږه "قوی بوی کوډ." موافقه وکړئ، دا سناریو خورا خوندور دی، او تحلیل کونکی د پروګرامر ریښتینی ملګری دی.
په واقعیت کې، په یوه لویه پروژه کې، لومړنی انځور به په بشپړه توګه توپیر ولري. تحلیل کونکی د میراث کوډ لپاره په سلګونو یا زره خبرداری ورکوي. دا ناشونې ده چې ژر تر ژره پوه شي چې د دې اخطارونو څخه کوم یو اړین دي او کوم ندي. دا غیر معقوله ده چې ناست شئ او د دې ټولو اخطارونو سره معامله پیل کړئ، ځکه چې پدې قضیه کې اصلي کار به د ورځو یا اونیو لپاره ودریږي. عموما، یو ټیم نشي کولی دا ډول سناریو برداشت کړي. دلته به یو لوی شمیر توپیرونه هم وي چې د بدلون تاریخ خرابوي. او په کوډ کې د ډیری برخو ګړندۍ ډله ایز ترمیم به حتمي د نوي ټایپونو او غلطیو پایله وي.
او تر ټولو مهم، د اخطارونو په وړاندې مبارزه کې دا ډول کار لږ معنی لري. موافقه وکړه چې دا پروژه له څو کلونو راهیسې په بریالیتوب سره روانه ده، ډیری مهمې تېروتنې لا دمخه سمې شوې دي. هو، دا اصلاحات خورا ګران وو، باید ډیبګ شوي وای، د بګ په اړه د کاروونکي منفي نظرونه ترلاسه کړي، او داسې نور. یو جامد تحلیل کونکی به د کوډ کولو په مرحله کې د دې ډیری غلطیو په سمولو کې مرسته وکړي، په چټکه او ارزانه توګه. مګر په اوس وخت کې، په یوه لاره یا بل ډول، دا تېروتنې سمې شوي، او تحلیل کونکی په عمده توګه په زاړه کوډ کې غیر جدي غلطی کشف کوي. دا کوډ ممکن ونه کارول شي، دا ممکن په ندرت سره وکارول شي، او پدې کې یوه تېروتنه ممکن د پام وړ پایلو لامل نشي. شاید په کوم ځای کې د تڼۍ سیوري غلط رنګ وي، مګر دا د هرچا د محصول په کارولو کې مداخله نه کوي.
البته، حتی کوچنۍ تېروتنې لا هم تېروتنې دي. او ځینې وختونه یوه تېروتنه کولی شي یو ریښتینی زیان پټ کړي. په هرصورت، هرڅه پریښودل او د نیمګړتیاوو سره معامله کولو لپاره ورځې / اونۍ مصرف کول چې په سختۍ سره ځان ښکاره کوي د شکمن نظر په څیر ښکاري.
پروګرام کونکي د زاړه کاري کوډ په اړه دا ټول اخطارونه ګوري، وګوري، وګوري ... او دوی فکر کوي: موږ کولی شو پرته له جامد تحلیل څخه ترسره کړو. راځئ چې ځینې نوي ګټور فعالیت ولیکئ.
په خپله طریقه، دوی سم دي. دوی فکر کوي چې لومړی دوی باید یو څه له دې ټولو اخطارونو څخه ځان خلاص کړي. یوازې بیا به دوی وکولی شي د کوډ تحلیل کونکي منظم کارولو څخه ګټه پورته کړي. که نه نو، نوي اخطارونه به په ساده ډول په زړو کې ډوب شي، او هیڅوک به ورته پام ونه کړي.
دا ورته ورته والی دی لکه د کمپیلر اخطارونو سره. دا بې دلیله نه ده چې دوی د کمپلر اخطارونو شمیره په 0 کې ساتلو وړاندیز کوي. که چیرې 1000 اخطارونه شتون ولري ، نو کله چې 1001 شتون ولري ، هیڅوک به ورته پام ونه کړي ، او دا روښانه نده چې دا نوي خبرداری چیرته وګورو.
پدې کیسه کې ترټولو بد شی دا دی که چیرې پدې شیبه کې له پورته څخه یو څوک تاسو د جامد کوډ تحلیل کارولو ته اړ کړي. دا به یوازې ټیم کمزوری کړي، ځکه چې د دوی له نظره به اضافي بیوروکراټیک پیچلتیا وي چې یوازې په لاره کې راځي. هیڅوک به د تحلیل کونکي راپورونه ونه ګوري، او ټول کارول به یوازې "په کاغذ" وي. هغوی. په رسمي ډول، تحلیل د DevOps پروسې کې جوړ شوی، مګر په عمل کې دا هیڅ ګټه نه کوي. موږ د کنفرانس برخه والو څخه په بوتونو کې مفصلې کیسې اوریدلې. دا ډول تجربه کولی شي پروګرام کونکي د اوږدې مودې لپاره د جامد تحلیل وسیلو کارولو څخه وهڅوي، که د تل لپاره نه وي.
د تخنیکي پورونو پلي کول او له منځه وړل
په حقیقت کې، د جامد تحلیل معرفي کولو په اړه هیڅ ستونزمن یا ډارونکي شتون نلري حتی په یوه لوی زاړه پروژه کې.
CI / CD
سربیره پردې ، تحلیل کونکی سمدلاسه د دوامداره پراختیا پروسې برخه کیدی شي. د مثال په توګه، د PVS-Studio توزیع د هغه ب formatه کې چې تاسو ورته اړتیا لرئ راپور په اسانۍ سره لیدو لپاره اسانتیاوې لري، او پراختیا کونکو ته خبرتیاوې چې د کوډ ستونزې لرونکي برخې یې لیکلي. د هغو کسانو لپاره چې د CI/CD سیسټمونو څخه د PVS-Studio په لاره اچولو کې لیوالتیا لري، زه وړاندیز کوم چې تاسو خپل ځان د اړونده سره آشنا کړئ اسناد او د مقالو لړۍ:
مګر راځئ چې د کوډ تحلیلي وسیلو پلي کولو په لومړیو مرحلو کې د لوی شمیر غلط مثبتو مسلو ته راستون شو.
د موجوده تخنیکي پورونو تنظیم کول او د نوي اخطارونو سره معامله کول
عصري سوداګریز جامد تحلیل کونکي تاسو ته اجازه درکوي یوازې نوي اخطارونه مطالعه کړئ چې په نوي یا بدل شوي کوډ کې څرګندیږي. د دې میکانیزم پلي کول توپیر لري، مګر جوهر ورته دی. په PVS-Studio جامد شنونکي کې، دا فعالیت په لاندې ډول پلي کیږي.
د دې لپاره چې ژر تر ژره د جامد تحلیل کارول پیل کړي، موږ وړاندیز کوو چې د PVS-Studio کاروونکي د اخطارونو د ډله ایز فشار لپاره میکانیزم وکاروي []. عمومي نظر په لاندې ډول دی. کارونکي شنونکی پیل کړ او ډیری اخطارونه یې ترلاسه کړل. څرنګه چې یوه پروژه چې د ډیرو کلونو لپاره د پراختیا په حال کې ده ژوندۍ ده، وده کوي او پیسې ګټي، نو ډیری احتمال به په راپور کې ډیری اخطارونه شتون ونلري چې مهمې نیمګړتیاوې په ګوته کوي. په بل عبارت، مهمې کیګونه دمخه د ډیرو ګرانو میتودونو په کارولو سره یا د پیرودونکو څخه د فیډبیک څخه مننه په یوه لاره یا بل ډول تنظیم شوي. په دې اساس، هر هغه څه چې شنونکی اوس مهال موندلی شي تخنیکي پور وګڼل شي، کوم چې د سمدستي له منځه وړلو هڅه کول ناممکن دي.
تاسو کولی شئ PVS-Studio ته ووایاست چې دا اخطارونه د اوس لپاره غیر مناسب په پام کې ونیسئ (د وروسته لپاره تخنیکي پور خوندي کړئ) او دا به نور دوی ونه ښیې. شنونکی یو ځانګړی فایل رامینځته کوي چیرې چې دا د غلطیو په اړه معلومات خوندي کوي چې لاهم په زړه پوري ندي. او اوس PVS-Studio به یوازې د نوي یا بدل شوي کوډ لپاره خبرداری ورکوي. سربیره پردې ، دا ټول په هوښیارۍ سره پلي کیږي. که د مثال په توګه، د سرچینې کوډ فایل په پیل کې یو خالي کرښه اضافه شي، نو بیا شنونکی پوهیږي چې په حقیقت کې هیڅ شی نه دی بدل شوی، او چوپتیا ته به دوام ورکړي. دا مارک اپ فایل د نسخې کنټرول سیسټم کې کیښودل کیدی شي. فایل لوی دی ، مګر دا کومه ستونزه نده ، ځکه چې ډیری وختونه د ذخیره کولو لپاره هیڅ معنی نلري.
اوس ټول پروګرام کونکي به یوازې د نوي یا بدل شوي کوډ پورې اړوند اخطارونه وګوري. په دې توګه، تاسو کولی شئ د شنونکي کارول پیل کړئ، لکه څنګه چې دوی وايي، د بلې ورځې څخه. او تاسو کولی شئ وروسته تخنیکي پور ته راستون شئ، او په تدریجي ډول غلطۍ سم کړئ او شنونکی تنظیم کړئ.
نو، په یوه لویه زاړه پروژه کې د شنونکي پلي کولو سره لومړۍ ستونزه حل شوې. اوس راځئ چې معلومه کړو چې د تخنیکي پور سره څه وکړو.
د بګ فکسونه او ریفکتورونه
ترټولو ساده او خورا طبیعي خبره دا ده چې یو څه وخت ونیسئ ترڅو په پراخه کچه فشار لرونکي تحلیل کونکي اخطارونه تحلیل کړئ او په تدریجي ډول ورسره معامله وکړئ. چیرته چې تاسو باید په کوډ کې غلطۍ حل کړئ، چیرته چې تاسو باید بیاکتنه وکړئ ترڅو تحلیل کونکي ته ووایاست چې کوډ ستونزه نلري. ساده مثال:
if (a = b)ډیری C++ تالیف کونکي او شنونکي د ورته کوډ په اړه شکایت کوي ، ځکه چې ډیر احتمال شتون لري چې دوی واقعیا لیکل غواړي (a == ب). مګر یو ناڅرګند تړون شتون لري، او دا معمولا په اسنادو کې یادونه کیږي، که چیرې اضافي قوسونه شتون ولري، نو دا په پام کې نیول کیږي چې پروګرام کونکي په قصدي توګه دا ډول کوډ لیکلی، او د قسم خوړلو اړتیا نشته. د مثال په توګه، د تشخیص لپاره د PVS-Studio اسنادو کې دا په واضح ډول لیکل شوي چې لاندې کرښه به سمه او خوندي وګڼل شي:
if ((a = b))بل مثال. ایا دا پدې C++ کوډ کې هیر شوی؟ د وقفې که نه؟
case A:
foo();
case B:
bar();
break;د PVS-Studio شنونکی به دلته یو خبرداری خپور کړي . دا ممکن تېروتنه نه وي، په دې حالت کې تاسو باید د ځانګړتیا په اضافه کولو سره پارسر ته اشاره ورکړئ یا د مثال په توګه __خاصیت__((د زوال له لارې)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;دا ویل کیدی شي چې دا ډول کوډ بدلونونه بګ نه حل کوي. هو، دا ریښتیا ده، مګر دا دوه ګټور کارونه کوي. لومړی، د شنونکي راپور له غلطو مثبتو څخه خلاصیږي. دوهم، کوډ د هغو خلکو لپاره د پوهیدو وړ کیږي چې د هغې په ساتنه کې ښکیل دي. او دا خورا مهم دی! یوازې د دې لپاره، دا د کوډ د روښانه کولو او ساتلو لپاره اسانه کولو لپاره د کوچنیو بیاکتنې ترسره کولو ارزښت لري. څرنګه چې شنونکی نه پوهیږي چې ایا "بریک" ته اړتیا ده یا نه، دا به د نورو پروګرام کونکو لپاره هم روښانه نه وي.
د بګ فکسونو او ریفیکٹرینګونو سربیره ، تاسو کولی شئ په ځانګړي ډول د غلط تحلیل کونکي خبرداری فشار ورکړئ. ځینې غیر اړونده تشخیصونه غیر فعال کیدی شي. د مثال په توګه، یو څوک فکر کوي چې اخطارونه بې معنی دي د فلوټ/ډبل ارزښتونو پرتله کولو په اړه. او ځینې یې د مهم او د مطالعې وړ په توګه طبقه بندي کوي []. کوم اخطارونه اړونده ګڼل کیږي او کوم نه دي د پراختیا ټیم پورې اړه لري چې پریکړه وکړي.
د غلط خبرتیاو د ځپلو لپاره نورې لارې شتون لري. د مثال په توګه، میکرو مارک اپ مخکې یادونه وشوه. دا ټول په اسنادو کې په ډیر تفصیل سره تشریح شوي. ترټولو مهمه خبره دا ده چې پوه شئ چې که تاسو په تدریجي او سیسټمیک ډول د غلط مثبتو سره کار کولو ته نږدې شئ، نو د دوی سره هیڅ شی نشته. د نه منلو وړ اخطارونو لویه برخه د ترتیب کولو وروسته ورک کیږي، او یوازې هغه ځایونه چې واقعیا دقیق مطالعې ته اړتیا لري او په کوډ کې ځینې بدلونونه پاتې دي.
همچنان ، موږ تل د خپلو پیرودونکو سره د PVS سټوډیو تنظیم کولو کې مرسته کوو که کومه ستونزه رامینځته شي. سربیره پردې، داسې قضیې وې کله چې موږ پخپله غلط اخطارونه له منځه یوړل او غلطۍ یې سمې کړې []. یوازې په هغه حالت کې ، ما پریکړه وکړه چې یادونه وکړم چې د پراخې همکارۍ لپاره دا اختیار هم امکان لري :).
د راچټ طریقه
د جامد تحلیل کونکي خبرتیا له مینځه وړلو سره د کوډ کیفیت په تدریجي ډول ښه کولو لپاره یو بل په زړه پورې طریقه شتون لري. لاندینۍ کرښه دا ده چې د اخطارونو شمیر یوازې کم کیدی شي.
د جامد تحلیل کونکي لخوا صادر شوي اخطارونو شمیر ثبت شوی. د کیفیت دروازه په داسې ډول ترتیب شوې چې اوس تاسو کولی شئ یوازې یو کوډ داخل کړئ چې د عملیاتو شمیر نه زیاتوي. د پایلې په توګه، په تدریجي ډول د الارمونو شمیر کمولو پروسه د تحلیل کونکي تنظیم کولو او د غلطیو سمولو سره پیل کیږي.
حتی که یو څوک وغواړي یو څه خیانت وکړي او پریکړه وکړي چې د کیفیت دروازې تیر کړي نه په خپل نوي کوډ کې د اخطارونو له مینځه وړلو سره ، مګر د زاړه دریمې ډلې کوډ په ښه کولو سره ، دا ویره نلري. په ورته ډول، ریچټ په یو لوري کې ګرځي، او په تدریجي ډول د نیمګړتیاوو شمیر به کم شي. حتی که یو څوک نه غواړي چې خپل نوي نیمګړتیاوې حل کړي، هغه به بیا هم د ګاونډي کوډ کې یو څه ښه کړي. په یو وخت کې، د اخطارونو شمیر کمولو لپاره اسانه لارې پای ته رسیږي، او یو ټکی راځي کله چې ریښتینې کیګونه به حل شي.
دا میتودولوژي په ډیر تفصیل سره د Ivan Ponomarev لخوا په زړه پورې مقاله کې تشریح شوې ""، کوم چې زه هر هغه چا ته د لوستلو وړاندیز کوم چې د کوډ کیفیت ښه کولو کې لیوالتیا لري.
د مقالې لیکوال هم پر همدې موضوع یو راپور لري:".
پایلې
زه امید لرم چې د دې مقالې وروسته، لوستونکي به د جامد تحلیلي وسیلو د منلو وړ وي او غواړي چې د پراختیا په بهیر کې پلي کړي. که تاسو کومه پوښتنه لرئ، موږ تل چمتو یو زموږ د جامد تحلیل کونکي PVS-Studio کارونکي او د دې پلي کولو کې مرسته کوي.
په دې اړه نور عادي شکونه شتون لري چې ایا جامد تحلیل واقعیا اسانه او ګټور کیدی شي. ما هڅه وکړه چې دا ډیری شکونه په خپرونه کې لرې کړم "د پراختیا پروسې ته د PVS-Studio جامد کوډ تحلیل کونکي معرفي کولو لاملونه" [].
ستاسو د پاملرنې څخه مننه او راځي او د PVS-Studio شنونکی هڅه وکړئ.
اضافي لینکونه
- اندری کارپوف
- ويکيپېډيا .
- اندری کارپوف، ویکتوریا خانیوا. .
- PVS- سټوډیو. اسناد. .
- اندری کارپوف .
- PVS- سټوډیو. اسناد. .
- ایوان اندریشین .
- پاول ایریمیف، سویاتوسلاو رازمیسلوف. .
- اندری کارپوف .
که تاسو غواړئ دا مقاله د انګلیسي ژبو لیدونکو سره شریکه کړئ، مهرباني وکړئ د ژباړې لینک وکاروئ: اندری کارپوف. .
سرچینه: www.habr.com