Khi bạn tiến hành sửa lỗi, thay đổi nhanh chóng, rõ ràng không phải lúc nào cũng là thay đổi tốt nhất. Và đoạn mã trước mặt bạn không bao giờ là toàn bộ câu chuyện. Để vượt ra khỏi cách khắc phục dễ dàng, bạn phải biết tại sao một số quyết định đã được thực hiện. Bạn phải hiểu lịch sử đằng sau mã. Và có ba cách tuyệt vời để học những gì bạn cần biết để tự tin thay đổi mã.
git đổ lỗi
Với sự trợ giúp của git blame , bạn có thể theo dõi mọi phiên bản của mọi dòng mã trong một dự án, quay trở lại thời điểm nó được viết.
Ví dụ:giả sử bạn đang xem queue_name.rb của ActiveJob và bạn muốn biết queue_name_delimiter này là gì thuộc tính tất cả về:
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
Bạn có thể chạy git blame trên đó:
$ 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)
...
Và đối với mỗi dòng, theo thứ tự, bạn sẽ thấy:
- Bản sửa đổi đã thay đổi dòng đó gần đây nhất (
11ab04b1, chẳng hạn), - Tên tác giả của cam kết đó,
- Và ngày thực hiện thay đổi.
Để tìm hiểu thêm về dòng mã đó, bạn sẽ cần số sửa đổi. Chuyển id (11ab04b1 đó part) thành git show hoặc 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
...
Mát mẻ! Bạn có thể tìm hiểu thêm một chút về thay đổi, tại sao nó lại hữu ích và xem phần Hướng dẫn về đường ray về nó mà bạn có thể đã bỏ qua trước đây.
Ở đây, chúng tôi đã khá may mắn. Chúng tôi đã tìm thấy thông tin mà chúng tôi đang tìm kiếm ngay lập tức. Nhưng git blame chỉ hiển thị cho bạn gần đây nhất thời gian dòng đó đã thay đổi. Và đôi khi, bạn sẽ không tìm thấy những gì bạn đang tìm kiếm cho đến khi bạn quay lại hai hoặc ba lần cam kết.
Để xem các cam kết trước đó, bạn có thể gọi git blame lại. Nhưng lần này, hãy vượt qua bản sửa đổi trước đó cam kết git blame tìm thấy. (Trong git, bạn có thể nói "cam kết trước cam kết khác này" bằng cách đặt ^ sau khi sửa đổi, chẳng hạn như 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 ...
Tuy nhiên, điều đó khá là tê liệt.
Thay vào đó, hãy khám phá trình soạn thảo văn bản của bạn. Hầu hết các biên tập viên thực hiện theo dõi lịch sử bằng git blame dễ dàng. Ví dụ:trong Emacs, sau git blame -ing mã của bạn, đặt con trỏ của bạn trên một dòng. Sau đó, bạn có thể nhấn a để lùi lại từng thay đổi ảnh hưởng đến dòng đó và sử dụng l và D để xem thêm chi tiết về một cam kết.
Nhóm của bạn có đề cập đến số phát hành và yêu cầu kéo trong thông điệp cam kết của bạn không? Nếu vậy, git blame có thể dễ dàng đưa bạn từ một dòng mã, đến một cam kết, đến cuộc thảo luận về cam kết đó. Và cuộc thảo luận đó là nơi bạn sẽ tìm thấy tất cả những điều thực sự công cụ tốt.
Vấn đề trên Github
Cách đây ít lâu, tôi nhận thấy rằng Rails 4.2 đã xóa respond_with . Trong tài liệu, rõ ràng là nó đã bị xóa, nhưng tôi không hiểu tại sao.
Có rất nhiều kiến thức tuyệt vời ẩn sau hộp tìm kiếm sự cố của GitHub. Nếu bạn muốn biết lý do tại sao một đối tượng địa lý bị xóa, không có nơi nào tốt hơn để tìm hiểu ngoài cuộc thảo luận mà nhóm đã có trong khi họ quyết định xóa đối tượng địa lý đó.
Vì vậy, nếu bạn tìm kiếm trên repo GitHub của Rails cho respond_with , bạn sẽ tìm thấy một số chuỗi thú vị về respond_with . Nếu bạn đang cố gắng tìm hiểu lý do tại sao nó bị xóa, có thể bạn sẽ truy cập vào chuỗi này. Thật không may, nó mô tả như thế nào nó đã bị xóa, nhưng không phải tại sao .
Tuy nhiên, về sau trong chuỗi đó, bạn sẽ tìm thấy một nhận xét hướng đến cuộc thảo luận thực sự về việc xóa respond_with . Đó là nơi có những thứ tốt!
Như với git blame , bạn có thể không tìm thấy chính xác những gì bạn đang tìm kiếm ngay lập tức. Bạn sẽ phải theo dõi tài liệu tham khảo, đọc nhận xét và nhấp vào liên kết. Nhưng tìm kiếm vấn đề của GitHub sẽ giúp bạn bắt đầu đúng chỗ. Và với một chút tò mò và óc khám phá, bạn sẽ biết được mình đến để làm gì.
Đặt câu hỏi
Thật không may, không phải tất cả kiến thức về một dự án đều có thể được tìm thấy trong lịch sử, các vấn đề và các yêu cầu kéo của dự án. Không phải mọi thứ đều được viết ra.
Vì vậy, nếu bạn có thể tìm thấy người đã viết mã ban đầu, hãy hỏi về điều đó. Bạn sẽ khám phá văn hóa nhà phát triển và những ý tưởng dẫn đến quyết định. Bạn sẽ tìm hiểu một số lịch sử về dự án mà có thể chưa bao giờ được ghi lại. Và bạn sẽ nghe về những con đường chưa bao giờ được thực hiện, điều này thực sự có ý nghĩa để thử ngay bây giờ.
Cách dễ dàng có thể nguy hiểm
Đôi khi, việc sửa chữa có vẻ như rất dễ dàng . Tất cả những gì bạn phải làm là giải cứu một ngoại lệ này ở một nơi này, và sau đó bạn có thể về nhà!
Nhưng thật nguy hiểm nếu bạn không hiểu mã thay đổi.
Vì vậy, khi một dòng mã có vẻ không ổn, hoặc một quyết định có vẻ kỳ lạ hoặc một lời kêu gọi có vẻ vô ích, hãy ngả mũ trước nhà khảo cổ học của bạn. Tìm hiểu càng nhiều càng tốt về mã đó. Đó là cách bạn sẽ thực hiện thay đổi mã của mình một cách có chủ ý và khắc phục sự cố tận gốc.