Dead Code Finder: Static Analysis-ன் கடினமான உண்மை

நான் ஒரு ஹேக்கத்தானிற்காக (hackathon) dead code-ஐக் கண்டறிய ஒரு கருவியை உருவாக்கினேன். அதன் நோக்கம் எளிமையானது: எந்தவொரு அழைப்பும் (call) இல்லாத குறியீட்டைக் (code) கண்டறிவது.

குறியீட்டை நீக்கினால் என்ன உடைந்துவிடும் என்பதை நான் அறிய விரும்பவில்லை. ஒரு குறிப்பிட்ட குறியீட்டை ஏதேனும் அழைக்கிறதா இல்லையா என்பதை மட்டுமே நான் அறிய விரும்பினேன்.

நான் இதற்கு Dead Code Finder என்று பெயரிட்டேன். இது calls மற்றும் imports-களைத் தேட ஒரு knowledge graph-ஐப் பயன்படுத்துகிறது. இது ஒவ்வொரு கண்டுபிடிப்பையும் மூன்று வகைகளாகப் பிரிக்கிறது:

• Confident: பூஜ்ஜிய உள்ளீட்டு விளிம்புகள் (zero incoming edges) மற்றும் அது ஒரு entry point இல்லை. • Uncertain: inheritance போன்ற static analysis போதுமானதாக இல்லாத நிகழ்வுகள். • Skipped: decorators அல்லது test frameworks போன்ற கருவியால் தீர்க்க முடியாத விஷயங்கள்.

நான் ஒரு கடுமையான விதியைப் பின்பற்றினேன். குறியீட்டை நீக்குவது பாதுகாப்பானது என்று ஒருபோதும் சொல்லக்கூடாது. வரைபடத்தில் (graph) எந்தக் குறிப்பும் (reference) காணப்படவில்லை என்று மட்டுமே அறிக்கை கூறும்.

இந்தத் திட்டம் நான் எதிர்பார்த்ததை விட கடினமாக இருந்தது. தளத்தில் (platform) நான் இரண்டு முக்கிய சிக்கல்களைச் சந்தித்தேன்:

  1. விடுபட்ட கருவிகள் (Missing Tools): config-இல் இருந்தபோதிலும், runtime நேரத்தில் graph கருவிகள் காணப்படவில்லை.
  2. நம்பகத்தன்மையற்ற Injection: ஏஜென்ட்டிற்கு (agent) முழுமையான தர்க்கத்தை (logic) வழங்க சில நேரங்களில் அமைப்புத் தவறிவிட்டது.

ஒரு fallback mode-ஐ உருவாக்குவதன் மூலம் இதைச் சரிசெய்தேன். graph கருவிகள் இல்லையென்றால், கருவி களஞ்சியத்தில் (repository) உள்ள உண்மையான கோப்புகளைப் படிக்கும். குறிப்புகளைக் கண்டறிய இது file searches-ஐப் பயன்படுத்துகிறது. இந்த முறையைப் பயன்படுத்தினால், அது கண்டுபிடிப்புகளை 'inferred' என்று குறிக்கும்.

குறிப்பிட்ட நிகழ்வுகளுக்கான தர்க்கப் பிழைகளையும் (logic errors) நான் சரிசெய்ய வேண்டியிருந்தது:

  • Dunder methods: __init__ போன்ற முறைகள் பெரும்பாலும் பூஜ்ஜிய உள்ளீட்டு விளிம்புகளைக் காட்டுகின்றன, ஏனெனில் graph அந்த அழைப்பை முறையோடு (method) இணைப்பதற்குப் பதிலாக வகுப்போடு (class) இணைக்கிறது. இதைச் சுற்றியுள்ள வகுப்பைச் (enclosing class) சரிபார்ப்பதன் மூலம் நான் சரிசெய்தேன்.
  • Decorators: ஒரு அகராதியில் (dictionary) string lookups மூலம் அழைக்கப்படும் செயல்பாடுகள் (functions), ஒரு static graph-க்கு dead code போலத் தோன்றும். இவற்றை நான் Skipped bucket-க்கு மாற்றினேன்.
  • Tests: Test frameworks reflection மூலம் முறைகளைக் கண்டறிகின்றன. இவையும் Skipped bucket-க்குச் செல்கின்றன.

முடிவுகள் நம்பகமானதாக இருந்தன. எனது fallback mode dead code-ஐச் சரியாகக் கண்டறிந்தது மற்றும் உண்மையான graph தரவுகளுடன் ஒத்துப்போனது. இது inheritance போன்ற நிச்சயமற்ற நிகழ்வுகளையும் சரியாகக் குறிப்பிட்டது.

கற்றுக்கொண்ட பாடங்கள்:

  • அவற்றைச் சார்ந்திருக்கும் தர்க்கத்தை எழுதுவதற்கு முன், கிடைக்கக்கூடிய கருவிகளை உறுதிப்படுத்திக் கொள்ளுங்கள்.
  • "எனக்குத் தெரியாது" என்று சொல்லும் அறிக்கை, நம்பிக்கையுடன் தவறான தகவலைத் தரும் அறிக்கையை விடச் சிறந்தது.
  • நிச்சயமற்ற தன்மையைக் குறிப்பிடுவது, உங்கள் உறுதியான கண்டுபிடிப்புகளைச் செயல்படுத்துவதற்குத் தகுதியுடையதாக மாற்றுகிறது.

மூலம்: https://dev.to/hereforlolz/dead-code-finder-gitlab-orbit-based-static-analysis-that-turned-out-to-be-harder-than-expected-4jgk

விருப்பமான கற்றல் சமூகம்: https://t.me/GyaanSetuAi