ബഗുകൾ കണ്ടെത്തുന്നതിന് അത് ഉപയോഗിക്കുന്നതിനുപകരം, പ്രക്രിയയിൽ സ്റ്റാറ്റിക് വിശകലനം നടപ്പിലാക്കുക

ഈ ലേഖനം എഴുതാൻ എന്നെ പ്രേരിപ്പിച്ചത് സ്റ്റാറ്റിക് വിശകലനത്തെക്കുറിച്ചുള്ള വലിയ അളവിലുള്ള മെറ്റീരിയലുകൾ എന്റെ ശ്രദ്ധയിൽ പെടുന്നു. ഒന്നാമതായി, ഇത് പിവിഎസ്-സ്റ്റുഡിയോ ബ്ലോഗ്, ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റുകളിൽ അവരുടെ ടൂൾ കണ്ടെത്തിയ പിശകുകളുടെ അവലോകനങ്ങളുടെ സഹായത്തോടെ ഹാബ്രെയിൽ സജീവമായി പ്രമോട്ട് ചെയ്യുന്നു. അടുത്തിടെ പിവിഎസ്-സ്റ്റുഡിയോ നടപ്പിലാക്കി ജാവ പിന്തുണ, തീർച്ചയായും, 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-ലേക്ക് മാറ്റില്ല.

എന്തുകൊണ്ടാണ് കൃത്യമായി ഈ വഴി അല്ലാത്തത്? പൈപ്പ്ലൈനിന്റെ ടെസ്റ്റിംഗ് ഭാഗത്ത്, ടെസ്റ്റർമാർ അറിയപ്പെടുന്ന ടെസ്റ്റിംഗ് പിരമിഡ് തിരിച്ചറിയും.

ടെസ്റ്റ് പിരമിഡ്. ഉറവിടം: ഒരു ലേഖനം മാർട്ടിൻ ഫൗളർ.

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

മൾട്ടി-സ്റ്റേജ് വാട്ടർ ഫിൽട്ടറേഷൻ സിസ്റ്റത്തിന്റെ രൂപത്തിൽ ഒരു സാമ്യം നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. വൃത്തികെട്ട വെള്ളം (വൈകല്യങ്ങളുള്ള മാറ്റങ്ങൾ) ഇൻപുട്ടിലേക്ക് വിതരണം ചെയ്യുന്നു; ഔട്ട്പുട്ടിൽ നമുക്ക് ശുദ്ധമായ വെള്ളം ലഭിക്കണം, അതിൽ അനാവശ്യമായ എല്ലാ മലിനീകരണങ്ങളും ഇല്ലാതാക്കി.

മൾട്ടി-സ്റ്റേജ് ഫിൽട്ടർ. ഉറവിടം: വിക്കിമീഡിയ കോമൺസ്

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

ഒരു "മഡ് ഫിൽട്ടർ" വെള്ളം കുടിക്കാൻ യോഗ്യമാക്കാത്തതുപോലെ, സ്ഥിരമായ വിശകലനം അന്തിമ ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുന്നില്ല. എന്നിട്ടും, പൈപ്പ്ലൈനിന്റെ മറ്റ് ഘടകങ്ങളുമായി സംയോജിച്ച്, അതിന്റെ പ്രാധാന്യം വ്യക്തമാണ്. ഒരു മൾട്ടിസ്റ്റേജ് ഫിൽട്ടറിൽ ഔട്ട്‌പുട്ട് ഘട്ടങ്ങൾ ഇൻപുട്ട് സ്റ്റേജുകൾ ചെയ്യുന്ന എല്ലാ കാര്യങ്ങളും ക്യാപ്‌ചർ ചെയ്യാൻ പ്രാപ്‌തമാണെങ്കിലും, ഇൻപുട്ട് ഘട്ടങ്ങളില്ലാതെ ഫൈൻ-പ്യൂരിഫിക്കേഷൻ സ്റ്റേജുകൾ ഉപയോഗിച്ച് മാത്രം ചെയ്യാൻ ശ്രമിച്ചാൽ എന്ത് അനന്തരഫലങ്ങൾ ഉണ്ടാകുമെന്നത് വ്യക്തമാണ്.

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

സ്റ്റാറ്റിക് അനാലിസിസ് ഇടയ്ക്കിടെ ഉപയോഗിക്കുകയാണെങ്കിൽ ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്താത്തത് എന്തുകൊണ്ടാണെന്ന് ഇപ്പോൾ വ്യക്തമാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു, മാത്രമല്ല മൊത്തത്തിലുള്ള വൈകല്യങ്ങളുള്ള മാറ്റങ്ങൾ ഫിൽട്ടർ ചെയ്യാൻ നിരന്തരം ഉപയോഗിക്കുകയും വേണം. ഒരു സ്റ്റാറ്റിക് അനലൈസർ ഉപയോഗിക്കുന്നത് നിങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുമോ എന്ന ചോദ്യം, "വൃത്തികെട്ട കുളത്തിൽ നിന്ന് എടുക്കുന്ന വെള്ളം ഒരു കോലാണ്ടറിലൂടെ കടത്തിവിട്ടാൽ കുടിവെള്ളത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുമോ?" എന്ന് ചോദിക്കുന്നതിന് തുല്യമാണ്.

ഒരു പൈതൃക പദ്ധതിയായി നടപ്പിലാക്കൽ

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

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

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

ഗുണനിലവാരമുള്ള ഗേറ്റുകൾ അവതരിപ്പിക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന രീതികൾ അറിയപ്പെടുന്നു:

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

റാറ്റ്ചെറ്റ്

ഇത് ഈ രീതിയിൽ പ്രവർത്തിക്കുന്നു:

1. പ്രാരംഭ ഘട്ടത്തിൽ, അനലൈസർമാർ കണ്ടെത്തിയ കോഡിലെ മുന്നറിയിപ്പുകളുടെ എണ്ണം റിലീസ് ചെയ്യുന്നതിനെക്കുറിച്ച് മെറ്റാഡാറ്റയിൽ ഒരു റെക്കോർഡ് ഉണ്ടാക്കുന്നു. അതിനാൽ, നിങ്ങൾ അപ്‌സ്ട്രീം നിർമ്മിക്കുമ്പോൾ, നിങ്ങളുടെ റിപ്പോസിറ്ററി മാനേജർ എഴുതുന്നത് “7.0.2 റിലീസ് ചെയ്യുക” മാത്രമല്ല, “7.0.2 ചെക്ക്‌സ്റ്റൈൽ മുന്നറിയിപ്പുകൾ അടങ്ങിയ 100500 റിലീസ് ചെയ്യുക.” നിങ്ങൾ ഒരു വിപുലമായ റിപ്പോസിറ്ററി മാനേജർ (ആർട്ടിഫാക്‌ടറി പോലുള്ളവ) ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ റിലീസിനെക്കുറിച്ചുള്ള അത്തരം മെറ്റാഡാറ്റ സംഭരിക്കുന്നത് എളുപ്പമാണ്.
2. ഇപ്പോൾ ഓരോ പുൾ അഭ്യർത്ഥനയും നിർമ്മിക്കുമ്പോൾ, ഫലമായുണ്ടാകുന്ന മുന്നറിയിപ്പുകളുടെ എണ്ണവും നിലവിലെ റിലീസിൽ ലഭ്യമായ മുന്നറിയിപ്പുകളുടെ എണ്ണവും താരതമ്യം ചെയ്യുന്നു. PR ഈ സംഖ്യയിൽ വർദ്ധനവിന് കാരണമാകുന്നുവെങ്കിൽ, സ്റ്റാറ്റിക് വിശകലനത്തിനായി കോഡ് ഗുണനിലവാര ഗേറ്റ് കടന്നുപോകുന്നില്ല. മുന്നറിയിപ്പുകളുടെ എണ്ണം കുറയുകയോ മാറുകയോ ചെയ്തില്ലെങ്കിൽ, അത് കടന്നുപോകുന്നു.
3. അടുത്ത റിലീസിൽ, വീണ്ടും കണക്കാക്കിയ മുന്നറിയിപ്പുകളുടെ എണ്ണം റിലീസ് മെറ്റാഡാറ്റയിൽ വീണ്ടും രേഖപ്പെടുത്തും.

അതിനാൽ കുറച്ചുകൂടെ എന്നാൽ സ്ഥിരമായി (ഒരു റാറ്റ്ചെറ്റ് പ്രവർത്തിക്കുമ്പോൾ പോലെ), മുന്നറിയിപ്പുകളുടെ എണ്ണം പൂജ്യമായി മാറും. തീർച്ചയായും, ഒരു പുതിയ മുന്നറിയിപ്പ് അവതരിപ്പിച്ചുകൊണ്ട് സിസ്റ്റത്തെ കബളിപ്പിക്കാൻ കഴിയും, എന്നാൽ മറ്റൊരാളുടെ തിരുത്തൽ. ഇത് സാധാരണമാണ്, കാരണം വളരെ ദൂരത്തിൽ ഇത് ഫലങ്ങൾ നൽകുന്നു: മുന്നറിയിപ്പുകൾ ശരിയാക്കുന്നു, ചട്ടം പോലെ, വ്യക്തിഗതമായല്ല, ഒരു പ്രത്യേക തരം ഗ്രൂപ്പിൽ ഒരേസമയം, എളുപ്പത്തിൽ നീക്കം ചെയ്യാവുന്ന എല്ലാ മുന്നറിയിപ്പുകളും വളരെ വേഗത്തിൽ ഇല്ലാതാക്കപ്പെടും.

ഈ ഗ്രാഫ് അത്തരം ഒരു "റാറ്റ്ചെറ്റിന്റെ" ആറ് മാസത്തെ പ്രവർത്തനത്തിനുള്ള ചെക്ക്സ്റ്റൈൽ മുന്നറിയിപ്പുകളുടെ ആകെ എണ്ണം കാണിക്കുന്നു ഞങ്ങളുടെ ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റുകളിൽ ഒന്ന്. മുന്നറിയിപ്പുകളുടെ എണ്ണം മാഗ്നിറ്റ്യൂഡ് ക്രമത്തിൽ കുറഞ്ഞു, ഇത് സ്വാഭാവികമായും ഉൽപ്പന്ന വികസനത്തിന് സമാന്തരമായി സംഭവിച്ചു!

ഞാൻ ഈ രീതിയുടെ പരിഷ്‌ക്കരിച്ച പതിപ്പ് ഉപയോഗിക്കുന്നു, പ്രോജക്റ്റ് മൊഡ്യൂളും വിശകലന ടൂളും മുഖേനയുള്ള മുന്നറിയിപ്പുകൾ വെവ്വേറെ എണ്ണുന്നു, അതിന്റെ ഫലമായി ബിൽഡ് മെറ്റാഡാറ്റയുള്ള ഒരു 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() ഏതെങ്കിലും വിഭാഗത്തിലെ മുന്നറിയിപ്പുകളുടെ എണ്ണം വർദ്ധിക്കുമ്പോൾ, അതേ റാറ്റ്ചെറ്റ് നടപ്പിലാക്കുന്നു.

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

അനലൈസർ പതിപ്പ് ശരിയാക്കുന്നതിന്റെ പ്രാധാന്യത്തെക്കുറിച്ച്

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

കണ്ടെത്തലുകൾ

• സ്റ്റാറ്റിക് വിശകലനം നിങ്ങൾക്കായി ബഗുകൾ കണ്ടെത്തില്ല, ഒരൊറ്റ ആപ്ലിക്കേഷന്റെ ഫലമായി നിങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുകയുമില്ല. ഡെലിവറി പ്രക്രിയയിൽ അതിന്റെ നിരന്തരമായ ഉപയോഗത്തിലൂടെ മാത്രമേ ഗുണനിലവാരത്തിൽ ഒരു നല്ല പ്രഭാവം നേടാനാകൂ.
• ബഗുകൾ കണ്ടെത്തുക എന്നത് വിശകലനത്തിന്റെ പ്രധാന ദൌത്യമല്ല; ഉപയോഗപ്രദമായ പ്രവർത്തനങ്ങളിൽ ഭൂരിഭാഗവും ഓപ്പൺ സോഴ്സ് ടൂളുകളിൽ ലഭ്യമാണ്.
• ലെഗസി കോഡിനായി "റാറ്റ്ചെറ്റ്" ഉപയോഗിച്ച് ഡെലിവറി പൈപ്പ്ലൈനിന്റെ ആദ്യ ഘട്ടത്തിൽ സ്റ്റാറ്റിക് വിശകലനത്തിന്റെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി ഗുണനിലവാരമുള്ള ഗേറ്റുകൾ നടപ്പിലാക്കുക.

റെഫറൻസുകൾ

1. തുടർച്ചയായ ഡെലിവറി
2. A. Kudryavtsev: പ്രോഗ്രാം വിശകലനം: നിങ്ങൾ ഒരു നല്ല പ്രോഗ്രാമറാണെന്ന് എങ്ങനെ മനസ്സിലാക്കാം കോഡ് വിശകലനത്തിന്റെ വിവിധ രീതികളെക്കുറിച്ചുള്ള റിപ്പോർട്ട് (സ്റ്റാറ്റിക് മാത്രമല്ല!)

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