कोड पुरातत्व के साथ आसान सुधार से परे जाएं

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

गिट दोष

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 <[email protected]>
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 . के बाद -अपना कोड दर्ज करते हुए, अपने कर्सर को एक लाइन पर रखें। फिर, आप a . दबा सकते हैं उस पंक्ति को प्रभावित करने वाले प्रत्येक परिवर्तन से पीछे हटने के लिए, और l . का उपयोग करें और D प्रतिबद्धता के बारे में अधिक विवरण देखने के लिए।

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

Github मुद्दे

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

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

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

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

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

प्रश्न पूछें

दुर्भाग्य से, किसी परियोजना के बारे में सभी ज्ञान उसके इतिहास, मुद्दों और पुल अनुरोधों में नहीं पाया जा सकता है। सब कुछ लिखा नहीं है।

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

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

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

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

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