घने कोड और इसके परीक्षण

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



समस्या को रेखांकित करने के लिए, आइए एक छोटा उदाहरण देखें। मान लीजिए कि आपके पास एक सर्वर है और इसके बाहर से कमांड प्राप्त करते हैं। आपको इन कमांड के लिए प्रोसेसिंग लॉजिक लिखना होगा। मैं इस समस्या का अनुकरण इस प्रकार करेगा:



ऐसा क्यों और बहुत कुछ है: सबसे पहले, हम कोड टू इंटरफ़ेस के सिद्धांत का पालन करते हैं, जो हमें उदाहरण के लिए, एक कमांड हैंडलर को नकली (नकली) सर्वर का परीक्षण करते समय अनुमति देगा; दूसरी बात, प्रत्येक टीम के तर्क को एक अलग वर्ग में अलग करके, हम आसानी से इस तर्क का परीक्षण कर सकते हैं। आप सोच सकते हैं, कि हम सिर्फ एक Handler क्लास क्यों नहीं बनाते हैं और प्रत्येक टीम के लिए सार्वजनिक तरीके जोड़ते हैं और इन तरीकों का परीक्षण करते हैं, इसमें कक्षाओं का एक गुच्छा क्यों रखा है? लेकिन, मेरी राय में, समस्या यह है कि इस मामले में वर्ग का कार्य वर्ग द्वारा "प्रसार" प्रतीत होता है, एक अर्थ में, हम बाहरी दुनिया के लिए हमारे हैंडलर के कार्यान्वयन का विवरण खोलते हैं जो उसके लिए अनावश्यक हैं। आखिरकार, सर्वर को जानने की जरूरत है कि यह वर्ग किसी भी कमांड को प्रोसेस कर सकता है, न कि यह कमांड 1, कमांड 2 और कमांड 3 को प्रोसेस कर सकता है।

अब सोचने की कोशिश करते हैं कि इस समस्या को "तंग कोड" के रूप में कैसे लागू किया जाएगा। बेशक, मैं लेखक और 20-25 साल के अनुभव वाले व्यक्ति के लिए नहीं बोल सकता। शायद उसका मतलब कुछ और है। लेकिन इस संदर्भ में, मेरे लिए, कोड संघनन है, उदाहरण के लिए, सभी हैंडलर को एक वर्ग में मिलाप करना। बेहतर अभी तक, एक विधि में:

 पब्लिक क्लास हैंडलर {
     पब्लिक रिजल्ट हैंडल (कमांड कमांड) {
         अगर (कमांड == COMMAND1) {
             // तर्क करना 1
         } और यदि (कमांड == COMMAND2) {
             // तर्क दो
         } 
         //।  ।  ।  ।
         और {
             log.error ("कमांड को कैसे संभालना है पता नहीं है" + कमांड);
         }
         वापसी परिणाम;
     }
 }

या हो सकता है कि अलग वर्ग में कमांड प्रोसेसिंग को शामिल करना आवश्यक न हो? बस उन्हें सर्वर पर डाल दिया?

 पब्लिक क्लास सर्वर {
     सार्वजनिक शून्य आक्षेप (सॉकेट क्लाइंट) {
         int कमांड;
         जबकि ((कमांड = client.getInputStream ()। पढ़ा ())! = -1) {
             अगर (कमांड == COMMAND1) {
                 // तर्क करना 1
             } और यदि (कमांड == COMMAND2) {
                 // तर्क दो
             } 
             //।  ।  ।  ।
             और {
                 log.error ("कमांड को कैसे संभालना है पता नहीं है" + कमांड);
             }
         }
     }
 }

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

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

पुनश्च मैं एक आरक्षण बनाऊंगा जिसे मैं कुछ एल्गोरिदम की छँटाई जैसी अनिवार्य भाषाओं में पूरी तरह से लागू करना चाहता हूँ। बाजीगर जैसे एल्गोरिदम - यह एक ही गेंद के साथ हथकंडा करने के लिए कोई मतलब नहीं है, जिसका अर्थ केवल एक ही समय में बहुत सारे गेंदों (ऑब्जेक्ट्स, चर, आदि) की बाजीगरी करते समय दिखाई देता है। यद्यपि यहाँ भी, यह मुझे लगता है कि विकल्प हैं।