कुछ स्थितियों में प्रोग्रामर के ध्यान आकर्षित कैसे करें?

Question

एक उदाहरण से शुरू करते हैं।

मान लीजिए, मेरे पास एक विधि है जिसे exportडीबी स्कीमा पर बहुत अधिक निर्भर करता है। और "बहुत हद तक निर्भर करता है" से मेरा मतलब है कि मुझे पता है कि एक निश्चित तालिका में एक नया कॉलम अक्सर (बहुत बार) exportजोड़ने से संबंधित विधि परिवर्तन होता है (आमतौर पर आपको नए क्षेत्र को निर्यात डेटा में भी जोड़ना चाहिए)।

प्रोग्रामर अक्सर exportविधि बदलना भूल जाते हैं क्योंकि यह वास्तव में स्पष्ट नहीं है कि आपको इस पर भी ध्यान देना चाहिए। मेरा लक्ष्य प्रोग्रामर को स्पष्ट रूप से यह निर्धारित करने के लिए बाध्य करना है कि वह exportविधि को देखना भूल गया या केवल निर्यात डेटा में फ़ील्ड जोड़ना नहीं चाहता। और मैं इस समस्या के लिए डिज़ाइन समाधान की तलाश कर रहा हूं।

मेरे पास दो विचार हैं, लेकिन दोनों में दोष हैं।

स्मार्ट "सभी पढ़ें" आवरण

मैं स्मार्ट रैपर बना सकता हूं जो सुनिश्चित करता है कि सभी डेटा स्पष्ट रूप से पढ़ा जाए।

कुछ इस तरह:

def export():
    checker = AllReadChecker.new(table_row)

    name    = checker.get('name')
    surname = checker.get('surname')
              checker.ignore('age') # explicitly ignore the "age" field

    result = [name, surname] # or whatever

    checker.check_now() # check all is read

    return result

इसलिए, checkerयदि table_rowकोई अन्य फ़ील्ड शामिल है जो पढ़ा नहीं गया है तो मुखर करता है । लेकिन यह सब कुछ एक तरह से भारी लगता है और (शायद) परफ्यूम को प्रभावित करता है।

" उस विधि की जाँच करें " unittest

मैं केवल अंतिम तालिका स्कीमा को याद रखने वाला सबसे उपयुक्त बना सकता हूं और हर बार तालिका बदलने पर विफल हो जाता है। उस स्थिति में प्रोग्रामर को कुछ इस तरह दिखाई देगा " exportविधि की जाँच करना मत भूलना "। चेतावनी को छिपाने के लिए प्रोग्रामर (या - यह एक समस्या नहीं है) की जांच करेगा exportऔर मैन्युअल रूप से (यह एक और समस्या है) इसमें नए फ़ील्ड जोड़कर परीक्षण को ठीक करें।

मेरे पास कुछ अन्य विचार हैं, लेकिन वे लागू करने के लिए बहुत परेशान हैं या समझना बहुत मुश्किल है (और मैं नहीं चाहता कि परियोजना एक पहेली बन जाए)।

---

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

Comments

क्या आप exportस्कीमा के आधार पर जनरेट कर सकते हैं ?

— coredump

यह मूल रूप से उत्पन्न नहीं किया जा सकता है, इसलिए मुझे प्रोग्रामर को कोड को देखने और निर्णय लेने के लिए कहना चाहिए ।

— वादिम पुश्तैव

क्या यह निर्यात वर्ग में फ़ील्डनाम (निर्यात और निर्यात-निर्यात) की दो सूचियों को जोड़ने के लिए एक समाधान होगा, और एक इकाई परीक्षण है जो यह जाँचता है कि उन दो सूचियों में डेटाबेस से फ़ील्ड का पूरा सेट शामिल है?

— सोज़र्ड जॉब पोस्टमस

क्या आप एक परीक्षण को स्वायत्त कर सकते हैं, हालांकि यह जांच करता है कि क्या exportआपके पास वास्तविक रूप से सब कुछ है?

— बिजिकलोप

स्रोत कोड में एक टिप्पणी भी सरलीकृत एक समाधान है? आमतौर पर चीजें याद आती हैं क्योंकि कोई अनुस्मारक नहीं है, एक टिप्पणी यह ​​तय करेगी।

— gbjbaanb

Answer 1

आप अपने यूनिट परीक्षण विचार के साथ सही रास्ते पर हैं, लेकिन आपका कार्यान्वयन गलत है।

यदि exportस्कीमा से संबंधित है और स्कीमा बदल गया है, तो दो संभावित मामले हैं:

• या तो exportअभी भी पूरी तरह से अच्छी तरह से काम करता है, क्योंकि यह स्कीमा में मामूली बदलाव से अप्रभावित था,

• या यह टूट जाता है।

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

आपका कार्यान्वयन गलत क्यों है? खैर, कई कारणों से।

1. इसका इकाई परीक्षणों से कोई लेना-देना नहीं है ...

2. ... और वास्तव में, यह एक परीक्षा भी नहीं है।

3. सबसे बुरी बात यह है कि "परीक्षण" को ठीक करने के लिए, वास्तव में, "परीक्षण" को बदलना आवश्यक है, जो एक ऑपरेशन कर रहा है जो पूरी तरह से असंबंधित है export।

इसके बजाय, exportप्रक्रिया के लिए वास्तविक परीक्षण करके , आप यह सुनिश्चित करते हैं कि डेवलपर इसे ठीक कर देगा export।

---

अधिक आम तौर पर, जब आप एक ऐसी स्थिति का सामना करते हैं जहां एक कक्षा में हमेशा बदलाव होता है या आमतौर पर पूरी तरह से अलग वर्ग में बदलाव की आवश्यकता होती है, तो यह एक अच्छा संकेत है कि आपने अपने डिजाइन को गलत किया और एकल जिम्मेदारी सिद्धांत का उल्लंघन कर रहे हैं।

जबकि मैं विशेष रूप से कक्षाओं के बारे में बात करता हूं, यह कमोबेश अन्य संस्थाओं पर भी लागू होता है। उदाहरण के लिए, डेटाबेस स्कीमा में परिवर्तन या तो अपने कोड में स्वचालित रूप से परिलक्षित होना चाहिए, उदाहरण के लिए कई ओआरएम द्वारा उपयोग किए जाने वाले कोड जनरेटर के माध्यम से, या कम से कम आसानी से स्थानीय होना चाहिए: यदि मैं तालिका में Descriptionकॉलम जोड़ता Productहूं और मैं नो ओआरएम या कोड जनरेटर का उपयोग करता हूं। मैं कम से कम DAL की कक्षा के भीतर एक एकल परिवर्तन करने की उम्मीद करता हूं Data.Product, बिना सभी कोड आधार के माध्यम से खोज करने की आवश्यकता है और Productप्रस्तुति, परत, में कक्षा की कुछ घटनाओं को खोजने की आवश्यकता है ।

यदि आप यथोचित रूप से परिवर्तन को एक स्थान तक सीमित नहीं कर सकते हैं (या तो क्योंकि आप ऐसे मामले में हैं जहां यह बस काम नहीं करता है, या क्योंकि इसमें विकास की एक बड़ी राशि की आवश्यकता होती है), तो आप प्रतिगमन का खतरा पैदा करते हैं । जब मैं क्लास बदलता हूं A, और Bकोड बेस में कहीं क्लास काम करना बंद कर देता है, तो यह एक रिग्रेशन है।

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

सभी मामलों में, केवल टिप्पणियों पर ऐसे मामलों में भरोसा करने से बचें। कुछ इस तरह:

// If you change the following line, make sure you also change the corresponding
// `measure` value in `Scaffolding.Builder`.

कभी काम नहीं करता। न केवल डेवलपर्स इसे ज्यादातर मामलों में नहीं पढ़ेंगे, लेकिन यह अक्सर या तो हटा दिया जाएगा या संबंधित लाइन से बहुत दूर चला जाएगा, और समझना असंभव हो जाएगा।

Comments

हां, यह "परीक्षण" वास्तव में एक परीक्षण नहीं है, यह किसी प्रकार का जाल है, किसी प्रकार का If you change the following line...काम स्वचालित रूप से होता है और इसे आसानी से नजरअंदाज नहीं किया जा सकता है। मैंने कभी नहीं देखा कि किसी ने वास्तव में इस तरह के जाल का इस्तेमाल किया है इसलिए संदेह है।

— वादिम पुष्टदेव

समस्या यह है कि वर्ग Bकाम करना बंद नहीं करता है , यह शायद अनुचित तरीके से काम करना शुरू कर देता है। लेकिन मैं भविष्य की भविष्यवाणी नहीं कर सकता और भविष्य की भविष्यवाणी करने वाले परीक्षण नहीं लिख सकता, इसलिए मैं डेवलपर को उस नए परीक्षण को लिखने के लिए याद दिलाने की कोशिश करता हूं।

— वादिम पुष्पावे

@VadimPushtaev: जब परीक्षण की बात आती है, तो "शायद अनुचित तरीके से काम करना शुरू हो जाता है" और "काम करना बंद कर देता है" बिल्कुल यही बात है। आप भविष्य की भविष्यवाणी नहीं कर सकते हैं, लेकिन आपको उन आवश्यकताओं को जानने में सक्षम होना चाहिए, और परीक्षण करना चाहिए कि उन आवश्यकताओं को आपके वास्तविक उत्पाद द्वारा पूरा किया गया है।

— आर्सेनी मूरज़ेंको

हाँ, यह एक बात है। मैं वास्तव में डेवलपर को नई आवश्यकताओं के बारे में सोचने के लिए याद दिलाना चाहता हूं । मैं सिर्फ एक हाथ लहराना चाहता हूं: “नमस्ते, क्या आप सुनिश्चित हैं कि आप निर्यात के बारे में नहीं भूलते हैं? प्रबंधक से पूछें या कुछ और, यह एक आम समस्या है ”।

— वदिम पुश्तैव

वैसे भी धन्यवाद, आपके उत्तर ने मुझे अपने विचारों को व्यवस्थित करने में मदद की और मेरी अब एक निश्चित योजना है।

— वादिम पुष्टदेव

Answer 2

यह मुझे लगता है कि आपके परिवर्तन अनपेक्षित हैं। आप कहीं ऐसे स्थान पर रहते हैं जिसमें डाक कोड नहीं होते हैं, इसलिए आपके पास पता तालिका में डाक कोड कॉलम नहीं है। फिर पोस्टल कोड पेश किए जाते हैं, या आप उन ग्राहकों के साथ काम करना शुरू कर देते हैं, जहां वे रहते हैं जहां पोस्टल कोड होते हैं, और आपको इस कॉलम को तालिका में जोड़ना होगा।

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

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

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

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

Answer 3

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

Comments

यह जाँच सकता है, कि हर वस्तु को db से बचाया और पुनः लोड किया गया है। यह इस मामले को कवर नहीं करता है कि किसी मौजूदा db- फ़ील्ड में कोई संबंधित ऑब्जेक्ट फ़ील्ड नहीं है।

— k3b

@ k3b सच। कम से कम मेरे सिस्टम में, यह आमतौर पर तब होता है जब कुछ का उपयोग नहीं किया जाता है, लेकिन स्कीमा से हटाया नहीं गया है, जो निर्यात तंत्र के दायरे से बाहर है - ऑब्जेक्ट दृढ़ता के लिए यूनिट परीक्षण यह जांचें कि क्या ऑब्जेक्ट का प्रत्येक क्षेत्र है कायम है, लेकिन मैं अप्रयुक्त स्तंभों के लिए परीक्षण नहीं करता हूं क्योंकि इससे सिस्टम फ़ंक्शन पर कोई अवलोकन प्रभाव नहीं होगा।

— पीट किर्कम