په پروسه کې جامد تحلیل پلي کړئ، د دې پرځای چې د کیګونو موندلو لپاره یې وکاروئ

ما ته وهڅول شو چې دا مقاله د جامد تحلیل په اړه د لوی مقدار موادو لخوا ولیکم چې په زیاتیدونکي توګه زما پام ته راځي. لومړی، دا د PVS سټوډیو بلاګ، کوم چې په فعاله توګه د خلاصې سرچینې پروژې کې د دوی وسیلې لخوا موندل شوي غلطیو بیاکتنې په مرسته په هابر کې ځان ته وده ورکوي. په دې وروستیو کې PVS-studio پلي شوی د جاوا ملاتړ، او البته، د IntelliJ IDEA پراختیا کونکي، چې جوړ شوی شنونکی شاید د نن ورځې جاوا لپاره خورا پرمختللی وي، لرې پاتې نشو.

کله چې دا ډول بیاکتنې ولولئ، تاسو احساس کوئ چې موږ د جادو امریت په اړه خبرې کوو: تڼۍ فشار کړئ، او دا دلته دی - ستاسو د سترګو په وړاندې د نیمګړتیاوو لیست. داسې بریښي چې لکه څنګه چې تحلیل کونکي وده کوي ، ډیر او نور بګ به په اوتومات ډول وموندل شي ، او د دې روبوټونو لخوا سکین شوي محصولات به زموږ په برخه کې پرته له کومې هڅې څخه ښه او غوره شي.

مګر هیڅ جادویی امرونه شتون نلري. زه غواړم د هغه څه په اړه وغږیږم چې معمولا په پوسټونو کې نه ویل کیږي لکه "دلته هغه شیان دي چې زموږ روبوټ موندلی شي": کوم تحلیل کونکي نشي کولی ، د سافټویر تحویلي پروسې کې د دوی اصلي رول او ځای څه دی ، او څنګه یې په سمه توګه پلي کول .

راچیټ (سرچینه: ويکيپېډيا).

کوم جامد شنونکي هیڅکله نشي کولی

د سرچینې کوډ تحلیل څه شی دی، د عملي نظر څخه؟ موږ ځینې سرچینې کوډ د ان پټ په توګه چمتو کوو، او د محصول په توګه، په لنډ وخت کې (د چلولو ازموینو څخه ډیر لنډ) موږ د خپل سیسټم په اړه ځینې معلومات ترلاسه کوو. د بنسټیز او ریاضيکي پلوه د نه منلو وړ محدودیت دا دی چې موږ کولی شو په دې طریقه یوازې د کافي محدود ټولګي معلومات ترلاسه کړو.

د یوې ستونزې ترټولو مشهور مثال چې د جامد تحلیل په کارولو سره نشي حل کیدی د بندولو ستونزه: دا یو تیوریم دی چې دا ثابتوي چې د عمومي الګوریتم رامینځته کول ناممکن دي چې کولی شي د برنامې سرچینې کوډ څخه وټاکي چې ایا دا به په یو محدود وخت کې لوپ شي یا پای ته ورسیږي. د دې تیورم توسیع دی د وريجو نظريه، کوم چې وايي چې د کمپیوټري فعالیتونو د هر غیر معمولي ملکیت لپاره ، دا معلومول چې ایا یو خپلسري برنامه د داسې ملکیت سره فنکشن ارزوي ایا د الګوریتمیک پلوه د پام وړ ستونزه ده. د مثال په توګه، دا ناشونې ده چې یو تحلیل کوونکی ولیکئ چې د کومې سرچینې کوډ څخه معلومه کړي چې ایا برنامه تحلیل کیږي د یو الګوریتم پلي کول دي چې د عدد د مربع محاسبه کوي.

په دې توګه، د جامد تحلیل کونکو فعالیت د نه منلو وړ محدودیتونه لري. یو جامد شنونکی به هیڅکله ونشي کولی په ټولو قضیو کې داسې شیان کشف کړي لکه د مثال په توګه ، په ژبو کې د "نول پوائنټر استثنا" شتون چې د نول ارزښت ته اجازه ورکوي ، یا په ټولو قضیو کې د پیښې پیژندلو لپاره. خاصیت نه موندل شوی" په متحرک ډول لیکل شوي ژبو کې. ټول هغه څه چې خورا پرمختللي جامد شنونکی یې کولی شي ځانګړي قضیې روښانه کړي، د کوم شمیر چې ستاسو د سرچینې کوډ سره د ټولو ممکنه ستونزو په منځ کې، پرته له مبالغې پرته، په بالټ کې یو کمښت دی.

جامد تحلیل د کیګونو موندلو په اړه ندي

له پورته څخه، پایله په لاندې ډول ده: جامد تحلیل په پروګرام کې د نیمګړتیاوو د کمولو وسیله نه ده. زه به ووایم: کله چې ستاسو په پروژه کې د لومړي ځل لپاره پلي کیږي، دا به په کوډ کې "په زړه پورې" ځایونه ومومي، مګر، ډیری احتمال، دا به هیڅ نیمګړتیا ونه موندل شي چې ستاسو د برنامه کیفیت اغیزه کوي.

د شنونکو لخوا په اوتومات ډول موندل شوي د نیمګړتیاو مثالونه اغیزمن دي ، مګر موږ باید هیر نکړو چې دا مثالونه د لوی کوډبیسونو لوی سیټ سکین کولو سره موندل شوي. د ورته اصولو له مخې، هیکرز چې فرصت لري په ډیری حسابونو کې د څو ساده پاسورډونو هڅه وکړي بالاخره هغه حسابونه ومومي چې ساده پاسورډ لري.

ایا دا پدې معنی ده چې جامد تحلیل باید ونه کارول شي؟ البته نه! او د ورته دلیل لپاره چې دا د هر نوي پاسورډ چیک کولو ارزښت لري ترڅو ډاډ ترلاسه کړي چې دا د "ساده" پاسورډونو په بند لیست کې شامل دي.

جامد تحلیل د کیګونو موندلو څخه ډیر دی

په حقیقت کې، هغه ستونزې چې په عملي توګه د تحلیل له لارې حل کیږي خورا پراخې دي. په هرصورت، په عموم کې، جامد تحلیل د سرچینې کوډونو هر ډول تصدیق دی چې مخکې له دې چې پیل شي ترسره کیږي. دلته ځینې شیان دي چې تاسو یې کولی شئ:

• د کلمې په پراخه مفهوم کې د کوډ کولو سټایل چیک کول. پدې کې د فارمیټینګ دواړه چک کول، د خالي/اضافي قوسونو کارول، په میتریکونو کې د حدونو ټاکل لکه د لینونو شمیر/د میتود سایکلومیټ پیچلتیا، او داسې نور - هر هغه څه چې په احتمالي توګه د کوډ لوستلو او ساتلو کې خنډ وي. په جاوا کې، دا ډول وسیله چیک سټایل دی، په پایتون کې - flake8. د دې ټولګي پروګرامونه معمولا د "لینټر" په نوم یادېږي.
• نه یوازې د اجرا وړ کوډ تحلیل کیدی شي. د سرچینو فایلونه لکه JSON، YAML، XML، .properties کیدای شي (او باید!) په اتوماتيک ډول د اعتبار لپاره وڅیړل شي. په هرصورت ، دا غوره ده چې ومومئ چې د JSON جوړښت د ازموینې اجرا کولو یا چلولو وخت په پرتله د اتوماتیک پل غوښتنې تایید په لومړي مرحله کې د ځینې بې جوړې نرخونو له امله مات شوی؟ مناسب وسایل شتون لري: د بیلګې په توګه YAMLlint, JSONLint.
• تالیف (یا د متحرک پروګرامینګ ژبو لپاره تحلیل) هم د جامد تحلیل یو ډول دی. په عموم کې، تالیف کونکي د اخطارونو تولید کولو توان لري چې د سرچینې کوډ کیفیت سره ستونزې په ګوته کوي او باید له پامه ونه غورځول شي.
• ځینې ​​​​وختونه تالیف یوازې د اجرا وړ کوډ تالیف کولو څخه ډیر دی. د مثال په توګه، که تاسو په بڼه کې اسناد لرئ اسسیدي ډیکټر، بیا په HTML/PDF کې د بدلولو په وخت کې د AsciiDoctor هینډلر (Maven پلگ ان) کولی شي اخطارونه صادر کړي، د بیلګې په توګه، د مات شوي داخلي اړیکو په اړه. او دا یو ښه دلیل دی چې د اسنادو بدلونونو سره د پل غوښتنه نه منل کیږي.
• د املا چک کول هم د جامد تحلیل یو ډول دی. افادیت اسپل د دې وړتیا لري چې املا نه یوازې په اسنادو کې چیک کړي ، بلکه د برنامې سرچینې کوډونو (تبصرې او لغوي) کې هم په مختلف پروګرامینګ ژبو کې ، پشمول د C/C++ ، Java او Python. د کارن انٹرفیس یا اسنادو کې د املا خطا هم یوه نیمګړتیا ده!
• د ترتیب کولو ازموینې (د هغه څه په اړه چې دوی دي - وګورئ. دا и دا راپورونه)، که څه هم د یونټ ټیسټ رن ټایم کې اعدام شوي لکه pytest، په حقیقت کې د جامد تحلیل یو ډول دی، ځکه چې دوی د دوی د اجرا کولو پرمهال د سرچینې کوډونه نه اجرا کوي.

لکه څنګه چې تاسو لیدلی شئ، په دې لیست کې د کیګونو لټون خورا لږ مهم رول لوبوي، او نور هرڅه د وړیا خلاصې سرچینې وسیلو په کارولو سره شتون لري.

د دې ډول جامد تحلیلونو څخه کوم یو باید په خپله پروژه کې وکاروئ؟ البته، څومره چې ډیر ښه وي! اصلي شی دا دی چې دا په سمه توګه پلي کړي، کوم چې به نور بحث وشي.

د تحویلي پایپ لاین د څو مرحلې فلټر په توګه او د لومړي مرحلې په توګه جامد تحلیل

د دوامداره ادغام لپاره کلاسیک استعاره یو پایپ لاین دی چې له لارې یې جریان بدلیږي ، د سرچینې کوډ بدلون څخه تولید ته تحویل ته. په دې پایپ لاین کې د مرحلو معیاري ترتیب داسې ښکاري:

1. جامد تحلیل
2. COMпиляция
3. د واحد ازموینې
4. د ادغام ازموینې
5. د UI ازموینې
6. لاسي چک

د پایپ لاین په نهم پړاو کې رد شوي بدلونونه د N+1 مرحلې ته نه لیږدول کیږي.

ولې په سمه توګه دا لاره او بل ډول نه؟ د پایپ لاین د ازموینې برخه کې، ازموینه کونکي به پیژندل شوي ټیسټ پیرامډ پیژني.

ټیسټ پیرامید. سرچینه: مقاله مارتین فولر.

د دې پیرامیډ په پای کې ازموینې دي چې لیکل یې اسانه دي ، د پلي کولو لپاره ګړندي دي ، او د ناکامۍ تمایل نلري. له همدې امله، د دوی باید ډیر وي، دوی باید ډیر کوډ پوښښ کړي او لومړی اعدام شي. د پیرامیډ په پورتنۍ برخه کې ، برعکس ریښتیا ده ، نو د ادغام او UI ازموینو شمیر باید اړین لږترلږه ته راټیټ شي. په دې سلسله کې سړی تر ټولو ګران، سست او بې اعتباره سرچینه ده، نو هغه په ​​پای کې دی او یوازې هغه کار ترسره کوي چې په تیرو مرحلو کې هیڅ عیب ونه موندل شي. په هرصورت، ورته اصول په هغو برخو کې د پایپ لاین جوړولو لپاره کارول کیږي چې په مستقیم ډول د ازموینې سره تړاو نلري!

زه غواړم د څو پړاوونو د اوبو فلټریشن سیسټم په بڼه یو مشابهت وړاندې کړم. ناپاکه اوبه (د نیمګړتیاوو سره بدلونونه) داخل ته ورکول کیږي؛ په محصول کې موږ باید پاکې اوبه ترلاسه کړو، په کوم کې چې ټول ناغوښتل ککړونکي له منځه وړل شوي.

د څو مرحلو فلټر. سرچینه: Wikimedia Commons

لکه څنګه چې تاسو پوهیږئ، د پاکولو فلټرونه ډیزاین شوي ترڅو هر راتلونکی کاسکیډ کولی شي د ککړتیا په زیاتیدونکي توګه ښه برخه فلټر کړي. په ورته وخت کې، د پاکولو cascades لوړ throughput او ټیټ لګښت لري. زموږ په مشابهت کې، دا پدې مانا ده چې د داخلي کیفیت دروازې ګړندۍ دي، د پیل کولو لپاره لږې هڅې ته اړتیا لري، او پخپله په عملیاتو کې خورا بې ساري دي - او دا هغه ترتیب دی چې دوی جوړ شوي. د جامد تحلیل رول، لکه څنګه چې موږ اوس پوهیږو، د دې وړتیا لري چې یوازې ترټولو لوی نیمګړتیاوې له منځه یوسي، د فلټر کاسکیډ په پیل کې د "خټو" گرډ رول دی.

پخپله جامد تحلیل د وروستي محصول کیفیت نه ښه کوي، لکه څنګه چې د "خټو فلټر" اوبه د څښاک وړ نه کوي. او بیا هم، د پایپ لاین د نورو عناصرو سره په ګډه، د هغې اهمیت څرګند دی. که څه هم په څو مرحلې فلټر کې د محصول مرحلې په بالقوه توګه د هر هغه څه د نیولو توان لري چې د ان پټ مرحلې ترسره کوي، دا روښانه ده چې د ان پټ مرحلو پرته، یوازې د پاک پاکولو مرحلو سره د ترسره کولو هڅه به څه پایلې ولري.

د "خټو د جال" موخه دا ده چې راتلونکی کیسکایډونه د خورا لوی نیمګړتیاوو له مینځه وړلو څخه خلاص کړي. د مثال په توګه، لږترلږه، هغه څوک چې د کوډ بیاکتنه کوي باید د غلط فارمیټ شوي کوډ او د تاسیس شوي کوډ کولو معیارونو څخه سرغړونې (لکه اضافي قوس یا ډیر ژور ځړول شوي څانګو) له امله مغشوش نشي. د NPEs په څیر بګ باید د واحد ازموینې لخوا ونیول شي ، مګر که حتی د ازموینې دمخه تحلیل کونکی موږ ته په ګوته کړي چې بګ باید پیښ شي ، نو دا به د پام وړ د هغې اصلاح ګړندي کړي.

زه باور لرم چې دا اوس روښانه ده چې ولې جامد تحلیل د محصول کیفیت نه ښه کوي که چیرې کله کله کارول کیږي، او باید په دوامداره توګه وکارول شي ترڅو د ناخالص نیمګړتیاوو سره بدلونونه فلټر کړي. دا پوښتنه چې ایا د جامد شنونکي کارول به ستاسو د محصول کیفیت ښه کړي تقریبا د دې پوښتنې سره مساوي دي چې "ایا له ناپاکو حوض څخه اخیستل شوي اوبه د څښاک کیفیت ښه کیدی شي که چیرې دا د کالیډر څخه تیریږي؟"

په میراثي پروژه کې پلي کول

یوه مهمه عملي پوښتنه: د "کیفیت دروازې" په توګه د دوامداره ادغام پروسې کې جامد تحلیل څنګه پلي کول؟ د اتوماتیک ازموینو په صورت کې، هرڅه روښانه دي: د ازموینو یوه ټولګه شتون لري، د دوی د ناکامۍ لپاره کافي دلیل دی چې باور لري چې مجلس د کیفیت دروازه نه وه تیره کړې. د جامد تحلیل پایلو پراساس په ورته ډول د دروازې نصبولو هڅه ناکامه کیږي: په میراثي کوډ کې ډیری تحلیلي اخطارونه شتون لري ، تاسو نه غواړئ دوی په بشپړ ډول له پامه وغورځوئ ، مګر د محصول لیږدولو مخه نیول هم ناممکن دي. یوازې د دې لپاره چې دا د تحلیل کونکي اخطارونه لري.

کله چې د لومړي ځل لپاره کارول کیږي، تحلیل کونکی په هره پروژه کې لوی شمیر اخطارونه تولیدوي، چې ډیری یې د محصول سم فعالیت پورې تړاو نلري. دا ناشونې ده چې دا ټول نظرونه په یو وخت کې سم کړئ، او ډیری یې اړین ندي. په هرصورت ، موږ پوهیږو چې زموږ محصول په بشپړ ډول کار کوي ، حتی د جامد تحلیل معرفي کولو دمخه!

د پایلې په توګه، ډیری یې کله ناکله د جامد تحلیل کارولو پورې محدود دي، یا دا یوازې د معلوماتو حالت کې کاروي، کله چې د تحلیل کونکي راپور په ساده ډول د مجلس په جریان کې خپور شي. دا د کوم تحلیل نشتوالي سره مساوي دی ، ځکه چې که موږ دمخه ډیری اخطارونه ولرو ، نو د کوډ بدلولو په وخت کې د بل پیښې (که څومره جدي وي) د پام وړ نه وي.

د کیفیت دروازې معرفي کولو لاندې میتودونه پیژندل شوي:

• د اخطارونو ټول شمیر یا د اخطارونو شمیر باندې د حد ټاکل د کوډ د لینونو شمیر لخوا ویشل شوي. دا خراب کار کوي، ځکه چې دا ډول دروازه په آزاده توګه د نوي نیمګړتیاوو سره بدلونونو ته اجازه ورکوي، تر هغه چې د دوی حد نه وي.
• فکس کول، په یوه ټاکلې شیبه کې، په کوډ کې ټول زاړه اخطارونه لکه څنګه چې له پامه غورځول شوي، او د جوړولو څخه انکار کول کله چې نوي اخطارونه پیښ شي. دا فعالیت د PVS-studio او ځینې آنلاین سرچینو لخوا چمتو شوی، د بیلګې په توګه، Codacy. ما په PVS-studio کې د کار کولو فرصت نه درلود، لکه څنګه چې د کوډسي سره زما د تجربې لپاره، د دوی اصلي ستونزه دا ده چې دا معلومه کړي چې "زاړه" څه شی دی او "نوی" تېروتنه څه ده یو پیچلی الګوریتم دی چې تل کار نه کوي. په سمه توګه، په ځانګړې توګه که فایلونه په پراخه کچه تعدیل شوي یا نوم بدل کړي. زما په تجربه کې، کوډیسي کولی شي د پلټ غوښتنې کې نوي اخطارونه له پامه غورځوي، پداسې حال کې چې په ورته وخت کې د اخطارونو له امله چې د ورکړل شوي PR په کوډ کې بدلونونو سره تړاو نلري د پلټ غوښتنه نه تیریږي.
• زما په نظر، ترټولو مؤثر حل هغه دی چې په کتاب کې بیان شوی دوامداره تحویلي "د راکټ کولو طریقه". بنسټیز نظر دا دی چې د جامد تحلیلي اخطارونو شمیر د هرې خوشې کولو ملکیت دی، او یوازې بدلونونو ته اجازه ورکول کیږي چې د اخطارونو مجموعي شمیر نه زیاتوي.

راچټ

دا په دې ډول کار کوي:

1. په لومړي مرحله کې، د تحلیل کونکو لخوا موندل شوي کوډ کې د اخطارونو شمیره خوشې کولو په اړه میټاډاټا کې ریکارډ جوړ شوی. نو، کله چې تاسو اپ سټریم جوړ کړئ، ستاسو د ذخیره کولو مدیر نه یوازې "7.0.2 خوشې کول" لیکي، مګر "د 7.0.2 خوشې کول چې د 100500 چک سټایل خبرداری لري." که تاسو د پرمختللي ذخیره کولو مدیر کاروئ (لکه هنري فابریکه)، ستاسو د خوشې کولو په اړه د داسې میټاډاټا ذخیره کول اسانه دي.
2. اوس هر پل غوښتنه، کله چې جوړ شي، د پایلې اخطارونو شمیر په اوسني ریلیز کې موجود اخطارونو شمیر سره پرتله کوي. که PR د دې شمیر زیاتوالي لامل شي ، نو کوډ د جامد تحلیل لپاره د کیفیت دروازې نه تیریږي. که د اخطارونو شمیر کم شي یا بدلون ونه کړي، نو دا تیریږي.
3. په راتلونکی ریلیز کې، د اخطارونو بیا حساب شوي شمیر به بیا د خوشې میټاډاټا کې ثبت شي.

نو لږ لږ مګر په ثابت ډول (لکه کله چې یو ریچټ کار کوي)، د اخطارونو شمیر به صفر ته ورسیږي. البته، سیسټم د نوي خبرتیا په معرفي کولو سره غولول کیدی شي، مګر د بل چا اصلاح کول. دا عادي خبره ده، ځکه چې په اوږده واټن کې دا پایلې ورکوي: اخطارونه سم کیږي، د یوې قاعدې په توګه، په انفرادي توګه نه، مګر په یو وخت کې د یو ځانګړي ډول په ډله کې، او ټول په اسانۍ سره د لرې کولو وړ اخطارونه په چټکۍ سره له منځه وړل کیږي.

دا ګراف د دې ډول "ریچټ" عملیاتو شپږ میاشتو لپاره د چک سټایل اخطارونو مجموعي شمیر ښیې. زموږ د OpenSource پروژې څخه یوه. د اخطارونو شمیر د اندازې په ترتیب سره کم شوی ، او دا په طبیعي ډول پیښ شوي ، د محصول پراختیا سره موازي!

زه د دې میتود بدله شوې نسخه کاروم ، په جلا توګه د پروژې ماډل او تحلیلي وسیلې لخوا اخطارونه حسابوم ، په پایله کې د 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 سکریپټ کې اړین منطق لیکل دي. تاسو کولی شئ وګورئ چې دا زموږ د خلاصې سرچینې پروژو کې د جینکنز او هنري فابریکې پراساس پلي کیږي دلته او یا دلته. دواړه مثالونه په کتابتون پورې اړه لري ratchetlib: طریقه countWarnings() په معمول ډول د چیک سټایل او سپوټبګ لخوا رامینځته شوي فایلونو کې د xml ټاګونه حسابوي ، او compareWarningMaps() ورته ریچټ پلي کوي، یوه تېروتنه اچوي کله چې په هره کټګورۍ کې د اخطارونو شمیر زیات شي.

د "ریچټ" په زړه پورې پلي کول د اسپیل په کارولو سره د تبصرو ، متن لیکونو او اسنادو املا تحلیل کولو لپاره امکان لري. لکه څنګه چې تاسو پوهیږئ، کله چې املا چیک کړئ، ټول هغه ټکي چې په معیاري قاموس کې ناپیژندل شوي غلط ندي؛ دوی د کارونکي لغت کې اضافه کیدی شي. که تاسو د پروژې د سرچینې کوډ دودیز لغت برخه جوړه کړئ، نو د املا کیفیت دروازه په دې ډول جوړه کیدی شي: د معیاري او دودیز لغت سره د اسپیل چلول باید نه د املا غلطۍ مه ګورئ.

د تحلیلي نسخې د فکس کولو اهمیت په اړه

په پایله کې، د یادولو وړ ټکی دا دی چې مهمه نده چې تاسو څنګه د خپل تحویلي پایپ لاین کې تحلیل پلي کوئ ، د تحلیل کونکي نسخه باید تنظیم شي. که تاسو تحلیل کونکي ته په ناڅاپي ډول د تازه کولو اجازه ورکړئ ، نو کله چې د راتلونکي پل غوښتنه راټول کړئ ، نو نوي نیمګړتیاوې ممکن "پاپ اپ" وي چې د کوډ بدلونونو سره تړاو نلري ، مګر پدې حقیقت پورې اړه لري چې نوی شنونکی په ساده ډول د نورو نیمګړتیاو موندلو توان لري - او دا به ستاسو د غوښتنې منلو پروسه مات کړي. د تحلیل کونکي لوړول باید یو شعوري عمل وي. په هرصورت، د هرې غونډې برخې نسخه سخت تنظیم کول عموما یو اړین اړتیا او د جلا بحث لپاره موضوع ده.

موندنو

• جامد تحلیل به ستاسو لپاره بګ ونه موندل شي او د یو واحد غوښتنلیک په پایله کې به ستاسو د محصول کیفیت ښه نه کړي. په کیفیت مثبت اغیزه یوازې د تحویلي پروسې په جریان کې د دې دوامداره کارونې له لارې ترلاسه کیدی شي.
• د بګ موندنه په اصل کې د تحلیل اصلي دنده نه ده؛ د ګټورو کارونو پراخه برخه د خلاصې سرچینې وسیلو کې شتون لري.
• د تحویلي پایپ لاین په لومړي مرحله کې د جامد تحلیل پایلو پراساس د کیفیت دروازې پلي کړئ ، د میراث کوډ لپاره د "ریچټ" په کارولو سره.

مرجع

1. دوامداره تحویلي
2. A. Kudryavtsev: د پروګرام تحلیل: څنګه پوه شو چې تاسو یو ښه پروګرامر یاست د کوډ تحلیل مختلف میتودونو راپور ورکړئ (نه یوازې جامد!)

سرچینه: www.habr.com