जब आप बगफिक्सिंग के लिए जाते हैं, तो त्वरित, स्पष्ट परिवर्तन हमेशा सबसे अच्छा नहीं होता। और आपके सामने का कोड कभी पूरी कहानी नहीं होता। आसान फिक्स से आगे जाने के लिए, आपको यह जानना होगा कि क्यों कुछ निर्णय लिए गए थे। आपको कोड के पीछे के इतिहास को समझना होगा। और आत्मविश्वास से कोड बदलने के लिए आपको जो जानने की आवश्यकता है उसे सीखने के तीन शानदार तरीके हैं।
git blame
git blame की मदद से, आप एक परियोजना में कोड की हर लाइन के हर वर्जन को ट्रेस कर सकते हैं, जब यह लिखा गया था तब तक वापस।
उदाहरण के लिए, मान लीजिए कि आप ActiveJob के queue_name.rb फाइल को देख रहे थे, और आप जानना चाहते थे कि यह queue_name_delimiter एट्रिब्यूट क्या था:
included do class_attribute :queue_name, instance_accessor: false class_attribute :queue_name_delimiter, instance_accessor: false self.queue_name = default_queue_name self.queue_name_delimiter = '_' # set default delimiter to '_' endआप इस पर git blame चला सकते हैं:
$ git blame queue_name.rb ... da6a86f8 lib/active_job/queue_name.rb (Douwe Maan 2014-06-09 18:49:14 +0200 34) included do 1e237b4e activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-25 17:34:50 +0300 35) class_attribute :queue_name, instance_accessor: false 11ab04b1 activejob/lib/active_job/queue_name.rb (Terry Meacham 2014-09-23 15:51:44 -0500 36) class_attribute :queue_name_delimiter, instance_accessor: false 11ab04b1 activejob/lib/active_job/queue_name.rb (Terry Meacham 2014-09-23 15:51:44 -0500 37) ...और प्रत्येक लाइन के लिए, क्रम में, आप देखेंगे:
- वह रिविजन जिसने उस लाइन को सबसे हाल ही में बदला (
11ab04b1, उदाहरण के लिए), - उस कमिट के लेखक का नाम,
- और वह तारीख जब परिवर्तन किया गया था।
उस लाइन के कोड के बारे में अधिक जानने के लिए, आपको रिविजन नंबर की आवश्यकता होगी। git show या git log को आईडी पास करें (वह 11ab04b1 भाग):
$ git show 11ab04b1 commit 11ab04b11170253e96515c3ada6f2566b092533a Author: Terry Meacham <zv1n.fire@gmail.com> Date: Tue Sep 23 15:51:44 2014 -0500 Added queue_name_delimiter attribute. - Added ActiveJob::Base#queue_name_delimiter to allow for developers using ActiveJob to change the delimiter from the default ('_') to whatever else they may be using (e.g., '.', '-', ...). - Updated source guide to include a blurb about the delimiter. diff --git a/activejob/lib/active_job/queue_name.rb b/activejob/lib/active_job/queue_name.rb index d167617..6ee7142 100644 ...कूल! आप बदलाव के बारे में थोड़ा और सीखते हैं, यह क्यों उपयोगी है, और रेल्स गाइड का वह भाग देखते हैं जिसके बारे में आप पहले चूक गए होंगे।
यहां, हम काफी भाग्यशाली रहे। हमें वह जानकारी तुरंत मिल गई जिसकी हम तलाश कर रहे थे। लेकिन git blame केवल आपको दिखाता है कि वह लाइन सबसे हाल ही में कब बदली गई। और कभी-कभी, आप जो खोज रहे हैं उसे तब तक नहीं पाएंगे जब तक आप दो या तीन कमिट वापस नहीं जाते।
पहले के कमिट्स देखने के लिए, आप git blame को फिर से कॉल कर सकते हैं। लेकिन इस बार, git blame द्वारा पाए गए कमिट से पहले का रिविजन पास करें। (गिट में, आप एक ^ को रिविजन के बाद रखकर "इस अन्य कमिट से पहले का कमिट" कह सकते हैं, जैसे 11ab04b1^):
$ git blame 11ab04b1^ queue_name.rb ... da6a86f8 lib/active_job/queue_name.rb (Douwe Maan 2014-06-09 18:49:14 +0200 33) included do 1e237b4e activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-25 17:34:50 +0300 34) class_attribute :queue_name, instance_accessor: false 94ae25ec activejob/lib/active_job/queue_name.rb (Cristian Bica 2014-08-15 23:32:08 +0300 35) self.queue_name = default_queue_name ... $ git blame 1e237b4e^ queue_name.rb ... and so on ...यह बहुत दिमाग सुन्न करने वाला है, हालांकि।
इसके बजाय, अपने टेक्स्ट एडिटर का पता लगाएं। अधिकांश एडिटर्स git blame के साथ इतिहास के माध्यम से ट्रेस करना आसान बनाते हैं। उदाहरण के लिए, Emacs में, अपने कोड को git blame-ing करने के बाद, अपना कर्सर एक लाइन पर रखें। फिर, आप उस लाइन को प्रभावित करने वाले प्रत्येक परिवर्तन के माध्यम से पीछे हटने के लिए a दबा सकते हैं, और एक कमिट के बारे में अधिक विवरण देखने के लिए l और D का उपयोग कर सकते हैं।
क्या आपकी टीम आपके कमिट मैसेज में इश्यू नंबर और पुल रिक्वेस्ट का उल्लेख करती है? यदि हां, तो git blame आसानी से आपको कोड की एक लाइन से, एक कमिट तक, उस कमिट के बारे में चर्चा तक ले जा सकता है। और वह चर्चा वह जगह है जहां आपको वास्तव में अच्छी चीजें मिलेंगी।
GitHub Issues
थोड़ी देर पहले, मैंने देखा कि रेल्स 4.2 ने respond_with को हटा दिया। डॉक्स में, यह स्पष्ट है कि इसे हटा दिया गया था, लेकिन मुझे समझ नहीं आया कि क्यों।
GitHub के इश्यू सर्च बॉक्स के पीछे बहुत सारा बेहतरीन ज्ञान छिपा हुआ है। यदि आप जानना चाहते हैं कि कोई फीचर क्यों हटाया गया, तो उसे सीखने के लिए कोई बेहतर जगह नहीं है जो टीम ने इसे हटाने का फैसला करते समय की थी।
तो, यदि आप रेल्स के GitHub रेपो में respond_with के लिए खोज करते हैं, तो आपको respond_with के बारे में कुछ दिलचस्प थ्रेड मिलेंगे। यदि आप यह पता लगाने की कोशिश कर रहे हैं कि इसे क्यों हटाया गया, तो आप शायद इस थ्रेड पर पहुंचेंगे। दुर्भाग्य से, यह बताता है कि इसे कैसे हटाया गया, लेकिन क्यों नहीं।
बाद में उस थ्रेड में, हालांकि, आपको एक कमेंट मिलेगा जो respond_with को हटाने के बारे में वास्तविक चर्चा की ओर इशारा करता है। वहीं अच्छी चीजें हैं!
git blame की तरह, हो सकता है कि आप तुरंत वही न पाएं जो आप खोज रहे हैं। आपको रेफरेंस का पालन करना होगा, कमेंट्स पढ़ने होंगे, और लिंक्स पर क्लिक करना होगा। लेकिन GitHub का इश्यू सर्च आपको सही जगह पर शुरू करेगा। और थोड़ी जिज्ञासा और अन्वेषण की भावना के साथ, आप वह सीखेंगे जो आप लेने आए थे।
प्रश्न पूछें
दुर्भाग्य से, एक परियोजना के बारे में सभी ज्ञान इसके इतिहास, इश्यूज, और पुल रिक्वेस्ट में नहीं पाया जा सकता। सब कुछ लिखा नहीं गया है।
इसलिए यदि आप उस व्यक्ति को ढूंढ सकते हैं जिसने मूल रूप से कोड लिखा था, तो इसके बारे में पूछें। आप उस डेव संस्कृति और विचारों की खोज करेंगे जो एक निर्णय का कारण बने। आप परियोजना के बारे में कुछ इतिहास सीखेंगे जो शायद कभी रिकॉर्ड नहीं किया गया था। और आप उन रास्तों के बारे में सुनेंगे जिन्हें कभी नहीं आजमाया गया, जो वास्तव में अब आजमाने लायक हो सकते हैं।
आसान तरीका खतरनाक हो सकता है
कभी-कभी, एक फिक्स बस इतना आसान लगता है। आपको बस इस एक अपवाद को इस एक जगह पर रेस्क्यू करना है, और फिर आप घर जा सकते हैं!
लेकिन उस कोड को बदलना खतरनाक है जिसे आप नहीं समझते।
तो जब कोड की एक लाइन अजीब लगती है, या एक निर्णय अजीब लगता है, या एक कॉल बेकार लगता है, तो अपना पुरातत्वविद् की टोपी पहनें। जितना हो सके उतना सीखें, जैसे भी आप कर सकते हैं, उस कोड के बारे में। इस तरह आप अपने कोड परिवर्तन को जानबूझकर करेंगे, और समस्या को उसकी जड़ में ठीक करेंगे।
