ટીમને ડિમોટિવેટ કર્યા વિના લેગસી પ્રોજેક્ટમાં સ્ટેટિક કોડ વિશ્લેષકને કેવી રીતે અમલમાં મૂકવું

સ્ટેટિક કોડ વિશ્લેષકનો પ્રયાસ કરવો સરળ છે. પરંતુ તેનો અમલ કરવા માટે, ખાસ કરીને મોટા જૂના પ્રોજેક્ટના વિકાસમાં, કૌશલ્યની જરૂર છે. જો ખોટી રીતે કરવામાં આવે તો, વિશ્લેષક કાર્ય ઉમેરી શકે છે, વિકાસને ધીમું કરી શકે છે અને ટીમને નિરાશ કરી શકે છે. ચાલો સંક્ષિપ્તમાં વાત કરીએ કે વિકાસ પ્રક્રિયામાં સ્થિર વિશ્લેષણના એકીકરણનો યોગ્ય રીતે સંપર્ક કેવી રીતે કરવો અને તેનો ઉપયોગ CI/CD ના ભાગ રૂપે શરૂ કરવો.

પરિચય

તાજેતરમાં મારું ધ્યાન પ્રકાશન તરફ દોરવામાં આવ્યું હતું "ટીમને જબરજસ્ત કર્યા વિના સ્થિર વિશ્લેષણ સાથે પ્રારંભ કરવું". એક તરફ, આ એક સારો લેખ છે જેની સાથે પરિચિત થવા યોગ્ય છે. બીજી બાજુ, મને લાગે છે કે તે હજી પણ ઘણા બધા પ્રોજેક્ટમાં સ્થિર વિશ્લેષણ કેવી રીતે પીડારહિત રીતે અમલમાં મૂકવું તે અંગે સંપૂર્ણ જવાબ પ્રદાન કરતું નથી. લેગસી કોડનો. લેખ કહે છે કે તમે તકનીકી દેવું સ્વીકારી શકો છો અને ફક્ત નવા કોડ પર જ કામ કરી શકો છો, પરંતુ પછીથી આ તકનીકી દેવુંનું શું કરવું તે અંગે કોઈ જવાબ નથી.

અમારી PVS-Studio ટીમ આ વિષય પર પોતાનો અભિપ્રાય આપે છે. ચાલો જોઈએ કે સ્ટેટિક કોડ વિશ્લેષકને અમલમાં મૂકવાની સમસ્યા પ્રથમ સ્થાને કેવી રીતે ઊભી થાય છે, આ સમસ્યાને કેવી રીતે દૂર કરવી અને કેવી રીતે પીડારહિત રીતે ધીમે ધીમે તકનીકી દેવું દૂર કરવું.

મુદ્દાઓ

સ્ટેટિક વિશ્લેષક કેવી રીતે કાર્ય કરે છે તે લોંચ કરવું અને જોવાનું સામાન્ય રીતે મુશ્કેલ નથી [1]. તમે કોડમાં રસપ્રદ ભૂલો અથવા ડરામણી સંભવિત નબળાઈઓ પણ જોઈ શકો છો. તમે કંઈક ઠીક પણ કરી શકો છો, પરંતુ પછી ઘણા પ્રોગ્રામરો છોડી દે છે.

બધા સ્થિર વિશ્લેષકો ખોટા હકારાત્મક પેદા કરે છે. આ સ્ટેટિક કોડ પૃથ્થકરણ પદ્ધતિનું લક્ષણ છે, અને તેના વિશે કશું કરી શકાતું નથી. સામાન્ય કિસ્સામાં, આ એક વણઉકેલાયેલી સમસ્યા છે, જે ચોખાના પ્રમેય દ્વારા પુષ્ટિ મળે છે.2]. મશીન લર્નિંગ અલ્ગોરિધમ્સ પણ મદદ કરશે નહીં [3]. જો કોઈ વ્યક્તિ હંમેશા કહી શકતી નથી કે આ અથવા તે કોડ ખોટો છે, તો તમારે પ્રોગ્રામમાંથી આની અપેક્ષા રાખવી જોઈએ નહીં :).

જો સ્ટેટિક વિશ્લેષક પહેલેથી ગોઠવેલું હોય તો ખોટા હકારાત્મક કોઈ સમસ્યા નથી:

• અક્ષમ અપ્રસ્તુત નિયમ સેટ;
• કેટલાક અપ્રસ્તુત ડાયગ્નોસ્ટિક્સ અક્ષમ કરવામાં આવ્યા છે;
• જો આપણે C અથવા C++ વિશે વાત કરી રહ્યા છીએ, તો મેક્રો માર્ક અપ કરવામાં આવે છે જેમાં ચોક્કસ રચનાઓ હોય છે જે દરેક જગ્યાએ જ્યાં આવા મેક્રોનો ઉપયોગ કરવામાં આવે છે ત્યાં નકામી ચેતવણીઓ દેખાય છે;
• પોતાના કાર્યોને ચિહ્નિત કરવામાં આવે છે જે સિસ્ટમ કાર્યો (તેના પોતાના એનાલોગ) જેવી જ ક્રિયાઓ કરે છે મેમ્પી અથવા printf) [4];
• ખોટા હકારાત્મક ખાસ કરીને ટિપ્પણીઓનો ઉપયોગ કરીને અક્ષમ કરવામાં આવે છે;
• અને તેથી.

આ કિસ્સામાં, અમે લગભગ 10-15% ના નીચા ખોટા હકારાત્મક દરની અપેક્ષા રાખી શકીએ છીએ [5]. બીજા શબ્દોમાં કહીએ તો, 9 માંથી 10 વિશ્લેષક ચેતવણી કોડમાં વાસ્તવિક સમસ્યા અથવા ઓછામાં ઓછા "ગંધવાળો કોડ" સૂચવે છે. સંમત થાઓ, આ દૃશ્ય અત્યંત સુખદ છે, અને વિશ્લેષક પ્રોગ્રામરનો વાસ્તવિક મિત્ર છે.

વાસ્તવમાં, મોટા પ્રોજેક્ટમાં, પ્રારંભિક ચિત્ર સંપૂર્ણપણે અલગ હશે. વિશ્લેષક લેગસી કોડ માટે સેંકડો અથવા હજારો ચેતવણીઓ આપે છે. આમાંથી કઈ ચેતવણીઓ સંબંધિત છે અને કઈ નથી તે ઝડપથી સમજવું અશક્ય છે. નીચે બેસીને આ બધી ચેતવણીઓ સાથે વ્યવહાર કરવાનું શરૂ કરવું અતાર્કિક છે, કારણ કે આ કિસ્સામાં મુખ્ય કાર્ય દિવસો કે અઠવાડિયા માટે બંધ થઈ જશે. સામાન્ય રીતે, ટીમ આવા દૃશ્ય પરવડી શકે નહીં. બદલાવના ઇતિહાસને બગાડતી મોટી સંખ્યામાં તફાવતો પણ હશે. અને કોડમાંના ઘણા ટુકડાઓનું ઝડપી સામૂહિક સંપાદન અનિવાર્યપણે નવી ટાઇપો અને ભૂલોમાં પરિણમશે.

અને સૌથી અગત્યનું, ચેતવણીઓ સામેની લડતમાં આવા પરાક્રમનો થોડો અર્થ નથી. સંમત થાઓ કે પ્રોજેક્ટ ઘણા વર્ષોથી સફળતાપૂર્વક ચાલી રહ્યો હોવાથી, તેમાંની મોટાભાગની ગંભીર ભૂલો પહેલાથી જ સુધારી લેવામાં આવી છે. હા, આ સુધારાઓ ખૂબ ખર્ચાળ હતા, ડીબગ કરવા પડ્યા હતા, ભૂલો વિશે નકારાત્મક વપરાશકર્તા પ્રતિસાદ પ્રાપ્ત થયો હતો, વગેરે. સ્ટેટિક વિશ્લેષક આમાંની ઘણી ભૂલોને કોડિંગ સ્ટેજ પર ઝડપથી અને સસ્તામાં ઠીક કરવામાં મદદ કરશે. પરંતુ આ ક્ષણે, એક રીતે અથવા બીજી રીતે, આ ભૂલોને ઠીક કરવામાં આવી છે, અને વિશ્લેષક મુખ્યત્વે જૂના કોડમાં બિન-જટિલ ભૂલોને શોધી કાઢે છે. આ કોડનો ઉપયોગ કરી શકાતો નથી, તે ખૂબ જ ભાગ્યે જ ઉપયોગમાં લેવાય છે, અને તેમાં ભૂલ ધ્યાનપાત્ર પરિણામો તરફ દોરી શકે નહીં. કદાચ ક્યાંક બટનમાંથી પડછાયો ખોટો રંગ છે, પરંતુ આ કોઈના ઉત્પાદનના ઉપયોગમાં દખલ કરતું નથી.

અલબત્ત, નાની ભૂલો પણ ભૂલો જ છે. અને કેટલીકવાર ભૂલ વાસ્તવિક નબળાઈને છુપાવી શકે છે. જો કે, બધું છોડી દેવું અને ખામીઓ સાથે વ્યવહાર કરવામાં દિવસો/સપ્તાહ ગાળવા જે ભાગ્યે જ પોતાને પ્રગટ કરે છે તે શંકાસ્પદ વિચાર જેવું લાગે છે.

પ્રોગ્રામર્સ જુએ છે, જુએ છે, જુએ છે, જૂના વર્કિંગ કોડ વિશેની આ બધી ચેતવણીઓ... અને તેઓ વિચારે છે: આપણે સ્થિર વિશ્લેષણ વિના કરી શકીએ છીએ. ચાલો કેટલીક નવી ઉપયોગી કાર્યક્ષમતા લખીએ.

તેમની પોતાની રીતે, તેઓ સાચા છે. તેઓ માને છે કે પહેલા તેઓએ આ બધી ચેતવણીઓમાંથી કોઈક રીતે છુટકારો મેળવવો પડશે. તો જ તેઓ કોડ વિશ્લેષકના નિયમિત ઉપયોગથી લાભ મેળવી શકશે. નહિંતર, નવી ચેતવણીઓ ફક્ત જૂનીમાં ડૂબી જશે, અને કોઈ તેમના પર ધ્યાન આપશે નહીં.

આ કમ્પાઇલર ચેતવણીઓ જેવી જ સમાનતા છે. તે કારણ વિના નથી કે તેઓ કમ્પાઈલર ચેતવણીઓની સંખ્યા 0 પર રાખવાની ભલામણ કરે છે. જો ત્યાં 1000 ચેતવણીઓ હોય, તો જ્યારે 1001 હશે, ત્યારે કોઈ તેના પર ધ્યાન આપશે નહીં, અને આ નવી ચેતવણી ક્યાં શોધવી તે સ્પષ્ટ નથી.

આ વાર્તામાં સૌથી ખરાબ બાબત એ છે કે જો આ ક્ષણે ઉપરથી કોઈ તમને સ્ટેટિક કોડ વિશ્લેષણનો ઉપયોગ કરવા દબાણ કરે છે. આ ફક્ત ટીમને નિરાશ કરશે, કારણ કે તેમના દૃષ્ટિકોણથી ત્યાં વધારાની અમલદારશાહી જટિલતા હશે જે ફક્ત માર્ગમાં આવે છે. વિશ્લેષકના અહેવાલો પર કોઈ જોશે નહીં, અને તમામ ઉપયોગ ફક્ત "કાગળ પર" હશે. તે. ઔપચારિક રીતે, વિશ્લેષણને DevOps પ્રક્રિયામાં બાંધવામાં આવે છે, પરંતુ વ્યવહારમાં આનાથી કોઈને ફાયદો થતો નથી. અમે પરિષદના પ્રતિભાગીઓ પાસેથી બૂથ પર વિગતવાર વાર્તાઓ સાંભળી. આવો અનુભવ પ્રોગ્રામરોને લાંબા સમય સુધી સ્થિર વિશ્લેષણ સાધનોનો ઉપયોગ કરવાથી નિરાશ કરી શકે છે, જો કાયમ માટે નહીં.

અમલીકરણ અને તકનીકી દેવું દૂર કરવું

વાસ્તવમાં, મોટા જૂના પ્રોજેક્ટમાં પણ સ્ટેટિક એનાલિસિસની રજૂઆત કરવામાં કંઈ મુશ્કેલ કે ડરામણી નથી.

સીઆઈ / સીડી

તદુપરાંત, વિશ્લેષકને તરત જ સતત વિકાસ પ્રક્રિયાનો ભાગ બનાવી શકાય છે. ઉદાહરણ તરીકે, PVS-Studio વિતરણમાં તમને જોઈતા ફોર્મેટમાં રિપોર્ટને સરળતાથી જોવા માટેની ઉપયોગિતાઓ અને કોડના સમસ્યારૂપ વિભાગો લખનારા વિકાસકર્તાઓને સૂચનાઓ શામેલ છે. જેઓ CI/CD સિસ્ટમ્સમાંથી PVS-Studio લોન્ચ કરવામાં વધુ રસ ધરાવે છે, હું ભલામણ કરું છું કે તમે તમારી જાતને અનુરૂપ સાથે પરિચિત થાઓ વિભાગ દસ્તાવેજીકરણ અને લેખોની શ્રેણી:

• PVS-સ્ટુડિયો વાદળોમાં જાય છે: Azure Devops
• પીવીએસ-સ્ટુડિયો વાદળોમાં જાય છે: ટ્રેવિસ સીઆઈ
• PVS-સ્ટુડિયો વાદળો પર જાય છે: GitLab CI/CD
• PVS-સ્ટુડિયો વાદળોમાં જાય છે: CircleCI

પરંતુ ચાલો કોડ વિશ્લેષણ સાધનોના અમલીકરણના પ્રથમ તબક્કામાં મોટી સંખ્યામાં ખોટા હકારાત્મક મુદ્દાઓ પર પાછા ફરીએ.

હાલના ટેકનિકલ દેવુંને ઠીક કરવું અને નવી ચેતવણીઓ સાથે કામ કરવું

આધુનિક વ્યાપારી સ્થિર વિશ્લેષકો તમને ફક્ત નવી ચેતવણીઓનો અભ્યાસ કરવાની મંજૂરી આપે છે જે નવા અથવા બદલાયેલા કોડમાં દેખાય છે. આ મિકેનિઝમનું અમલીકરણ બદલાય છે, પરંતુ સાર એ જ છે. પીવીએસ-સ્ટુડિયો સ્ટેટિક વિશ્લેષકમાં, આ કાર્યક્ષમતા નીચે પ્રમાણે અમલમાં મૂકવામાં આવે છે.

સ્ટેટિક એનાલિસિસનો ઝડપથી ઉપયોગ શરૂ કરવા માટે, અમે PVS-સ્ટુડિયો વપરાશકર્તાઓને ચેતવણીઓના સામૂહિક દમન માટે મિકેનિઝમનો ઉપયોગ કરવાનું સૂચન કરીએ છીએ.6]. સામાન્ય વિચાર નીચે મુજબ છે. વપરાશકર્તાએ વિશ્લેષક લોન્ચ કર્યું અને ઘણી ચેતવણીઓ પ્રાપ્ત કરી. એક પ્રોજેક્ટ કે જે ઘણા વર્ષોથી વિકાસમાં છે તે જીવંત છે, વિકાસશીલ છે અને પૈસા કમાય છે, તો સંભવતઃ રિપોર્ટમાં ગંભીર ખામીઓ દર્શાવતી ઘણી ચેતવણીઓ હશે નહીં. બીજા શબ્દોમાં કહીએ તો, વધુ ખર્ચાળ પદ્ધતિઓનો ઉપયોગ કરીને અથવા ગ્રાહકોના પ્રતિસાદને આભારી નિર્ણાયક ભૂલો પહેલેથી જ એક અથવા બીજી રીતે ઠીક કરવામાં આવી છે. તદનુસાર, વિશ્લેષક હાલમાં જે શોધે છે તે બધું તકનીકી દેવું ગણી શકાય, જે તાત્કાલિક દૂર કરવાનો પ્રયાસ કરવો અવ્યવહારુ છે.

તમે PVS-સ્ટુડિયોને આ ચેતવણીઓને હાલ માટે અપ્રસ્તુત ગણવા માટે કહી શકો છો (પછી માટે તકનીકી દેવું સાચવો), અને તે હવે તેમને બતાવશે નહીં. વિશ્લેષક એક વિશિષ્ટ ફાઇલ બનાવે છે જ્યાં તે ભૂલો વિશેની માહિતી સાચવે છે જે હજી સુધી રસપ્રદ નથી. અને હવે PVS-Studio માત્ર નવા અથવા બદલાયેલા કોડ માટે જ ચેતવણીઓ આપશે. તદુપરાંત, આ બધું ચતુરાઈથી અમલમાં મૂકવામાં આવે છે. જો, ઉદાહરણ તરીકે, સ્રોત કોડ ફાઇલની શરૂઆતમાં ખાલી લાઇન ઉમેરવામાં આવે છે, તો વિશ્લેષક સમજે છે કે, હકીકતમાં, કંઈપણ બદલાયું નથી, અને તે શાંત રહેવાનું ચાલુ રાખશે. આ માર્કઅપ ફાઇલને વર્ઝન કંટ્રોલ સિસ્ટમમાં મૂકી શકાય છે. ફાઇલ મોટી છે, પરંતુ આ કોઈ સમસ્યા નથી, કારણ કે તેને વારંવાર સંગ્રહિત કરવાનો કોઈ અર્થ નથી.

હવે બધા પ્રોગ્રામરો ફક્ત નવા અથવા બદલાયેલા કોડને લગતી ચેતવણીઓ જોશે. આમ, તમે વિશ્લેષકનો ઉપયોગ શરૂ કરી શકો છો, જેમ કે તેઓ કહે છે, બીજા દિવસથી. અને તમે પછીથી તકનીકી દેવા પર પાછા આવી શકો છો, અને ધીમે ધીમે ભૂલોને સુધારી શકો છો અને વિશ્લેષકને ગોઠવી શકો છો.

તેથી, મોટા જૂના પ્રોજેક્ટમાં વિશ્લેષકના અમલીકરણની પ્રથમ સમસ્યા હલ થઈ ગઈ છે. હવે ચાલો જાણીએ કે ટેકનિકલ દેવું સાથે શું કરવું.

બગ ફિક્સ અને રિફેક્ટરિંગ

સૌથી સરળ અને સૌથી કુદરતી બાબત એ છે કે મોટા પાયે દબાયેલી વિશ્લેષક ચેતવણીઓનું વિશ્લેષણ કરવા માટે થોડો સમય ફાળવવો અને ધીમે ધીમે તેમની સાથે વ્યવહાર કરવો. ક્યાંક તમારે કોડમાંની ભૂલો ઠીક કરવી જોઈએ, ક્યાંક તમારે વિશ્લેષકને કહેવા માટે રિફેક્ટર કરવું જોઈએ કે કોડ સમસ્યારૂપ નથી. સરળ ઉદાહરણ:

if (a = b)

મોટાભાગના C++ કમ્પાઇલર્સ અને વિશ્લેષકો આવા કોડ વિશે ફરિયાદ કરે છે, કારણ કે ત્યાં ઉચ્ચ સંભાવના છે કે તેઓ ખરેખર લખવા માંગતા હતા (a == b). પરંતુ ત્યાં એક અસ્પષ્ટ કરાર છે, અને આ સામાન્ય રીતે દસ્તાવેજીકરણમાં નોંધવામાં આવે છે, જો ત્યાં વધારાના કૌંસ હોય, તો પછી એવું માનવામાં આવે છે કે પ્રોગ્રામરે ઇરાદાપૂર્વક આવો કોડ લખ્યો છે, અને શપથ લેવાની જરૂર નથી. ઉદાહરણ તરીકે, ડાયગ્નોસ્ટિક્સ માટે 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-Studio ના વપરાશકર્તાઓ અને તેના અમલીકરણમાં મદદ કરે છે.

સ્થિર વિશ્લેષણ ખરેખર અનુકૂળ અને ઉપયોગી હોઈ શકે છે કે કેમ તે અંગે અન્ય લાક્ષણિક શંકાઓ છે. મેં આમાંની મોટાભાગની શંકાઓને "વિકાસ પ્રક્રિયામાં PVS-Studio સ્ટેટિક કોડ વિશ્લેષક દાખલ કરવાના કારણો" પ્રકાશનમાં દૂર કરવાનો પ્રયાસ કર્યો [9].

તમારા ધ્યાન બદલ આભાર અને આવો скачать અને PVS-સ્ટુડિયો વિશ્લેષકનો પ્રયાસ કરો.

વધારાની લિંક્સ

1. આન્દ્રે કાર્પોવ. PVS-સ્ટુડિયો વિશ્લેષક C અને C++ કોડ માટે બનાવેલી રસપ્રદ ચેતવણીઓ હું ઝડપથી કેવી રીતે જોઈ શકું?
2. વિકિપીડિયા ચોખાનું પ્રમેય.
3. આન્દ્રે કાર્પોવ, વિક્ટોરિયા ખાનીએવા. પ્રોગ્રામ સોર્સ કોડના સ્થિર વિશ્લેષણમાં મશીન લર્નિંગનો ઉપયોગ.
4. પીવીએસ-સ્ટુડિયો. દસ્તાવેજીકરણ. વધારાના ડાયગ્નોસ્ટિક સેટિંગ્સ.
5. આન્દ્રે કાર્પોવ. EFL કોર લાઇબ્રેરીના ઉદાહરણનો ઉપયોગ કરીને PVS-સ્ટુડિયો વિશ્લેષકની લાક્ષણિકતાઓ, 10-15% ખોટા હકારાત્મક.
6. પીવીએસ-સ્ટુડિયો. દસ્તાવેજીકરણ. વિશ્લેષક સંદેશાઓનું સામૂહિક દમન.
7. ઇવાન એન્ડ્ર્યાશિન. એક્સ-રે એન્ડોવાસ્ક્યુલર સર્જરીના શૈક્ષણિક સિમ્યુલેટરના અમારા પ્રોજેક્ટ પર અમે સ્ટેટિક એનાલિસિસનું પરીક્ષણ કેવી રીતે કર્યું તે વિશે.
8. પાવેલ Eremeev, Svyatoslav Razmyslov. PVS-Studio ટીમે કેવી રીતે અવાસ્તવિક એન્જિન કોડમાં સુધારો કર્યો.
9. આન્દ્રે કાર્પોવ. વિકાસ પ્રક્રિયામાં સ્ટેટિક કોડ વિશ્લેષક PVS-સ્ટુડિયો દાખલ કરવાના કારણો.

જો તમે આ લેખ અંગ્રેજી બોલતા પ્રેક્ષકો સાથે શેર કરવા માંગતા હો, તો કૃપા કરીને અનુવાદ લિંકનો ઉપયોગ કરો: એન્ડ્રી કાર્પોવ. લેગસી પ્રોજેક્ટમાં સ્ટેટિક કોડ વિશ્લેષક કેવી રીતે રજૂ કરવું અને ટીમને નિરાશ ન કરવા.

સોર્સ: www.habr.com