संयोग से प्रोग्रामिंग कैसे पार करें? [बन्द है]


24

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

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

खानों के लिए सैनिक की प्रारंभिक जांच से कुछ भी नहीं पता चला, लेकिन यह केवल भाग्यशाली था। वह एक झूठे निष्कर्ष के लिए नेतृत्व किया गया था - विनाशकारी परिणामों के साथ।

डेवलपर्स के रूप में, हम माइनफील्ड्स में भी काम करते हैं। हर दिन हमें पकड़ने के लिए सैकड़ों जाल हैं। सैनिक की कहानी को याद करते हुए, हमें गलत निष्कर्ष निकालने से सावधान रहना चाहिए। हमें संयोग से प्रोग्रामिंग से बचना चाहिए - भाग्य और आकस्मिक सफलताओं पर भरोसा करना - जानबूझकर प्रोग्रामिंग के पक्ष में ...

लेकिन मैं वास्तव में इस तरह से संतुष्ट नहीं हूं कि वे "इसे कैसे दूर करें" मुद्दे का वर्णन करते हैं। हाँ, आपको कोड लिखने से पहले सोचना होगा, लेकिन इसका अभ्यास कैसे करें? केवल एक चीज जो मैं सोच सकता हूं वह मौजूदा ओपन सोर्स प्रोजेक्ट्स में सुविधाओं को जोड़कर है, जहां आपको "अब मैं क्या कर रहा हूं" और "कोड के अन्य टुकड़े कैसे काम कर रहे हैं" दोनों पर ज्ञान होना चाहिए, और यह लागू नहीं है जब आप अपनी परियोजनाओं को लिख रहे हैं।

संपादित करें:

आपके पोस्ट से एक सारांश:

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

BTW, एक उत्तर को स्वीकार करना कठिन है, यह वास्तव में कठिन है। सभी जवाब वास्तव में महान हैं :)


6
यह उन लोगों की मदद करेगा जो लंबे समय तक किताब को नहीं पढ़ सकते हैं जैसे कि pragprog.com/the-pragmatic-programmer/extracts/coincidence जैसी लिंक ।
btilly

जब तक आपके पास एक बहुत छोटा प्रोग्रामिंग कैरियर नहीं है (या एक एक आदमी की दुकान है), तो आपको कोड के आने की संभावना है जो कि अजीब तरह से परिचित है और कुछ कोड-बाद में चलते हैं, पेनी ड्रॉप हो जाती है: यह आपका है। यह केवल एक ओपन सोर्स विचार नहीं है ...
रॉबी डी

@ रोबी दी। क्या आप इसे थोड़ा और स्पष्ट कर सकते हैं? मैं तुम्हें नहीं मिलता। दरअसल, मेरे पास एक छोटा प्रोग्रामिंग करियर है और जूनियर-प्रोग्रामर टैग का कारण है।
py_script

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

जवाबों:


26

आपको आगे सोचने की ज़रूरत नहीं है, जो किया गया था उस पर केवल बहुत स्पष्ट होना चाहिए, और अभी जो आप कर रहे हैं उस पर बहुत स्पष्ट रहें।

सबरूटीन्स को कहना चाहिए कि वे क्या करते हैं, वे जो कहते हैं वह करते हैं, और छिपी निर्भरता नहीं है। फिर उन्हें कॉल करने वाला कोई भी व्यक्ति आसानी से कारण बता सकता है कि वे क्या करेंगे।

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

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

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

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

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


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

1
मेरे पास बहुत से उदाहरण हैं। C ++ प्रोजेक्ट में मैंने बिना स्ट्रीफ़ मेथड के तरीके बनाये। एक बार जब मैंने उन्हें बनाया, तो डिबगिंग आसान हो गई और विकास फैल गया। एक पर्ल प्रोजेक्ट में हमारे पास एक कॉन्फ़िगरेशन हैश था, जहां प्रत्येक डेवलपर के पास प्रत्येक नए कॉन्फ़िगरेशन की अपनी स्वयं की प्रतिलिपि बनाई गई थी। कॉन्फ़िगरेशन पैरामीटर जोड़ना एक दर्द था क्योंकि आपको प्रत्येक डेवलपर के कॉन्फ़िगरेशन को संपादित करना था। मैंने हैश के लिए टेम्प्लेट सिस्टम लिखा, और यह आसान हो गया। एक रिपोर्टिंग प्रणाली में मैंने मध्यवर्ती परिणाम दिखाने के लिए एक सुविधा जोड़ी। मेरे विकास में तेजी आई, और मुझे एक उपयोगकर्ता बग रिपोर्ट भी मिली ...
btilly

1
जहां वित्त विभाग ने मेरे तर्क का पता लगाया था, और उस सटीक क्वेरी को पाया, जिस पर मैं गलत था और मेरी बग क्या थी। (मैं गलती से डुप्लिकेट पंक्तियों को स्क्वीज़ कर रहा था UNIONजहाँ मुझे ज़रूरत थी UNION ALL।) और इसी तरह।
23

1
एक महीने के अंदर? मुझे आमतौर पर लगता है कि हर बार जब मुझे लगता है कि मुझे लगता है कि कोड को स्पर्श किया जाना चाहिए, लेकिन इसे फिर से कायम नहीं किया गया है, तो इसे रिफ्लैक्टर करने में लगभग उतना ही समय लगेगा।
एमी ब्लेंकशिप

1
@AmyBlankenship हाँ। एक महीने के अंदर। कभी हास्यास्पद रूप से अंदर, कभी नहीं। मेरे द्वारा उल्लिखित विन्यास फाइल चीज़ "कभी-कभी नहीं" का एक उदाहरण है। नया टेम्प्लेट इंजन लिखने, दस्तावेज बनाने और परीक्षण करने में मुझे कुछ दिन लग गए। फिर इसे उपयोग करने के लिए मौजूदा कॉन्फ़िगरेशन को फिर से लिखें, और बहुत कम हो, लेकिन समान डेटा संरचना का उत्पादन करें। (यह परियोजना का सबसे कठिन हिस्सा था।) इसलिए..बस बर्बाद हो गया, बिल्कुल दिखाई नहीं परिणाम के साथ। अभी तक प्रयास केवल एक महीने के भीतर भुगतान किया गया था, लेकिन तब से ब्याज कमा रहा है।
btilly

41

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

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

दूसरे शब्दों में, आप तब तक नहीं किए जाते हैं जब तक आप यह नहीं जान लेते हैं कि आपका फिक्स काम क्यों करता है। वहां पहुंचने के लिए आप जो रास्ता अपनाते हैं, वह इतना मायने नहीं रखता। यहां तक ​​कि यादृच्छिक क्रमपरिवर्तन कभी-कभी एक बग को संकीर्ण करने में मददगार हो सकता है, जिसका निदान करना मुश्किल है, जब तक कि आप बाद में खुद को पूछने के लिए समय लेते हैं, "ठीक है, यह सही गलत को बदलकर तय किया गया है, लेकिन क्यों?"


1
उत्कृष्ट बिंदु +1। कहीं यह कोड फिक्स से ज्यादा लागू नहीं होता ...
रॉबी डी

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

मैं मानता हूँ। जब झुकाव वाले टूथपिक सिंड्रोम का सामना करना पड़ रहा हो, तब तक \
_

16

एक कार्यक्रम में मुझे सबसे डरावनी टिप्पणी मिली

इसे मत छुओ। यह काम करता हैं। हम नहीं जानते कि कैसे या क्यों, लेकिन यह काम करता है। 1

और यह केवल डरावना है क्योंकि यह स्वीकार करता है कि कोड का टुकड़ा संयोग से प्रोग्रामिंग का परिणाम था ।

संयोग से प्रोग्रामिंग से बचने के लिए, आपको यह समझाने में सक्षम होना चाहिए (एक सहकर्मी, अपने आप को या एक रबर बतख ) वास्तव में कोड क्या करता है और यह क्यों काम करता है। प्रोग्रामिंग के लिए गोलियों को जानबूझकर कोड को समझाने में सक्षम होने के लक्ष्य की ओर बढ़ने में ज्यादातर सहायता मिलती है।


1 संदर्भ के लिए, यह टिप्पणी उस कोड में दिखाई दी जो एक आदिम ओएस में संदर्भ स्विच को संभालती है। जब मैं सामना कर रहा था तो कोड कई सालों से उत्पादन में था।


2
इसे वूडू चिकन कोडिंग c2.com/cgi/wiki?VoodooChickenCoding
माइनसवेन जुवे

1
यहां तक ​​कि अगर कोडर इसे सच मानता है, तो भी उस तरह की टिप्पणी बड़े पैमाने पर अनपेक्षित है। कोड अच्छी तरह से जटिल हो सकता है, लेकिन यदि आप कोड को अन्यथा पढ़ते हैं, तो आप सोच सकते हैं कि यह सीधे-आगे था। सभी टिप्पणी करता है वृद्धि व्यामोह है!
रॉबी डी

3
यह तब भी हो सकता है जब एक पुराने कोडबेस को बनाए रखने के लिए, एक भाषा में अधिकांश वर्तमान विकास टीम के साथ बहुत सहज नहीं है।
पीसीरी

तो रबर बतख न केवल डिबगिंग के लिए है। अच्छा ... मुझे लगता है कि हम एक ही कंपनी में काम कर रहे हैं, हमारे पास इस तरह की कई टिप्पणियां हैं: P
py_script

ऐसी परिस्थितियां होती हैं जब एक एपीआई में एक गड़बड़ के कारण एक फिक्स बस काम करता है, और कोई बेहतर और तार्किक फिक्स नहीं है। कुछ संकलित तृतीय पक्ष परिवाद को डीबग करना कर्नेल डीबगिंग जितना गहरा हो सकता है। और यहां तक ​​कि अगर आपको समस्या मिली, तो डिबगिंग के घंटों के बाद बहुत कम ही आप कर सकते हैं। इसलिए आप समस्या को अलग तरीके से समझें। आप "ब्लैक बॉक्स" मॉडल को अपनाते हैं जो आपको संयोग से कार्यक्रम के लिए लागू करता है। आप ब्लैक बॉक्स के अजीब व्यवहार के साथ खेलते हैं और यदि आप इसे जिस तरह से आप चाहते हैं, काम करने के लिए इसे प्राप्त करने का प्रबंधन करते हैं, तो महान, "जादू मत छुओ" के साथ एक टिप्पणी जोड़ें और आगे बढ़ें।
रादु सिमियोनेस्कु

7

नए प्रोग्रामर के लिए, इस पर काबू पाने का सबसे महत्वपूर्ण हिस्सा वास्तव में यह समझना है कि वे क्या कर रहे हैं।

कई क्षेत्रों में, जब आप कुछ करना नहीं जानते हैं, तो आप सिर्फ परीक्षण और त्रुटि के द्वारा जाते हैं। कुछ करने की कोशिश; अगर यह काम करता है, महान, यदि नहीं, तो कुछ और प्रयास करें।

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

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

Takeaway यह है कि एक नए प्रोग्रामर के रूप में आपको वास्तव में यह समझाने में सक्षम होना है कि आपका कोड क्या करता है। आपको कोड पढ़ना सीखना है, न कि केवल लिखना।

(बेशक जो अनुभवी प्रोग्रामरों पर भी लागू होता है, लेकिन यहां मेरा अनुभव ज्यादातर नए पूर्ण शुरुआती लोगों के साथ रहा है।)


<< आपको कोड पढ़ना सीखना है, न कि केवल लिखना।
py_script

2

"रेसिंग लाइन पर" कोड, परीक्षण और ठीक करना बहुत आसान है। आपके पास कुछ कार्यक्षमता है जो X & Y को दी गई है, Z का उत्पादन करती है। लेकिन क्या होगा यदि X भ्रष्ट है और Y अनुपलब्ध है? क्या होगा अगर आप Z को आउटपुट करने में असमर्थ हैं? लगातार ध्यान रखें कि क्या गलत हो सकता है और परीक्षण चक्र के लिए इसे नोट कर सकते हैं।

अपनी दिनचर्या को छोटा और वर्णनात्मक रखें - सर्वोत्तम कोड के लिए कुछ (यदि कोई हो) टिप्पणियों की आवश्यकता होती है।

सार्थक विधि, वर्ग और परिवर्तनशील नाम पठनीयता की सहायता के लिए एक लंबा रास्ता तय करते हैं।

यदि आपको एक कोड गंध आती है तो STOP। उस गंध को दूर जाने की संभावना नहीं है और थोड़ा प्रयास अब आपको बाद में दु: ख की एक बड़ी राशि बचा सकता है।

अपनी विकास प्रक्रिया के भीतर परीक्षण शामिल करें। मैं BDD के बजाय TDD के उपयोग की वकालत करता हूँ क्योंकि यह आपको यह बताने के लिए मजबूर करता है कि आप परीक्षण के बेड़ा पर आँख बंद करके भरोसा करने के बजाय क्या हासिल करना चाहते हैं जो आपको सुरक्षा का झूठा एहसास दिला सकता है।

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

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