ടീമിനെ തരംതാഴ്ത്താതെ ഒരു ലെഗസി പ്രോജക്റ്റിൽ ഒരു സ്റ്റാറ്റിക് കോഡ് അനലൈസർ എങ്ങനെ നടപ്പിലാക്കാം

ഒരു സ്റ്റാറ്റിക് കോഡ് അനലൈസർ പരീക്ഷിക്കുന്നത് എളുപ്പമാണ്. എന്നാൽ അത് നടപ്പിലാക്കാൻ, പ്രത്യേകിച്ച് ഒരു വലിയ പഴയ പദ്ധതിയുടെ വികസനത്തിൽ, വൈദഗ്ധ്യം ആവശ്യമാണ്. തെറ്റായി ചെയ്താൽ, അനലൈസറിന് ജോലി ചേർക്കാനും വികസനം മന്ദഗതിയിലാക്കാനും ടീമിനെ തരംതാഴ്ത്താനും കഴിയും. വികസന പ്രക്രിയയിൽ സ്റ്റാറ്റിക് വിശകലനത്തിൻ്റെ സംയോജനത്തെ എങ്ങനെ ശരിയായി സമീപിക്കാമെന്നും അത് CI/CD യുടെ ഭാഗമായി ഉപയോഗിക്കാൻ തുടങ്ങുന്നതിനെക്കുറിച്ചും നമുക്ക് ചുരുക്കമായി സംസാരിക്കാം.

ആമുഖം

അടുത്തിടെ പ്രസിദ്ധീകരണത്തിലേക്ക് എൻ്റെ ശ്രദ്ധ ആകർഷിച്ചു.ടീമിനെ തളർത്താതെ സ്റ്റാറ്റിക് അനാലിസിസ് ഉപയോഗിച്ച് ആരംഭിക്കുക". ഒരു വശത്ത്, ഇത് പരിചയപ്പെടേണ്ട ഒരു നല്ല ലേഖനമാണ്, മറുവശത്ത്, ഒരു പ്രോജക്റ്റിൽ സ്റ്റാറ്റിക് വിശകലനം എങ്ങനെ വേദനയില്ലാതെ നടപ്പിലാക്കാം എന്നതിന് ഇപ്പോഴും പൂർണ്ണമായ ഉത്തരം നൽകുന്നില്ലെന്ന് എനിക്ക് തോന്നുന്നു. നിങ്ങൾക്ക് സാങ്കേതിക കടം സ്വീകരിക്കാനും പുതിയ കോഡിൽ മാത്രം പ്രവർത്തിക്കാനും കഴിയുമെന്ന് ലേഖനം പറയുന്നു, എന്നാൽ ഈ സാങ്കേതിക കടം പിന്നീട് എന്തുചെയ്യണം എന്നതിന് ഉത്തരമില്ല.

ഞങ്ങളുടെ പിവിഎസ്-സ്റ്റുഡിയോ ടീം ഈ വിഷയത്തെക്കുറിച്ചുള്ള കാഴ്ചപ്പാട് വാഗ്ദാനം ചെയ്യുന്നു. ഒരു സ്റ്റാറ്റിക് കോഡ് അനലൈസർ നടപ്പിലാക്കുന്നതിനുള്ള പ്രശ്നം എങ്ങനെയാണ് ആദ്യം ഉണ്ടാകുന്നത്, ഈ പ്രശ്നം എങ്ങനെ മറികടക്കാം, സാങ്കേതിക കടം എങ്ങനെ വേദനയില്ലാതെ ക്രമേണ ഇല്ലാതാക്കാം എന്ന് നോക്കാം.

പ്രശ്നങ്ങൾ

ഒരു സ്റ്റാറ്റിക് അനലൈസർ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാനും സമാരംഭിക്കാനും സാധാരണയായി ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല.1]. നിങ്ങൾ കോഡിൽ രസകരമായ പിശകുകളോ ഭയപ്പെടുത്തുന്ന അപകടസാധ്യതകളോ കണ്ടേക്കാം. നിങ്ങൾക്ക് എന്തെങ്കിലും ശരിയാക്കാൻ പോലും കഴിയും, എന്നാൽ പല പ്രോഗ്രാമർമാരും ഉപേക്ഷിക്കുന്നു.

എല്ലാ സ്റ്റാറ്റിക് അനലൈസറുകളും തെറ്റായ പോസിറ്റീവ് ഉണ്ടാക്കുന്നു. ഇത് സ്റ്റാറ്റിക് കോഡ് വിശകലന രീതിയുടെ ഒരു സവിശേഷതയാണ്, അതിനെക്കുറിച്ച് ഒന്നും ചെയ്യാൻ കഴിയില്ല. പൊതുവേ, ഇത് പരിഹരിക്കാനാവാത്ത ഒരു പ്രശ്നമാണ്, റൈസിൻ്റെ സിദ്ധാന്തം സ്ഥിരീകരിച്ചു.2]. മെഷീൻ ലേണിംഗ് അൽഗോരിതങ്ങളും സഹായിക്കില്ല [3]. ഈ അല്ലെങ്കിൽ ആ കോഡ് തെറ്റാണോ എന്ന് ഒരു വ്യക്തിക്ക് എല്ലായ്പ്പോഴും പറയാൻ കഴിയില്ലെങ്കിലും, പ്രോഗ്രാമിൽ നിന്ന് നിങ്ങൾ ഇത് പ്രതീക്ഷിക്കരുത് :).

സ്റ്റാറ്റിക് അനലൈസർ ഇതിനകം കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ തെറ്റായ പോസിറ്റീവുകൾ ഒരു പ്രശ്നമല്ല:

• അപ്രസക്തമായ റൂൾ സെറ്റുകൾ പ്രവർത്തനരഹിതമാക്കി;
• ചില അപ്രസക്തമായ ഡയഗ്നോസ്റ്റിക്സ് പ്രവർത്തനരഹിതമാക്കി;
• നമ്മൾ C അല്ലെങ്കിൽ C++ നെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, അത്തരം മാക്രോകൾ ഉപയോഗിക്കുന്ന എല്ലാ സ്ഥലങ്ങളിലും ഉപയോഗശൂന്യമായ മുന്നറിയിപ്പുകൾ പ്രത്യക്ഷപ്പെടുന്നതിന് കാരണമാകുന്ന നിർദ്ദിഷ്ട നിർമ്മിതികൾ ഉൾക്കൊള്ളുന്ന മാക്രോകൾ അടയാളപ്പെടുത്തിയിരിക്കുന്നു;
• സിസ്റ്റം ഫംഗ്ഷനുകൾക്ക് സമാനമായ പ്രവർത്തനങ്ങൾ ചെയ്യുന്ന സ്വന്തം ഫംഗ്ഷനുകൾ അടയാളപ്പെടുത്തിയിരിക്കുന്നു (അതിൻ്റെ സ്വന്തം അനലോഗ് എംഎംപിപി അഥവാ printf) [4];
• കമൻ്റുകൾ ഉപയോഗിച്ച് തെറ്റായ പോസിറ്റീവുകൾ പ്രത്യേകമായി പ്രവർത്തനരഹിതമാക്കിയിരിക്കുന്നു;
• അങ്ങനെയാണ്.

ഈ സാഹചര്യത്തിൽ, നമുക്ക് ഏകദേശം 10-15% തെറ്റായ പോസിറ്റീവ് നിരക്ക് പ്രതീക്ഷിക്കാം.5]. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, 9-ൽ 10 അനലൈസർ മുന്നറിയിപ്പുകൾ കോഡിലെ ഒരു യഥാർത്ഥ പ്രശ്‌നത്തെ സൂചിപ്പിക്കും, അല്ലെങ്കിൽ കുറഞ്ഞത് “ശക്തമായ മണമുള്ള കോഡ്”. സമ്മതിക്കുക, ഈ സാഹചര്യം വളരെ മനോഹരമാണ്, കൂടാതെ അനലൈസർ പ്രോഗ്രാമറുടെ യഥാർത്ഥ സുഹൃത്താണ്.

വാസ്തവത്തിൽ, ഒരു വലിയ പദ്ധതിയിൽ, പ്രാരംഭ ചിത്രം തികച്ചും വ്യത്യസ്തമായിരിക്കും. ലെഗസി കോഡിനായി അനലൈസർ നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് മുന്നറിയിപ്പുകൾ നൽകുന്നു. ഈ മുന്നറിയിപ്പുകളിൽ ഏതാണ് പ്രസക്തവും അല്ലാത്തതും എന്ന് പെട്ടെന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല. ഈ കേസിലെ പ്രധാന ജോലി ദിവസങ്ങളോ ആഴ്ചകളോ നിർത്തുമെന്നതിനാൽ, ഈ മുന്നറിയിപ്പുകളെല്ലാം കൈകാര്യം ചെയ്യാൻ ആരംഭിക്കുന്നത് യുക്തിരഹിതമാണ്. സാധാരണഗതിയിൽ, ഒരു ടീമിന് അത്തരമൊരു സാഹചര്യം താങ്ങാൻ കഴിയില്ല. മാറ്റത്തിൻ്റെ ചരിത്രത്തെ നശിപ്പിക്കുന്ന നിരവധി വ്യത്യാസങ്ങളും ഉണ്ടാകും. കോഡിലെ നിരവധി ശകലങ്ങളുടെ ദ്രുതഗതിയിലുള്ള എഡിറ്റിംഗ് അനിവാര്യമായും പുതിയ അക്ഷരത്തെറ്റുകൾക്കും പിശകുകൾക്കും കാരണമാകും.

ഏറ്റവും പ്രധാനമായി, മുന്നറിയിപ്പുകൾക്കെതിരായ പോരാട്ടത്തിലെ അത്തരമൊരു നേട്ടത്തിന് അർത്ഥമില്ല. നിരവധി വർഷങ്ങളായി പദ്ധതി വിജയകരമായി പ്രവർത്തിക്കുന്നതിനാൽ, അതിലെ നിർണായകമായ മിക്ക പിശകുകളും ഇതിനകം തന്നെ തിരുത്തിയിട്ടുണ്ട്. അതെ, ഈ പരിഹാരങ്ങൾ വളരെ ചെലവേറിയതായിരുന്നു, ഡീബഗ്ഗ് ചെയ്യേണ്ടി വന്നു, ബഗുകളെ കുറിച്ച് ഉപയോക്തൃ ഫീഡ്ബാക്ക് നെഗറ്റീവ് ആയി ലഭിച്ചു. കോഡിംഗ് ഘട്ടത്തിൽ ഈ പിശകുകളിൽ പലതും വേഗത്തിലും വിലകുറഞ്ഞും പരിഹരിക്കാൻ ഒരു സ്റ്റാറ്റിക് അനലൈസർ സഹായിക്കും. എന്നാൽ ഇപ്പോൾ, ഒരു വഴി അല്ലെങ്കിൽ മറ്റൊന്ന്, ഈ പിശകുകൾ പരിഹരിച്ചു, കൂടാതെ വിശകലനം പ്രധാനമായും പഴയ കോഡിലെ നിർണ്ണായകമല്ലാത്ത പിശകുകൾ കണ്ടെത്തുന്നു. ഈ കോഡ് ഉപയോഗിച്ചേക്കില്ല, ഇത് വളരെ അപൂർവമായി മാത്രമേ ഉപയോഗിക്കൂ, അതിലെ ഒരു പിശക് ശ്രദ്ധേയമായ പ്രത്യാഘാതങ്ങളിലേക്ക് നയിച്ചേക്കില്ല. ഒരുപക്ഷേ എവിടെയെങ്കിലും ബട്ടണിൽ നിന്നുള്ള നിഴൽ തെറ്റായ നിറമായിരിക്കാം, പക്ഷേ ഇത് ഉൽപ്പന്നത്തിൻ്റെ ആരുടെയും ഉപയോഗത്തെ തടസ്സപ്പെടുത്തുന്നില്ല.

തീർച്ചയായും, ചെറിയ തെറ്റുകൾ പോലും ഇപ്പോഴും തെറ്റുകൾ തന്നെയാണ്. ചിലപ്പോൾ ഒരു തെറ്റ് ഒരു യഥാർത്ഥ പരാധീനത മറയ്ക്കാം. എന്നിരുന്നാലും, എല്ലാം ഉപേക്ഷിച്ച്, സ്വയം പ്രകടമാകാത്ത വൈകല്യങ്ങൾ കൈകാര്യം ചെയ്യാൻ ദിവസങ്ങൾ/ആഴ്ചകൾ ചെലവഴിക്കുന്നത് ഒരു സംശയാസ്പദമായ ആശയമായി തോന്നുന്നു.

പ്രോഗ്രാമർമാർ നോക്കൂ, നോക്കൂ, പഴയ വർക്കിംഗ് കോഡിനെക്കുറിച്ചുള്ള ഈ മുന്നറിയിപ്പുകളെല്ലാം നോക്കൂ... അവർ ചിന്തിക്കുന്നു: സ്റ്റാറ്റിക് വിശകലനം കൂടാതെ നമുക്ക് ചെയ്യാൻ കഴിയും. നമുക്ക് കുറച്ച് പുതിയ ഉപയോഗപ്രദമായ പ്രവർത്തനങ്ങൾ എഴുതാം.

അവരുടേതായ രീതിയിൽ, അവർ ശരിയാണ്. ആദ്യം എങ്ങനെയെങ്കിലും ഈ മുന്നറിയിപ്പുകളിൽ നിന്ന് രക്ഷപ്പെടണമെന്ന് അവർ കരുതുന്നു. എങ്കിൽ മാത്രമേ കോഡ് അനലൈസറിൻ്റെ സ്ഥിരമായ ഉപയോഗത്തിൽ നിന്ന് അവർക്ക് പ്രയോജനം ലഭിക്കൂ. അല്ലെങ്കിൽ, പുതിയ മുന്നറിയിപ്പുകൾ പഴയവയിൽ മുങ്ങിപ്പോകും, ​​ആരും അവ ശ്രദ്ധിക്കില്ല.

കംപൈലർ മുന്നറിയിപ്പുകളുടെ സമാന സമാനതയാണിത്. കംപൈലർ മുന്നറിയിപ്പുകളുടെ എണ്ണം 0 ആയി നിലനിർത്താൻ അവർ ശുപാർശ ചെയ്യുന്നത് കാരണമില്ലാതെയല്ല. 1000 മുന്നറിയിപ്പുകൾ ഉണ്ടെങ്കിൽ, 1001 ഉള്ളപ്പോൾ ആരും അത് ശ്രദ്ധിക്കില്ല, ഈ ഏറ്റവും പുതിയ മുന്നറിയിപ്പ് എവിടെയാണ് നോക്കേണ്ടതെന്ന് വ്യക്തമല്ല.

സ്റ്റാറ്റിക് കോഡ് വിശകലനം ഉപയോഗിക്കാൻ ഈ നിമിഷം മുകളിൽ നിന്ന് ആരെങ്കിലും നിങ്ങളെ നിർബന്ധിച്ചാൽ ഈ കഥയിലെ ഏറ്റവും മോശം കാര്യം. ഇത് ടീമിനെ തരംതാഴ്ത്താൻ മാത്രമേ സഹായിക്കൂ, കാരണം അവരുടെ കാഴ്ചപ്പാടിൽ അധിക ബ്യൂറോക്രാറ്റിക് സങ്കീർണ്ണത ഉണ്ടാകും. ആരും അനലൈസറിൻ്റെ റിപ്പോർട്ടുകൾ നോക്കില്ല, എല്ലാ ഉപയോഗവും "പേപ്പറിൽ" മാത്രമായിരിക്കും. ആ. ഔപചാരികമായി, വിശകലനം DevOps പ്രോസസിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, എന്നാൽ പ്രായോഗികമായി ഇത് ആർക്കും പ്രയോജനം ചെയ്യുന്നില്ല. കോൺഫറൻസിൽ പങ്കെടുത്തവരിൽ നിന്ന് ഞങ്ങൾ ബൂത്തുകളിൽ വിശദമായ കഥകൾ കേട്ടു. അത്തരമൊരു അനുഭവം പ്രോഗ്രാമർമാരെ സ്ഥിരമായ വിശകലന ടൂളുകൾ ദീർഘകാലത്തേക്ക് ഉപയോഗിക്കുന്നതിൽ നിന്ന് നിരുത്സാഹപ്പെടുത്തും.

സാങ്കേതിക കടം നടപ്പിലാക്കുകയും ഇല്ലാതാക്കുകയും ചെയ്യുക

വാസ്തവത്തിൽ, ഒരു വലിയ പഴയ പ്രോജക്റ്റിലേക്ക് പോലും സ്റ്റാറ്റിക് വിശകലനം അവതരിപ്പിക്കുന്നതിൽ ബുദ്ധിമുട്ടുള്ളതോ ഭയപ്പെടുത്തുന്നതോ ആയ ഒന്നുമില്ല.

സിഐ / സിഡി

മാത്രമല്ല, അനലൈസർ ഉടനടി തുടർച്ചയായ വികസന പ്രക്രിയയുടെ ഭാഗമാക്കാം. ഉദാഹരണത്തിന്, PVS-Studio വിതരണത്തിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ള ഫോർമാറ്റിൽ റിപ്പോർട്ട് സൗകര്യപ്രദമായി കാണുന്നതിനുള്ള യൂട്ടിലിറ്റികളും കോഡിൻ്റെ പ്രശ്നകരമായ വിഭാഗങ്ങൾ എഴുതിയ ഡവലപ്പർമാർക്കുള്ള അറിയിപ്പുകളും അടങ്ങിയിരിക്കുന്നു. CI/CD സിസ്റ്റങ്ങളിൽ നിന്ന് PVS-Studio സമാരംഭിക്കുന്നതിൽ കൂടുതൽ താൽപ്പര്യമുള്ളവർക്ക്, അനുബന്ധമായി നിങ്ങൾ സ്വയം പരിചയപ്പെടാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു വിഭാഗം ഡോക്യുമെൻ്റേഷനും ലേഖനങ്ങളുടെ ഒരു പരമ്പരയും:

• PVS-സ്റ്റുഡിയോ മേഘങ്ങളിലേക്ക് പോകുന്നു: അസൂർ ഡെവോപ്‌സ്
• പിവിഎസ്-സ്റ്റുഡിയോ മേഘങ്ങളിലേക്ക് പോകുന്നു: ട്രാവിസ് സിഐ
• PVS-Studio മേഘങ്ങളിലേക്ക് പോകുന്നു: GitLab CI/CD
• PVS-സ്റ്റുഡിയോ മേഘങ്ങളിലേക്ക് പോകുന്നു: CircleCI

എന്നാൽ കോഡ് വിശകലന ഉപകരണങ്ങൾ നടപ്പിലാക്കുന്നതിൻ്റെ ആദ്യ ഘട്ടങ്ങളിൽ ധാരാളം തെറ്റായ പോസിറ്റീവുകളുടെ പ്രശ്നത്തിലേക്ക് മടങ്ങാം.

നിലവിലുള്ള സാങ്കേതിക കടം പരിഹരിക്കുകയും പുതിയ മുന്നറിയിപ്പുകൾ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു

പുതിയതോ മാറ്റിയതോ ആയ കോഡിൽ ദൃശ്യമാകുന്ന പുതിയ മുന്നറിയിപ്പുകൾ മാത്രം പഠിക്കാൻ ആധുനിക വാണിജ്യ സ്റ്റാറ്റിക് അനലൈസറുകൾ നിങ്ങളെ അനുവദിക്കുന്നു. ഈ സംവിധാനം നടപ്പിലാക്കുന്നത് വ്യത്യസ്തമാണ്, എന്നാൽ സാരാംശം ഒന്നുതന്നെയാണ്. പിവിഎസ്-സ്റ്റുഡിയോ സ്റ്റാറ്റിക് അനലൈസറിൽ, ഈ പ്രവർത്തനം ഇനിപ്പറയുന്ന രീതിയിൽ നടപ്പിലാക്കുന്നു.

സ്റ്റാറ്റിക് വിശകലനം ഉപയോഗിച്ച് വേഗത്തിൽ ആരംഭിക്കുന്നതിന്, മുന്നറിയിപ്പുകൾ കൂട്ടത്തോടെ അടിച്ചമർത്തുന്നതിനുള്ള സംവിധാനം ഉപയോഗിക്കണമെന്ന് ഞങ്ങൾ നിർദ്ദേശിക്കുന്നു.6]. പൊതുവായ ആശയം ഇനിപ്പറയുന്നതാണ്. ഉപയോക്താവിന് അനലൈസർ സമാരംഭിക്കുകയും നിരവധി മുന്നറിയിപ്പുകൾ ലഭിക്കുകയും ചെയ്തു. വർഷങ്ങളായി വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്രോജക്റ്റ് സജീവവും വികസിപ്പിക്കുന്നതും പണം സമ്പാദിക്കുന്നതുമായതിനാൽ, റിപ്പോർട്ടിൽ ഗുരുതരമായ വൈകല്യങ്ങൾ സൂചിപ്പിക്കുന്ന നിരവധി മുന്നറിയിപ്പുകൾ ഉണ്ടാകില്ല. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, കൂടുതൽ ചെലവേറിയ രീതികൾ ഉപയോഗിച്ച് അല്ലെങ്കിൽ ഉപഭോക്താക്കളിൽ നിന്നുള്ള ഫീഡ്‌ബാക്കിന് നന്ദി, ഗുരുതരമായ ബഗുകൾ ഇതിനകം ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു രീതിയിൽ പരിഹരിച്ചിട്ടുണ്ട്. അതനുസരിച്ച്, അനലൈസർ നിലവിൽ കണ്ടെത്തുന്നതെല്ലാം സാങ്കേതിക കടമായി കണക്കാക്കാം, അത് ഉടനടി ഇല്ലാതാക്കാൻ ശ്രമിക്കുന്നത് അപ്രായോഗികമാണ്.

ഈ മുന്നറിയിപ്പുകൾ ഇപ്പോൾ അപ്രസക്തമായി കണക്കാക്കാൻ നിങ്ങൾക്ക് PVS-Studio-നോട് പറയാനാകും (സാങ്കേതിക കടം പിന്നീട് സംരക്ഷിക്കുക), അത് ഇനി കാണിക്കില്ല. അനലൈസർ ഒരു പ്രത്യേക ഫയൽ സൃഷ്ടിക്കുന്നു, അവിടെ ഇതുവരെ രസകരമല്ലാത്ത പിശകുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ സംരക്ഷിക്കുന്നു. ഇപ്പോൾ PVS-Studio പുതിയതോ മാറ്റിയതോ ആയ കോഡിന് മാത്രമേ മുന്നറിയിപ്പുകൾ നൽകൂ. മാത്രമല്ല, ഇതെല്ലാം സമർത്ഥമായി നടപ്പിലാക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, സോഴ്‌സ് കോഡ് ഫയലിൻ്റെ തുടക്കത്തിൽ ഒരു ശൂന്യമായ വരി ചേർത്തിട്ടുണ്ടെങ്കിൽ, വാസ്തവത്തിൽ, ഒന്നും മാറിയിട്ടില്ലെന്നും നിശബ്ദത തുടരുമെന്നും അനലൈസർ മനസ്സിലാക്കുന്നു. ഈ മാർക്ക്അപ്പ് ഫയൽ ഒരു പതിപ്പ് നിയന്ത്രണ സംവിധാനത്തിൽ ഉൾപ്പെടുത്താം. ഫയൽ വലുതാണ്, പക്ഷേ ഇത് ഒരു പ്രശ്നമല്ല, കാരണം ഇത് പലപ്പോഴും സൂക്ഷിക്കുന്നതിൽ അർത്ഥമില്ല.

ഇപ്പോൾ എല്ലാ പ്രോഗ്രാമർമാരും പുതിയതോ മാറ്റിയതോ ആയ കോഡുമായി ബന്ധപ്പെട്ട മുന്നറിയിപ്പുകൾ കാണും. അതിനാൽ, അവർ പറയുന്നതുപോലെ, അടുത്ത ദിവസം മുതൽ നിങ്ങൾക്ക് അനലൈസർ ഉപയോഗിക്കാൻ തുടങ്ങാം. നിങ്ങൾക്ക് പിന്നീട് സാങ്കേതിക കടത്തിലേക്ക് മടങ്ങാനും ക്രമേണ പിശകുകൾ ശരിയാക്കാനും അനലൈസർ ക്രമീകരിക്കാനും കഴിയും.

അതിനാൽ, ഒരു വലിയ പഴയ പ്രോജക്റ്റിൽ അനലൈസർ നടപ്പിലാക്കുന്നതിനുള്ള ആദ്യ പ്രശ്നം പരിഹരിച്ചു. സാങ്കേതിക കടവുമായി എന്തുചെയ്യണമെന്ന് ഇപ്പോൾ നമുക്ക് നോക്കാം.

ബഗ് പരിഹാരങ്ങളും റീഫാക്‌ടറിംഗുകളും

വൻതോതിൽ അടിച്ചമർത്തപ്പെട്ട അനലൈസർ മുന്നറിയിപ്പുകൾ വിശകലനം ചെയ്യാനും ക്രമേണ അവ കൈകാര്യം ചെയ്യാനും കുറച്ച് സമയം നീക്കിവെക്കുക എന്നതാണ് ഏറ്റവും ലളിതവും സ്വാഭാവികവുമായ കാര്യം. എവിടെയെങ്കിലും നിങ്ങൾ കോഡിലെ പിശകുകൾ പരിഹരിക്കണം, എവിടെയെങ്കിലും കോഡ് പ്രശ്‌നകരമല്ലെന്ന് അനലൈസറോട് പറയാൻ നിങ്ങൾ റീഫാക്റ്റർ ചെയ്യണം. ലളിതമായ ഉദാഹരണം:

if (a = b)

മിക്ക C++ കംപൈലറുകളും അനലൈസറുകളും അത്തരം കോഡിനെക്കുറിച്ച് പരാതിപ്പെടുന്നു, കാരണം അവർ യഥാർത്ഥത്തിൽ എഴുതാൻ ആഗ്രഹിച്ചതിൻ്റെ ഉയർന്ന സംഭാവ്യതയുണ്ട്. (എ == ബി). എന്നാൽ പറയാത്ത ഒരു ഉടമ്പടിയുണ്ട്, ഇത് സാധാരണയായി ഡോക്യുമെൻ്റേഷനിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട്, അധിക പരാൻതീസിസുകൾ ഉണ്ടെങ്കിൽ, പ്രോഗ്രാമർ മനഃപൂർവ്വം അത്തരം കോഡ് എഴുതിയതായി കണക്കാക്കപ്പെടുന്നു, സത്യം ചെയ്യേണ്ടതില്ല. ഉദാഹരണത്തിന്, ഡയഗ്നോസ്റ്റിക്സിനായുള്ള പിവിഎസ്-സ്റ്റുഡിയോ ഡോക്യുമെൻ്റേഷനിൽ V559 (CWE-481) ഇനിപ്പറയുന്ന വരി ശരിയും സുരക്ഷിതവുമായി പരിഗണിക്കുമെന്ന് വ്യക്തമായി എഴുതിയിരിക്കുന്നു:

if ((a = b))

മറ്റൊരു ഉദാഹരണം. ഈ C++ കോഡിൽ അത് മറന്നുപോയോ? ഇടവേള അല്ലെങ്കിൽ അല്ല?

case A:
  foo();
case B:
  bar();
  break;

PVS-Studio അനലൈസർ ഇവിടെ ഒരു മുന്നറിയിപ്പ് നൽകും V796 (CWE-484). ഇതൊരു പിശക് ആയിരിക്കില്ല, ഈ സാഹചര്യത്തിൽ ആട്രിബ്യൂട്ട് ചേർത്തുകൊണ്ട് നിങ്ങൾ പാഴ്‌സറിന് ഒരു സൂചന നൽകണം [[വീഴ്ചയിലൂടെ]] അല്ലെങ്കിൽ, ഉദാഹരണത്തിന്, __ആട്രിബ്യൂട്ട്__((ഫാൾത്രൂ)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

ഇത്തരം കോഡ് മാറ്റങ്ങൾ ബഗ് പരിഹരിക്കില്ല എന്ന് പറയാം. അതെ, ഇത് ശരിയാണ്, എന്നാൽ ഇത് രണ്ട് ഉപയോഗപ്രദമായ കാര്യങ്ങൾ ചെയ്യുന്നു. ഒന്നാമതായി, അനലൈസർ റിപ്പോർട്ട് തെറ്റായ പോസിറ്റീവുകൾ ഒഴിവാക്കുന്നു. രണ്ടാമതായി, കോഡ് അതിൻ്റെ പരിപാലനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്ന ആളുകൾക്ക് കൂടുതൽ മനസ്സിലാക്കാവുന്നതേയുള്ളൂ. ഇത് വളരെ പ്രധാനമാണ്! ഇതിനായി മാത്രം, കോഡ് വ്യക്തവും പരിപാലിക്കാൻ എളുപ്പവുമാക്കുന്നതിന് ചെറിയ റീഫാക്ടറിംഗുകൾ നടത്തുന്നത് മൂല്യവത്താണ്. "ബ്രേക്ക്" വേണോ വേണ്ടയോ എന്ന് അനലൈസറിന് മനസ്സിലാകാത്തതിനാൽ, സഹ പ്രോഗ്രാമർമാർക്കും ഇത് വ്യക്തമല്ല.

ബഗ് പരിഹരിക്കലുകൾക്കും റീഫാക്‌ടറിംഗുകൾക്കും പുറമേ, നിങ്ങൾക്ക് വ്യക്തമായും തെറ്റായ അനലൈസർ മുന്നറിയിപ്പുകൾ അടിച്ചമർത്താൻ കഴിയും. ചില അപ്രസക്തമായ ഡയഗ്നോസ്റ്റിക്സ് പ്രവർത്തനരഹിതമാക്കാം. ഉദാഹരണത്തിന്, മുന്നറിയിപ്പുകൾ അർത്ഥശൂന്യമാണെന്ന് ആരെങ്കിലും കരുതുന്നു V550 ഫ്ലോട്ട്/ഇരട്ട മൂല്യങ്ങൾ താരതമ്യം ചെയ്യുന്നതിനെക്കുറിച്ച്. ചിലർ അവയെ പ്രധാനപ്പെട്ടതും പഠിക്കാൻ യോഗ്യവുമാണെന്ന് തരംതിരിക്കുന്നു [7]. ഏതൊക്കെ മുന്നറിയിപ്പുകളാണ് പ്രസക്തമായി കണക്കാക്കുന്നത്, അല്ലാത്തത് തീരുമാനിക്കേണ്ടത് ഡെവലപ്‌മെൻ്റ് ടീമാണ്.

തെറ്റായ അലേർട്ടുകൾ അടിച്ചമർത്താൻ മറ്റ് മാർഗങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, മാക്രോ മാർക്ക്അപ്പ് നേരത്തെ സൂചിപ്പിച്ചിരുന്നു. ഇതെല്ലാം ഡോക്യുമെൻ്റേഷനിൽ കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു. തെറ്റായ പോസിറ്റീവുകളുമായി പ്രവർത്തിക്കാൻ നിങ്ങൾ ക്രമേണയും വ്യവസ്ഥാപിതമായും സമീപിക്കുകയാണെങ്കിൽ, അവയിൽ തെറ്റൊന്നുമില്ലെന്ന് മനസ്സിലാക്കുക എന്നതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം. താൽപ്പര്യമില്ലാത്ത മുന്നറിയിപ്പുകളിൽ ഭൂരിഭാഗവും കോൺഫിഗറേഷനുശേഷം അപ്രത്യക്ഷമാകും, കൂടാതെ സൂക്ഷ്മമായ പഠനവും കോഡിലെ ചില മാറ്റങ്ങളും ആവശ്യമുള്ള സ്ഥലങ്ങൾ മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ.

കൂടാതെ, എന്തെങ്കിലും ബുദ്ധിമുട്ടുകൾ ഉണ്ടായാൽ PVS-Studio സജ്ജീകരിക്കാൻ ഞങ്ങൾ എപ്പോഴും ഞങ്ങളുടെ ക്ലയൻ്റുകളെ സഹായിക്കുന്നു. മാത്രമല്ല, തെറ്റായ മുന്നറിയിപ്പുകൾ ഞങ്ങൾ തന്നെ ഇല്ലാതാക്കുകയും തെറ്റുകൾ തിരുത്തുകയും ചെയ്ത സന്ദർഭങ്ങളുണ്ട്.8]. വിപുലീകൃത സഹകരണത്തിനുള്ള ഈ ഓപ്ഷനും സാധ്യമാണെന്ന് സൂചിപ്പിക്കാൻ ഞാൻ തീരുമാനിച്ചു :).

റാറ്റ്ചെറ്റ് രീതി

സ്റ്റാറ്റിക് അനലൈസർ മുന്നറിയിപ്പ് ഒഴിവാക്കിക്കൊണ്ട് കോഡ് ഗുണനിലവാരം ക്രമേണ മെച്ചപ്പെടുത്തുന്നതിന് രസകരമായ മറ്റൊരു സമീപനമുണ്ട്. മുന്നറിയിപ്പുകളുടെ എണ്ണം കുറയാനേ കഴിയൂ എന്നതാണ് സാരം.

സ്റ്റാറ്റിക് അനലൈസർ നൽകുന്ന മുന്നറിയിപ്പുകളുടെ എണ്ണം രേഖപ്പെടുത്തിയിട്ടുണ്ട്. പ്രവർത്തനങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കാത്ത ഒരു കോഡ് മാത്രമേ ഇപ്പോൾ നിങ്ങൾക്ക് നൽകാനാവൂ എന്ന തരത്തിലാണ് ഗുണനിലവാര ഗേറ്റ് ക്രമീകരിച്ചിരിക്കുന്നത്. തൽഫലമായി, അനലൈസർ ക്രമീകരിച്ചും പിശകുകൾ തിരുത്തിയും അലാറങ്ങളുടെ എണ്ണം ക്രമേണ കുറയ്ക്കുന്ന പ്രക്രിയ ആരംഭിക്കുന്നു.

ഒരു വ്യക്തി അൽപ്പം വഞ്ചിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽപ്പോലും, തൻ്റെ പുതിയ കോഡിലെ മുന്നറിയിപ്പുകൾ ഒഴിവാക്കുന്നതിലൂടെയല്ല, മറിച്ച് പഴയ മൂന്നാം കക്ഷി കോഡ് മെച്ചപ്പെടുത്തുന്നതിലൂടെ ഗുണനിലവാരമുള്ള ഗേറ്റ് കടന്നുപോകാൻ തീരുമാനിച്ചാലും, ഇത് ഭയാനകമല്ല. എല്ലാം തന്നെ, റാറ്റ്ചെറ്റ് ഒരു ദിശയിൽ കറങ്ങുന്നു, ക്രമേണ വൈകല്യങ്ങളുടെ എണ്ണം കുറയും. ഒരു വ്യക്തിക്ക് സ്വന്തം പുതിയ വൈകല്യങ്ങൾ പരിഹരിക്കാൻ താൽപ്പര്യമില്ലെങ്കിലും, അയാൾക്ക് അയൽ കോഡിൽ എന്തെങ്കിലും മെച്ചപ്പെടുത്തേണ്ടതുണ്ട്. ചില ഘട്ടങ്ങളിൽ, മുന്നറിയിപ്പുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിനുള്ള എളുപ്പവഴികൾ അവസാനിക്കുന്നു, യഥാർത്ഥ ബഗുകൾ പരിഹരിക്കപ്പെടുമ്പോൾ ഒരു ഘട്ടം വരുന്നു.

ഇവാൻ പൊനോമറേവിൻ്റെ വളരെ രസകരമായ ഒരു ലേഖനത്തിൽ ഈ രീതിശാസ്ത്രം കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു.ബഗുകൾ കണ്ടെത്തുന്നതിന് അത് ഉപയോഗിക്കുന്നതിനുപകരം, പ്രക്രിയയിൽ സ്റ്റാറ്റിക് വിശകലനം നടപ്പിലാക്കുക", കോഡ് ഗുണനിലവാരം മെച്ചപ്പെടുത്താൻ താൽപ്പര്യമുള്ള ആർക്കും വായിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു.

ലേഖനത്തിൻ്റെ രചയിതാവിന് ഈ വിഷയത്തിൽ ഒരു റിപ്പോർട്ടും ഉണ്ട്: "തുടർച്ചയായ സ്റ്റാറ്റിക് വിശകലനം".

തീരുമാനം

ഈ ലേഖനത്തിനു ശേഷം, വായനക്കാർ സ്റ്റാറ്റിക് അനാലിസിസ് ടൂളുകൾ കൂടുതൽ അംഗീകരിക്കുകയും അവ വികസന പ്രക്രിയയിൽ നടപ്പിലാക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. നിങ്ങൾക്ക് എന്തെങ്കിലും ചോദ്യങ്ങളുണ്ടെങ്കിൽ, ഞങ്ങൾ എപ്പോഴും തയ്യാറാണ് ഉപദേശിക്കുക ഞങ്ങളുടെ സ്റ്റാറ്റിക് അനലൈസർ പിവിഎസ്-സ്റ്റുഡിയോയുടെ ഉപയോക്താക്കൾ അത് നടപ്പിലാക്കുന്നതിൽ സഹായിക്കുക.

സ്റ്റാറ്റിക് വിശകലനം ശരിക്കും സൗകര്യപ്രദവും ഉപയോഗപ്രദവുമാണോ എന്നതിനെക്കുറിച്ച് മറ്റ് സാധാരണ സംശയങ്ങളുണ്ട്. "വികസന പ്രക്രിയയിൽ പിവിഎസ്-സ്റ്റുഡിയോ സ്റ്റാറ്റിക് കോഡ് അനലൈസർ അവതരിപ്പിക്കുന്നതിനുള്ള കാരണങ്ങൾ" എന്ന പ്രസിദ്ധീകരണത്തിൽ ഈ സംശയങ്ങളിൽ ഭൂരിഭാഗവും ഞാൻ ഇല്ലാതാക്കാൻ ശ്രമിച്ചു.9].

നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് നന്ദി, വന്നതിന് скачать കൂടാതെ PVS-Studio അനലൈസർ പരീക്ഷിക്കുക.

അധിക ലിങ്കുകൾ

1. ആൻഡ്രി കാർപോവ്. C, C++ കോഡുകൾക്കായി PVS-Studio അനലൈസർ നിർമ്മിക്കുന്ന രസകരമായ മുന്നറിയിപ്പുകൾ എനിക്ക് എങ്ങനെ പെട്ടെന്ന് കാണാൻ കഴിയും?
2. വിക്കിപീഡിയ അരിയുടെ സിദ്ധാന്തം.
3. ആൻഡ്രി കാർപോവ്, വിക്ടോറിയ ഖനീവ. പ്രോഗ്രാം സോഴ്സ് കോഡിൻ്റെ സ്റ്റാറ്റിക് വിശകലനത്തിൽ മെഷീൻ ലേണിംഗ് ഉപയോഗിക്കുന്നു.
4. പിവിഎസ്-സ്റ്റുഡിയോ. പ്രമാണീകരണം. അധിക ഡയഗ്നോസ്റ്റിക് ക്രമീകരണങ്ങൾ.
5. ആൻഡ്രി കാർപോവ്. EFL കോർ ലൈബ്രറികളുടെ ഉദാഹരണം ഉപയോഗിച്ച് PVS-സ്റ്റുഡിയോ അനലൈസറിൻ്റെ സവിശേഷതകൾ, 10-15% തെറ്റായ പോസിറ്റീവുകൾ.
6. പിവിഎസ്-സ്റ്റുഡിയോ. പ്രമാണീകരണം. അനലൈസർ സന്ദേശങ്ങൾ കൂട്ടത്തോടെ അടിച്ചമർത്തൽ.
7. ഇവാൻ ആൻഡ്രിയാഷിൻ. എക്സ്-റേ എൻഡോവാസ്കുലർ സർജറിയുടെ ഒരു വിദ്യാഭ്യാസ സിമുലേറ്ററിൻ്റെ ഞങ്ങളുടെ പ്രോജക്റ്റിൽ സ്റ്റാറ്റിക് വിശകലനം ഞങ്ങൾ എങ്ങനെ പരീക്ഷിച്ചു എന്നതിനെക്കുറിച്ച്.
8. പവൽ എറെമീവ്, സ്വ്യാറ്റോസ്ലാവ് റസ്മിസ്ലോവ്. PVS-Studio ടീം എങ്ങനെയാണ് അൺറിയൽ എഞ്ചിൻ കോഡ് മെച്ചപ്പെടുത്തിയത്.
9. ആൻഡ്രി കാർപോവ്. വികസന പ്രക്രിയയിൽ സ്റ്റാറ്റിക് കോഡ് അനലൈസർ പിവിഎസ്-സ്റ്റുഡിയോ അവതരിപ്പിക്കുന്നതിനുള്ള കാരണങ്ങൾ.

ഇംഗ്ലീഷ് സംസാരിക്കുന്ന പ്രേക്ഷകരുമായി ഈ ലേഖനം പങ്കിടാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, വിവർത്തന ലിങ്ക് ഉപയോഗിക്കുക: Andrey Karpov. ഒരു ലെഗസി പ്രോജക്റ്റിൽ ഒരു സ്റ്റാറ്റിക് കോഡ് അനലൈസർ എങ്ങനെ അവതരിപ്പിക്കാം, ടീമിനെ നിരുത്സാഹപ്പെടുത്തരുത്.

അവലംബം: www.habr.com