コード考古学で簡単な修正を超えて

バグ修正を行う場合、迅速で明白な変更が常に最良の変更であるとは限りません。そして、目の前のコードがすべてではありません。簡単な修正を超えるには、理由を知る必要があります。 特定の決定がなされました。 コードの背後にある歴史を理解する必要があります。 そして、自信を持ってコードを変更するために知っておくべきことを学ぶための3つの優れた方法があります。

git blame

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 <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
...

涼しい！変更についてもう少し学び、なぜそれが役立つのかを学び、以前は見逃していたかもしれない変更についてのRailsガイドの一部を参照してください。

ここで、私たちはかなり幸運になりました。探していた情報がすぐに見つかりました。 しかしgit blame 最新のみが表示されます その行が変わった時間。 また、2、3回コミットするまで、探しているものが見つからない場合もあります。

以前のコミットを確認するには、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の後 -コードを作成し、カーソルを1行に置きます。次に、aを押すことができます その行に影響を与えた各変更をステップバックし、lを使用します およびD コミットの詳細を確認するには。

あなたのチームは、コミットメッセージで発行番号とプルリクエストを参照していますか？ その場合、git blame コード行からコミット、そのコミットに関するディスカッションに簡単に移動できます。 そして、その議論はあなたがすべての本当にを見つける場所です 良いもの。

Githubの問題

少し前に、Rails4.2がrespond_withを削除したことに気づきました。 。ドキュメントでは、削除されたことは明らかですが、理由がわかりませんでした。

GitHubの問題検索ボックスの背後にはたくさんの優れた知識が隠されています。 機能が削除された理由を知りたい場合は、チームがその機能を削除することを決定したときに話し合ったよりも、学ぶのに最適な場所はありません。

したがって、RailsのGitHubリポジトリでrespond_withを検索すると 、respond_withに関する興味深いスレッドがいくつかあります。 。削除された理由を調べようとしている場合は、おそらくこのスレッドにたどり着きます。残念ながら、方法について説明しています。 削除されましたが、理由 。

ただし、そのスレッドの後半で、respond_withの削除に関する実際の議論を示すコメントが見つかります。 。そこに良いものがあります！

git blameと同様 、探しているものがすぐに見つからない場合があります。 参考文献をフォローし、コメントを読み、リンクをクリックする必要があります。ただし、GitHubの問題検索を使用すると、適切な場所から始めることができます。そして、少しの好奇心と探求心で、あなたは自分が何のために来たのかを学ぶでしょう。