क्या नोट्स, विचार, एल्गोरिदम, कोडिंग और रखरखाव के दौरान निर्णय लिखना सामान्य / स्वीकार्य है? [बन्द है]


22

कुछ लोगों को यह समस्या है कि वे शब्दों के बिना नहीं सोच सकते। और उनके विचारों और निर्णयों को लिखना आगे बढ़ने का सबसे प्रभावी तरीका है।

तो - क्या यह सामान्य और स्वीकार्य है कि मैं कोडिंग के दौरान कुछ नोटपैड ++ फ़ाइल में अपने विचारों और निर्णयों को लिखूं?

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

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


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

21
मुझे ऐसा लग रहा है कि हम संदर्भ का हिस्सा याद कर रहे हैं? क्या यह अवलोकन दक्षता के इर्द-गिर्द एक शिकायत के आसपास किया गया था? अक्सर, आलोचना मूल कारण के लिए सुझाव के साथ आती है जो प्रासंगिक हो सकती है या नहीं।
जिम रश

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

4
... पुनश्च: मैं आमतौर पर पेंसिल और कागज, या इस सामान के लिए एक सफेद बोर्ड पसंद करता हूं, और मुझे लगता है कि मैं एक बेहतर प्रोग्रामर नहीं बनूंगा अगर मैं यह सब अपने सिर में करने की कोशिश करूंगा, काफी विपरीत।
डॉक ब्राउन

7
यह स्वीकार्य क्यों नहीं होगा? स्वीकार्य कौन?
पॉल डी। वेट

जवाबों:


62

न केवल यह सामान्य है, यह एक अच्छा विचार है।

एक प्रसिद्ध उद्धरण है

"मुझे एक पेड़ को काटने के लिए छह घंटे का समय दें और मैं पहले चार कुल्हाड़ियों को तेज करने में खर्च करूंगा"।

अपने विचारों को व्यवस्थित करने के लिए समय निकालना और कोडिंग से पहले अपने काम की योजना बनाना समय व्यतीत करना है। उन विचारों को कागज पर डालने से आपको अपनी योजनाओं को प्रतिबिंबित करने, उनकी आलोचना करने और उन्हें उन तरीकों से व्यवस्थित करने का समय मिलेगा, जो केवल "अपने सिर में" किए जाने पर बहुत मुश्किल होगा।


8
यह एक अच्छा उद्धरण है, हालांकि मैं गलत आरोप को हटा दूंगा। quotinvestigator.com/tag/abraham-lincoln
पॉल ड्रेपर

1
निश्चित रूप से एक सच्चा बयान और अच्छा उद्धरण, लेकिन मेरी समझ में सवाल का एक अलग ध्यान केंद्रित है। जहां तक ​​मैं इसे समझता हूं, ओपी को पहले से योजना बनाने के महत्व के बारे में कोई संदेह नहीं है। वह पूछ रहा है कि क्या इन विचारों को लिखने / योजना बनाने में अधिक कुशल है, या केवल उन सभी को अपने सिर में रखना है।
डॉक्टर ब्राउन

2
रेकिंग का एक घंटे का समय पर्याप्त से अधिक है। इस कार्य को अधिकतम 3 घंटे अनुमानित किया जाना चाहिए था, लेकिन सुस्त व्यर्थ अति-तैयारी पर खर्च किया गया है। फिर क्या था नैतिक? ;-)
स्टीव जेसप

26

हां, यह पूरी तरह से स्वीकार्य और सामान्य है।

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

इन नोटों को सीधे कोड में टिप्पणी के रूप में शामिल किया जा सकता है, यदि बहुत कम हो। एक्सटेंडेड कमेंट्री को अक्सर बाहरी तकनीकी डिजाइन दस्तावेज के हिस्से के रूप में रखा जाता है।


4
मैं डिजाइन विकल्पों पर विचार करने और स्रोत कोड में टिप्पणियों के रूप में निर्णय लेने की कोशिश करने के बारे में नोटों को शामिल नहीं करने की भारी सिफारिश करूंगा , ये कभी भी "कम पर्याप्त" नहीं हैं। केवल उस विचार प्रक्रिया के अंतिम परिणाम, लेकिन यह ओपी से जो पूछ रहा था, उससे काफी अलग है।
डॉक ब्राउन

3
मैं अक्सर "हम यह निर्णय क्यों लेते हैं" की तर्ज पर खुद को चर्चाओं में पाते हैं। हमारे द्वारा चर्चा की गई विकल्पों सहित, संदर्भ प्रदान करने के लिए मेरे दैनिक प्रोजेक्ट नोट्स पर वापस जाने के लिए यह अविश्वसनीय रूप से सहायक है। मुझे लगता है कि मैं अच्छी कंपनी में हूं: द एवरीथिंग स्टोर के अनुसार जेफ बेजोस ऐसा ही करते हैं।
kdgregory

8
@DocBrown - कभी-कभी यह उन कारणों को शामिल करने के लिए एक अच्छा विचार है कि आपने अन्य संभावित तरीकों / एल्गोरिदम का उपयोग क्यों नहीं किया , इसलिए भविष्य के डेवलपर ने आपके द्वारा किए गए काम को बदलने की कोशिश नहीं की होगी
HorusKol

1
@ हॉर्सकॉल: निश्चित रूप से, कुछ दुर्लभ मामलों में, यह सामान्य ज्ञान है। लेकिन यह "निर्णय लेने की प्रक्रिया का दस्तावेजीकरण" करने से काफी अलग है ।
डॉक ब्राउन

1
@DocBrown सही है, मुझे नहीं लगता कि कोई भी अपने सोर्स कोड में नोटों के पेज चाहता है। :)
mcknz

20

यह एक अच्छा विचार है। जब तक यह शिथिलता का एक तरीका नहीं बन जाता।

कुंजी संतुलन है। मुझे लगता है कि मैं सबसे अधिक उत्पादक हूं अगर मैं अपने आप को बॉक्स में नहीं रखता लेकिन विचारों को पकड़ लेता हूं जैसे वे आते हैं।

अगर मैं एक निचले स्तर पर पीस रहा हूं और एक उच्च स्तर का विचार आता है, तो मैं इसे संक्षेप में बता देता हूं और बाद में वापस आता हूं।

काम की योजना बनाना एक अच्छा विचार है, लेकिन जब तक आपको दर्शकों के सामने संवाद या प्रस्तुत नहीं करना पड़ता है, तब तक सबसे अच्छा उपकरण पेन और नैपकिन हैं। विचार को पकड़ें। यह सुंदर बनाने में समय बर्बाद मत करो।


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

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

9

किसी भी पेशेवर स्थिति में, यह न केवल "सामान्य और स्वीकार्य" है, यह अनिवार्य है। किसी भी कोडिंग के शुरू होने से पहले दो चक्रों में विशिष्ट विकास चक्र शामिल होते हैं:

  1. कार्यात्मक आवश्यकताएँ दस्तावेज़: आमतौर पर व्यापार विश्लेषकों द्वारा लिखा गया है, कार्यक्षमता को लागू करने के लिए निर्दिष्ट करता है।

  2. विस्तार से डिजाइन दस्तावेज़: जो काफी तुम क्या बारे में अभी और अधिक औपचारिक, बात कर रहे हैं, प्रणाली के कार्यात्मक अपघटन (फैक्टरिंग), एल्गोरिदम, आदि को निर्दिष्ट मेरी (बहुत) पुराने लोगों में से कुछ है ऑनलाइन, जैसे हैं यह

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


4

इस तरह की जानकारी डालने के लिए एक शानदार जगह सीधे आपके संस्करण नियंत्रण प्रणाली (एसवीएन, गिट, आदि) के प्रतिबद्ध संदेश में है। इस तरह आप एक ही स्थान पर उनके लिए परिवर्तन और तर्क देख सकते हैं।


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

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

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

इसे संस्करण नियंत्रण प्रणाली में रखना बहुत अच्छा है। एक बेहतर जगह हालांकि अंदर एक सादे पाठ फ़ाइल है। उन प्रतिबद्ध संदेशों की तुलना में उपयोग करना आसान है।
Thorbjørn Ravn Andersen

2

अन्य अच्छे उत्तरों के अलावा, मैं यह जोड़ूंगा कि मैं अक्सर अपने विचारों को लिखता हूं कि मैं क्या करने की कोशिश कर रहा हूं।

मैं जो करने की कोशिश कर रहा हूं, उसे स्पष्ट करने के बारे में स्पष्ट होने से मुझे अनुमानों, मान्यताओं और / या आवश्यकताओं को महसूस करने में मदद मिलती है जो जरूरी नहीं रखती हैं।

इसके बाद विकल्प पर संकेत दिया जाता है, जिसे मैं बाद में बेहतर रूप से बेहतर बना सकता हूं; अगर मैं कुछ और सोचता हूं तो लेखन मेरी जगह बचाने में मदद करता है।

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


1

कुछ भी लिखना जो आपको बचा सकता है / (नया) टीममैंबर्स का समय समय अच्छी तरह से व्यतीत होता है। बस यह सुनिश्चित करें कि यह कुछ ऐसा है जिसे किसी को बाद में आवश्यकता हो सकती है और जब तक यह एक वास्तविक दीर्घकालिक परियोजना नहीं है, तब तक इसे खत्म न करें।

यह भी किसी भी समय नहीं लेना चाहिए। यदि आप यह सोचकर समय बिताते हैं कि आप अपने विचारों को 1 से 1 तक लिख सकते हैं (जब तक वे किसी के लिए उपयोगी होंगे / हो सकते हैं)।

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

यदि आपकी पसंद कुछ भी नहीं लिखने और नोटपैड पर केवल अनफ़ॉर्मल नोट्स लिखने के बीच है, तो बस असंगत नोट लिखें।


1

आप कहते हैं: "कुछ लोगों को यह समस्या है कि वे शब्दों के बिना नहीं सोच सकते हैं। और अपने विचारों और निर्णयों को लिखना आगे बढ़ने का सबसे प्रभावी तरीका है।"

यदि अपने विचारों और निर्णयों को लिखना आगे बढ़ने का सबसे प्रभावी तरीका है, तो सबसे प्रभावी तरीके से आगे बढ़ना सामान्य और स्वीकार्य क्यों नहीं होगा? आप वही करते हैं जो आपके लिए सबसे अच्छा काम करता है। यह किसी और के लिए सबसे अच्छा काम नहीं हो सकता है। उस स्थिति में आप किसी और को यह बताने नहीं देते कि आपके लिए सबसे अच्छा क्या है, और आप उन्हें यह नहीं बताएँगे कि उनके लिए सबसे अच्छा क्या है। हर कोई वही करता है जो उनके लिए सबसे अच्छा है।


1

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

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

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

आपके लिए जो भी विधि काम करती है उसका उपयोग करने में बुरा न मानें, लेकिन यह नोटिस करने की कोशिश करें कि आपके "कुशल" सहयोगियों ने किन तरीकों का उपयोग किया है। उनकी वही मानवीय सीमाएँ हैं जो आप करते हैं।


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