ไปไกลกว่าการแก้ไขอย่างง่ายด้วยรหัสโบราณคดี

เมื่อคุณแก้ไขจุดบกพร่อง การเปลี่ยนแปลงที่รวดเร็วและชัดเจนอาจไม่ใช่สิ่งที่ดีที่สุดเสมอไป และรหัสที่อยู่ตรงหน้าก็ไม่ใช่เรื่องราวทั้งหมด หากต้องการไปไกลกว่าการแก้ไขง่ายๆ คุณต้องรู้ว่า ทำไม มีการตัดสินใจบางอย่าง คุณต้องเข้าใจประวัติเบื้องหลังโค้ด และมีสามวิธีที่ยอดเยี่ยมในการเรียนรู้สิ่งที่คุณต้องรู้เพื่อเปลี่ยนรหัสอย่างมั่นใจ

โทษคอม

ด้วยความช่วยเหลือของ git blame คุณสามารถติดตามโค้ดทุกบรรทัดในโปรเจ็กต์ได้ในทุกเวอร์ชัน ย้อนหลังไปถึงตอนที่เขียน

ตัวอย่างเช่น สมมติว่าคุณกำลังดู queue_name.rb . ของ ActiveJob และคุณต้องการทราบว่า queue_name_delimiter . นี้คืออะไร แอตทริบิวต์เป็นเรื่องเกี่ยวกับ:

activejob/lib/active_job/queue_name.rb

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 เช่น)
ชื่อผู้เขียนของการกระทำนั้น
และวันที่ทำการเปลี่ยนแปลง

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับรหัสบรรทัดนั้น คุณจะต้องมีหมายเลขการแก้ไข ส่ง id (ที่ 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
...

เย็น! คุณจะได้เรียนรู้เพิ่มเติมเล็กน้อยเกี่ยวกับการเปลี่ยนแปลงนี้ เหตุใดจึงมีประโยชน์ และดูส่วนต่างๆ ของ Rails Guide เกี่ยวกับการเปลี่ยนแปลงที่คุณอาจพลาดไปก่อนหน้านี้

ที่นี่เราโชคดีมาก เราพบข้อมูลที่เรากำลังมองหาทันที แต่ git blame แสดงเฉพาะ ล่าสุด เวลาที่บรรทัดนั้นเปลี่ยนไป และบางครั้ง คุณจะไม่พบสิ่งที่คุณกำลังมองหาจนกว่าคุณจะกลับไปสองหรือสามครั้ง

หากต้องการดูการกระทำก่อนหน้านี้ คุณสามารถเรียก git blame อีกครั้ง. แต่คราวนี้ ผ่านการแก้ไข ก่อน คอมมิชชัน git blame พบแล้ว (ใน git คุณสามารถพูดว่า “the commit before this other commit” โดยใส่ ^ หลังการแก้ไข เช่น 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

เมื่อไม่นานมานี้ ฉันสังเกตว่า Rails 4.2 ได้ลบ respond_with . ในเอกสาร ชัดเจนว่าลบแล้ว แต่ฉันไม่เข้าใจว่าทำไม

มีความรู้มากมายซ่อนอยู่หลังช่องค้นหาปัญหาของ GitHub หากคุณต้องการทราบว่าเหตุใดคุณลักษณะจึงถูกลบ ไม่มีที่ใดที่จะดีไปกว่าการสนทนาที่ทีมมีในขณะที่พวกเขาตัดสินใจที่จะลบออก

ดังนั้น หากคุณค้นหา GitHub repo ของ Rails สำหรับ respond_with คุณจะพบกระทู้ที่น่าสนใจเกี่ยวกับ respond_with . หากคุณกำลังพยายามหาสาเหตุว่าทำไมมันถึงถูกลบออก คุณอาจจะเข้ามาในกระทู้นี้ ขออภัย มันอธิบาย วิธีการ มันถูกลบไปแล้ว แต่ไม่ใช่ ทำไม .

ต่อมาในชุดข้อความนั้น คุณจะพบความคิดเห็นที่ชี้ไปที่การสนทนาจริงเกี่ยวกับการลบ respond_with . นั่นคือสิ่งที่ดี!

เช่นเดียวกับ git blame คุณอาจไม่พบสิ่งที่คุณต้องการในทันที คุณจะต้องติดตามข้อมูลอ้างอิง อ่านความคิดเห็น และคลิกลิงก์ แต่การค้นหาปัญหาของ GitHub จะช่วยให้คุณเริ่มต้นถูกที่ และด้วยความอยากรู้อยากเห็นและความรู้สึกสำรวจเพียงเล็กน้อย คุณจะได้เรียนรู้ว่าตัวเองเกิดมาเพื่ออะไร

ถามคำถาม

น่าเสียดายที่ความรู้ทั้งหมดเกี่ยวกับโครงการไม่สามารถพบได้ในประวัติ ปัญหา และคำขอดึง ไม่ใช่ทุกอย่างที่เขียนลงไป

ดังนั้น หากคุณพบบุคคลที่เขียนโค้ดดังกล่าวในตอนแรก ให้ถามเกี่ยวกับมัน คุณจะค้นพบวัฒนธรรมและแนวคิดของนักพัฒนาซอฟต์แวร์ที่นำไปสู่การตัดสินใจ คุณจะได้เรียนรู้ประวัติศาสตร์บางอย่างเกี่ยวกับโครงการที่อาจไม่เคยมีการบันทึก และคุณจะได้ยินเกี่ยวกับเส้นทางที่ไม่เคยไป ซึ่งอาจสมเหตุสมผลที่จะลองตอนนี้

วิธีที่ง่ายอาจเป็นอันตรายได้

บางครั้ง การแก้ไขดูเหมือนง่ายมาก . สิ่งที่คุณต้องทำคือช่วยชีวิตข้อยกเว้นนี้ไว้ในที่เดียว จากนั้นคุณสามารถกลับบ้านได้!

แต่การเปลี่ยนรหัสที่คุณไม่เข้าใจนั้นอันตราย

ดังนั้นเมื่อโค้ดไม่ตรงกัน หรือการตัดสินใจดูแปลกๆ หรือการโทรดูเหมือนไร้ประโยชน์ ให้สวมหมวกนักโบราณคดีของคุณ เรียนรู้ให้มากที่สุดเท่าที่จะทำได้เกี่ยวกับรหัสนั้น นั่นคือวิธีที่คุณจะเปลี่ยนรหัสโดยเจตนาและแก้ไขปัญหาที่ราก