ቡድኑን ሳያሳድግ በቆየ ፕሮጀክት ውስጥ የማይንቀሳቀስ ኮድ ተንታኝ እንዴት እንደሚተገበር

የማይንቀሳቀስ ኮድ ተንታኝ መሞከር ቀላል ነው። ነገር ግን እሱን ለመተግበር በተለይም በትልቅ አሮጌ ፕሮጀክት ልማት ውስጥ ክህሎት ይጠይቃል. በስህተት ከተሰራ፣ ተንታኙ ስራን ይጨምራል፣ እድገትን ይቀንሳል እና ቡድኑን ያሳድጋል። የስታቲክ ትንታኔን ወደ ልማት ሂደት እንዴት በትክክል ማቀናጀት እንደሚቻል በአጭሩ እንነጋገር እና እንደ CI/CD አካል መጠቀም እንጀምር።

መግቢያ

በቅርቡ ትኩረቴ ወደ ህትመቱ ስቧል "ቡድኑን ሳያሸንፉ በስታቲክ ትንታኔ መጀመር". በአንድ በኩል, ይህ ጥሩ መተዋወቅ የሚገባ ጽሑፍ ነው. በሌላ በኩል, ብዙ ጋር ፕሮጀክት ውስጥ static ትንተና እንዴት ያለ ህመም መተግበር ላይ አሁንም የተሟላ መልስ ያለ አይመስለኝም. ሌጋሲ ኮድ፡- ጽሁፉ የቴክኒካል እዳ መቀበል እና በአዲስ ኮድ ላይ ብቻ መስራት እንደምትችል ይናገራል፡ ነገር ግን ከዚህ ቴክኒካል እዳ በኋላ ምን ማድረግ እንዳለብህ ምንም አይነት መልስ የለም።

የእኛ የPVS-ስቱዲዮ ቡድን በዚህ ርዕስ ላይ ያለውን አመለካከት ያቀርባል። የስታቲስቲክ ኮድ ትንታኔን የመተግበር ችግር በመጀመሪያ ደረጃ እንዴት እንደሚነሳ ፣ ይህንን ችግር እንዴት ማሸነፍ እንደሚቻል እና እንዴት ያለ ህመም ቀስ በቀስ ቴክኒካዊ ዕዳዎችን ማስወገድ እንደሚቻል እንመልከት ።

ጉዳዮች

የማይንቀሳቀስ ተንታኝ እንዴት እንደሚሰራ ማስጀመር እና ማየት ብዙውን ጊዜ አስቸጋሪ አይደለም [1]. በኮዱ ውስጥ ደስ የሚሉ ስህተቶችን አልፎ ተርፎም አስፈሪ ሊሆኑ የሚችሉ ተጋላጭነቶችን ሊመለከቱ ይችላሉ። አንድ ነገር እንኳን ማስተካከል ይችላሉ, ነገር ግን ብዙ ፕሮግራመሮች ተስፋ ቆርጠዋል.

ሁሉም የማይንቀሳቀሱ ተንታኞች የውሸት አወንታዊ ውጤቶችን ያስገኛሉ። ይህ የስታቲክ ኮድ ትንተና ዘዴ ባህሪ ነው, እና ምንም ማድረግ አይቻልም. በአጠቃላይ ይህ የማይፈታ ችግር ነው፣ በሩዝ ቲዎሬም እንደተረጋገጠው [2]. የማሽን መማር ስልተ ቀመሮችም አይረዱም [3]. ምንም እንኳን አንድ ሰው ይህ ወይም ያ ኮድ ስህተት መሆኑን ሁልጊዜ ማወቅ ባይችልም ከፕሮግራሙ ይህንን መጠበቅ የለብዎትም :).

የማይንቀሳቀስ ተንታኝ አስቀድሞ ከተዋቀረ የውሸት አወንታዊ ነገሮች ችግር አይደሉም፡-

• አግባብነት የሌላቸው ደንቦች ስብስቦች ተሰናክለዋል;
• አንዳንድ ተዛማጅነት የሌላቸው ምርመራዎች ተሰናክለዋል;
• ስለ C ወይም C ++ እየተነጋገርን ከሆነ ማክሮዎች እንደዚህ ያሉ ማክሮዎች በሚጠቀሙባቸው ቦታዎች ሁሉ የማይጠቅሙ ማስጠንቀቂያዎች እንዲታዩ የሚያደርጉ የተወሰኑ ግንባታዎችን የያዙ ምልክት ተደርጎባቸዋል ።
• ከስርዓት ተግባራት (የራሱ አናሎግ) ጋር ተመሳሳይ የሆኑ ድርጊቶችን የሚፈጽም የራሱ ተግባራት ምልክት ተደርጎባቸዋል ትውስታ ወይም printf) [4];
• አስተያየቶችን በመጠቀም የውሸት አወንታዊዎች በተለይ ተሰናክለዋል;
• እና የመሳሰሉት.

በዚህ ሁኔታ፣ ከ10-15% አካባቢ ዝቅተኛ የውሸት አወንታዊ መጠን መጠበቅ እንችላለን።5]. በሌላ አነጋገር፣ 9 ከ10 ተንታኝ ማስጠንቀቂያዎች በኮዱ ውስጥ ያለን ትክክለኛ ችግር ወይም ቢያንስ “ጠንካራ ሽታ ያለው ኮድ” ያመለክታሉ። እስማማለሁ፣ ይህ ሁኔታ በጣም ደስ የሚል ነው፣ እና ተንታኙ የፕሮግራም አድራጊው እውነተኛ ጓደኛ ነው።

እንደ እውነቱ ከሆነ, በአንድ ትልቅ ፕሮጀክት ውስጥ, የመነሻ ሥዕል ሙሉ ለሙሉ የተለየ ይሆናል. ተንታኙ ለቅርስ ኮድ በመቶዎች ወይም በሺዎች የሚቆጠሩ ማስጠንቀቂያዎችን ይሰጣል። ከእነዚህ ማስጠንቀቂያዎች ውስጥ የትኞቹ አስፈላጊ እንደሆኑ እና የትኞቹ እንደማይሆኑ በፍጥነት ለመረዳት የማይቻል ነው. በዚህ ጉዳይ ላይ ዋናው ሥራ ለቀናት ወይም ለሳምንታት ስለሚቆም ቁጭ ብሎ እነዚህን ሁሉ ማስጠንቀቂያዎች ማስተናገድ መጀመር ምክንያታዊነት የጎደለው ነው. በተለምዶ አንድ ቡድን እንዲህ ዓይነቱን ሁኔታ መግዛት አይችልም. የለውጡን ታሪክ የሚያበላሹ እጅግ በጣም ብዙ ልዩነቶችም ይኖራሉ። እና በኮዱ ውስጥ ያሉ ብዙ ቁርጥራጮችን በፍጥነት ማረም አዳዲስ ስህተቶችን እና ስህተቶችን ማድረጉ የማይቀር ነው።

እና ከሁሉም በላይ, ከማስጠንቀቂያዎች ጋር በሚደረገው ትግል ውስጥ እንዲህ ዓይነቱ ስኬት ትንሽ ትርጉም አይሰጥም. ፕሮጀክቱ ለብዙ አመታት በተሳካ ሁኔታ እየሄደ ስለሆነ በውስጡ ያሉት አብዛኛዎቹ ወሳኝ ስህተቶች ቀድሞውኑ ተስተካክለዋል. አዎን, እነዚህ ጥገናዎች በጣም ውድ ነበሩ, ማረም ነበረባቸው, ስለ ስህተቶች አሉታዊ የተጠቃሚ ግብረመልስ ተቀብለዋል, ወዘተ. የማይንቀሳቀስ ተንታኝ ብዙዎቹን ስህተቶች በኮዲንግ ደረጃ በፍጥነት እና በርካሽ ለማስተካከል ይረዳል። ግን በአሁኑ ጊዜ ፣ ​​አንድ ወይም ሌላ ፣ እነዚህ ስህተቶች ተስተካክለዋል ፣ እና ተንታኙ በዋናነት በአሮጌው ኮድ ውስጥ ወሳኝ ያልሆኑ ስህተቶችን ያገኛል። ይህ ኮድ ጥቅም ላይ መዋል አይችልም፣ በጣም አልፎ አልፎ ጥቅም ላይ ሊውል ይችላል፣ እና በውስጡ ያለው ስህተት ወደሚታዩ ውጤቶች አይመራም። ምናልባት የሆነ ቦታ ከአዝራሩ ላይ ያለው ጥላ የተሳሳተ ቀለም ነው, ነገር ግን ይህ በማንም ሰው የምርት አጠቃቀም ላይ ጣልቃ አይገባም.

እርግጥ ነው, ጥቃቅን ስህተቶች እንኳን አሁንም ስህተቶች ናቸው. እና አንዳንድ ጊዜ ስህተት እውነተኛ ተጋላጭነትን ሊደብቅ ይችላል። ነገር ግን፣ ሁሉንም ነገር መተው እና ቀናቶች/ሳምንት እራሳቸውን በቀላሉ ከሚገለጡ ጉድለቶች ጋር ማዋል አጠራጣሪ ሀሳብ ይመስላል።

ፕሮግራመሮች ስለ አሮጌው የስራ ኮድ እነዚህን ሁሉ ማስጠንቀቂያዎች ይመለከታሉ፣ ይመለከቷቸዋል፣ ይመለከቷቸዋል… እና እነሱ ያስባሉ-ያለ ቋሚ ትንታኔ ማድረግ እንችላለን። አንዳንድ አዲስ ጠቃሚ ተግባራትን እንፃፍ።

በራሳቸው መንገድ ትክክል ናቸው. በመጀመሪያ እነዚህን ሁሉ ማስጠንቀቂያዎች በሆነ መንገድ ማስወገድ እንዳለባቸው አስበዋል. ከዚያ በኋላ ብቻ የኮድ ተንታኙን በመደበኛነት መጠቀም የሚችሉት። ያለበለዚያ አዳዲስ ማስጠንቀቂያዎች በአሮጌዎቹ ውስጥ ይሰምጣሉ ፣ እና ማንም ለእነሱ ትኩረት አይሰጥም።

ይህ ከአቀናባሪ ማስጠንቀቂያዎች ጋር ተመሳሳይ ተመሳሳይነት ነው። የማጠናቀቂያ ማስጠንቀቂያዎችን ቁጥር በ 0 እንዲይዙ ያቀረቡት ያለ ምክንያት አይደለም 1000 ማስጠንቀቂያዎች ካሉ 1001 ሲኖሩ ማንም ትኩረት አይሰጠውም እና ይህን አዲስ ማስጠንቀቂያ የት እንደሚፈልጉ ግልጽ አይደለም.

በዚህ ታሪክ ውስጥ በጣም መጥፎው ነገር ከላይ የሆነ ሰው በዚህ ጊዜ የማይንቀሳቀስ ኮድ ትንተና እንድትጠቀም ቢያስገድድህ ነው። ይህ ደግሞ ቡድኑን ዝቅ ያደርገዋል። ማንም ሰው የትንታኔውን ሪፖርቶች አይመለከትም, እና ሁሉም አጠቃቀሞች "በወረቀት ላይ" ብቻ ይሆናሉ. እነዚያ። በመደበኛነት, ትንተና በ DevOps ሂደት ውስጥ ተገንብቷል, ነገር ግን በተግባር ይህ ለማንም አይጠቅምም. በዳስ ውስጥ ከጉባኤው ተሳታፊዎች ዝርዝር ታሪኮችን ሰምተናል። እንዲህ ያለው ልምድ ፕሮግራመሮች ለዘለአለም ካልሆነ ለረጅም ጊዜ የማይለዋወጥ የመተንተን መሳሪያዎችን እንዳይጠቀሙ ተስፋ ያስቆርጣል.

የቴክኒክ ዕዳን መተግበር እና ማስወገድ

በእውነቱ፣ በትልቅ አሮጌ ፕሮጀክት ውስጥ እንኳን የማይለዋወጥ ትንታኔን ለማስተዋወቅ ምንም አስቸጋሪ ወይም አስፈሪ ነገር የለም።

ሲአይ / ሲዲ

ከዚህም በላይ ተንታኙ ወዲያውኑ ቀጣይነት ያለው የእድገት ሂደት አካል ሊሆን ይችላል. ለምሳሌ፣ የPVS-ስቱዲዮ ስርጭቱ ሪፖርቱን በሚፈልጉት ቅርጸት በተመቸ ሁኔታ ለማየት መገልገያዎችን እና ችግር ያለባቸውን የኮዱ ክፍሎችን ለጻፉ ገንቢዎች ማሳወቂያዎችን ይዟል። ከ CI/CD ሲስተሞች PVS-Studioን ለመክፈት የበለጠ ፍላጎት ላላቸው ሰዎች እራስዎን በሚዛመደው እንዲያውቁ እመክራለሁ ክፍል ሰነዶች እና ተከታታይ መጣጥፎች;

• PVS-ስቱዲዮ ወደ ደመናዎች ይሄዳል: Azure Devops
• PVS-ስቱዲዮ ወደ ደመና ይሄዳል: Travis CI
• PVS-ስቱዲዮ ወደ ደመናው ይሄዳል፡ GitLab CI/CD
• PVS-ስቱዲዮ ወደ ደመናዎች ይሄዳል: CircleCI

ነገር ግን የኮድ ትንተና መሳሪያዎችን በመተግበር የመጀመሪያ ደረጃዎች ላይ ብዙ ቁጥር ያላቸውን የውሸት ውጤቶች ወደ ጉዳዩ እንመለስ.

ያለውን የቴክኒክ ዕዳ ማስተካከል እና አዲስ ማስጠንቀቂያዎችን ማስተናገድ

ዘመናዊ የንግድ የማይንቀሳቀስ ተንታኞች በአዲስ ወይም በተለወጠ ኮድ ውስጥ የሚታዩ አዳዲስ ማስጠንቀቂያዎችን ብቻ እንዲያጠኑ ያስችሉዎታል። የዚህ ዘዴ አተገባበር ይለያያል, ነገር ግን ዋናው ነገር አንድ ነው. በ PVS-Studio static analyzer ውስጥ ይህ ተግባር እንደሚከተለው ተተግብሯል.

የማይንቀሳቀስ ትንታኔን በፍጥነት ለመጠቀም፣ የPVS-ስቱዲዮ ተጠቃሚዎች የጅምላ ማስጠንቀቂያዎችን ለማፈን ዘዴውን እንዲጠቀሙ እንመክራለን።6]. አጠቃላይ ሀሳቡ የሚከተለው ነው። ተጠቃሚው ተንታኙን አስነሳ እና ብዙ ማስጠንቀቂያዎችን ተቀብሏል። ለብዙ ዓመታት በልማት ላይ ያለ ፕሮጀክት ሕያው፣ እያደገና ገንዘብ ስለሚያገኝ፣ በሪፖርቱ ውስጥ ወሳኝ ጉድለቶችን የሚያመለክቱ ብዙ ማስጠንቀቂያዎች ሊኖሩ አይችሉም። በሌላ አገላለጽ፣ ወሳኝ ስህተቶች በአንድ ወይም በሌላ መንገድ በጣም ውድ የሆኑ ዘዴዎችን በመጠቀም ወይም ለደንበኞች አስተያየት ምስጋና ይግባቸው። በዚህ መሠረት ተንታኙ በአሁኑ ጊዜ ያገኘው ነገር ሁሉ እንደ ቴክኒካዊ ዕዳ ሊቆጠር ይችላል, ይህም ወዲያውኑ ለማጥፋት መሞከር የማይቻል ነው.

ለ PVS-ስቱዲዮ እነዚህን ማስጠንቀቂያዎች ለአሁን አግባብነት እንደሌለው እንዲቆጥራቸው መንገር ይችላሉ (ለቴክኒክ ዕዳ ይቆጥቡ) እና ከአሁን በኋላ አያሳያቸውም። ተንታኙ ገና ትኩረት የማይሰጡ ስህተቶችን መረጃ የሚያስቀምጥበት ልዩ ፋይል ይፈጥራል። እና አሁን PVS-Studio ለአዲስ ወይም ለተለወጠ ኮድ ብቻ ማስጠንቀቂያ ይሰጣል። ከዚህም በላይ ይህ ሁሉ በጥበብ ይተገበራል. ለምሳሌ, ባዶ መስመር ወደ የምንጭ ኮድ ፋይል መጀመሪያ ላይ ከተጨመረ, ተንታኙ ምንም ነገር እንዳልተለወጠ እና ዝም ማለቱን እንደሚቀጥል ይገነዘባል. ይህ የማርክ ፋይል ወደ ስሪት ቁጥጥር ስርዓት ሊገባ ይችላል። ፋይሉ ትልቅ ነው, ነገር ግን ይህ ችግር አይደለም, ምክንያቱም ብዙ ጊዜ ማከማቸት ምንም ፋይዳ የለውም.

አሁን ሁሉም ፕሮግራመሮች ከአዲስ ወይም ከተለወጠ ኮድ ጋር የተያያዙ ማስጠንቀቂያዎችን ያያሉ። ስለዚህ ፣ እነሱ እንደሚሉት ፣ በሚቀጥለው ቀን ተንታኙን መጠቀም መጀመር ይችላሉ። እና በኋላ ወደ ቴክኒካዊ ዕዳ መመለስ ይችላሉ, እና ቀስ በቀስ ስህተቶችን ያስተካክሉ እና ተንታኙን ያዋቅሩ.

ስለዚህ በትልቅ አሮጌ ፕሮጀክት ውስጥ የመተንተን አተገባበር የመጀመሪያው ችግር ተፈትቷል. አሁን በቴክኒክ ዕዳ ምን ማድረግ እንዳለብን እንወቅ.

የሳንካ ጥገናዎች እና ማሻሻያዎች

በጣም ቀላሉ እና በጣም ተፈጥሯዊው ነገር በጅምላ የታፈኑ የትንታኔ ማስጠንቀቂያዎችን ለመተንተን እና ቀስ በቀስ እነሱን ለመቋቋም የተወሰነ ጊዜ መመደብ ነው። የሆነ ቦታ ላይ ስህተቶችን በኮዱ ውስጥ ማስተካከል አለብህ፣ የሆነ ቦታ ላይ ኮዱ ችግር እንደሌለበት ለተንታኙ መንገር አለብህ። ቀላል ምሳሌ፡-

if (a = b)

አብዛኛዎቹ የC++ አቀናባሪዎች እና ተንታኞች ስለ እንደዚህ አይነት ኮድ ቅሬታ ያሰማሉ፣ ምክንያቱም እነሱ በትክክል ለመፃፍ የሚፈልጉት ከፍተኛ ዕድል ስላለ ነው። (ሀ = ለ). ነገር ግን ያልተነገረ ስምምነት አለ, እና ይህ ብዙውን ጊዜ በሰነዱ ውስጥ ይገለጻል, ተጨማሪ ቅንፎች ካሉ, ፕሮግራሚው ሆን ብሎ እንዲህ አይነት ኮድ እንደጻፈ ይቆጠራል, እናም መሳደብ አያስፈልግም. ለምሳሌ፣ በ PVS-Studio ሰነዶች ለምርመራዎች V559 (CWE-481) የሚከተለው መስመር ትክክል እና ደህንነቱ የተጠበቀ እንደሆነ ተደርጎ እንደሚቆጠር በግልፅ ተጽፏል፡-

if ((a = b))

ሌላ ምሳሌ። በዚህ የC++ ኮድ ተረሳ? ቆረጣ ኦር ኖት?

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

የPVS-ስቱዲዮ ተንታኝ እዚህ ማስጠንቀቂያ ይሰጣል V796 (CWE-484). ይህ ስህተት ላይሆን ይችላል፣ በዚህ ጊዜ ባህሪውን በማከል ለተንታኙ ፍንጭ መስጠት አለብዎት [[ውድቀት]] ወይም ለምሳሌ __ባህሪ__((ውድቀት)):

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

እንደነዚህ ያሉ የኮድ ለውጦች ስህተቱን አያስተካክሉም ማለት ይቻላል. አዎ, ይህ እውነት ነው, ግን ሁለት ጠቃሚ ነገሮችን ያደርጋል. በመጀመሪያ ፣ የተንታኙ ዘገባ የውሸት አወንታዊ ውጤቶችን ያስወግዳል። በሁለተኛ ደረጃ, ኮዱ በጥገናው ውስጥ ለተሳተፉ ሰዎች የበለጠ ለመረዳት ቀላል ይሆናል. እና ይህ በጣም አስፈላጊ ነው! ለእዚህ ብቻ, ኮዱን የበለጠ ግልጽ ለማድረግ እና ለማቆየት ቀላል ለማድረግ ጥቃቅን ማሻሻያዎችን ማከናወን ጠቃሚ ነው. ተንታኙ "እረፍት" እንደሚያስፈልግ ወይም እንደሌለበት ስለማይረዳ፣ ለፕሮግራም አዘጋጆችም ግልጽ አይሆንም።

ከሳንካ ጥገናዎች እና ማሻሻያዎች በተጨማሪ፣ በግልፅ የውሸት ተንታኝ ማስጠንቀቂያዎችን ማፈን ይችላሉ። አንዳንድ ተዛማጅነት የሌላቸው ምርመራዎች ሊሰናከሉ ይችላሉ። ለምሳሌ፣ አንድ ሰው ማስጠንቀቂያዎች ከንቱ እንደሆኑ ያስባል V550 ተንሳፋፊ / ድርብ እሴቶችን ስለ ማነፃፀር። እና አንዳንዶች እንደ አስፈላጊ እና ለጥናት ብቁ ብለው ይመድቧቸዋል [7]. የትኞቹ ማስጠንቀቂያዎች ተገቢ እንደሆኑ ተደርገው የሚታዩ እና የትኞቹ ያልሆኑት በልማት ቡድኑ የሚወስኑት ነው።

የውሸት ማንቂያዎችን ለማፈን ሌሎች መንገዶች አሉ። ለምሳሌ ማክሮ ማርክ ቀደም ብሎ ተጠቅሷል። ይህ ሁሉ በሰነዱ ውስጥ በበለጠ ዝርዝር ተብራርቷል. በጣም አስፈላጊው ነገር ቀስ በቀስ እና ስልታዊ በሆነ መንገድ ከሐሰት አወንታዊ ውጤቶች ጋር ለመስራት ከቀረቡ በእነሱ ላይ ምንም ችግር እንደሌለው መረዳት ነው. አብዛኛዎቹ የማይስቡ ማስጠንቀቂያዎች ከተዋቀሩ በኋላ ይጠፋሉ፣ እና በትክክል በጥንቃቄ ጥናት የሚያስፈልጋቸው ቦታዎች እና በኮዱ ላይ አንዳንድ ለውጦች ብቻ ይቀራሉ።

እንዲሁም፣ ማንኛውም ችግሮች ከተፈጠሩ ደንበኞቻችን PVS-Studio እንዲያዘጋጁ እንረዳለን። በተጨማሪም እኛ እራሳችን የውሸት ማስጠንቀቂያዎችን ያስወገድን እና ስህተቶችን የምናስተካክልባቸው አጋጣሚዎች ነበሩ።8]. እንደዚያ ከሆነ ፣ ይህ ለተራዘመ ትብብር ይህ አማራጭ እንዲሁ ሊሆን እንደሚችል ለመጥቀስ ወሰንኩኝ :).

ራትቼት ዘዴ

የማይንቀሳቀስ ተንታኝ ማስጠንቀቂያን በማስወገድ የኮድ ጥራትን ቀስ በቀስ ለማሻሻል ሌላ አስደሳች አካሄድ አለ። ዋናው ነገር የማስጠንቀቂያዎች ቁጥር መቀነስ ብቻ ነው.

በስታቲክ ተንታኝ የተሰጡ የማስጠንቀቂያዎች ብዛት ተመዝግቧል። ጥራት ያለው በር የተዋቀረው አሁን የኦፕሬሽኖችን ቁጥር የማይጨምር ኮድ ብቻ ማስገባት ይችላሉ። በውጤቱም, ቀስ በቀስ የማንቂያዎችን ቁጥር የመቀነስ ሂደት የሚጀምረው ተንታኙን በማስተካከል እና ስህተቶችን በማስተካከል ነው.

ምንም እንኳን አንድ ሰው ትንሽ ማጭበርበር ቢፈልግ እና የጥራት በርን ለማለፍ ቢወስን በአዲሱ ኮድ ውስጥ ማስጠንቀቂያዎችን በማስወገድ ሳይሆን የድሮውን የሶስተኛ ወገን ኮድ በማሻሻል, ይህ አስፈሪ አይደለም. ሁሉም ተመሳሳይ, ራኬቱ ወደ አንድ አቅጣጫ ይሽከረከራል, እና ቀስ በቀስ ጉድለቶች ቁጥር ይቀንሳል. አንድ ሰው የራሱን አዲስ ጉድለቶች ማስተካከል ባይፈልግም, በአጎራባች ኮድ ውስጥ አንድ ነገር ማሻሻል ይኖርበታል. በአንድ ወቅት, የማስጠንቀቂያዎችን ቁጥር ለመቀነስ ቀላል መንገዶች ያበቃል, እና እውነተኛ ስህተቶች የሚስተካከሉበት ነጥብ ይመጣል.

ይህ ዘዴ በኢቫን ፖኖማርቭቭ በጣም አስደሳች በሆነ ጽሑፍ ውስጥ በበለጠ ዝርዝር ተብራርቷል ።ስህተቶችን ለማግኘት ከመጠቀም ይልቅ በሂደቱ ውስጥ የማይለዋወጥ ትንታኔን ይተግብሩ"የኮዱን ጥራት ለማሻሻል ለሚፈልግ ለማንኛውም ሰው እንዲያነቡት እመክራለሁ።

የጽሁፉ ደራሲም በዚህ ርዕስ ላይ ዘገባ አለው፡ "ቀጣይነት ያለው የማይንቀሳቀስ ትንተና".

መደምደሚያ

ከዚህ ጽሑፍ በኋላ አንባቢዎች የማይለዋወጥ የመተንተን መሳሪያዎችን የበለጠ እንደሚቀበሉ እና ወደ ልማት ሂደቱ እንዲተገበሩ እንደሚፈልጉ ተስፋ አደርጋለሁ. ማንኛውም አይነት ጥያቄ ካሎት ሁሌም ዝግጁ ነን መምከር የእኛ የማይንቀሳቀስ ተንታኝ PVS-ስቱዲዮ ተጠቃሚዎች እና በአተገባበሩ ላይ ያግዙ።

የማይለዋወጥ ትንተና በእውነት ምቹ እና ጠቃሚ ሊሆን ስለመቻሉ ሌሎች የተለመዱ ጥርጣሬዎች አሉ። "የ PVS-Studio static code analyzer ወደ ልማት ሂደት ለማስተዋወቅ ምክንያቶች" በሚለው እትም ውስጥ አብዛኛዎቹን እነዚህን ጥርጣሬዎች ለማስወገድ ሞከርኩ [9].

ስለ ትኩረትዎ እናመሰግናለን እና ይምጡ скачать እና የPVS-Studio analyzerን ይሞክሩ።

ተጨማሪ ማገናኛዎች

1. አንድሬ ካርፖቭ. የPVS-Studio analyzer ለ C እና C++ ኮድ የሚያዘጋጃቸውን አስደሳች ማስጠንቀቂያዎች በፍጥነት እንዴት ማየት እችላለሁ?
2. ውክፔዲያ. የሩዝ ጽንሰ-ሐሳብ.
3. አንድሬ ካርፖቭ ፣ ቪክቶሪያ ካኒቫ። የፕሮግራም ምንጭ ኮድ በማይለዋወጥ ትንተና የማሽን ትምህርትን መጠቀም.
4. PVS-ስቱዲዮ. ሰነድ. ተጨማሪ የምርመራ ቅንብሮች.
5. አንድሬ ካርፖቭ. የኢኤፍኤል ኮር ቤተ-መጻሕፍት ምሳሌን በመጠቀም የPVS-ስቱዲዮ ተንታኝ ባህሪያት ከ10-15% የውሸት አዎንታዊ.
6. PVS-ስቱዲዮ. ሰነድ. ተንታኝ መልዕክቶችን በጅምላ ማገድ.
7. ኢቫን አንድሪያሺን. በፕሮጀክታችን ላይ የራጅ ኢንዶቫስኩላር ቀዶ ጥገና ትምህርታዊ አስመሳይን እንዴት እንደሞከርን የማይለዋወጥ ትንታኔን እንደሞከርን.
8. Pavel Eremeev, Svyatoslav Razmyslov. የPVS-ስቱዲዮ ቡድን የእውነተኛ ሞተር ኮድን እንዴት እንዳሻሻለው.
9. አንድሬ ካርፖቭ. የስታቲክ ኮድ ተንታኝ PVS-ስቱዲዮን ወደ ልማት ሂደት የማስተዋወቅ ምክንያቶች.

ይህን ጽሑፍ ለእንግሊዝኛ ተናጋሪ ታዳሚዎች ማጋራት ከፈለጉ፣ እባክዎ የትርጉም ማያያዣውን አንድሬ ካርፖቭ ይጠቀሙ። በትሩፋት ፕሮጀክት ውስጥ የማይለዋወጥ ኮድ ተንታኝ እንዴት ማስተዋወቅ እና ቡድኑን ላለማስፈራራት.

ምንጭ: hab.com