ตอน bugfixing quick, obvious change ไม่ได้เป็นที่ดีที่สุด และโค้ดหน้าตาไม่ได้เป็นทั้งเรื่อง ต้องรู้ ทำไม decisions ถูกทำ ต้องเข้าใจ history ข้างหลังโค้ด มี 3 วิธีเรียนรู้สิ่งที่ต้องการเพื่อเปลี่ยนโค้ดด้วยความมั่นใจ
git blame
ด้วย git blame trace ทุก version ของทุกบรรทัด จนถึงตอนเขียน
เช่น ดู ActiveJob queue_name.rb อยากรู้ queue_name_delimiter attribute ทำไมมี:
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) ...แต่ละบรรทัดตามลำดับเห็น:
- Revision ที่เปลี่ยนบรรทัดล่าสุด (
11ab04b1) - ชื่อ author ของ commit
- วันที่เปลี่ยน
เรียนรู้เพิ่มต้องการ revision number ส่ง id (11ab04b1) ให้ git show หรือ git log:
$ 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 ...Cool! เรียนรู้เพิ่มเกี่ยวกับการเปลี่ยน ทำไม useful และเห็น Rails Guide ส่วนที่อาจพลาด
ที่นี่โชคดี เจอ info ทันที แต git blame แสดงแค่ ล่าสุด ที่บรรทัดเปลี่ยน บางครั้งต้องย้อน 2-3 commits
ดู earlier commits เรียก git blame อีกครั้ง แตครั้งนี้ส่ง revision ก่อน commit ที่ git blame หา (ใน git "commit ก่อน commit นี้" ใส่ ^ หลัง revision เช่น 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 ...น่าเบื่อหน่อย
แทนสำรวจ editor Editors ส่วนใหญ่ทำให้ trace history ด้วย git blame ง่าย เช่น Emacs หลัง git blame วาง cursor บนบรรทัด กด a ย้อนแต่ละการเปลี่ยน และ l และ D ดูรายละเอียด commit
Team refer issue numbers และ pull requests ใน commit messages? ถ้าใช่ git blame พาไปจากบรรทัดโค้ด → commit → discussion เกี่ยว commit และ discussion นั่นคือที่มี really good stuff
GitHub Issues
พอดีเคยสังเกต Rails 4.2 ลบ respond_with ใน docs ชัดว่าลบ แตไม่เข้าใจทำไม
มีความรู้เยอะซ่อนอยู่หลัง GitHub issue search box อยากรู้ทำไม feature ถูกลบ ไม่มีที่ดีกว่าการอภิปรายของ team ระหว่างตัดสินใจลบ
Search Rails GitHub repo respond_with จะเจอ threads น่าสนใจ ถ้าอยากรู้ทำไมลบ จะไปที่ thread นี้ แต่บอก how ลบ ไม่ใช่ why
ต่อไปใน thread จะเจอ comment point ไปยัง discussion จริงๆ เกี่ยวกับลบ respond_with นั่นคือที่ดี!
เหมือน git blame อาจไม่เจอสิ่งที่หา ทันที ต้อง follow references, อ่าน comments, กด links แต GitHub issue search เริ่มที่ถูก และด้วย curiosity และ exploration จะเรียนรู้สิ่งที่มาหา
ถามคำถาม
เสียดายไม่ได้ knowledge ทั้งหมดจาก history, issues, PRs ไม่ได้เขียนทั้งหมด
ถ้าหา person ที่เขียนโค้ดต้นทางได้ ถามพวกเขา ค้นพบ dev culture และ ideas นำไปสู่ decision เรียน history ที่ไม่เคย recorded และได้ยิน paths ที่ไม่ได้ลอง ซึ่งอาจทำ sense ตอนนี้
The Easy Way Can Be Dangerous
บางครั้ง fix ดู ง่ายมาก แค่ rescue exception นี้ที่นี่ แล้วไปบ้าน!
แตเปลี่ยนโค้ดที่ไม่เข้าใจ อันตราย
ตอนบรรทัดโค้ดดู off หรือ decision ดูแปลก หรือ call ดู useless ใส่หมวก archaeologist เรียนรู้มากที่สุดได้ อย่างไรก็ตาม เกี่ยวกับโค้ดนั้น นั่นคือวิธีเปลี่ยนโค้ดด้วยเจตนา และแก้ปัญหาที่ราก
