பிழைகளைக் கண்டறிய அதைப் பயன்படுத்துவதை விட, செயல்பாட்டில் நிலையான பகுப்பாய்வைச் செயல்படுத்தவும்

எனது கவனத்திற்கு பெருகிய முறையில் வரும் நிலையான பகுப்பாய்வைப் பற்றிய பெரிய அளவிலான பொருட்களால் இந்த கட்டுரையை எழுத நான் தூண்டப்பட்டேன். முதலில், இது 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-ஸ்டுடியோ மற்றும் சில ஆன்லைன் ஆதாரங்களால் வழங்கப்படுகிறது, எடுத்துக்காட்டாக, Codacy. பிவிஎஸ்-ஸ்டுடியோவில் பணிபுரிய எனக்கு வாய்ப்பு கிடைக்கவில்லை, கோடாசி உடனான எனது அனுபவத்தைப் பொறுத்தவரை, அவர்களின் முக்கிய பிரச்சனை என்னவென்றால், "பழைய" மற்றும் "புதிய" பிழை எது என்பதை தீர்மானிப்பது எப்போதும் வேலை செய்யாத ஒரு சிக்கலான வழிமுறையாகும். சரியாக, குறிப்பாக கோப்புகள் பெரிதும் மாற்றப்பட்டால் அல்லது மறுபெயரிடப்பட்டால். எனது அனுபவத்தில், கோடாசி ஒரு இழுப்பு கோரிக்கையில் புதிய எச்சரிக்கைகளை புறக்கணிக்க முடியும், அதே நேரத்தில் கொடுக்கப்பட்ட 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() வழக்கமான முறையில் Checkstyle மற்றும் Spotbugs மூலம் உருவாக்கப்பட்ட கோப்புகளில் xml குறிச்சொற்களை எண்ணுகிறது, மற்றும் compareWarningMaps() அதே ராட்செட்டை செயல்படுத்துகிறது, எந்த வகையிலும் எச்சரிக்கைகளின் எண்ணிக்கை அதிகரிக்கும் போது பிழையை எறிகிறது.

"ராட்செட்" இன் சுவாரஸ்யமான செயலாக்கம், கருத்துகளின் எழுத்துப்பிழை, உரை எழுத்துக்கள் மற்றும் ஆஸ்பெல்லைப் பயன்படுத்தி ஆவணங்களை பகுப்பாய்வு செய்ய முடியும். உங்களுக்குத் தெரியும், எழுத்துப்பிழையைச் சரிபார்க்கும்போது, ​​நிலையான அகராதிக்குத் தெரியாத எல்லா சொற்களும் தவறானவை அல்ல; அவை பயனர் அகராதியில் சேர்க்கப்படலாம். திட்டத்தின் மூலக் குறியீட்டின் ஒரு தனிப்பயன் அகராதியின் ஒரு பகுதியாக நீங்கள் உருவாக்கினால், எழுத்துப்பிழை தர வாயிலை இவ்வாறு உருவாக்கலாம்: நிலையான மற்றும் தனிப்பயன் அகராதியுடன் அஸ்பெல் இயங்கும் கூடாது எழுத்து பிழைகள் இல்லை.

பகுப்பாய்வி பதிப்பை சரிசெய்வதன் முக்கியத்துவம் பற்றி

முடிவில், கவனிக்க வேண்டிய விஷயம் என்னவென்றால், உங்கள் டெலிவரி பைப்லைனில் பகுப்பாய்வை எவ்வாறு செயல்படுத்தினாலும், பகுப்பாய்வியின் பதிப்பு சரி செய்யப்பட வேண்டும். பகுப்பாய்வியை தன்னிச்சையாகப் புதுப்பிக்க அனுமதித்தால், அடுத்த இழுப்புக் கோரிக்கையைச் சேகரிக்கும் போது, ​​புதிய குறைபாடுகள் "பாப் அப்" ஆகலாம், அவை குறியீடு மாற்றங்களுடன் தொடர்புடையவை அல்ல, ஆனால் புதிய பகுப்பாய்வி அதிக குறைபாடுகளைக் கண்டறிய முடியும் என்பதோடு தொடர்புடையது - மேலும் இது இழுக்கும் கோரிக்கைகளை ஏற்கும் உங்கள் செயல்முறையை முறித்துவிடும் . பகுப்பாய்வியை மேம்படுத்துவது நனவான செயலாக இருக்க வேண்டும். இருப்பினும், ஒவ்வொரு சட்டசபை கூறுகளின் பதிப்பின் கடுமையான நிர்ணயம் பொதுவாக அவசியமான தேவை மற்றும் ஒரு தனி விவாதத்திற்கான தலைப்பு.

கண்டுபிடிப்புகள்

• நிலையான பகுப்பாய்வு உங்களுக்கான பிழைகளைக் கண்டறியாது மற்றும் ஒரு பயன்பாட்டின் விளைவாக உங்கள் தயாரிப்பின் தரத்தை மேம்படுத்தாது. விநியோகச் செயல்பாட்டின் போது அதன் நிலையான பயன்பாட்டின் மூலம் மட்டுமே தரத்தில் நேர்மறையான விளைவை அடைய முடியும்.
• பிழைகளைக் கண்டறிவது பகுப்பாய்வின் முக்கிய பணி அல்ல; பெரும்பாலான பயனுள்ள செயல்பாடுகள் திறந்த மூலக் கருவிகளில் கிடைக்கின்றன.
• டெலிவரி பைப்லைனின் முதல் கட்டத்தில் நிலையான பகுப்பாய்வின் முடிவுகளின் அடிப்படையில் தர வாயில்களை நடைமுறைப்படுத்தவும், மரபுக் குறியீட்டிற்கான "ராட்செட்" ஐப் பயன்படுத்தவும்.

குறிப்புகள்

1. தொடர்ச்சியான டெலிவரி
2. A. Kudryavtsev: நிரல் பகுப்பாய்வு: நீங்கள் ஒரு நல்ல புரோகிராமர் என்பதை எவ்வாறு புரிந்துகொள்வது குறியீடு பகுப்பாய்வின் வெவ்வேறு முறைகள் பற்றிய அறிக்கை (நிலையானது மட்டுமல்ல!)

ஆதாரம்: www.habr.com