लगभग हर उन्नत प्रोग्रामर का कहना है कि अन्य पेशेवरों के कोड को पढ़ना बहुत उपयोगी है। आमतौर पर वे खुले स्रोत की सलाह देते हैं।
आप इसे पढ़ते हैं या नहीं? यदि आप करते हैं, तो कितनी बार और कोड पढ़ने की प्रक्रिया क्या है? इसके अलावा, SVN से निपटने के लिए newbies के लिए यह थोड़ा मुश्किल है - फाइलों का एक गुच्छा। इसका क्या उपाय है?
जवाबों:
आप इसे पढ़ते हैं या नहीं?
हाँ।
यदि आप करते हैं, तो कितनी बार
रोज। लगातार। मैं कई ओपन-सोर्स प्रोजेक्ट्स (ज्यादातर पायथन-संबंधी) के साथ काम करता हूं और स्रोत को पढ़ना चाहिए क्योंकि यह सबसे सटीक प्रलेखन है।
और कोड पढ़ने की प्रक्रिया क्या है?
उम। खोलें और पढ़ें।
इसके अलावा, SVN से निपटने के लिए newbies के लिए यह थोड़ा मुश्किल है - फाइलों का एक गुच्छा। इसका क्या उपाय है?
खोलें और पढ़ें। तो और पढ़ें
यह आसान नहीं है। कुछ भी आसान नहीं है। समझने के लिए कोई रॉयल रोड नहीं है। यह काम लेता है।
आपके पास के लिए कई परतें हैं। सबसे पहले, उच्च स्तर पर शुरू करें, बोलने के लिए एक पक्षी-आंखों का दृश्य। एक बार जब आप एक परियोजना की जाँच करते हैं तो एक निर्देशिका संरचना में फ़ाइलों का एक गुच्छा होगा। यह वही है चाहे आप खुले स्रोत या बंद स्रोत को देख रहे हों (स्रोत कोड सभी के बाद स्रोत कोड है)। तो इसकी शुरुआत करें:
यह अभ्यास करता है, लेकिन यह निश्चित रूप से उल्लेखनीय है। आपके द्वारा उपयोग किए जा रहे पुस्तकालयों और चौखटों के बारे में जितना अधिक आप जानते हैं, उतना ही आप जानते हैं कि कोड को कैसे व्यवस्थित करने की आवश्यकता है और विशिष्ट प्रश्नों के उत्तर की तलाश में कहां है। कुछ कोड का पालन करना थोड़ा कठिन है, खासकर अगर यह काफी हद तक अप्रत्यक्ष है। इसलिए आपको पेंसिल और कागज की आवश्यकता है। आखिरकार आपके सिर में एक प्रकाश बल्ब बंद हो जाता है और आप इसे प्राप्त करते हैं। जब बाकी कोड पढ़ते हैं तो पूरी तरह से अधिक समझ में आता है।
यह ऐसा नहीं है जैसे आप एक उपन्यास पढ़ते हैं, बल्कि यह भी पसंद है कि आप एक संदर्भ पुस्तक कैसे पढ़ते हैं। एक अच्छा तरीका संदेश में एक चेक से हाल ही में तय किए गए बग को चुनना है, जो कुछ भी बदला है उसका एक प्रकार करें, और संबंधित हिस्सों को तब तक पढ़ें जब तक आप समस्या और समाधान दोनों को नहीं समझते। अच्छी तरह से प्रचारित सुरक्षा कमजोरियां लेने के लिए मजेदार बग हैं क्योंकि मंचों पर उनके बारे में बहुत चर्चा होती है। फिर बग ट्रैकर से "लो हैंगिंग फ्रूट" बग्स में से एक को चुनें और तब तक पढ़ें जब तक आपको समझ न आ जाए कि इसे खुद कैसे ठीक किया जाए। अधिकांश कोड पढ़ने वाले पेशेवर बग को ठीक करने या सुविधाओं को जोड़ने के पाठ्यक्रम में आकस्मिक हैं।
आमतौर पर सबसे अच्छा कोड नमूने मुश्किल से ध्यान देने योग्य होते हैं। आप तुरन्त उन्हें एक से अधिक बार बिना पढ़े समझ जाएंगे। वे यह देखते हैं कि यह लिखना बेहद आसान था, भले ही कोड आमतौर पर कई ड्राफ्ट से गुजरता हो। यह विरोधाभास की भावना पैदा करता है कि निश्चित रूप से दिए गए कोड इसे करने का स्पष्ट तरीका है, भले ही यह पहला तरीका नहीं है जिसके बारे में आपने सोचा था।
जब आप उस तरह के कोड में आते हैं, तो उस अंतर्दृष्टि को समझने की कोशिश करें जो इसे लिखने में गया था, और डिजाइन सिद्धांत शामिल थे, इसलिए जब आप भविष्य में खुद को इसी तरह की स्थिति में पाते हैं तो आप उसी सिद्धांतों को उम्मीद से लागू कर सकते हैं।
एक चाल जब मैं कुछ जटिल फ़ंक्शन को पढ़ता हूं तो अक्सर उपयोग करता हूं, कोड सेगमेंट को तर्क को बदलने के बिना इसे कुछ और पठनीय में फिर से शुरू करना है।
"फाइलों का एक गुच्छा" मुश्किल से कैसे निपटना है? जब आप अपना कोड लिखते हैं, तब तक यह अलग नहीं होता है, जब तक कि आपको इसके संगठन का पूर्व ज्ञान न हो, जब तक कि यह दस्तावेज न हो।
यदि आप एक दावा किए गए प्रोग्रामर के रूप में, "फाइल का एक गुच्छा" से प्रोजेक्ट संरचना का पता नहीं लगा सकते हैं या तो यह एक अत्यंत खराब संगठित परियोजना है, या आप एक अयोग्य प्रोग्रामर (या, चरम मामलों में, दोनों) हैं।
पढ़ना शुरू करें, कुछ प्रवेश बिंदुओं या अन्यथा आवश्यक धुरी कक्षाओं / विधियों को खोजने का प्रयास करें, और यह समझने का निर्माण करें कि यह सब वहां से कैसे आता है। तुरंत नहीं होगा, समय लगेगा, लेकिन अगर कोई प्रलेखन नहीं है, तो भी किया जा सकता है।
किसी अन्य परियोजना के कोड को पढ़ते समय आप जिस चीज की आशा कर सकते हैं, वह है एपीआई या सॉफ्टवेयर का टुकड़ा, यह है कि चर, फ़ंक्शन और मैक्रो नाम संक्षिप्त रूप से या नामित नहीं हैं ताकि आप उनके इरादे का पता लगा सकें।
लेकिन इसके अलावा, यह भाषा, प्रोग्रामिंग तकनीकों में फैले ज्ञान का एक सभ्य राशि लेता है और कोड के उद्देश्य के बारे में भी जटिल कोड में गोता लगाने में सक्षम है।
मैं वर्तमान में यह देखने की कोशिश कर रहा हूं कि लुआ किस तरह से कुछ जादू करता है, लेकिन मैं ऊपर उस बिंदु पर पहुंच रहा हूं, जहां बहुत सारे पहचानकर्ताओं को अस्पष्ट रूप से नामित किया गया है, बल्कि उस बिंदु पर संक्षिप्त किया गया है जहां मैं यह पता नहीं लगा सकता कि कौन सी रेखा कोशिश कर रही है फ़ंक्शन कोड में कुछ बिंदु पर मुझे पता होना चाहिए कि करने के लिए ... लगातार एकल अक्षर चर और बल्कि संक्षिप्त मैक्रो / फ़ंक्शन नाम मेरे सिर में कर रहे हैं।
"पहले, उच्च स्तर पर शुरू होने के बाद, एक पक्षी-दृष्टि को देखें" जैसा कि @Berin Loritsch ने दावा किया है कि यदि आप किसी भी तरह के हैं तो आप unittests और / या इंटीग्रेशन को देख सकते हैं।
unittests यह देखने के लिए दिलचस्प है कि (एपी) विवरण कैसे काम करते हैं।
इंटीग्रेटेस्ट आमतौर पर बसाइनप्रोसेस पर एक अच्छा अवलोकन देता है।