क्विक फिक्स से आगे: स्मार्ट बग मरम्मत के लिए कोड पुरातत्व में महारत हासिल करें

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

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, उदाहरण के लिए),
  
उस कमिट के लेखक का नाम,
  
और वह तारीख जब परिवर्तन किया गया था।


उस लाइन के बारे में अधिक जानने के लिए, आपको रिविजन नंबर की आवश्यकता होगी। आईडी (11ab04b1 भाग) को git show या git log में पास करें:

$ git show 11ab04b1 commit 11ab04b11170253e96515c3ada6f2566b092533a Author: Terry Meacham  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 ... 

कूल! आप परिवर्तन के बारे में थोड़ा और सीखते हैं, यह क्यों उपयोगी है, और इसके बारे में Rails गाइड का वह भाग देखें जिसे आप पहले चूक गए होंगे।

यहां, हम बहुत भाग्यशाली रहे। हमें वह जानकारी तुरंत मिल गई जिसकी हम तलाश कर रहे थे। लेकिन git blame केवल आपको वह सबसे हाल का समय दिखाता है जब वह लाइन बदली गई थी। और कभी-कभी, आप जो खोज रहे हैं वह तब तक नहीं मिलेगा जब तक आप दो या तीन कमिट पीछे नहीं जाते।

पहले के कमिट देखने के लिए, आप git blame को फिर से कॉल कर सकते हैं। लेकिन इस बार, git blame द्वारा पाए गए कमिट से पहले का रिविजन पास करें। (git में, आप "इस अन्य कमिट से पहले का कमिट" कह सकते हैं रिविजन के बाद ^ लगाकर, जैसे 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

थोड़ी देर पहले, मैंने देखा कि Rails 4.2 ने respond_with हटा दिया। डॉक्स में, यह स्पष्ट है कि इसे हटा दिया गया था, लेकिन मुझे समझ नहीं आया कि क्यों।

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

तो, यदि आप Rails के GitHub रेपो में respond_with के लिए खोज करते हैं, तो आपको respond_with के बारे में कुछ दिलचस्प थ्रेड मिलेंगे। यदि आप यह पता लगाने की कोशिश कर रहे हैं कि इसे क्यों हटाया गया, तो आप शायद इस थ्रेड पर पहुंचेंगे। दुर्भाग्य से, यह बताता है कैसे इसे हटाया गया, लेकिन क्यों नहीं।

बाद में उस थ्रेड में, हालांकि, आपको एक टिप्पणी मिलेगी जो respond_with को हटाने के बारे में वास्तविक चर्चा की ओर इशारा करती है। वहीं अच्छा सामान है!

git blame की तरह, आप शायद तुरंत वही नहीं ढूंढ पाएंगे जो आप खोज रहे हैं। आपको संदर्भों का पालन करना होगा, टिप्पणियां पढ़नी होंगी, और लिंक पर क्लिक करना होगा। लेकिन GitHub का इश्यू सर्च आपको सही जगह से शुरू करेगा। और थोड़ी जिज्ञासा और अन्वेषण की भावना के साथ, आप वह सीखेंगे जो आप लेने आए थे।

सवाल पूछें

दुर्भाग्य से, एक प्रोजेक्ट के बारे में सभी ज्ञान इसके इतिहास, इश्यूज़, और पुल रिक्वेस्ट में नहीं पाया जा सकता। सब कुछ लिखा नहीं जाता।

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

आसान तरीका खतरनाक हो सकता है

कभी-कभी, एक फिक्स बस इतना आसान लगता है। आपको बस इस एक अपवाद को इस एक जगह पर रेस्क्यू करना है, और फिर आप घर जा सकते हैं!

लेकिन उस कोड को बदलना खतरनाक है जिसे आप नहीं समझते।

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