버그 수정을 할 때 빠르고 명백한 변경이 항상 최선의 것은 아닙니다. 그리고 당신 앞에 있는 코드는 결코 전체 이야기가 아닙니다. 쉬운 문제를 해결하려면 이유를 알아야 합니다. 특정 결정이 내려졌습니다. 코드 이면의 역사를 이해해야 합니다. 그리고 자신 있게 코드를 변경하기 위해 알아야 할 사항을 배울 수 있는 세 가지 훌륭한 방법이 있습니다.
자식 비난
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, 예), - 그 커밋의 작성자 이름,
- 변경된 날짜입니다.
해당 코드 줄에 대해 자세히 알아보려면 개정 번호가 필요합니다. 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 가이드의 일부를 볼 수 있습니다.
여기, 우리는 꽤 운이 좋았습니다. 우리는 우리가 찾던 정보를 즉시 찾았습니다. 하지만 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 뒤에 - 코드를 작성하려면 커서를 줄에 놓으십시오. 그런 다음 a를 누를 수 있습니다. 해당 줄에 영향을 준 각 변경 사항을 한 단계씩 뒤로 이동하고 l을 사용합니다. 및 D 커밋에 대한 자세한 내용을 보려면.
당신의 팀은 커밋 메시지에서 이슈 번호와 풀 리퀘스트를 참조합니까? 그렇다면 git blame 코드 줄에서 커밋으로, 해당 커밋에 대한 토론으로 쉽게 이동할 수 있습니다. 그리고 그 토론에서 모든 진짜 좋은 물건입니다.
Github 문제
조금 전에 Rails 4.2가 respond_with를 제거한 것을 확인했습니다. . 문서에서 삭제된 것이 분명하지만 이유를 이해하지 못했습니다.
GitHub의 문제 검색창 뒤에는 엄청난 지식이 숨겨져 있습니다. 기능이 제거된 이유를 알고 싶다면 해당 기능을 제거하기로 결정하는 동안 팀에서 논의한 것보다 더 배울 수 있는 곳은 없습니다.
따라서 respond_with에 대해 Rails의 GitHub 저장소를 검색하면 , respond_with에 대한 흥미로운 스레드를 찾을 수 있습니다. . 제거된 이유를 찾으려고 한다면 아마도 이 스레드에 도달하게 될 것입니다. 안타깝게도 어떻게 삭제되었지만 이유가 아님 .
나중에 해당 스레드에서 respond_with 제거에 대한 실제 토론을 가리키는 주석을 찾을 수 있습니다. . 좋은 물건이 바로 여기에 있습니다!
git blame과 마찬가지로 , 원하는 것을 바로 찾지 못할 수도 있습니다. 참조를 따르고, 댓글을 읽고, 링크를 클릭해야 합니다. 그러나 GitHub의 문제 검색을 통해 올바른 위치에서 시작할 수 있습니다. 그리고 약간의 호기심과 탐구심이 있으면 당신이 무엇을 위해 왔는지 알게 될 것입니다.
질문하기
불행히도 프로젝트에 대한 모든 지식이 이력, 문제 및 끌어오기 요청에서 찾을 수 있는 것은 아닙니다. 모든 것이 기록되어 있는 것은 아닙니다.
따라서 원래 코드를 작성한 사람을 찾을 수 있다면 그에 대해 물어보세요. 결정으로 이어진 개발자 문화와 아이디어를 발견하게 될 것입니다. 결코 기록되지 않았을 수도 있는 프로젝트에 대한 몇 가지 역사를 배우게 될 것입니다. 그리고 한 번도 가본 적이 없는 길에 대해 듣게 될 것입니다. 지금 시도하는 것이 합리적일 수 있습니다.
쉬운 길이 위험할 수 있음
때때로 수정이 너무 쉬워 . 이 한 곳에서 예외를 구하면 집에 갈 수 있습니다!
하지만 이해하지 못하는 코드를 변경하는 것은 위험합니다.
따라서 한 줄의 코드가 잘못되거나 결정이 이상해 보이거나 호출이 쓸모없어 보이면 고고학자의 모자를 쓰십시오. 그 코드에 대해 가능한 한 많이 배우십시오. 그렇게 하면 의도적으로 코드를 변경하고 문제의 근본 원인을 해결할 수 있습니다.