బగ్‌లను కనుగొనడానికి దాన్ని ఉపయోగించకుండా, ప్రక్రియలో స్టాటిక్ విశ్లేషణను అమలు చేయండి

నా దృష్టికి ఎక్కువగా వస్తున్న స్టాటిక్ అనాలిసిస్‌పై పెద్ద మొత్తంలో మెటీరియల్‌ల ద్వారా ఈ కథనాన్ని వ్రాయమని నేను ప్రాంప్ట్ చేయబడ్డాను. మొదట, ఇది PVS-స్టూడియో బ్లాగ్, ఇది ఓపెన్ సోర్స్ ప్రాజెక్ట్‌లలో వారి సాధనం ద్వారా కనుగొనబడిన లోపాల సమీక్షల సహాయంతో హబ్రేలో చురుకుగా ప్రచారం చేస్తుంది. ఇటీవల PVS-స్టూడియో అమలు చేయబడింది జావా మద్దతు, మరియు, వాస్తవానికి, IntelliJ IDEA డెవలపర్లు, దీని అంతర్నిర్మిత ఎనలైజర్ బహుశా ఈ రోజు జావాకు అత్యంత అధునాతనమైనది, దూరంగా ఉండలేకపోయింది.

అటువంటి సమీక్షలను చదివేటప్పుడు, మేము మాయా అమృతం గురించి మాట్లాడుతున్నామనే భావన మీకు వస్తుంది: బటన్‌ను నొక్కండి మరియు ఇక్కడ ఉంది - మీ కళ్ళ ముందు లోపాల జాబితా. ఎనలైజర్‌లు మెరుగుపడినప్పుడు, మరిన్ని బగ్‌లు స్వయంచాలకంగా కనుగొనబడతాయి మరియు ఈ రోబోట్‌ల ద్వారా స్కాన్ చేయబడిన ఉత్పత్తులు మన వంతు ప్రయత్నం లేకుండానే మెరుగ్గా మరియు మెరుగ్గా మారతాయి.

కానీ మంత్ర అమృతాలు లేవు. "మా రోబోట్ కనుగొనగలిగే విషయాలు ఇక్కడ ఉన్నాయి" వంటి పోస్ట్‌లలో సాధారణంగా మాట్లాడని వాటి గురించి నేను మాట్లాడాలనుకుంటున్నాను: ఎనలైజర్‌లు ఏమి చేయలేవు, సాఫ్ట్‌వేర్ డెలివరీ ప్రక్రియలో వారి నిజమైన పాత్ర మరియు స్థానం ఏమిటి మరియు వాటిని సరిగ్గా ఎలా అమలు చేయాలి .

రాట్చెట్ (మూలం: వికీపీడియా).

స్టాటిక్ ఎనలైజర్లు ఏమి చేయలేవు

ప్రాక్టికల్ పాయింట్ నుండి సోర్స్ కోడ్ విశ్లేషణ అంటే ఏమిటి? మేము కొంత సోర్స్ కోడ్‌ను ఇన్‌పుట్‌గా అందిస్తాము మరియు అవుట్‌పుట్‌గా, తక్కువ సమయంలో (రన్నింగ్ టెస్ట్‌ల కంటే చాలా తక్కువ) మేము మా సిస్టమ్ గురించి కొంత సమాచారాన్ని పొందుతాము. ప్రాథమిక మరియు గణితశాస్త్రపరంగా అధిగమించలేని పరిమితి ఏమిటంటే, మనం ఈ విధంగా చాలా ఇరుకైన తరగతి సమాచారాన్ని మాత్రమే పొందగలము.

స్థిర విశ్లేషణను ఉపయోగించి పరిష్కరించలేని సమస్యకు అత్యంత ప్రసిద్ధ ఉదాహరణ షట్డౌన్ సమస్య: ఇది ఒక సాధారణ అల్గారిథమ్‌ను అభివృద్ధి చేయడం అసాధ్యమని నిరూపించే ఒక సిద్ధాంతం, ఇది ప్రోగ్రామ్ యొక్క సోర్స్ కోడ్ నుండి అది లూప్ అవుతుందా లేదా నిర్ణీత సమయంలో ముగిసిపోతుందా అని నిర్ధారించగలదు. ఈ సిద్ధాంతం యొక్క పొడిగింపు రైస్ సిద్ధాంతం, కంప్యూటబుల్ ఫంక్షన్‌ల యొక్క ఏదైనా నాన్-ట్రివియల్ ప్రాపర్టీ కోసం, ఒక ఏకపక్ష ప్రోగ్రామ్ అటువంటి ఆస్తితో ఫంక్షన్‌ను మూల్యాంకనం చేస్తుందో లేదో నిర్ణయించడం అల్గారిథమిక్‌గా పరిష్కరించలేని సమస్య అని పేర్కొంది. ఉదాహరణకు, విశ్లేషించబడుతున్న ప్రోగ్రామ్ పూర్ణాంకం యొక్క స్క్వేర్‌ని గణించే అల్గారిథమ్ యొక్క అమలు కాదా అని ఏదైనా సోర్స్ కోడ్ నుండి నిర్ధారించగల ఎనలైజర్‌ను వ్రాయడం అసాధ్యం.

అందువలన, స్టాటిక్ ఎనలైజర్ల కార్యాచరణకు అధిగమించలేని పరిమితులు ఉన్నాయి. ఒక స్టాటిక్ ఎనలైజర్ అన్ని సందర్భాల్లోనూ ఎప్పటికీ గుర్తించదు, ఉదాహరణకు, శూన్య విలువను అనుమతించే భాషలలో "శూన్య పాయింటర్ మినహాయింపు" సంభవించడం లేదా అన్ని సందర్భాల్లో "" సంభవించడాన్ని గుర్తించడం. డైనమిక్‌గా టైప్ చేసిన భాషలలో లక్షణం కనుగొనబడలేదు. అత్యంత అధునాతన స్టాటిక్ ఎనలైజర్ చేయగలిగినదంతా ప్రత్యేక సందర్భాలను హైలైట్ చేస్తుంది, మీ సోర్స్ కోడ్‌తో సాధ్యమయ్యే అన్ని సమస్యలలో వాటి సంఖ్య, అతిశయోక్తి లేకుండా, సముద్రంలో పడిపోతుంది.

స్థిర విశ్లేషణ దోషాలను కనుగొనడం కాదు

పై నుండి, ముగింపు క్రింది విధంగా ఉంది: స్టాటిక్ విశ్లేషణ అనేది ప్రోగ్రామ్‌లోని లోపాల సంఖ్యను తగ్గించే సాధనం కాదు. నేను చెప్పే సాహసం: మీ ప్రాజెక్ట్‌కి మొదటిసారి దరఖాస్తు చేసినప్పుడు, అది కోడ్‌లో “ఆసక్తికరమైన” స్థలాలను కనుగొంటుంది, కానీ, చాలా మటుకు, ఇది మీ ప్రోగ్రామ్ నాణ్యతను ప్రభావితం చేసే ఏ లోపాలను కనుగొనదు.

ఎనలైజర్‌ల ద్వారా స్వయంచాలకంగా కనుగొనబడిన లోపాల ఉదాహరణలు ఆకట్టుకుంటాయి, అయితే ఈ ఉదాహరణలు పెద్ద పెద్ద కోడ్‌బేస్‌లను స్కాన్ చేయడం ద్వారా కనుగొనబడినట్లు మనం మర్చిపోకూడదు. అదే సూత్రం ప్రకారం, పెద్ద సంఖ్యలో ఖాతాలలో అనేక సాధారణ పాస్‌వర్డ్‌లను ప్రయత్నించే అవకాశం ఉన్న హ్యాకర్లు చివరికి సాధారణ పాస్‌వర్డ్‌ను కలిగి ఉన్న ఖాతాలను కనుగొంటారు.

స్టాటిక్ అనాలిసిస్ ఉపయోగించకూడదని దీని అర్థం? అస్సలు కానే కాదు! మరియు సరిగ్గా అదే కారణంతో ప్రతి కొత్త పాస్‌వర్డ్‌ను "సింపుల్" పాస్‌వర్డ్‌ల స్టాప్ లిస్ట్‌లో చేర్చారని నిర్ధారించుకోవడానికి దాన్ని తనిఖీ చేయడం విలువైనదే.

బగ్‌లను కనుగొనడం కంటే స్టాటిక్ విశ్లేషణ ఎక్కువ

వాస్తవానికి, విశ్లేషణ ద్వారా ఆచరణాత్మకంగా పరిష్కరించబడిన సమస్యలు చాలా విస్తృతమైనవి. అన్నింటికంటే, సాధారణంగా, స్టాటిక్ అనాలిసిస్ అనేది సోర్స్ కోడ్‌లను ప్రారంభించే ముందు నిర్వహించే ఏదైనా ధృవీకరణ. మీరు చేయగలిగే కొన్ని విషయాలు ఇక్కడ ఉన్నాయి:

• పదం యొక్క విస్తృత అర్థంలో కోడింగ్ శైలిని తనిఖీ చేస్తోంది. ఇందులో ఫార్మాటింగ్‌ని తనిఖీ చేయడం, ఖాళీ/అదనపు కుండలీకరణాల ఉపయోగం కోసం వెతకడం, పంక్తుల సంఖ్య/పద్ధతి యొక్క సైక్లోమాటిక్ సంక్లిష్టత మొదలైన కొలమానాలపై థ్రెషోల్డ్‌లను సెట్ చేయడం రెండూ ఉంటాయి. జావాలో, అటువంటి సాధనం చెక్‌స్టైల్, పైథాన్‌లో - ఫ్లేక్8. ఈ తరగతి యొక్క ప్రోగ్రామ్‌లను సాధారణంగా "లింటర్స్" అని పిలుస్తారు.
• ఎక్జిక్యూటబుల్ కోడ్ మాత్రమే విశ్లేషించబడదు. JSON, YAML, XML, .properties వంటి వనరుల ఫైల్‌లు చెల్లుబాటు కోసం స్వయంచాలకంగా తనిఖీ చేయబడతాయి (మరియు తప్పక!). అన్నింటికంటే, టెస్ట్ ఎగ్జిక్యూషన్ లేదా రన్ టైమ్ కంటే ఆటోమేటిక్ పుల్ రిక్వెస్ట్ వెరిఫికేషన్ యొక్క ప్రారంభ దశలో జత చేయని కొన్ని కోట్‌ల కారణంగా JSON నిర్మాణం విచ్ఛిన్నమైందని కనుగొనడం ఉత్తమం? తగిన సాధనాలు అందుబాటులో ఉన్నాయి: ఉదా. YAMLlint, JSONLint.
• సంకలనం (లేదా డైనమిక్ ప్రోగ్రామింగ్ భాషల కోసం అన్వయించడం) కూడా ఒక రకమైన స్టాటిక్ విశ్లేషణ. సాధారణంగా, కంపైలర్‌లు సోర్స్ కోడ్ నాణ్యతతో సమస్యలను సూచించే హెచ్చరికలను ఉత్పత్తి చేయగలవు మరియు విస్మరించకూడదు.
• కొన్నిసార్లు కంపైలేషన్ అనేది ఎక్జిక్యూటబుల్ కోడ్‌ను కంపైల్ చేయడం కంటే ఎక్కువ. ఉదాహరణకు, మీరు ఫార్మాట్‌లో డాక్యుమెంటేషన్ కలిగి ఉంటే AsciiDoctor, తర్వాత దానిని HTML/PDFగా మార్చే సమయంలో AsciiDoctor హ్యాండ్లర్ (మావెన్ ప్లగ్ఇన్) హెచ్చరికలను జారీ చేయవచ్చు, ఉదాహరణకు, విచ్ఛిన్నమైన అంతర్గత లింక్‌ల గురించి. డాక్యుమెంటేషన్ మార్పులతో పుల్ అభ్యర్థనను అంగీకరించకపోవడానికి ఇది మంచి కారణం.
• స్పెల్ చెకింగ్ కూడా ఒక రకమైన స్టాటిక్ అనాలిసిస్. వినియోగ ఆస్పెల్ డాక్యుమెంటేషన్‌లో మాత్రమే కాకుండా, C/C++, Java మరియు Pythonతో సహా వివిధ ప్రోగ్రామింగ్ భాషల్లోని ప్రోగ్రామ్ సోర్స్ కోడ్‌లలో (వ్యాఖ్యలు మరియు అక్షరాలు) స్పెల్లింగ్‌ని తనిఖీ చేయగలదు. వినియోగదారు ఇంటర్‌ఫేస్ లేదా డాక్యుమెంటేషన్‌లో స్పెల్లింగ్ లోపం కూడా ఒక లోపం!
• కాన్ఫిగరేషన్ పరీక్షలు (అవి ఏమిటో - చూడండి. ఈ и ఈ నివేదికలు), పైటెస్ట్ వంటి యూనిట్ టెస్ట్ రన్‌టైమ్‌లో అమలు చేయబడినప్పటికీ, వాస్తవానికి అవి ఒక రకమైన స్టాటిక్ అనాలిసిస్, ఎందుకంటే అవి వాటి అమలు సమయంలో సోర్స్ కోడ్‌లను అమలు చేయవు.

మీరు చూడగలిగినట్లుగా, ఈ జాబితాలో బగ్‌ల కోసం శోధించడం చాలా ముఖ్యమైన పాత్ర పోషిస్తుంది మరియు ఉచిత ఓపెన్ సోర్స్ సాధనాలను ఉపయోగించడం ద్వారా మిగతావన్నీ అందుబాటులో ఉంటాయి.

మీరు మీ ప్రాజెక్ట్‌లో ఈ రకమైన స్టాటిక్ విశ్లేషణలో ఏది ఉపయోగించాలి? వాస్తవానికి, మరింత మంచిది! ప్రధాన విషయం ఏమిటంటే దానిని సరిగ్గా అమలు చేయడం, ఇది మరింత చర్చించబడుతుంది.

బహుళ-దశల ఫిల్టర్‌గా డెలివరీ పైప్‌లైన్ మరియు దాని మొదటి దశగా స్టాటిక్ విశ్లేషణ

నిరంతర ఏకీకరణ కోసం క్లాసిక్ రూపకం అనేది పైప్‌లైన్, దీని ద్వారా సోర్స్ కోడ్ మార్పుల నుండి డెలివరీ వరకు ఉత్పత్తి వరకు మార్పులు ప్రవహిస్తాయి. ఈ పైప్‌లైన్‌లోని దశల ప్రామాణిక క్రమం ఇలా కనిపిస్తుంది:

1. స్థిర విశ్లేషణ
2. సంగ్రహం
3. యూనిట్ పరీక్షలు
4. ఏకీకరణ పరీక్షలు
5. UI పరీక్షలు
6. మాన్యువల్ చెక్

పైప్‌లైన్ యొక్క Nవ దశలో తిరస్కరించబడిన మార్పులు దశ N+1కి బదిలీ చేయబడవు.

ఎందుకు సరిగ్గా ఈ విధంగా మరియు లేకపోతే కాదు? పైప్‌లైన్ యొక్క టెస్టింగ్ భాగంలో, టెస్టర్‌లు బాగా తెలిసిన టెస్టింగ్ పిరమిడ్‌ను గుర్తిస్తారు.

పరీక్ష పిరమిడ్. మూలం: వ్యాసం మార్టిన్ ఫౌలర్.

ఈ పిరమిడ్ దిగువన సులభంగా రాయడానికి, వేగంగా అమలు చేయడానికి మరియు విఫలమయ్యే ధోరణి లేని పరీక్షలు ఉన్నాయి. అందువల్ల, వాటిలో ఎక్కువ ఉండాలి, అవి మరింత కోడ్‌ను కవర్ చేయాలి మరియు ముందుగా అమలు చేయాలి. పిరమిడ్ ఎగువన, వ్యతిరేకం నిజం, కాబట్టి ఏకీకరణ మరియు UI పరీక్షల సంఖ్యను అవసరమైన కనిష్ట స్థాయికి తగ్గించాలి. ఈ గొలుసులోని వ్యక్తి అత్యంత ఖరీదైన, నెమ్మదిగా మరియు నమ్మదగని వనరు, కాబట్టి అతను చాలా చివరిలో ఉన్నాడు మరియు మునుపటి దశలు ఏ లోపాలను కనుగొనలేకపోతే మాత్రమే పనిని నిర్వహిస్తాడు. అయినప్పటికీ, పరీక్షకు నేరుగా సంబంధం లేని భాగాలలో పైప్‌లైన్‌ను నిర్మించడానికి అదే సూత్రాలు ఉపయోగించబడతాయి!

నేను బహుళ-దశల నీటి వడపోత వ్యవస్థ రూపంలో సారూప్యతను అందించాలనుకుంటున్నాను. మురికి నీరు (లోపాలతో మార్పులు) ఇన్‌పుట్‌కు సరఫరా చేయబడుతుంది; అవుట్‌పుట్ వద్ద మనం స్వచ్ఛమైన నీటిని అందుకోవాలి, దీనిలో అన్ని అవాంఛిత కలుషితాలు తొలగించబడతాయి.

బహుళ-దశల ఫిల్టర్. మూలం: వికీమీడియా కామన్స్

మీకు తెలిసినట్లుగా, శుభ్రపరిచే ఫిల్టర్‌లు రూపొందించబడ్డాయి, తద్వారా ప్రతి తదుపరి క్యాస్కేడ్ కలుషితాల యొక్క సూక్ష్మమైన భాగాన్ని ఫిల్టర్ చేయగలదు. అదే సమయంలో, ముతక శుద్దీకరణ క్యాస్కేడ్లు అధిక నిర్గమాంశ మరియు తక్కువ ధరను కలిగి ఉంటాయి. మా సారూప్యతలో, ఇన్‌పుట్ క్వాలిటీ గేట్‌లు వేగవంతమైనవి, ప్రారంభించడానికి తక్కువ ప్రయత్నం అవసరం మరియు ఆపరేషన్‌లో మరింత అనుకవగలవి అని దీని అర్థం - మరియు అవి నిర్మించబడిన క్రమం. స్టాటిక్ అనాలిసిస్ పాత్ర, మనం ఇప్పుడు అర్థం చేసుకున్నట్లుగా, స్థూల లోపాలను మాత్రమే తొలగించగల సామర్థ్యం ఉంది, ఫిల్టర్ క్యాస్కేడ్ ప్రారంభంలోనే "మడ్" గ్రిడ్ పాత్ర.

"మడ్ ఫిల్టర్" నీటిని త్రాగడానికి వీలుగా చేయనట్లే, స్టాటిక్ విశ్లేషణ అంతిమ ఉత్పత్తి నాణ్యతను మెరుగుపరచదు. మరియు ఇంకా, పైప్లైన్ యొక్క ఇతర అంశాలతో కలిపి, దాని ప్రాముఖ్యత స్పష్టంగా ఉంది. బహుళ-దశల ఫిల్టర్‌లో అవుట్‌పుట్ దశలు ఇన్‌పుట్ దశలు చేసే ప్రతిదాన్ని క్యాప్చర్ చేయగల సామర్థ్యాన్ని కలిగి ఉన్నప్పటికీ, ఇన్‌పుట్ దశలు లేకుండా కేవలం ఫైన్-ప్యూరిఫికేషన్ దశలతో చేయడానికి ప్రయత్నించడం వల్ల ఎలాంటి పరిణామాలు సంభవిస్తాయో స్పష్టంగా తెలుస్తుంది.

"మడ్ ట్రాప్" యొక్క ఉద్దేశ్యం చాలా స్థూల లోపాలను పట్టుకోవడం నుండి తదుపరి క్యాస్కేడ్‌లను ఉపశమనం చేయడం. ఉదాహరణకు, కనీసం, కోడ్ సమీక్ష చేస్తున్న వ్యక్తి తప్పుగా ఫార్మాట్ చేయబడిన కోడ్ మరియు స్థాపించబడిన కోడింగ్ ప్రమాణాల ఉల్లంఘనల (అదనపు కుండలీకరణాలు లేదా చాలా లోతుగా ఉన్న శాఖలు వంటివి) ద్వారా పరధ్యానంలో ఉండకూడదు. NPEల వంటి బగ్‌లను యూనిట్ పరీక్షల ద్వారా పట్టుకోవాలి, అయితే పరీక్షకు ముందే ఎనలైజర్ బగ్ జరగబోతోందని సూచిస్తే, ఇది దాని ఫిక్సింగ్‌ను గణనీయంగా వేగవంతం చేస్తుంది.

స్టాటిక్ అనాలిసిస్ అప్పుడప్పుడు ఉపయోగించినట్లయితే ఉత్పత్తి నాణ్యతను ఎందుకు మెరుగుపరచదు మరియు స్థూల లోపాలతో మార్పులను ఫిల్టర్ చేయడానికి నిరంతరం ఉపయోగించాలి అని ఇప్పుడు స్పష్టంగా ఉందని నేను నమ్ముతున్నాను. స్టాటిక్ ఎనలైజర్‌ని ఉపయోగించడం వల్ల మీ ఉత్పత్తి నాణ్యత మెరుగుపడుతుందా లేదా అనే ప్రశ్న, "మురికి చెరువు నుండి తీసిన నీటిని కోలాండర్ ద్వారా పంపితే త్రాగే నాణ్యతలో మెరుగుపడుతుందా?" అని అడగడానికి దాదాపు సమానం.

లెగసీ ప్రాజెక్ట్‌లో అమలు

ఒక ముఖ్యమైన ఆచరణాత్మక ప్రశ్న: "నాణ్యత గేట్"గా నిరంతర ఏకీకరణ ప్రక్రియలో స్టాటిక్ విశ్లేషణను ఎలా అమలు చేయాలి? స్వయంచాలక పరీక్షల విషయంలో, ప్రతిదీ స్పష్టంగా ఉంటుంది: పరీక్షల సమితి ఉంది, వాటిలో ఏదైనా వైఫల్యం అసెంబ్లీ నాణ్యత గేట్ను ఆమోదించలేదని నమ్మడానికి తగినంత కారణం. స్టాటిక్ విశ్లేషణ ఫలితాల ఆధారంగా గేట్‌ను అదే విధంగా ఇన్‌స్టాల్ చేసే ప్రయత్నం విఫలమవుతుంది: లెగసీ కోడ్‌లో చాలా విశ్లేషణ హెచ్చరికలు ఉన్నాయి, మీరు వాటిని పూర్తిగా విస్మరించకూడదు, కానీ ఉత్పత్తిని రవాణా చేయడాన్ని ఆపడం కూడా అసాధ్యం ఇది ఎనలైజర్ హెచ్చరికలను కలిగి ఉన్నందున.

మొదటి సారి ఉపయోగించినప్పుడు, ఎనలైజర్ ఏదైనా ప్రాజెక్ట్‌పై భారీ సంఖ్యలో హెచ్చరికలను ఉత్పత్తి చేస్తుంది, వీటిలో ఎక్కువ భాగం ఉత్పత్తి యొక్క సరైన పనితీరుకు సంబంధించినవి కావు. ఈ వ్యాఖ్యలన్నింటినీ ఒకేసారి సరిచేయడం అసాధ్యం మరియు చాలా అవసరం లేదు. అన్నింటికంటే, స్టాటిక్ అనాలిసిస్‌ను పరిచయం చేయడానికి ముందే మా ఉత్పత్తి మొత్తం పని చేస్తుందని మాకు తెలుసు!

తత్ఫలితంగా, చాలా మంది స్టాటిక్ అనాలిసిస్ యొక్క అప్పుడప్పుడు వినియోగానికి పరిమితం చేయబడతారు లేదా అసెంబ్లింగ్ సమయంలో ఎనలైజర్ రిపోర్ట్ జారీ చేయబడినప్పుడు మాత్రమే ఇన్ఫర్మేషన్ మోడ్‌లో ఉపయోగిస్తారు. ఇది ఏ విశ్లేషణ లేకపోవడంతో సమానం, ఎందుకంటే మనకు ఇప్పటికే అనేక హెచ్చరికలు ఉంటే, కోడ్‌ను మార్చేటప్పుడు మరొకటి (ఎంత తీవ్రంగా ఉన్నా) సంభవించడం గుర్తించబడదు.

నాణ్యమైన గేట్లను పరిచయం చేసే క్రింది పద్ధతులు అంటారు:

• మొత్తం హెచ్చరికల సంఖ్య లేదా హెచ్చరికల సంఖ్యను కోడ్ పంక్తుల సంఖ్యతో విభజించే పరిమితిని సెట్ చేయడం. ఇది పేలవంగా పని చేస్తుంది, ఎందుకంటే అటువంటి గేట్ వారి పరిమితిని మించనంత వరకు కొత్త లోపాలతో మార్పులను స్వేచ్ఛగా గుండా అనుమతిస్తుంది.
• నిర్దిష్ట సమయంలో, కోడ్‌లోని అన్ని పాత హెచ్చరికలను విస్మరించినట్లుగా పరిష్కరించడం మరియు కొత్త హెచ్చరికలు సంభవించినప్పుడు నిర్మించడానికి నిరాకరించడం. ఈ కార్యాచరణ PVS-స్టూడియో మరియు కొన్ని ఆన్‌లైన్ వనరుల ద్వారా అందించబడింది, ఉదాహరణకు, కోడసీ. నాకు PVS-స్టూడియోలో పని చేసే అవకాశం లేదు, కోడసీతో నా అనుభవం దృష్ట్యా, వారి ప్రధాన సమస్య ఏమిటంటే "పాతది" మరియు "కొత్త" లోపం ఏమిటో నిర్ణయించడం అనేది ఎల్లప్పుడూ పని చేయని సంక్లిష్టమైన అల్గోరిథం. సరిగ్గా, ముఖ్యంగా ఫైల్‌లు భారీగా సవరించబడినా లేదా పేరు మార్చబడినా. నా అనుభవంలో, కోడసీ పుల్ రిక్వెస్ట్‌లో కొత్త హెచ్చరికలను విస్మరించగలదు, అదే సమయంలో ఇచ్చిన 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 స్క్రిప్ట్‌లో అవసరమైన లాజిక్‌ను రాయడమే మిగిలి ఉంది. జెంకిన్స్ మరియు ఆర్టిఫ్యాక్టరీ ఆధారంగా మా ఓపెన్ సోర్స్ ప్రాజెక్ట్‌లలో ఇది ఎలా అమలు చేయబడుతుందో మీరు చూడవచ్చు ఇక్కడ లేదా ఇక్కడ. రెండు ఉదాహరణలు లైబ్రరీపై ఆధారపడి ఉంటాయి రాట్చెట్లిబ్: పద్ధతి countWarnings() చెక్‌స్టైల్ మరియు స్పాట్‌బగ్‌ల ద్వారా సాధారణ పద్ధతిలో రూపొందించబడిన ఫైల్‌లలో xml ట్యాగ్‌లను గణిస్తుంది మరియు compareWarningMaps() అదే రాట్‌చెట్‌ను అమలు చేస్తుంది, ఏదైనా వర్గాలలో హెచ్చరికల సంఖ్య పెరిగినప్పుడు లోపం ఏర్పడుతుంది.

"రాట్‌చెట్" యొక్క ఆసక్తికరమైన అమలు కామెంట్‌ల స్పెల్లింగ్, టెక్స్ట్ లిటరల్స్ మరియు డాక్యుమెంటేషన్‌ను ఆస్పెల్ ఉపయోగించి విశ్లేషించడం సాధ్యమవుతుంది. మీకు తెలిసినట్లుగా, స్పెల్లింగ్‌ని తనిఖీ చేస్తున్నప్పుడు, ప్రామాణిక నిఘంటువుకు తెలియని అన్ని పదాలు తప్పు కాదు; వాటిని వినియోగదారు నిఘంటువుకి జోడించవచ్చు. మీరు ప్రాజెక్ట్ యొక్క సోర్స్ కోడ్‌లో కస్టమ్ డిక్షనరీని భాగం చేస్తే, స్పెల్లింగ్ నాణ్యత గేట్‌ని ఈ విధంగా రూపొందించవచ్చు: ప్రామాణిక మరియు అనుకూల నిఘంటువుతో aspellని అమలు చేయడం చేయకూడదు స్పెల్లింగ్ దోషాలను కనుగొనలేదు.

ఎనలైజర్ వెర్షన్ ఫిక్సింగ్ యొక్క ప్రాముఖ్యత గురించి

ముగింపులో, మీరు మీ డెలివరీ పైప్‌లైన్‌లో విశ్లేషణను ఎలా అమలు చేసినా, ఎనలైజర్ వెర్షన్ తప్పనిసరిగా స్థిరపరచబడాలి. మీరు ఎనలైజర్‌ని ఆకస్మికంగా అప్‌డేట్ చేయడానికి అనుమతించినట్లయితే, తదుపరి పుల్ అభ్యర్థనను సమీకరించేటప్పుడు, కొత్త లోపాలు "పాప్ అప్" కావచ్చు, అవి కోడ్ మార్పులకు సంబంధించినవి కావు, కానీ కొత్త ఎనలైజర్ కేవలం మరిన్ని లోపాలను కనుగొనగలదనే దానికి సంబంధించినవి - మరియు ఇది పుల్ అభ్యర్థనలను ఆమోదించే మీ ప్రక్రియను విచ్ఛిన్నం చేస్తుంది . ఎనలైజర్‌ను అప్‌గ్రేడ్ చేయడం అనేది ఒక చేతన చర్యగా ఉండాలి. ఏదేమైనా, ప్రతి అసెంబ్లీ భాగం యొక్క సంస్కరణ యొక్క దృఢమైన స్థిరీకరణ సాధారణంగా అవసరమైన అవసరం మరియు ప్రత్యేక చర్చ కోసం ఒక అంశం.

కనుగొన్న

• స్టాటిక్ విశ్లేషణ మీ కోసం బగ్‌లను కనుగొనదు మరియు ఒకే అప్లికేషన్ ఫలితంగా మీ ఉత్పత్తి నాణ్యతను మెరుగుపరచదు. డెలివరీ ప్రక్రియలో దాని స్థిరమైన ఉపయోగం ద్వారా నాణ్యతపై సానుకూల ప్రభావం మాత్రమే సాధించబడుతుంది.
• బగ్‌లను కనుగొనడం అనేది విశ్లేషణ యొక్క ప్రధాన పని కాదు; చాలా ఉపయోగకరమైన ఫంక్షన్‌లు ఓపెన్‌సోర్స్ సాధనాల్లో అందుబాటులో ఉన్నాయి.
• లెగసీ కోడ్ కోసం “రాట్‌చెట్” ఉపయోగించి డెలివరీ పైప్‌లైన్ యొక్క మొదటి దశలో స్టాటిక్ విశ్లేషణ ఫలితాల ఆధారంగా నాణ్యమైన గేట్‌లను అమలు చేయండి.

సూచనలు

1. నిరంతర డెలివరీ
2. A. కుద్రియావ్ట్సేవ్: ప్రోగ్రామ్ విశ్లేషణ: మీరు మంచి ప్రోగ్రామర్ అని ఎలా అర్థం చేసుకోవాలి కోడ్ విశ్లేషణ యొక్క వివిధ పద్ధతులపై నివేదిక (స్టాటిక్ మాత్రమే కాదు!)

మూలం: www.habr.com