प्रोग्रामिंग करते समय आप अपने कोड को कितनी बार चलाते और परखते हैं? [बन्द है]


16

विशेष रूप से सी में स्क्रैच से नया कोड लिखते समय, मैं खुद को घंटों के लिए कोड लिख रहा हूं, यहां तक ​​कि किसी भी चीज के लिए संकलक को चलाने के बिना दिन भी।

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

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

आपको क्या लगता है कि दो दृष्टिकोणों के बीच सही संतुलन क्या है? बेशक पहले वाले को अधिक अनुभव की आवश्यकता होती है, लेकिन क्या यह उत्पादकता को सकारात्मक या नकारात्मक रूप से प्रभावित करता है? क्या दूसरा एक बेहतर स्तर पर त्रुटियों को दूर करने में आपकी मदद करता है?


3
संपूर्ण उप-पाठ लिखने में आपको घंटों या दिनों का समय लगता है?

1
@ थोरबॉर्न सबरूटीन लगभग 999 लाइनें लंबी है, और यह बाधित है: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)और यह केवल एक लाइन है।
मतीन उल्हाक

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

जवाबों:


6

यह वास्तव में उस परियोजना के पहलू पर निर्भर करता है जिस पर आप काम कर रहे हैं।

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

  • बड़े पैमाने पर "हुड के तहत" विकास के लिए, मैं पहले से ही संभव के रूप में कई परीक्षण प्राप्त करने की कोशिश करता हूं। चूंकि परीक्षण मुझे आसानी से बता सकते हैं कि क्या टूट गया, मैं आमतौर पर लंबे संकलन के लिए इंतजार किए बिना कुछ समय के लिए जा सकता हूं।

  • UX डिजाइन के लिए, मैं कुछ प्रकार के विज़ुअल डिज़ाइनर का उपयोग करता हूं, जो हमेशा यह देखता है कि यह किस प्रकार चलेगा (या इसके करीब)। यह अनिवार्य रूप से हमेशा डिजाइन कोड को संकलित करता है।


63

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

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


12
Upvote for "... काफी स्मार्ट नहीं है .." मुझे काफी समय से ऐसा लगा है।
leed25d

4
आपके L2 कैश के बारे में क्या?
मतीन उलूक

मैं इसे उभारने जा रहा था, लेकिन स्कोर 42 पर है ...
वेन वर्नर

नए मॉडल में बहुत बड़ा एल 1 कैश है। आपने अपना कब खरीदा? आप हार्डवेयर अपडेट के लिए जाना चाहते हैं।
पीटर अज़ताई

खैर इसकी मॉडल की उम्र इतनी नहीं है कि यह तथ्य है कि यह "बजट" लाइन थी। :(
dss539

17

अपना कार्यान्वयन कोड लिखने से पहले मुझे अपना परीक्षण लिखना पसंद है । मुझे यह तीन कारणों से पसंद है:

  1. हाथ से पहले अपना टेस्ट कोड लिखने से मुझे लगता है कि मेरे कोड का उपयोग कैसे किया जाना चाहिए। यह मुझे किनारे के मामलों के बारे में सोचने में मदद करता है जो मैंने तब नहीं सोचा था जब मैं मूल रूप से अपना कार्यक्रम डिजाइन कर रहा था।
  2. मुझे पता है कि जब मेरा सभी टेस्ट केस पास हो जाएगा तो मैं कार्यान्वयन कोड लिख रहा हूं।
  3. कोड से पहले परीक्षण लिखने की आदत में शामिल होने से यह साबित करने में सक्षम होने का अतिरिक्त प्रभाव पड़ता है कि आपके कोड में कोई नया बग नहीं जोड़ा गया है (यह मानते हुए कि आपने अच्छे परीक्षण मामले लिखे हैं)।

2
"मुझे पता है कि जब मेरा सभी टेस्ट केस पास हो जाएगा तो मैं कार्यान्वयन कोड लिख रहा हूं।" - यदि आप सभी आवश्यक परीक्षण मामलों को लिखते हैं तो आप कैसे निर्धारित करते हैं?
dss539

1
यह बहुत अच्छा सवाल है। मेरी राय में, आप कभी भी पूरी तरह से निश्चित नहीं हो सकते कि आपका कोड सही ढंग से काम करता है जब तक कि आपके पास ऐसा करने का कोई औपचारिक प्रमाण न हो। मैं इकाई परीक्षणों को सबूत के रूप में देखता हूं कि आपका कोड वह करता है जो आप करने का मतलब है। लेकिन, जैसे-जैसे आप सुविधाएँ बढ़ाते जाते हैं, आपके द्वारा लिखे जाने वाले परीक्षण मामलों की संख्या भी संभवतः बढ़ती जाएगी। यदि संदेह है, तो किसी और को अपने परीक्षण मामलों को देखने के लिए कहें और उन मामलों के लिए पूछें जिनके बारे में आपने नहीं सोचा है।
डेविड वेसर

4
@ डेविड - आप औपचारिक रूप से कैसे साबित करते हैं कि आपके औपचारिक प्रमाण में कोई त्रुटि नहीं है? आप औपचारिक रूप से कैसे साबित करते हैं कि आपके द्वारा बताई गई आवश्यकताएं वास्तविकता की आवश्यकताओं से मेल खाती हैं। आप औपचारिक रूप से साबित कर सकते हैं कि एक विवरण दूसरे से मेल खाता है, लेकिन यह पूरी तरह से संभव है कि दोनों विवरण एक ही तरह से गलत हैं - खासकर यदि दोनों विवरण एक ही व्यक्ति द्वारा लिखे गए थे। गणित संकेतन में चीजें लिखना लोगों को अचूक नहीं बनाता है। गणितीय "प्रमाण" की बहुत बड़ी संख्या गलत साबित हुई है (बहुत विस्तृत जाँच के लंबे समय के बाद)।
स्टीव

1
@ स्टीव 314: AFAIK, जब औपचारिक रूप से एक एल्गोरिथ्म की शुद्धता साबित होती है, तो आप सटीक रूप से निर्दिष्ट करते हैं और उम्मीद की शुद्धता सही है। आप एक अच्छा बिंदु लाते हैं, हालांकि "शुद्धता" की परिभाषा वास्तव में सही नहीं हो सकती है।
डेविड वीज़र

1
@ dss539, यह उन उपयोग मामलों से आता है जिन्हें कार्यक्रम को लागू करने का इरादा है।

4

मैं खुद को घंटों तक कोड लिखना चाहता हूं, यहां तक ​​कि किसी भी चीज के लिए संकलक को चलाने के बिना भी दिन लेकिन एक सामयिक वाक्यविन्यास जांच।

घंटे से दिन - यह एक स्पष्ट संकेत है कि आप अपने कोड को छोटे विखंडू में तोड़ने की क्षमता को याद करते हैं जिसे सत्यापित किया जा सकता है और अपने दम पर परीक्षण किया जा सकता है। आपको निश्चित रूप से उस पर काम करना चाहिए।

मैं कोड के बड़े हिस्से को ध्यान से लिखता हूं और पूरी तरह से परीक्षण करता हूं, जब मुझे यकीन हो जाता है कि कोड वह करता है जो मेरे सिर में प्रवाह का विश्लेषण करके करना चाहिए।

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

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


3

मैं संकलित करता हूं और जांचता हूं कि निम्नलिखित में से कोई एक स्थिति संतुष्ट है या नहीं:

  • अंतिम संकलन 15 मिनट पहले था
  • अंतिम संकलन 25 लाइनों पहले था
  • नया फंक्शन / सबरूटिन लागू किया गया है
  • बड़ा परिवर्तन
  • नई सुविधा (या एक फीचर के रूप में प्रच्छन्न बग)
  • बग फिक्स (एक "सुविधा" को हटा दिया गया)
  • मैं ऊब गया हूं

1

मैं कितनी बार चलाता हूं और परीक्षण कोड इस बात पर निर्भर करता है कि मैं उस समय किस भाषा में काम कर रहा हूं। अगर मैं एक संग्रहीत प्रक्रिया को कोडित कर रहा हूं, तो मैं आमतौर पर सब कुछ होने तक इंतजार करूंगा।

दूसरी ओर, अगर मैं लिस्प में कोडिंग कर रहा हूं, तो मैं इसे टाइप करने के बाद प्रत्येक फ़ंक्शन की कोशिश करूँगा।

यदि मैं हास्केल में कोडिंग कर रहा हूं, तो मैं आमतौर पर किसी भी प्रकार की त्रुटियों को पकड़ने के लिए प्रत्येक फ़ंक्शन के बाद एक संकलन करता हूं, और सब कुछ पूरा होने के बाद कोड चलाता हूं।


1

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


1

एक घंटे में तीन बार, चाहे उसे इसकी आवश्यकता हो या नहीं।

हम परीक्षण-प्रथम प्रोग्रामिंग करते हैं और केवल वीसीएस के लिए काम करने वाले कोड के लिए प्रतिबद्ध हैं। Smolderbot हर 20 मिनट में रेपो की जांच करता है और टेस्ट सूट चलाता है। किसी भी विफलताओं को तत्काल फिक्सिंग के लिए पूरी प्रोग्रामिंग टीम को तुरंत मेल किया जाता है।


1

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

कभी-कभी हालांकि, आपके कोड को चलते देखना एक बहुत बड़ा प्रेरक बढ़ावा है, जब आपने कुछ भी नहीं चलाया है तो इसे काम करते हुए देखना अच्छा है।


0

मेरे लिए; -
संक्षिप्त समय (सोचने के लिए ज्यादा समय नहीं) - कोड, संकलन, परीक्षण लिखें। डिबग
पर्याप्त समय - जबकि (किया गया) {छोटा कोड लिखें, संकलन करें}, टेस्ट, डीबग करें


मुझे लगता है कि पूर्व में उत्तरार्द्ध की तुलना में अधिक समय लगता है: आपके पास डिबग करने के लिए अधिक है कि अगर आपके पास बहुत छोटा परीक्षण / राइट लूप है।
फ्रैंक शियरर

शायद। लेकिन छोटी समयावधि का मतलब है कि गधा आग पर है, और प्रबंधक को रिपोर्ट की आवश्यकता है जो कहती है कि कुछ कार्य 100% किया गया है।
मनोज आर

0

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


0

मैं कोशिश करता हूं और कोड से पहले परीक्षण लिखता हूं। मैं कमिटमेंट से पहले कम से कम दो बार अपने परीक्षण चलाता हूं। यह फिर कंटीन्यूअस इंटीग्रेशन सर्वर के साथ फिर से चलता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.