Apache Hadoop कोड गुणवत्ता: उत्पादन VS परीक्षण

उच्च-गुणवत्ता वाले उत्पादन कोड प्राप्त करने के लिए, यह केवल अधिकतम परीक्षण कवरेज प्रदान करने के लिए पर्याप्त नहीं है। निस्संदेह, उच्च परिणाम प्राप्त करने के लिए, मुख्य परियोजना कोड और परीक्षणों को पूरी तरह से एक साथ मिलकर काम करना होगा। इसलिए, आपको मुख्य कोड के रूप में परीक्षणों पर ध्यान देने की आवश्यकता है। एक अच्छा परीक्षण लिखना उत्पादन में प्रतिगमन को पकड़ने की कुंजी है। इस तथ्य के महत्व को दिखाने के लिए कि परीक्षणों में बग्स उत्पादन से बदतर नहीं हैं, हम पीवीएस-स्टूडियो स्थैतिक विश्लेषक से चेतावनी के अगले विश्लेषण पर विचार करेंगे। लक्ष्य: अपाचे Hadoop।

परियोजना के बारे में

जो लोग कभी बिग डेटा में रुचि रखते थे, उन्होंने शायद अपाचे हडोप जैसी परियोजना के बारे में सुना या काम किया है। संक्षेप में, Hadoop एक ढांचा है जिसका उपयोग बिग डेटा सिस्टम बनाने और उनके साथ काम करने के लिए आधार के रूप में किया जा सकता है।

Hadoop में चार मुख्य मॉड्यूल होते हैं, जिनमें से प्रत्येक एक बड़े डेटा एनालिटिक्स सिस्टम के लिए आवश्यक विशिष्ट कार्य करता है:

• Hadoop आम
• MapReduce
• Hadoop वितरित फ़ाइल सिस्टम (Hadoop वितरित फ़ाइल सिस्टम)
• यार्न

हालांकि, इंटरनेट पर इसके साथ खुद को परिचित करने के लिए बहुत सारी सामग्रियां हैं।

सत्यापन के बारे में

प्रलेखन में दिखाया गया है, पीवीएस-स्टूडियो को परियोजना में विभिन्न तरीकों से एकीकृत किया जा सकता है:

• मावेन प्लगइन का उपयोग करना;
• ग्रेडल प्लगइन का उपयोग करना;
• IntellJ IDEA का उपयोग करना
• सीधे विश्लेषक का उपयोग करना।

Hadoop को maven build system के आधार पर बनाया गया था, इसलिए सत्यापन में कोई कठिनाई नहीं हुई।

प्रलेखन से स्क्रिप्ट को एकीकृत करने और pom.xml में से एक को थोड़ा ठीक कर दिया (निर्भरता में मॉड्यूल थे कि वहां नहीं थे), विश्लेषण चला गया!

विश्लेषण के बाद, सबसे दिलचस्प चेतावनियों को चुनते हुए, मैंने देखा कि मेरे पास उत्पादन कोड और परीक्षणों दोनों में समान संख्या में चेतावनी थी। आमतौर पर, मैं विश्लेषक ट्रिगर पर विचार नहीं करता हूं जो परीक्षणों पर पड़ता है। लेकिन, उन्हें विभाजित करते हुए, मैं अपना ध्यान पिछले 'परीक्षण' श्रेणी से चेतावनियों को याद नहीं कर सका। "क्यों नहीं?" मैंने सोचा, क्योंकि परीक्षणों में बग के परिणाम भी होते हैं। वे गलत या आंशिक परीक्षण या यहां तक ​​कि बकवास के लिए नेतृत्व कर सकते हैं (सिर्फ दिखाने के लिए, ताकि वे हमेशा हरे रहें)।

इसलिए, कोड (उत्पादन, परीक्षण) और चार मुख्य Hadoop मॉड्यूल द्वारा उन्हें विभाजित करते हुए, सबसे दिलचस्प चेतावनियाँ एकत्र की हैं, मैं आपके ध्यान में विश्लेषक के संचालन का विश्लेषण लाता हूं।

उत्पादन कोड

Hadoop आम

V6033 समान कुंजी 'KDC_BIND_ADDRESS' के साथ एक आइटम पहले ही जोड़ा जा चुका है। MiniKdc.java (163), MiniKdc.java (162)

public class MiniKdc { .... private static final Set<String> PROPERTIES = new HashSet<String>(); .... static { PROPERTIES.add(ORG_NAME); PROPERTIES.add(ORG_DOMAIN); PROPERTIES.add(KDC_BIND_ADDRESS); PROPERTIES.add(KDC_BIND_ADDRESS); // <= PROPERTIES.add(KDC_PORT); PROPERTIES.add(INSTANCE); .... } .... } 

परियोजनाओं की जाँच करते समय एक हाशसेट में दो बार जोड़ा गया मूल्य एक सामान्य दोष है। वास्तव में, दूसरे जोड़ को नजरअंदाज कर दिया जाएगा। खैर, अगर यह दोहराव एक बेतुका दुर्घटना है। लेकिन क्या होगा अगर यह वास्तव में एक और मूल्य जोड़ने का मतलब है?

MapReduce

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'लोकलफेयर' के बजाय 'लोकलफाइल्स' चर का उपयोग किया जाना चाहिए। LocalDistributedCacheManager.java (183), LocalDistributedCacheManager.java (178), LocalDistributedCacheManager.java (176), LocalDistributedCacheManager.java (181)

 public synchronized void setup(JobConf conf, JobID jobId) throws IOException { .... // Update the configuration object with localized data. if (!localArchives.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALARCHIVES, StringUtils .arrayToString(localArchives.toArray(new String[localArchives // <= .size()]))); } if (!localFiles.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALFILES, StringUtils .arrayToString(localFiles.toArray(new String[localArchives // <= .size()]))); } .... } 

डायग्नोस्टिक्स V6072 कभी-कभी बहुत दिलचस्प निष्कर्ष निकालता है। डायग्नोस्टिक्स का सार एक ही प्रकार के कोड अंशों की खोज करना है जो कॉपी-पेस्ट और एक या दो चर की जगह ले रहे थे, लेकिन एक ही समय में कुछ चर "कम करके आंका" गए थे।

उपरोक्त कोड यह प्रदर्शित करता है। पहले ब्लॉक में, स्थानीयश्रेणी चर के साथ, उसी प्रकार के अगले ब्लॉक में लोकलफाइल्स के साथ कार्रवाई की जाती है । और अगर आप कर्तव्यनिष्ठा से इस कोड का अध्ययन करते हैं, और जल्दी से इस पर नहीं जाते हैं, जैसा कि अक्सर कोड की समीक्षा के साथ होता है, तो उस स्थान पर ध्यान दें जहां आप स्थानीयर्च चर को बदलना भूल गए थे।

इस तरह का निरीक्षण निम्नलिखित परिदृश्य को जन्म दे सकता है:

• मान लें कि हमारे पास स्थानीय आकृतियाँ (आकार = 4) और स्थानीयकृत (आकार = 2) हैं;
• जब LocalFiles.toArray सरणी (नया स्ट्रिंग [localArchives.size ()]) बनाते हैं , तो हमें अंतिम 2 तत्व शून्य होने लगते हैं (["pathToFile1", "pathToFile2", null, null]);
• उसके बाद, org.apache.hadoop.util.StringUtils.arrayToString हमारे सरणी का एक स्ट्रिंग प्रतिनिधित्व लौटाएगा जिसमें अंतिम फ़ाइल नामों को "null" ("pathToFile1, pathToFile2, null, null" ) के रूप में दर्शाया जाएगा;
• यह सब पारित किया जाएगा, और कौन जानता है कि ऐसे मामलों के लिए क्या जाँचें =)।

V6007 अभिव्यक्ति 'बच्चों। आकार ()> 0' हमेशा सच है। कतार.जावा (347)

 boolean isHierarchySameAs(Queue newState) { .... if (children == null || children.size() == 0) { .... } else if(children.size() > 0) { .... } .... } 

इस तथ्य के कारण कि 0 पर तत्वों की संख्या की जाँच अलग से की जाती है, आगे के बच्चों की जाँच करें। आकार ()> 0 हमेशा सही होगा।

HDFS

V6001 समान उप-अभिव्यक्तियाँ हैं 'this.bucketSize' बाईं ओर और '%' ऑपरेटर के दाईं ओर। रोलिंग विंदो। जावा (79)

  RollingWindow(int windowLenMs, int numBuckets) { buckets = new Bucket[numBuckets]; for (int i = 0; i < numBuckets; i++) { buckets[i] = new Bucket(); } this.windowLenMs = windowLenMs; this.bucketSize = windowLenMs / numBuckets; if (this.bucketSize % bucketSize != 0) { // <= throw new IllegalArgumentException( "The bucket size in the rolling window is not integer: windowLenMs= " + windowLenMs + " numBuckets= " + numBuckets); } } 

यह दोष इस तथ्य में निहित है कि चर स्वयं में विभाजित है। नतीजतन, बहुलता के लिए चेक हमेशा पास होगा, और, गलत इनपुट डेटा ( windowLenMs , numBuckets ) के मामले में, अपवाद नहीं फेंका जाएगा।

यार्न

V6067 दो या दो से अधिक केस-शाखाएँ एक ही क्रिया करते हैं। टाइमलाइनइंटरिटी वी 2 कनेक्टोर्टर.जावा (386), टाइमलाइनइंटीवीसीऑनक्वर्टर.जवा (386)

  public static ApplicationReport convertToApplicationReport(TimelineEntity entity) { .... if (metrics != null) { long vcoreSeconds = 0; long memorySeconds = 0; long preemptedVcoreSeconds = 0; long preemptedMemorySeconds = 0; for (TimelineMetric metric : metrics) { switch (metric.getId()) { case ApplicationMetricsConstants.APP_CPU_METRICS: vcoreSeconds = getAverageValue(metric.getValues().values()); break; case ApplicationMetricsConstants.APP_MEM_METRICS: memorySeconds = ....; break; case ApplicationMetricsConstants.APP_MEM_PREEMPT_METRICS: preemptedVcoreSeconds = ....; // <= break; case ApplicationMetricsConstants.APP_CPU_PREEMPT_METRICS: preemptedVcoreSeconds = ....; // <= break; default: // Should not happen.. break; } } .... } .... } 

दो मामले शाखाओं में, एक ही कोड के टुकड़े। ऐसा हर समय होता है! मामलों की प्रमुख संख्या में, यह एक वास्तविक गलती नहीं है, लेकिन केवल एक अवसर है जो स्विच रिफैक्टरिंग के बारे में सोचता है। लेकिन सवाल में मामले के लिए नहीं। बार-बार कोड स्निपेट में, वैरिएबल प्रीमेप्टेडVcoreSeconds का मान सेट होता है । यदि आप सभी चर और स्थिरांक के नामों पर ध्यान देते हैं, तो आप इस निष्कर्ष पर आ सकते हैं कि metric.getId () == APP_MEM_PREEMPT_METRICS के मामले में, चर emememedMemorySeconds का मान सेट किया जाना चाहिए, न कि preemptedVcoreSeconds । इस संबंध में, preemptedMemorySeconds 'स्विच' स्टेटमेंट को निष्पादित करने के बाद हमेशा 0 ही रहेगा, और preemptedVcoreSeconds का मान गलत हो सकता है।

V6046 गलत प्रारूप। विभिन्न प्रकार के प्रारूप आइटम अपेक्षित हैं। तर्क का उपयोग नहीं किया: 2. AbstractSchedulerPlanFollower.java (186)

 @Override public synchronized void synchronizePlan(Plan plan, boolean shouldReplan) { .... try { setQueueEntitlement(planQueueName, ....); } catch (YarnException e) { LOG.warn("Exception while trying to size reservation for plan: {}", currResId, planQueueName, e); } .... } 

लॉग इन करते समय अप्रयुक्त चर planQueueName । यहां, उन्होंने या तो बहुत अधिक प्रतिलिपि बनाई, या प्रारूप स्ट्रिंग को संशोधित नहीं किया। लेकिन फिर भी मैं अच्छे पुराने और कभी-कभी एक असंतुष्ट, कॉपी-पेस्ट लाने के लिए इच्छुक हूं।

टेस्ट कोड

Hadoop आम

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'allSecretsB' के बजाय 'allSecretsB' वैरिएबल का उपयोग किया जाना चाहिए। TestZKSignerSecretProvider.java (316), TestZKSignerSecretProvider.java (309), TestZKSignerSecretProvider.java (306), TestZKSignerSecretProvider.java (313)

 public void testMultiple(int order) throws Exception { .... currentSecretA = secretProviderA.getCurrentSecret(); allSecretsA = secretProviderA.getAllSecrets(); Assert.assertArrayEquals(secretA2, currentSecretA); Assert.assertEquals(2, allSecretsA.length); // <= Assert.assertArrayEquals(secretA2, allSecretsA[0]); Assert.assertArrayEquals(secretA1, allSecretsA[1]); currentSecretB = secretProviderB.getCurrentSecret(); allSecretsB = secretProviderB.getAllSecrets(); Assert.assertArrayEquals(secretA2, currentSecretB); Assert.assertEquals(2, allSecretsA.length); // <= Assert.assertArrayEquals(secretA2, allSecretsB[0]); Assert.assertArrayEquals(secretA1, allSecretsB[1]); .... } 

और फिर से V6072। चर allSecretsA और allSecretsB के लिए बाहर देखो।

V6043 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। इटरेटर के प्रारंभिक और अंतिम मूल्य समान हैं। TestTFile.java (235)

 private int readPrepWithUnknownLength(Scanner scanner, int start, int n) throws IOException { for (int i = start; i < start; i++) { String key = String.format(localFormatter, i); byte[] read = readKey(scanner); assertTrue("keys not equal", Arrays.equals(key.getBytes(), read)); try { read = readValue(scanner); assertTrue(false); } catch (IOException ie) { // should have thrown exception } String value = "value" + key; read = readLongValue(scanner, value.getBytes().length); assertTrue("values nto equal", Arrays.equals(read, value.getBytes())); scanner.advance(); } return (start + n); } 

एक परीक्षण जो हमेशा हरा होता है? =)। लूप का शरीर, जो परीक्षण का हिस्सा है, कभी निष्पादित नहीं होता है। यह इस तथ्य के कारण है कि कथन के लिए काउंटर मैच का प्रारंभ और अंत मान। नतीजतन, स्थिति i <start हमें तुरंत झूठा देगी, जिससे यह व्यवहार होगा। मैं परीक्षणों के साथ फ़ाइल के माध्यम से भाग गया और इस निष्कर्ष पर पहुंचा कि लूप i की स्थिति में लिखना आवश्यक था <(प्रारंभ + n) ।

MapReduce

a href = " www.viva64.com/en/w/v6007 "> V6007 अभिव्यक्ति 'बाइटअम <0' हमेशा झूठी होती है। DataWriter.java (322)

 GenerateOutput writeSegment(long byteAm, OutputStream out) throws IOException { long headerLen = getHeaderLength(); if (byteAm < headerLen) { // not enough bytes to write even the header return new GenerateOutput(0, 0); } // adjust for header length byteAm -= headerLen; if (byteAm < 0) { // <= byteAm = 0; } .... } 

हालत बाइटएएम <0 हमेशा गलत है। समझने के लिए, ऊपर दिए गए कोड को छोड़ दें। यदि परीक्षण निष्पादन ऑपरेशन बाइट - = हैडरलेन पर पहुंचता है , तो इसका मतलब है कि बाइटआम> = हेडरटेन होगा । यहाँ से, घटाव प्रदर्शन करने के बाद, बाइट का मान कभी भी ऋणात्मक नहीं होगा। जिसे सिद्ध करना आवश्यक था।

HDFS

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'normalFile' के बजाय 'normalFile' चर का उपयोग किया जाना चाहिए। TestWebHDFS.java (625), TestWebHDFS.java (615), TestWebHDFS.java (614), TestWebHDFS.java (624)

 public void testWebHdfsErasureCodingFiles() throws Exception { .... final Path normalDir = new Path("/dir"); dfs.mkdirs(normalDir); final Path normalFile = new Path(normalDir, "file.log"); .... // logic block #1 FileStatus expectedNormalDirStatus = dfs.getFileStatus(normalDir); FileStatus actualNormalDirStatus = webHdfs.getFileStatus(normalDir); // <= Assert.assertEquals(expectedNormalDirStatus.isErasureCoded(), actualNormalDirStatus.isErasureCoded()); ContractTestUtils.assertNotErasureCoded(dfs, normalDir); assertTrue(normalDir + " should have erasure coding unset in " + ....); // logic block #2 FileStatus expectedNormalFileStatus = dfs.getFileStatus(normalFile); FileStatus actualNormalFileStatus = webHdfs.getFileStatus(normalDir); // <= Assert.assertEquals(expectedNormalFileStatus.isErasureCoded(), actualNormalFileStatus.isErasureCoded()); ContractTestUtils.assertNotErasureCoded(dfs, normalFile); assertTrue( normalFile + " should have erasure coding unset in " + ....); } 

यह विश्वास नहीं है, और फिर V6072! बस normalDir और normalFile चर का पालन करें

V6027 चर को एक ही फ़ंक्शन के लिए कॉल के माध्यम से आरंभीकृत किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। TestDFSAdmin.java (883), TestDFSAdmin.java (879)

 private void verifyNodesAndCorruptBlocks( final int numDn, final int numLiveDn, final int numCorruptBlocks, final int numCorruptECBlockGroups, final DFSClient client, final Long highestPriorityLowRedundancyReplicatedBlocks, final Long highestPriorityLowRedundancyECBlocks) throws IOException { /* init vars */ .... final String expectedCorruptedECBlockGroupsStr = String.format( "Block groups with corrupt internal blocks: %d", numCorruptECBlockGroups); final String highestPriorityLowRedundancyReplicatedBlocksStr = String.format( "\tLow redundancy blocks with highest priority " + "to recover: %d", highestPriorityLowRedundancyReplicatedBlocks); final String highestPriorityLowRedundancyECBlocksStr = String.format( "\tLow redundancy blocks with highest priority " + "to recover: %d", highestPriorityLowRedundancyReplicatedBlocks); .... } 

इस खंड में, वैरिएबल उच्चतमप्राणप्रतिष्ठा लॉरेडेडेंसीरीप्लिप्टेडब्लॉकस्टस्ट और उच्चतमपायरलरीलोवेडरेडेंसीजेकब्लॉकस्ट्रीम को समान मानों के साथ आरंभीकृत किया गया है। अक्सर यह होना चाहिए, लेकिन इस स्थिति में नहीं। यहां चर नाम एक दूसरे के समान लंबे और समान हैं, इसलिए मुझे आश्चर्य नहीं है कि कॉपी-पेस्ट के अनुरूप कोई संशोधन नहीं थे। स्थिति को ठीक करने के लिए, जब वेरिएबल हाईपायरिटी लोवेरेडेन्डेंसीईसीब्लॉकस्ट्रीम को इनिशियलाइज़ किया जाता है, तो आपको इनपुट पैरामीटर हाईपायरिटी लोवेडरेडेंसीजेकब्लॉक का उपयोग करना होगा । इसके अलावा, सबसे अधिक संभावना है, आपको अभी भी प्रारूप स्ट्रिंग को ठीक करने की आवश्यकता है।

V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestReplaceDatanodeFailureReplication.java (222)

 private void verifyFileContent(...., SlowWriter[] slowwriters) throws IOException { LOG.info("Verify the file"); for (int i = 0; i < slowwriters.length; i++) { LOG.info(slowwriters[i].filepath + ....); FSDataInputStream in = null; try { in = fs.open(slowwriters[i].filepath); for (int j = 0, x;; j++) { x = in.read(); if ((x) != -1) { Assert.assertEquals(j, x); } else { return; } } } finally { IOUtils.closeStream(in); } } } 

विश्लेषक शपथ लेता है कि i ++ काउंटर को लूप में बदलना अप्राप्य है। इसका अर्थ है कि लूप के लिए (int i = 0; i <slowwriters.length; i ++) {....} एक से अधिक पुनरावृत्ति नहीं की जाएगी। आइए जानें इसका कारण। इसलिए, पहले पुनरावृत्ति में, हम स्ट्रीमर को फाइल के साथ जोड़ते हैं जो आगे के पढ़ने के लिए धीमी गति से होता है [0] । लूप के लिए (int j = 0, x ;; j ++) के माध्यम से, हम फाइल की सामग्री को बाइट द्वारा पढ़ते हैं, जहां:

• यदि हम पर्याप्त रूप से कुछ पढ़ते हैं, तो अभिकथन के माध्यम से हम काउंटर बाइट के वर्तमान मूल्य के साथ रीड बाइट की तुलना करते हैं (असफल सत्यापन के मामले में, हम असफल होने के साथ परीक्षा से बाहर निकलते हैं);
• यदि फ़ाइल ने परीक्षण पास कर लिया और हम फ़ाइल के अंत तक पहुँच गए (-1 पढ़ें), तो हम विधि से बाहर निकलते हैं।

इसलिए, कोई भी बात नहीं है जब धीमी गति से लिखने वाले [0] की जांच करते हैं , यह निम्नलिखित तत्वों के सत्यापन में नहीं आएगा। सबसे अधिक संभावना है, रिटर्न के बजाय ब्रेक का उपयोग किया जाना चाहिए।

यार्न

V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestNodeManager.java (176)

 @Test public void testCreationOfNodeLabelsProviderService() throws InterruptedException { try { .... } catch (Exception e) { Assert.fail("Exception caught"); e.printStackTrace(); } } 

इस स्थिति में, यदि कोई अपवाद होता है, तो स्टैकट्रेस मुद्रित नहीं किया जाएगा, क्योंकि Assert.fail विधि परीक्षण को बाधित करेगी। यदि पर्याप्त संदेश है कि अपवाद पकड़ा गया है, तो भ्रमित न होने के लिए, स्टैट्रेस का प्रिंट निकालने की आवश्यकता है। यदि मुद्रण आवश्यक है, तो आपको बस उन्हें स्वैप करने की आवश्यकता है।

ऐसे कई स्थान हैं:

• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (928)
• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (737)
• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (685)
• ....

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'publicCache' चर का उपयोग 'usercache' के बजाय किया जाना चाहिए। TestResourceLocalizationService.java (315), TestResourceLocalizationService.java (309), TestResourceLocalizationService.java (307), TestResourceLocalizationService.java (313)

 @Test public void testDirectoryCleanupOnNewlyCreatedStateStore() throws IOException, URISyntaxException { .... // verify directory creation for (Path p : localDirs) { p = new Path((new URI(p.toString())).getPath()); // logic block #1 Path usercache = new Path(p, ContainerLocalizer.USERCACHE); verify(spylfs).rename(eq(usercache), any(Path.class), any()); // <= verify(spylfs).mkdir(eq(usercache), ....); // logic block #2 Path publicCache = new Path(p, ContainerLocalizer.FILECACHE); verify(spylfs).rename(eq(usercache), any(Path.class), any()); // <= verify(spylfs).mkdir(eq(publicCache), ....); .... } .... } 

और अंत में, फिर से V6072 =)। संदिग्ध स्निपेट के साथ खुद को परिचित करने के लिए चर: usercache और publicCache ।

निष्कर्ष

विकास के दौरान, कोड की सैकड़ों हजारों लाइनें लिखी जाती हैं। यदि उत्पादन कोड बग, दोष और कमियों से साफ रखने की कोशिश कर रहा है (डेवलपर अपने कोड का परीक्षण करता है, कोड की समीक्षा, और बहुत कुछ करता है), तो परीक्षण स्पष्ट रूप से इस से हीन हैं। परीक्षणों में दोष चुपचाप "ग्रीन टिक" के पीछे छिप सकता है। और जैसा कि आप आज के चेतावनियों के विश्लेषण से समझते हैं, एक सफलतापूर्वक पारित परीक्षण हमेशा एक गारंटीकृत परीक्षण से दूर है।

Apache Hadoop कोडबेस की जाँच करते समय, स्थैतिक विश्लेषण ने न केवल उत्पादन में जाने वाले कोड के लिए, बल्कि उन परीक्षणों के लिए भी अपनी आवश्यकता का प्रदर्शन किया जो विकास में महत्वपूर्ण भूमिका निभाते हैं।

इसलिए यदि आप अपने कोड और परीक्षण आधार की गुणवत्ता के बारे में परवाह करते हैं, तो मेरा सुझाव है कि आप स्थिर विश्लेषण की ओर देखें। और परीक्षण के लिए पहला आवेदक मैं पीवीएस-स्टूडियो की कोशिश करने का प्रस्ताव करता हूं।

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: मैक्सिम स्टेफानोव। अपाचे Hadoop कोड गुणवत्ता: उत्पादन वी.एस. टेस्ट ।