તેની સાથે ભૂલો શોધવાને બદલે પ્રક્રિયામાં સ્થિર વિશ્લેષણનો અમલ કરો

મને આ લેખ લખવા માટે સ્થિર વિશ્લેષણ પરની મોટી સંખ્યામાં સામગ્રી દ્વારા પ્રેરિત કરવામાં આવી હતી જે વધુને વધુ સામે આવી રહી છે. પ્રથમ, આ પીવીએસ-સ્ટુડિયો બ્લોગ, જે ઓપન સોર્સ પ્રોજેક્ટ્સમાં તેમના ટૂલ દ્વારા મળેલી ભૂલોની સમીક્ષાઓ સાથે Habré પર સક્રિયપણે પોતાનો પ્રચાર કરે છે. પીવીએસ-સ્ટુડિયો તાજેતરમાં અમલમાં આવ્યો જાવા સપોર્ટ, અને, અલબત્ત, IntelliJ IDEA ના વિકાસકર્તાઓ, જેમનું બિલ્ટ-ઇન વિશ્લેષક કદાચ આજે જાવા માટે સૌથી અદ્યતન છે, દૂર રહી શક્યો નહીં.

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

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

રેચેટ (સ્રોત: વિકિપીડિયા).

સ્ટેટિક વિશ્લેષકો શું કરી શકતા નથી

વ્યવહારિક દૃષ્ટિકોણથી, સ્રોત કોડ વિશ્લેષણ શું છે? અમે કેટલાક સ્રોતોમાં ફીડ કરીએ છીએ, અને ટૂંકા સમયમાં (ચાલતા પરીક્ષણો કરતાં ખૂબ ટૂંકા) અમને અમારી સિસ્ટમ વિશે કેટલીક માહિતી મળે છે. મૂળભૂત અને ગાણિતિક રીતે દુસ્તર મર્યાદા એ છે કે આપણે આ રીતે માત્ર એક સાંકડી વર્ગની માહિતી મેળવી શકીએ છીએ.

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

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

સ્થિર વિશ્લેષણ એ ભૂલોની શોધ નથી

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

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

શું આનો અર્થ એ છે કે સ્થિર વિશ્લેષણ લાગુ ન કરવું જોઈએ? અલબત્ત નહીં! અને બરાબર એ જ કારણસર "સરળ" પાસવર્ડ્સની સ્ટોપ લિસ્ટમાં આવવા માટે દરેક નવા પાસવર્ડને તપાસવા યોગ્ય છે.

સ્થિર વિશ્લેષણ ભૂલો શોધવા કરતાં વધુ છે

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

• શબ્દના વ્યાપક અર્થમાં કોડિંગ શૈલી તપાસી રહ્યું છે. આમાં ફોર્મેટિંગ તપાસવું અને ખાલી/અતિરિક્ત કૌંસનો ઉપયોગ શોધવો, મેટ્રિક્સ પર થ્રેશોલ્ડ સેટ કરવા જેવા કે રેખાઓની સંખ્યા / સાયક્લોમેટિક પદ્ધતિ જટિલતા વગેરેનો સમાવેશ થાય છે. - બધું જે સંભવિતપણે કોડને વધુ વાંચવા યોગ્ય અને જાળવવા યોગ્ય બનાવે છે. જાવામાં આ ટૂલ ચેકસ્ટાઇલ છે, પાયથોનમાં તે flake8 છે. આ વર્ગના કાર્યક્રમોને સામાન્ય રીતે "લિંટર્સ" કહેવામાં આવે છે.
• માત્ર એક્ઝેક્યુટેબલ કોડનું જ વિશ્લેષણ કરી શકાતું નથી. JSON, YAML, XML, .properties જેવી સંસાધન ફાઇલો માન્યતા માટે આપમેળે તપાસી શકાય છે (અને જોઈએ!) શું તે શોધવાનું વધુ સારું નથી કે કેટલાક અનપેયર્ડ ક્વોટ્સને કારણે JSON માળખું પરીક્ષણો ચલાવતી વખતે અથવા રન ટાઇમ કરતાં સ્વચાલિત પુલ વિનંતી માન્યતાના પ્રારંભિક તબક્કે તૂટી ગયું છે? યોગ્ય સાધનો ઉપલબ્ધ છે: ઉદાહરણ તરીકે, YAMLlint, JSONLint.
• સંકલન (અથવા ગતિશીલ પ્રોગ્રામિંગ ભાષાઓ માટે પાર્સિંગ) પણ એક પ્રકારનું સ્થિર વિશ્લેષણ છે. એક નિયમ તરીકે, કમ્પાઇલર્સ ચેતવણીઓ આપવા માટે સક્ષમ છે જે સ્રોત કોડની ગુણવત્તા સાથે સમસ્યાઓ સૂચવે છે, અને તેમને અવગણવા જોઈએ નહીં.
• કેટલીકવાર સંકલન એ એક્ઝેક્યુટેબલ કોડનું સંકલન કરતાં વધુ હોય છે. ઉદાહરણ તરીકે, જો તમારી પાસે ફોર્મેટમાં દસ્તાવેજીકરણ છે એસીસી ડોક્ટર, પછી તે HTML/PDF હેન્ડલર AsciiDoctor માં પરિવર્તનની ક્ષણે (મેવેન પ્લગઇન) ચેતવણીઓ આપી શકે છે, ઉદાહરણ તરીકે, તૂટેલી આંતરિક લિંક્સ વિશે. અને દસ્તાવેજીકરણના ફેરફારો સાથે પુલ વિનંતીને ન સ્વીકારવાનું આ એક સારું કારણ છે.
• જોડણી તપાસ એ પણ સ્થિર વિશ્લેષણનો એક પ્રકાર છે. ઉપયોગિતા એસ્પેલ માત્ર દસ્તાવેજીકરણમાં જ નહીં, પણ C/C++, Java અને Python સહિત વિવિધ પ્રોગ્રામિંગ ભાષાઓમાં પ્રોગ્રામ સોર્સ કોડ (ટિપ્પણીઓ અને શાબ્દિક) માં પણ જોડણી તપાસવામાં સક્ષમ છે. વપરાશકર્તા ઈન્ટરફેસ અથવા દસ્તાવેજીકરણમાં જોડણીની ભૂલ એ પણ ખામી છે!
• રૂપરેખાંકન પરીક્ષણો (તે શું છે તે માટે, જુઓ આ и આ અહેવાલો), જો કે તેઓ પાયટેસ્ટ જેવા યુનિટ ટેસ્ટ રનટાઈમમાં એક્ઝિક્યુટ કરવામાં આવે છે, તેઓ વાસ્તવમાં એક પ્રકારનું સ્ટેટિક એનાલિસિસ પણ છે, કારણ કે તેઓ તેમના અમલ દરમિયાન સોર્સ કોડનો અમલ કરતા નથી.

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

તમારા પ્રોજેક્ટમાં આમાંથી કયા પ્રકારના સ્ટેટિક એનાલિસિસનો ઉપયોગ કરવો જોઈએ? અલબત્ત, વધુ, વધુ સારું! મુખ્ય વસ્તુ તેને યોગ્ય રીતે અમલમાં મૂકવાનું છે, જેની આગળ ચર્ચા કરવામાં આવશે.

મલ્ટી-સ્ટેજ ફિલ્ટર તરીકે ડિલિવરી પાઇપલાઇન અને તેના પ્રથમ કાસ્કેડ તરીકે સ્થિર વિશ્લેષણ

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

1. સ્થિર વિશ્લેષણ
2. ઓ
3. એકમ પરીક્ષણો
4. એકીકરણ પરીક્ષણો
5. UI પરીક્ષણો
6. મેન્યુઅલ તપાસ

પાઈપલાઈનના Nth તબક્કામાં નકારવામાં આવેલ ફેરફારો સ્ટેજ N+1 પર પ્રચારિત કરવામાં આવતા નથી.

શા માટે બરાબર આ રીતે અને અન્યથા નહીં? પાઇપલાઇનના પરીક્ષણ ભાગમાં, પરીક્ષકો જાણીતા પરીક્ષણ પિરામિડને ઓળખશે.

ટેસ્ટ પિરામિડ. સ્ત્રોત: લેખ માર્ટિન ફાઉલર.

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

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

મલ્ટિ-સ્ટેજ ફિલ્ટર. સ્ત્રોત: Wikimedia Commons નો ભાગ

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

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

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

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

લેગસી પ્રોજેક્ટમાં અમલીકરણ

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

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

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

ગુણવત્તાવાળા દરવાજા રજૂ કરવાની નીચેની રીતો જાણીતી છે:

• ચેતવણીઓની કુલ સંખ્યા અથવા કોડની રેખાઓની સંખ્યા દ્વારા વિભાજિત ચેતવણીઓની સંખ્યા પર મર્યાદા સેટ કરે છે. આ સારી રીતે કામ કરતું નથી, કારણ કે આવા દરવાજો તેમની મર્યાદા ઓળંગી ન જાય ત્યાં સુધી નવી ખામીઓ સાથે ફેરફારોને મુક્તપણે છોડી દે છે.
• અમુક સમયે, કોડમાંની તમામ જૂની ચેતવણીઓને અવગણવામાં આવી રહી હોય તે રીતે ફિક્સ કરવું, અને જ્યારે નવી ચેતવણીઓ આવે ત્યારે બિલ્ડ નિષ્ફળ થવું. આ કાર્યક્ષમતા PVS-studio અને કોડસી જેવા કેટલાક ઑનલાઇન સંસાધનો દ્વારા પ્રદાન કરવામાં આવે છે. મને પીવીએસ-સ્ટુડિયોમાં કામ કરવાની તક મળી ન હતી, કોડસી સાથેના મારા અનુભવ માટે, તેમની મુખ્ય સમસ્યા એ છે કે "જૂની" શું છે અને "નવી" ભૂલ શું છે તેની વ્યાખ્યા એ એક જટિલ અલ્ગોરિધમ છે જે નથી કરતું. હંમેશા યોગ્ય રીતે કાર્ય કરો, ખાસ કરીને જો ફાઇલોમાં ભારે ફેરફાર અથવા નામ બદલવામાં આવ્યા હોય. મારી યાદમાં, કોડસી પુલ વિનંતીમાં નવી ચેતવણીઓને છોડી શકતી નથી, અને તે જ સમયે ચેતવણીઓને કારણે પુલ વિનંતીને અવગણી શકતી નથી જે આ 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 સ્ક્રિપ્ટમાં ફક્ત જરૂરી તર્કની નોંધણી કરવાનું બાકી છે. જેનકિન્સ અને આર્ટિફેક્ટરી પર આધારિત અમારા ઓપન સોર્સ પ્રોજેક્ટ્સમાં આનો અમલ કેવી રીતે થાય છે તે તમે જોઈ શકો છો, તમે અહીં અથવા અહીં. બંને ઉદાહરણો પુસ્તકાલય આધારિત છે ratchetlib: પદ્ધતિ countWarnings() ચેકસ્ટાઇલ અને સ્પોટબગ્સ દ્વારા સામાન્ય રીતે જનરેટ કરાયેલ ફાઇલોમાં xml ટૅગ્સની ગણતરી કરે છે, અને compareWarningMaps() સમાન રેચેટને લાગુ કરે છે, જ્યારે કોઈપણ કેટેગરીમાં ચેતવણીઓની સંખ્યા વધે ત્યારે ભૂલ ફેંકે છે.

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

વિશ્લેષક સંસ્કરણને ઠીક કરવાના મહત્વ વિશે

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

તારણો

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

સંદર્ભો

1. સતત ડિલિવરી
2. A. કુદ્ર્યાવત્સેવ: પ્રોગ્રામ વિશ્લેષણ: કેવી રીતે સમજવું કે તમે સારા પ્રોગ્રામર છો કોડ વિશ્લેષણની વિવિધ પદ્ધતિઓ પર અહેવાલ (માત્ર સ્થિર જ નહીં!)

સોર્સ: www.habr.com